Managing IT Projects – Are the IT folks bludging?

By Dexter Duncan

A recent experience with a client got me thinking about metrics and benchmarking of IT projects. Whether you want to install a new Server, upgrade your Wide Area Network (WAN),  dive into some Business Improvements with custom software or improve your business with CRM or SharePoint (document management and intranet messaging), you need a reference to plan your budget and schedule.    If you have not had experience with similar projects, how do you know who to blame when the project is delayed or over budget?

Gartner releases key IT metrics each year drawing on thousands of IT performance benchmarks which enable clients to compare their spending and performance against best practice.

Only 57% of IT projects are completed on-time and only 67% are completed on budget?  Why?  Are the IT folks bludging?!

According to Gartners’ research the main reasons why projects are late or over budget are:

• Poor Initial Scope
• Resource Availability
• Scope Creep

Laziness is in the eye of the beholder.    If you are diligent on how you define project scope, ensure stakeholders and resources are available and identify scope creep, then you are covering the main risks involved in IT projects.   IT people do not usually sit on their hands, but if they are not focused in the right areas, then it is a form of laziness.

The first step, before a budget is finalised, is to define the project scope.    A few paragraphs would be the minimum for a simple project upgrade.    A few pages are needed if you are trying to do something custom.   If you are not sure what is possible, then you need to go through the idea with your IT provider.    For software development, a business analyst documents the requirements by talking to those close to the business.   They usually capture what a user screens should look like and the actions that are needed.  A good start is to document your existing processes.

As an example, let’s say you want to streamline how you manage leave and expenses.  The first step is to capture the existing paper based process.   Answering the following questions would help define the “scope”.  Who needs to sign-off leave requests and how do you treat rejections?   What level of expense requires manager only approval, etc.  Do you need to print a confirmation or is an e-mail sufficient?   Should leave balance automatically update or will it manually be entered in you HR system?     The more automation, approval levels and complex details you build into your requirements, the more costly it will become.

The second step is to ensure stakeholders and key resources are available throughout the project.   If they are not available, you project will most certainly be delayed.   And if the key resource and stakeholders are not clear on scope for budget, they will add to the scope creep.

One of the best ways to avoid scope creep, or adding features in the middle of the project, is to leave all requests for additional features til the end of the project.  Reworking estimates and getting approvals for more money always adds to budget and schedule.

If you and/or the people on your team do not have a clear idea of scope, are not available or are adding to the scope rather than working within initial boundaries, there is a good chance your project spend and schedule will blow-out.    If you have picked your IT folks well, they will be trustworthy and love to solve your business issues, but they are unable to approve scope or ensure your resources are available.

Call your local technology partner for more advice.

See our websites for more:

www.EmpowerIT.com.au

or

www.EmpowerCS.com.au

About the author: Dexter Duncan is a Division Manager at Empower IT Solutions. Contact Dexter at dd@EmpowerIT.com.au

 

Reference:

Gartner Group, Benchmark Analytics, “IT Key Metrics Data 2011: Key Application Measures: Project Measures: Current Year”, by Jamie K Guevara, Linda Hall, Eric Stegman.

Have you spent too much? (Project Quality and Monitoring)

By Dexter Duncan

You are the project manager and you just spent heaps of money for labour and materials that were unnecessary.   How did that happen?!

I am sure you have heard of GIGO?   GARBAGE IN = GARBAGE OUT

Part of a quality plan is to ensure all your assumptions and data you are using are correct, especially when it involves success criteria involving multiple stake holders.     In short, you have to ensure you do not have garbage information.       How do you do this?

In our simple example of building a bridge, our stake holders each identified the key success criteria:

1)  Council – identified safety as key criteria with related criteria being dimensions required such as height, width and length

2) Mayor – identified beauty as key criteria

3) Finance – identified budget and resources

We need to break key criteria down further.    For safety, we need to pass two cars going in each direction and have ability to pass ships through.     This information is critical and should be verified against your initial assumptions.    The best way to ensure you do not overspend is to get all our assumptions checked by the stakeholders.   This may involve getting them to sign off your initiation document or may involve a meeting to discuss details.   The earlier you do this the less money it will cost in terms of time and materials.

Often the easy way is always to get the stake holders to clearly define their requirements either in a scoping session, meeting or document.    The more clearly you define, the better.   You then can verify the cost of your labour and materials needed based on this information and share back with stakeholder for “approval”.        You should also plan to share your results along the way and allocate a change budget.       As long as stakeholders have approved the expected outcome, assumptions and other information, you can be more assured that your focus on detailed planning and delivery has a better chance to succeed!

