« What Can Project Managers Learn from the Movies?
Agile Software Development - Road Trip Analogy »

When Do You Kill A Project?

February 25, 2010 | Author: PM Hut | Filed under: Performance Reporting, Project Management Best Practices

When Do You Kill A Project?
By Samuel Prasad

The project is behind schedule. The scope and objectives are not clearly defined. There are no interim verifiable milestones to monitor progress. The project plan changes on a daily basis. The project manager has no information on what the team members are working on at any given time. Resource planning was omitted. In fact, the planning phase was skipped because it was considered a waste of time and everyone knows it is only for wimps. The team knows that the project is on its deathbed. Most people in the company know that the project is in trouble except management. Sounds familiar?

As a project manager what do you do?

First, admit that there are serious problems that need to be fixed. Do a root cause analysis and identify the sources of failures. Draft a few options on how to get the project out of the “intensive care unit”. Present the facts to management without playing the blame game. Propose options with recommendations to get the project back on track.

But, as a project manager or as business stakeholder how does one determine whether to bring the project back to life or just kill it? Answering this question is not that hard.

  • The project is over budget and behind schedule. It will not meet the market demands and/or customer requirements in a timely manner.
  • Support of key business stakeholders is dwindling.
  • The project had poor or no planning and inadequate risk assessment.
  • Quality assurance standards were not considered important and quality control procedures were continually diluted or completely absent.
  • The project was not staffed with resources with the proper domain knowledge and technical skills.
  • The project was poorly monitored. Key performance indicators (KPIs) and interim deliverables were not defined to monitor the project.

If your project suffers from one or more of the above conditions it has reached a point where its viability must be seriously examined and while it is not an easy decision to kill any project it may be the right decision in this case.

A scorecard is a good way to keep tabs on the health of a project. The first step is to define what goes on the scorecard. In other words, you need to define the key performance indicators (KPIs) or the vital signs that must be monitored against a project baseline. The extent of the variance of the KPIs from the planned baseline is used to decide the next steps of the project.

The KPIs listed below are frequently used by many companies and successful project managers.

  • Project Schedule – actual vs. plan: % difference in days
    • < 10 % add 0 point
    • 10% to 20% add 1 point
    • 20 % add 2 points

  • Milestones – actual vs. plan: % goals completed on time

    • < 10 % add 0 point
    • 10% to 20% add 1 point
    • 20 % add 2 points

  • Deliverables – actual vs. plan: % goals achieved

    • < 10 % add 0 point
    • 10% to 20% add 2 points
    • 20 % add 4 points

  • Unresolved Issues – number of issues vs. deliverables to be completed

    • No issues add 0 point
    • < deliverables add 1 point
    • > deliverables add 2 points

  • Cost to Date – actual vs. estimated: % over or under budget

    • < 10 % add 0 point
    • 10% to 20% add 1 point
    • 20 % add 2 points

  • Resources – actual vs. planned: % difference in staff, equipment, etc.

    • < 10 % add 0 point
    • 10% to 20% add 2 points
    • 20 % add 4 points

  • High risk events – technology failure, loss of sponsor, key personnel, etc.

    • 1-3 Risks add 1 point
    • 4-5 Risks 3 points
    • 6-7 Risks add 5 points

The project diagnosis is as follows:

  • Healthy (1-5 points): Kudos to the project manager and the team members. The project is on track.

  • Caution (6-10 points): The project manager has lost control of the project. If the business stakeholders want the project to be completed, they need to take over the project and formulate a plan of action.

  • Danger (11+ points): The project has spiraled out of control. It is highly recommended that the business stakeholders shut down the project.

