Project Management - Reasons Why Projects Fail

There are many reasons why projects fail. They run over time and over budget and often don't deliver the business benefits promised. Good project management techniques build in regular assessments of strategic viability as part of the project plan. Halting a project that is no longer strategically viable due to changing external factors is not a project failure. Allowing the project to run in these circumstances is a failure. Project failures are almost entirely due to internal factors that can be controlled by the business.

Failing to plan properly

Projects are often started to solve a problem. Someone has a great idea and rather than analyzing the problem and finding the appropriate solution they jump straight into implementing the first solution that comes to mind. There is always more than one solution to a problem and the first is not necessarily the right solution for the business. Lots of activity in and of itself will not necessarily mean that the problem will be solved. Up to eighty percent of the effort in successful projects is in the planning. If a project is that urgent it demands that high energy and enthusiasm is invested in the planning.

Failing to do anything

This is the opposite of failing to plan. Analysis can create a momentum all its own. Investigation needs to be done but only enough to have confidence in the next step. This hesitation can appear not only at the project kick off but also as each gate is approached. Stakeholders who are not fully committed to the project can cause delays by insisting on more analysis before decisions are made. To overcome this specific deliverables for each gate should be established and agreed during the planning stage.

Ignoring the risks In projects that fail risks are often identified but not monitored or managed. Risks do not disappear by themselves. All assumptions that are made when setting the project plan are risks and they should be tested and mitigation plans put in place to minimise the impact if the assumption turns out to be incorrect.

Functional thinking When projects cross functional lines cooperation is required to keep the project on track. Individual and team rewards and bonuses are often based on functional objectives being met and project involvement can be seen as inhibiting action on these base objectives. As a result cooperation with the project team takes a low priority in functional activities. The solution to this problem is to directly link performance objectives, rewards and bonuses to project outcomes. Changing sponsors The sponsor is the power behind the project. If sponsors keep changing there must be some doubt whether the project is really required. Different sponsors will have their own personal focus. Even minor differences can cause the project to waiver on its course. Without a sponsor willing to take accountability for the strategic benefits to be delivered there should be no project. When the project manager spends as much time bringing new sponsors up to date and adjusting the plan for new direction as they do running the project it is time to propose killing the project. If the project is considered to be important enough someone at the executive level will step forward and take responsibility. Many common reasons for project failure can be prevented by careful planning and clear approval processes. If however the project does run over time, over budget or does not

deliver the promised benefits a post implementation review can provide information that can be used to improve project performance in the future.

whiteboard

How To Kill A Troubled Project

N O
Start with a troubled project.

N O Y E S
Unique project?

N O Y E S
Fit with business strategy?

N O Y E S
Technologically viable?

N O Y E S
Right sponsor?

N O Y E S
Customer buy-in?

Y E S

Approved project?

Y E S

Define vital signs, set threshold levels.

The CIO should look for signals such as missed deadlines, increased budgets and dissatisfaction in the ranks. After identifying a troubled project, the CIO should, with the help of the project manager, seek answers to questions in the following six gray boxes.

Was the project approved by an authorized person? If the person who approved the project is no longer with the organization, make sure the current sponsor is fully committed to the project.

Is this the only project of this kind underway? Is there no project that duplicates this one?

Does the project fit with the currently stated business strategy?

Is the enabling technology available and reliable? Can it be supported by the IT organization? Will users adapt it properly?

Does the sponsor understand the projects complexity? Is he or she committed to the project? Does the sponsor have the authority to shut down the project?

Are the projects internal customers satisfied with the project?

Vital Signs Report Card

The best way to track a projects health is by measuring its vital signs. In this report card, most signs are measured by the variance between the projects current status and the plan. It also uses a point system: The greater the variance or potential problem, the more points it is assigned. After the project manager measures the vital signs, he or she can assign statushealthy, caution or dangerand a course of action. At this step, the sponsor and project manager select the appropriate vital signs and, depending on the projects complexity, decide how many points to assign and what threshold levels to set for the caution or danger stage. The vital signs and numbers listed here are frequently used by companies that have adopted this methodology.

