Killing IT Projects (Dead or Alive)

About 10 years ago I was the infrastructure manager for the Tokyo branch of global financial firm. I was involved with 2 projects that had gone wrong.

Project A was an initiative to pull some additional analysis and data from a well-known market data provider. The vendor was unresponsive, even though the project was as much in their interest as ours. The requirements were growing more complex by the day. Overnight the vendor rolled out some new code unannounced that broke our test system. The next day we pulled the plug.

Project B was an ERP system that was to be rolled out globally, to a bunch of independently-managed and funded IT departments. It contained no features or functionality that our users wanted. The global project “manager”, himself a last-minute transplant, announced a minor milestone the day it was due. I asked for a project plan and received an amorphous blob of unintelligible requirements. We tried to comply with their requests for a while, but none of our local users were helping us. I heard tales of the project well after I left.

Project B had too many issues to discuss. There are two I would like to mention here, in the context of both projects A and B. Both concepts are strait from the PRINCE2 method. Let’s start with RACI, an acronym for:

R = Responsible: one or more parties who carry out the work

A = Accountable: one party who is accountable for all activities

C = Consulted: zero or more parties (other than R or A) who may also be consulted on the task, or alternatively on the planning of the task in a process

I = Informed: zero or more parties who may be informed of the results of the task, or alternatively may be informed via reporting of the outputs of the process that performs that task

PRINCE2 is very clear on the accountable party, called the Project Sponsor. The Sponsor is one person (not group, not committee) who owns the Business Case, and who can allocate resources as necessary to achieve the Business Case.

The second concept is the Business Case. It is qualitative and quantitative descriptions of the benefits to be achieved by the project. It is a living, breathing document that is updated throughout the project, more specifically between each phase. Every phase contains a go/no-go decision based on the business case.

In my examples above, Project A had a clear sponsor who understood the business case (as far as I know the business case was never documented, but it may have been). When requirements escalated, and the relationship with the vendor’s project team soured, the sponsor pulled the plug. It was an easy decision, and none of the project participants were tainted. It wasn’t a particularly eventful day.

Project B had no individual sponsor. The sponsor was a committee with a broadly defined goal to improve transparency and accountability. There was no business case, for the organization as a whole or for the individual offices (the latter is a governance issue). The project died a long, slow death, but I am absolutely sure it died. Lacking a sponsor or business case, it should never have started in the first place.

Dying projects should be killed. No remorse. No finger-pointing. No false gestures of “accountability” only meant to take down political enemies (or cover up incompetence). Project requirements change, especially in IT projects. The external environment changes. These affect the business case. If the business case no longer warrants further expenditures, the project should be killed. There is no shame.

In fact I would reward the project sponsors who kill the most projects for lack of business case. If they save $200,000 in bungled projects, they deserve a $20,000 vacation package. On the company. Most IT departments would agree they deserve it.

Researching the Value of Project Management

On Tuesday I attended the monthly dinner meeting of Portland Chapter of the Project Management Institute, where Dr. Janice Thomas presented some results of her three year study that PMI will sell this year in a paper called Research on the Value of Project Management. The research team studied over 60 organizations over a year and a half in a variety of industries. They gained access to senior managers and detailed project records in order to corroborate interview statements with actual findings.

I initially skeptical of the research. Imagine this: research sponsored by the Project Management Institute finds that organizations always find value in Project Management. The research sponsor proclaims “I can definitively say that project management will bring value to companies”. However, the presentation by Dr. Janice Thomas showed she was very intelligent and thoughtful, and she was aware of the implicit biases.

Some interesting observations:

  1. Companies who focus on project management to control costs find a strong correlation with customer satisfaction, and that correlation is negative.
  2. No company in the sample could deliver ROI numbers for their project management programs. In other words, there was no ROI for calculating ROI.
  3. Companies who benefit from project management cannot simply make a one-time investment and then let it go. They must continually adjust, improve, and invest in the project management program for it to continue to succeed.

The full research paper will be available at PMI.org for $50 for non-members and $40 for members.