Dr. Samuel Prasad is a renowned global technology manager with a 15-year track record in helping companies on their implementation of strategic plans and programs related to technology projects for major media, entertainment, data warehousing and financial companies in the U.S., China, Europe and India. His domain expertise extends into areas of financial transaction processing, mobile, wireless, RFID, online media, casual gaming and business intelligence. Sam is a certified Project Management Professional (PMP) and a Certified Software Quality Engineer (CSQE). Sam has a Ph.D. in Robotics & Computer Science from the Stevens Institute of Technology (USA), and a master’s degree in Computer Science from the Indian Institute of Technology. Dr. Prasad can be reached at Intelligent Software Systems. Blog: http://blog.prasads.com/ - Email: blog@prasads.com - Telephone: 631-368-8130

Share this article:
  • Digg
  • del.icio.us
  • Facebook
  • Google
  • blogmarks
  • LinkedIn
  • Reddit
  • StumbleUpon
  • TwitThis
  • Yahoo! Buzz

This entry was posted on Thursday, February 25th, 2010 and is filed under Performance Reporting, Project Management Best Practices. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

6 people have left comments

Good article. I agree, it’s never easy to kill a project. It’s usually the customer who pulls the plug because the delivery team usually tries to go down with the ship. But either way it does happen and it’s usually justified.

Though I’m a little confused on the ‘unresolved issues vs. deliverables’ one, I like your scorecard method. Nice way to make it somewhat quantifiable. Again, thanks for the article…nice read.

——–
Brad Egeland
IT/Project Management Consultant
email: brad@bradegeland.com
website: http://www.bradegeland.com
Project Mgmt articles: http://www.pmtips.net/author/brad/

Brad Egeland wrote on February 25, 2010 - 9:07 pm | Visit Link

The scorecard looks good. Defined parameters defintely help you make the decision.

The intangibles, however, are much harder to define. Different stakeholders may have conflicting interests. Sales may be relying on the project to hit their goals. Others may have similar reasons for wanting to prolong the project, which have nothing to do with the project’s purpose or its likelihood of success.

How do we measure the human or political risk in the project? How does the organization deal with failed projects, for example? Does it learn lessons or fire project team members? What effect do factors like these play?

Nicholas Hawtin wrote on February 26, 2010 - 3:03 am | Visit Link

Using the KPIs in project management is not a good idea.

In practice, overseeing KPIs can prove expensive or difficult for organizations. Some such as staff morale may be impossible to quantify.

Another serious issue in practice is that once a KPI is created, it becomes difficult to adjust to changing needs as historical comparisons will be lost. Conversely a dubious KPI is often created because history does exist.

Furthermore if a KPI is based only on in-house practices it may be difficult for an organization to compare with similar organisations yet often, business with a similar background are used as a benchmark for KPIs.

Analyst must be aware that a KPI may be a rough guide rather than a precise benchmark.

Atallah chamieh wrote on February 26, 2010 - 9:44 pm | Visit Link

Great article. I believe that projects should have more rigorous measurement. Techniques like earned value analysis are also useful and more time spent on demand, benefit and revenue forecasting and baseline measurement up front would enable projects to have a better chance of success

Dave Rochford wrote on February 27, 2010 - 8:13 am | Visit Link

My experience with KPIs are quite different than the opinion expressed by Atallah Chamieh. By definition, KPI is a measurable and quantifiable factor that is agreed to beforehand by the team and stakeholders to help measure critical success factors in a project. However, I agree with Atallah that selecting the right KPI is important. One size does not fit all. KPIs once selected are not cast in stone. Based on lessons learned at the end of a project KPIs are modified so that they are able to better measure success factors in future projects.

Samuel Prasad wrote on March 1, 2010 - 9:28 pm | Visit Link

Nicholas Hatwin makes an interesting point about human and political risks. They are usually not discussed in too much detail when we talk about risk management in projects. The reasons are that they are not easily qualifiable nor quantifiable. It involves understanding and identifying the behavior of team members in individual and group settings. It is also dependent on the country and its culture - political and social. It is no surprise that many “offshore” projects fail because the company fails to understand the local culture of the country and the team.

Samuel Prasad wrote on March 1, 2010 - 9:48 pm | Visit Link

feel free to leave a comment

Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

All fields marked with " * " are required.

Project Management Categories