Vital Signs
Project Schedule: actual vs. plan % difference in days Milestones: actual vs. plan % goals completed on time Deliverables: actual vs. plan % goals achieved Unresolved Issues 1 # issues vs. deliverables to be completed Cost to Date: actual vs. estimated % over or under budget
3

Variance
< 10% 10% to 20% > 20% < 10% 10% to 20% >20% < 10% 10% to 20% > 20% No Issues2 < Deliverables > Deliverables < 10% 10% to 20% > 20% < 10% 10% to 15% > 15% 1-3 Risks 4-5 Risks 6-7 Risks

Points
0 1 2 0 1 2 0 2 4 0 1 2 0 1 2 0 2 4 1 3 5

Healthy (1-5 points)

The projects performance is on track; the variances are within acceptable limits.

Caution (6-10 points)

The projects performance has deteriorated beyond the project managers ability to improve it. It is now at risk of becoming a runaway project. If the steering committee wants the project to be completed, the project sponsor needs to take charge of the situation and devise a plan to fix the problem(s).

Danger (11+ points)

The project has reached runaway project status; not even the projects sponsors can fix it or get it back on track. At this point, the project steering committee needs to take a serious look at the projects viability, and either shut down or save the project.
1 Issues are unanswered questions and differences of opinion. 2 It is seldom that a project has no outstanding issues. Therefore, make sure when the value here is 0, that there are really no outstanding issues. The 0 value could be a sign that issues are not being tracked. 3 In case of fixed-price contracts, change the variances to < 5%, 5% to 10%, and >10%.

gopal k. kapur is the president and founder of the Center for Project Management in San Ramon, Calif. (www.center4pm.com).
How To Kill A Troubled Project concept 2001 Center for Project Management

Resources: actual vs. planned % difference in staff, equipment, etc. High Probability, High Impact Risk Events e.g., technology failure, loss of sponsor, key personnel

Information Design: Jessica Helfand | William Drenttel

Consult with legal department.

Consult with HR department.

If the project to be cancelled involves vendors or contractors, the sponsor needs to review the cancellation plan with the legal department.

Because a cancelled project means reassigning team members, the sponsor ought to consult the HR department to make sure any career-related issues are addressed properly.

Assess vital signs.

Send assessment to steering committee.

Vital signs within limits?

N O

Kill the project?

Y E S

Develop project cancellation plan.

Tell key stakeholders privately.

Announce the project has been cancelled.

Now that the vital signs are defined and the threshold levels are set, its time for an assessment. To ensure accuracy and completeness, the CIO should verify the vital signs.

The steering committee should be made up of crossfunctional executives. For major strategic projects, these should be department heads reporting to the CEO.

Y E S
If the vital sign variances are acceptable, the project can continue as planned. However, if the variances breach either threshold level, the steering committee needs to decide the fate of the project.

N O
The steering committee now decides the fate of the project. In one commonly used method, each steering group member casts a vote with a value of between 1 (low priority) and 5 (high priority). Usually, only projects averaging 4 or more are deemed worth saving.

The sponsor and the project manager develop a welldefined plan, with specific responsibilities, to carry out the project cancellation process. This is to ensure that damage to the end customer, the key stakeholders and the project team is minimized.

The sponsor should call or personally meet with key stakeholders to set out the reasons for the cancellation before announcing the decision publicly.

The sponsor should be available to take questions from employees and vendors as well as key stakeholders. Executives should not assign blame to individuals or teams; if they do, staff morale and willingness to honestly assess future projects will suffer.

Continue the project.

Develop a recovery plan.

Re-assign project team members.

Glean lessons from the project.

Salvage usable project components.

The steering committee should evaluate the projects vital signs every two weeks, and more frequently if it breached the Caution or Danger threshold.

The sponsor and the project manager outline the steps needed to bring the projects vital signs back to acceptable levels, and devise a plan for tracking the projects recovery. The plan should include getting proper authorization, an appropriate sponsor, and buy-in from customers if these factors had not been agreed upon earlier.

Members should be assigned to other project teams or given new responsibilities.

The project manager should interview team members (including customers) and review the projects history, then draft a set of lessons learned to share with managers and staff.

In any project, there are always certain components such as requirements, design, code, test datathat can be salvaged for use in other projects. The project manager should develop and implement a plan to salvage any/all such components.