By Simon Beuhring
Have you ever worked on a project which lost sight of its goals? Or worse, worked on a project where the goals were never clearly defined?
If so, then join the club of projects which have been a waste of money.
Recipe for disaster
Too many times projects are started based upon loosely defined objectives. The most important stakeholder on a project – the sponsor – authorizes such projects and then sits back thinking their job is done. Project managers are then left with the job of delivering the project, often without further input from the sponsor. This is a recipe for disaster.
Business justification
A fundamental principle of project management is that a project must have continued business justification. Without it, you are guaranteed to waste both precious time and money.
This means that the sponsor must be involved from the very beginning in defining the reasons for doing the project. This means being clear about the business problem(s) you are facing, or the business opportunity which is presenting itself.
Business Case is the key
The most important of all project documentation is the Business Case. This document outlines the reasons for doing the project and the expected benefits which will result from the project. It should contain an investment appraisal where the costs and risks are weighed up against the expected benefits.
Deliverables help realise benefits
On all projects, the project will deliver one or more deliverables which will then be used by the organization in its daily work. The use of these deliverables will enable it to realize the expected benefits.
For example, an I.T. system might be introduced because it is expected to raise the efficiency of the staff. These efficiencies in turn will help realize benefits which might be measured in the form of cost savings. Therefore the Business Case must weigh up these costs and associated risks against the expected benefits. If the costs and risks outweigh the benefits then the project should never be initiated.
Business Case review
So, although a project can be started if a robust Business Case exists, it should also be stopped if circumstances change and the project no longer offers a worthwhile investment. For example, suppose the costs of the new I.T. system increase to such an extent that by continuing with the project the costs and risk are higher than the expected benefits. In this case the project should be stopped even though this might result in writing off the investment to date.
This is often preferable to continuing to throw bad money after good.
Involve your sponsor
So how do we ensure that the correct decision to close the project prematurely can be taken? The answer lies in involving the project sponsor on a regular basis so they can review the current Business Case and take appropriate decisions.
This in turn requires that the project manager updates the Business Case on a regular basis and presents the updated version to the sponsor for a decision.
Educate your sponsor
This often requires the project manager to educate the sponsor in some of his/her responsibilities. Whilst this in itself is often fraught with dangers, it’s always a better option than delivering a project only to subsequently find it had stopped being worthwhile some time previously.
Have you worked on a project which should have been prematurely closed? Please respond in the Comments and tell us about your projects.
Please subscribe to the RSS feed of Virtual Project Consulting not to miss future posts.
About the author: Simon Buehring is the founder and Managing Director of Knowledge Train which is a PRINCE2® accredited training organization based in the UK. PRINCE2® is a registered trade mark of the Cabinet Office.
Nice article! Great post about Closing a project prematurely – is it right?! Linky, What motivated you to call this blog “Closing a project prematurely – is it right?”, not that the title does not go with the content, I am just wondering. I appreciate you sharing this with the rest of us Linky.
I’m glad you liked the article. Actually Linky didn’t write the article – I did that, but Linky was kind enough to add it to her blog. The idea for the post was because in my experience it’s often assumed that premature closure of a project is a sign of failure, whereas what I was trying to say in the article was that it is often better to close prematurely rather than battling on with the project regardless.