Project Management: Initiating a Project (Part II)

By Dexter Duncan

The Empire State Building was successful in achieving its goal of being the tallest building in the world, building under budget and delivering on-time.     From an execution point of view, the architects and builders did well enough for the building to earn titles like “eighth wonder of the world” and “tallest building in world for 40 years”.

The "Empty State Building"

Many people do not know that the Empire State Building was a failure at the business level – in fact, it was nicknamed the “Empty State Building” for almost two decades.     They often made more from charging tourists to visit the observation deck than they made in rent.    One of the golden principles of real-estate is “location, location, location” and the building was erected in an area that left it 50% empty and unprofitable until they sold it in 1951.      Nobody wanted to go there, when the Chrysler building, which was completed less than 2 months before,  was fully occupied and in a more central location.   The reason it was not a success is likely related to how they defined the scope for the project.       They achieved quality, built in record time, were under budget and made their goal of being the tallest, but they did not think through the function of the building.   Being the largest office building in New York, this is a major oversight.

In Part I of this series, I gave a overview of Project Management based on PMBOK ideas.    This post dives into the pre-project, and initiation phase. Pre-project vs Initiation.  Prior to initiating a project, the question that needs to be answered is:

Why are we doing this?

The answer to this question is the purpose of the project.   The other important questions for pre-project include:

1. What organisational goals does this project support/achieve?
2. What are project dependencies and and context for the project (especially if there are other projects)?
3. What is the business case? – e.g. expected benefits, value, return of investment, alternatives
4. What are we going to do? (Scope)
5. Who has a vested interest in project being a success? (Stakeholders)
6. How will we know the project is successful?  (Success Criteria)

The above seven will be carried through and checked, updated and expanded on in subsequent phases. During the pre-project phase, the decision maker (“Executive”) can be appointed from the preliminary list of stakeholders.     A Project Manager  can also be selected prior to starting the project.

The initiation phase is where the project is set-up and defined.

In this initiation phase, we define who is involved and refine what we will do.    Later in the planning stage, we focus on how we will do it.

The key outputs of the initiation stage are to identify stakeholders (including the stakeholder management strategy) and developing a project charter (project definition document).      If an executive is not yet appointed, an appropriate person from the list of stakeholders should be made the decision maker. If you are lucky enough to already have team members available, you can start by reviewing all the stakeholders, scope, success factors together with them.

I suggest starting with a list of all the stakeholders or anyone with a vested interest in the project outcome.    The stakeholder can be the person paying (i.e. department head, sponsor or customer), senior management, other department/division leaders, suppliers or other outside parties.     Give each stakeholder a rating (i.e. high, med, low, etc.) according to their level of interest in the project and share their style/personality/manner and expectations based on your experience.

Managing Stakeholders

*Also try to identify if the stakeholder is a negative or positive for the project.  Those that want the project to succeed can be enlisted to help and those with a vested interest in the project failing should be treated cordially.   This is a balancing act for the project manager.   Sharing this with the team is usually best, but sometimes office politics require you to keep the negatives to yourself.

It is important to ensure all the stakeholders are in agreement on the project purpose, goals and success criteria early.     It is also important to define a communication strategy to give stakeholders updates on project according to the type of project and personalities involved.   Identifying Stakeholders and managing expectations early is a critical success factor. If there is a big risk that quality will not be met, timing will slip or features will be missing, this should be shared early.

Do not over promise and under deliver.    Leave yourself some buffers in terms of time and money, as there are often variables outside your control.   These unknown variables often start appearing in the planning stage and depend largely on the skill and experience of your team, but also on how well the project scope was documented. The project definition document should be done based on key stakeholder input. The one with the most vested interest is often the one paying (but not always).

Developing project definition document is critical before moving to planning. Some suggestions for the Project Definition document are to dust off, review and expand all the pre-project factors (identified above):

1. Define Purpose by answering “Why?”.   What business value is expected, what problems are being solved, what is the objective being supported, etc.   A priority level should be assigned to all if there are is list involved.

2. What are you going to accomplish?   What are the goals and objectives?

3. Clearly identify all the Success Criteria associated with above goals/objectives.   Identify measurable items such as quantity, quality, costs, time limitations or other unique business or support outcomes.

