In 2013, the APM published a bold vision statement for the profession, that by 2020 we will be in “A World in Which All Projects Succeed”. If nothing else, it has generated controversy and discussion, since we all know of studies showing that 40% of all projects fail (or 50%, 60%, or 70%… you can pretty much pick your own statistic).
The trouble with these studies of project failure – and the beauty of the APM vision – is that it all depends what you mean by “success”. In order to deliver successful projects, we need to know what success looks like. The usual answer is that a project is successful if it meets its triple-constraint of time, cost and quality. But I disagree, as we can surely all think of successful projects that were a bit late, overspent, and/or excluded some scope. Similarly there are projects that met their constraints but were deemed to be failures because they delivered an unwanted white elephant.
At a simplistic level, a project is successful if the project owner says it is (or “sponsor” depending on your preferred terminology). Actually this is quite a useful definition, as it leads the project manager to focus strongly on stakeholder management. Playing under these rules, under extreme circumstances it is possible for a project to be cancelled (e.g. if unforeseen circumstances make the project uneconomic) and for the project owner to be happy with the outcome. So the project would be judged a success, even though nothing was delivered. If for the right reasons, then I think that is a good outcome, and in line with APM’s desire for all projects to succeed.
On the other hand, it does rather assume that the project owner will behave consistently and rationally – and we all know that doesn’t always happen. The owner might be unhappy with the outcome for irrational reasons entirely outside the PM’s control, and it would be a shame to count such a project as a failure.
So what we need is a way to define and measure project success that is impartial and measurable, yet takes into account the stakeholder wishes. The solution is to be found in the definition and application of project success criteria. I think the three steps to project success are as follows:
- Define your project success criteria at the outset, during project initiation.
- Track and report against project success criteria during project execution.
- Measure against the project success criteria at project closure.
Let’s look at each of these in more detail.
Defining Project Success Criteria
This is where the well-known “SMART” acronym comes into play: project success criteria should be Specific, Measurable, Achievable, Relevant and Time-bound. Achievable and relevant both imply that the criteria need to be within the scope that the project manager is delivering; they should not be business objectives that sit outside the project. So, for example, “launch in time for the Christmas marketing campaign” is a valid criterion. But “achieve a 20% improvement in customer satisfaction” is probably not.
These success criteria are likely to include the traditional measures of time, cost and scope. And they might include multiple measures, such as “launch in two countries by August; launch in a further three countries by October”. Also, it is very useful to define “ideal” and “minimum” criteria – so the previous example might become “launch in a minimum of one country by August, and ideally in five countries by October”.
The success criteria need to be agreed with the project owner, and whatever governance sits above the project, for example a steering board. This MUST happen before the project moves from initiation into execution – bitter experience shows that it is too late afterwards!
Tracking Project Success Criteria
During project execution, the status against the project success criteria should be a routine part of the project manager’s status reporting – be that in the form of a dashboard, weekly progress report, or steering board slides. Each criterion can be assigned a RAG status, with the following interpretation:
- Green: on track to succeed.
- Amber: at risk. Corrective actions (including escalations) should be identified.
- Red: not on track to succeed.
The red situation is an interesting one. How many times have we seen projects struggle on, despite the PM clearly stating that the project is doomed? In fact, there are only three options available in this situation:
- Do something to get it back on track – now. It isn’t going to be a trivial action, or the PM would already have thought of it. It is more likely to be some form of escalation that was beyond the PM’s immediate control.
- Rescope, which means revising the success criteria.
- Stop the project! If the minimum success criteria are not going to be met, then why continue? Of course this is a drastic step that few steering boards have the courage to take – but in this situation how can it possibly not be the right thing to do? Stopping the project at the right time and for the right reasons should be considered as a project success.
Rescoping implies that project success criteria are not necessarily locked down for the duration of the project. In fact, under proper change control, it is perfectly reasonable to renegotiate success criteria at any point. Things change, stuff happens, and projects need to be able to adapt accordingly.
Measuring Project Success
At the conclusion of the project, it now becomes almost trivial to measure success. Simply: were the success criteria met? If everything I have described has been applied with rigour, it is hard to think of a circumstance in which the answer will be “no”.
So… all projects can indeed succeed!