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.