4.   Project Context and Dependencies.   Identify all the dependencies that could impact results or success of the project.     Identify other related projects and how/if they depend on your outcome.

5. Scope and out-of-scope.    Clearly identify all the parameters and boundaries for the project.   Include definitions, measurements, sketches or anything that helps define what you are doing.  The better you define the scope – what is included and what is not, the easier it will be for you to set expectations.

6.  Assumptions, constraints and risks.   Identify anything that you’ve been given to be true, especially if it comes from outside suppliers or other departments not part of the project.   Constraints are usually related to money, timing, resources, skills or technical limitations beyond your control.    Anything that is uncertain or could have a negative impact on all or part of the project is a risk.    All risks should be identified with their probable causes and probability of happening.    A planned response or action in the event of the “risk” occurring is called a risk mitigation strategy.

7. Stakeholders should be identified, along with their role, their decision making authority and information about the department or organisation they are part of.

8. Approach.   Discuss the approach to getting the work done and why the recommended approach is better than the other options.

9. Identify all the team members, their roles, skills, availability and weaknesses.

10. Plan the Quality, Identify how measurement and control will be done and decide how project will be approved.

After outlining the business case, designing a team, assessing the risks, planning the quality and approach, a decision needs to be made on whether the project is worth doing.   In other words, some

 projects may get terminated before reaching the planning stage once initiation stage is complete.

 

High Level Planning

Once you have the above definition document and approval to proceed, try a high level plan.      See above for the key elements in a plan and below for other more detail in planning an Event.    

Product Flow Diagram for an Event

 

List of Activities 

 

 

 

Gantt Chart Example

a

a

a

References

1. Some of the above example planning comes from Managing Successful Projects with Prince 2,  Published by TSO, 2005

http://www.leadge.com/renzheng/doc/prince2_2005_Version.PDF

Intro to Project Management (Part 1)

by Dexter Duncan

Whether you are deploying a project in the cloud or with bricks and mortar or developing a new product launch or scheduling a regular marketing event, you’ll need to use some project management tools.   This series is the result of a request to give a project management overview to 50 esteemed students, so here is a work in progress:

Firstly, let’s define a Project:

A temporary endeavour undertaken to create a unique product, service or result.

A project (different from routine work) has a defined beginning  and end.  The end is when objectives are achieved or project is terminated.      Temporary does not mean short duration nor does it imply that the result is short lived.   In fact, many projects are undertaken to create a lasting outcome.    For example – buildings, monuments or parks.

Here is a popular “successful” project from past:   Empire State Building

The Empire State Building held the record of the tallest building in the world for 40 years and it was started after another building, the Chrysler Building, was already in progress of becoming the world’s tallest.     The building and its construction is a legend of how crazy ideas can be achieved with a mix of bravado, competition, risk, networking and money.   In the age before computers and at the start of the Great Depression, this mammoth building was erected in just over 12 months.   From American Society of Civil Engineers:

The building’s framework rose at an astonishing rate of 4 ½ stories per week. During construction of the Empire State Building, its peak workforce amounted to 3,400 workers including 328 arch laborers, 290 bricklayers, 384 brick laborers, 225 carpenters, 107 derrick operators, 105 electricians, 249 elevator installers, 194 heating and ventilation installers, 192 plumbers, 285 steelworkers, a number of other specialists, plus clerks, foremen, inspectors, and water boys.

See the ASCE website for more facts.     We will use this example later when talking about project life cycles.

Secondly, project management is a system with standard definitions.   Perhaps the most well known is Project Management Institute (PMI) and their Project Management Body of Knowledge (PMBOK) which is representative of a global standard.    The importance of having common language and practices is the foundational science part.  There are around 40 micro processes that are defined.   The good product manager knows the art of when, where and how to apply them.   If you apply all the micro processes to each project, you are likely wasting time and money.

Project management is:

The application of knowledge, skills, tools and techniques to project activities to meet project requirements. (Source: PMBOK Guide)

Those that are interested can become full-time, certified project managers by passing exams and applying the craft.

Why PM?   The main outcome is to achieve results that are:

• Delivered on time
• Within the budget ($)
• High Confidence in Quality
• Meets Original Purpose
• Is a win/win for all stakeholders

Importance of Processes

• A good process should be written down, known & followed by all and have built-in reviews that result in constant improvement(s) (e.g. a feedback loop).

Here is one way to look at the big picture of the major components in project management:

Figure 1: How to manage a project - the process groups (Source: LDT consulting).

The five processes groups:

1. Initiation – Determines if project is worth doing.

The Initiation Process Group is where stakeholders are identified, goals and vision are set, business case is prepared and project is authorised by the sponsor.      The most important part of this is the business case which looks at whether the project is worth doing.     The scope is broadly defined giving parameters and boundaries for the project.

2. Planning (Design) – how work will be done, including how the deliverables and project will be developed and managed.

This stage is perhaps the most important since the scope of effort is established, boundaries are drawn, risks are estimated and methods of monitoring and control are defined based on the course of action taken.  A project needs to be broken into a group of the smallest possible deliverables (where possible) with clear definitions/descriptions, including responsibility, cost, dependencies and risks.   The process of subdividing deliverables into smaller tasks is called Work Breakdown Structure (WBS) which will be covered later.  Each activity is defined including resources, time durations, sequence (dependencies) into an activity list that is analysed and placed into a project schedule.    An estimated cost for each activity is developed and an overall budget is developed.   Another important feature of the planning process that is often missed is the communications plan.

3. Executing -

After all the planning, this is where the work gets done.    It is important to direct and manage the various teams, control quality and ensure good communication with team and stakeholders.    In some cases, the plan needs to be changed in order to meet quality, time or budget constraints.

4. Monitoring and Controlling -

Monitoring and Controlling processes are used throughout the initiation, planning and executing phases to ensure project objectives are met.    The overall control of scope, schedule, costs, quality, risks and a change process are part of this.

5. Closing -

One of the most important aspects of closing is to get acceptance from stakeholder(s).   This is usually done after going through a task check-list, documenting project results and making recommendations for future.

Other General Information: Project Teams, Sample Projects and Approaches.

For large projects, each of the above can have a dedicated team.    For smaller projects a single team can divide all the tasks to fit into process areas.

Sample Teams can be divided in a number of ways:

1. Project Manager, Expert Resources, Sponsor(s) & Stakeholders
2. Teams based around processes – Initiation team, Planning team, Execution team, Monitoring team & Closing team.
3. Phase based teams:  Different teams assigned according to outcomes in a multiple phase project.

Figure 1.2: Sample of process group interaction.

Sample projects

• An example single phase project.  Installation of a telecommunications network.
• An example of a multiphase project.   Cleaning up a hazardous waste site.
• Sample Mega projects - from $1.5 Billion to $40 Billion (from PMI)

Figure 2: Single and Multi phase projects (source: PMBOK Guide)

Deciding whether to use a single phase, multiple phase or layered multi-phase structure of a project can vary dramatically.    Some organisations have policies on which structure to use and some leave it to the project team.     The structure might be applied based on common industry practice or based on the project team.   In other words, a research study can be treated as pre-project work, the first phase of a project or as a stand-alone project.   Similarly, one project team might elect to apply a multi-phase approach and another team may use a single phase for an identical project.    An overlapping, multiphase project is sometimes called “fast-tracking”.

Figure 3: Cost and Staffing across Project Life cycle (Source: PMBOK Guide)

With 3400 labourers and the Empire State Building had a cost of around $USD41 million in 1932.   The Empire State Building was a multi-phase and overlapping project.

Occupying a plot of land approximately two acres (8,100 square meters) in size, the Empire State Building contains 70 miles (121 km) of water mains, 2.5 million feet (232,000 m) of electrical wiring, 1,060 miles (1,700 km) of telephone cables, 50 miles (129 km) of radiator pipe, and 73 elevators in 7 miles (18 km) of shafts.  (Source ASCE website.)

Article on how to prioritise projects from PMI:

Ideas on Success or Failure of projects:   Was Sydney Opera house a success?   Was Empire State Building a failure?     It depends on your perspective.  Have a look at this article on success and failure.

Part 2 will go into Initiating a project in more detail.

Importance of Risk Assessment (& Mitigation)

Part 3 in this series will go into Project Planning in more detail.

Importance of Planning

References:

1.Project Management Institute (PMI):

http://www.pmi.org

2. Project Management History and Overview:

http://www.ireference.ca/search/Project%20management/

3. Empire State Building Links

Construction Company.com  http://www.constructioncompany.com/historic-construction-projects/empire-state-building/

Wikipedia

http://en.wikipedia.org/wiki/Empire_State_Building