It all begins with a question: why? Chances are, many of the estimated 51pc of projects that fail weren’t able to answer it: the most basic requirement, a reason for being.
The statistic comes from a survey of 10,000 projects over a two-year period by the Standish Group in the US, which found that over half either are not on time or on budget — which by definition means they have failed. Of those, 15pc of projects are never used in the end — meaning zero benefit for the organisation concerned. In one year in the US, the total cost of this amounted to a massive US$55bn.
“That’s failure on a massive scale,” comments Sean McEvoy, a practising project manager, who spoke recently at an introduction to project management hosted by Trigraph in Dublin. “The risk of getting it wrong is significant in terms of money lost, people’s time wasted and business opportunities missed.” The tantalising question posed by McEvoy was to think of the amount that could be saved by changing that failure rate by a mere percentage point to just 14pc.
To achieve this, he argues, a project management methodology is vital. There are many to choose from and some are incredibly industry-specific, but two are emerging as de facto standards: Prince 2, which originated in the UK; and its US counterpart the Project Management Body of Knowledge (PMBOK). “The differences between Prince 2 and PMBOK are in definitions only – the end goal is the same,” claims McEvoy. “A methodology should never feel like a straitjacket; it should help. All methodologies have exactly the same approach: they break a big problem into small chunks.”
Prince 2 is short for Projects IN a Controlled Environment version 2 and all government departments and the National Health Service as well as other public bodies in the UK and leading private sector companies worldwide now use the methodology. The version 2 isn’t an afterthought: it’s because version 1 was “a dog”, as McEvoy acknowledges. “It was designed for large projects and was bureaucracy gone mad. It had been IT focused,” he explains. “Now, it’s totally scalable, whether the project in question is due to last for two weeks or two years.”
According to McEvoy, one of the key benefits to Prince 2 is a focus on business justification. “Hopefully, somebody in the past has asked the question: ‘why do we need it?’ and the answer should be: ‘the organisation has a problem and this product will fix it’,” he relates. “Where there was failure, some of those projects were not addressing the right problem. That’s the first question in any organisation: what project should we be doing?”
A successful project, to use McEvoy’s definition, is to deliver functionality to the customer to a quality specified within an agreed time frame and under budget. “It’s not simple but it is straightforward,” he outlines. “You deliver on those four elements and it’s a success. That’s your job as a project manager. To deliver them, you first have to define them and that’s where the real challenges are. That’s why you need a methodology.”
A Prince 2 project has four distinct phases: definition, planning, implementation and closure. At the first stage, before any budget has been allocated, the team prepares documents defining what the customer wants the project to do. The level of seniority required for approval obviously depends on the scale of the project. Prince 2 also includes a template to produce a project specification. “Because I have that, by definition I’m going to make fewer mistakes,” says McEvoy.
Prince 2 also has a focus on roles and responsibilities. In essence, there are three parties involved: the business interest, the user interest and the supplier interest. Those three elements have to work together if the project is to be successfully completed. The business asks: ‘do we need it?’; the user raises the question: ‘what do we need?’ and the supplier supplies resources to fix the problem.
In many ways, the difference between a small and a big project is the level of formality that’s applied, but there should be a methodology all the same — a standard set of steps and controls.
This applies to the highlight or status report, which is a key part of Prince 2. This involves the project manager calling the customer to keep them informed of progress. The frequency of contact will depend to a large extent on the complexity of the undertaking — it could be anything from a monthly briefing to a weekly 60-second phone call. “The level of formality matches what’s required for the level of project.”
The concept of project assurance also plays a critical role in Prince 2. By assigning signoff to different people, the organisation has some guarantees that what they’re being told is true about the progress of a particular project. As McEvoy wryly remarks: “Are you going to bet a €2m project on only one person telling you it’s going well?” Before the project supplier starts delivering anything, everyone knows who can sign off what on the project. Those clear lines of communication are important. “On a Prince 2 project, you know what everyone is doing from a management perspective,” he says.
The benefits of a methodology that’s used throughout an organisation is that a common terminology is used — which in turn reduces the possibility of ‘assumption killers’. Everybody starts speaking the same language.
McEvoy emphasises that the methodology allows a controlled start to a project. “We are not running into spending money without the right questions being asked,” he points out. The project delivery is then carefully managed in a series of stages, with regular reviews to take stock and check that the project is still delivering what is required. “The lights are set on red and need to be formally turned to green, like the signals at a railway crossing,” he says.
Though this might sound fine in theory, cynics could understandably point out that the scope of some projects often extends beyond their original allotted time frame. “If the user signs — preferably in his own blood — that the project needs two more weeks, then the goalposts are moved,” McEvoy quips. He stresses that the user or business group takes the responsibility for deciding to deliver that change and that Prince 2 has provisions for this. “It’s not a failure in that case; there’s total visible agreement that we are changing the one of the four success factors. The benefit of Prince 2 is that it forces you to clarify who’s running what.”
Summing up, McEvoy underlines exactly what to expect from Prince 2: it is not just another planning tool, nor a piece of software. It isn’t prescriptive, bureaucratic or inflexible. The latter is crucial because change can’t be prevented — it will happen, but having a methodology means that at least the change can be controlled and there’s a clear understanding of how it will affect the project plan, the end product or the quality expectations.
Prince 2 also won’t guarantee success, he warns, but it will help. “It will certainly reduce the probability of failure,” he adds.
Ironically, if any group or company finds itself asking if it has a problem and whether Prince 2 will solve it, it is already applying a Prince 2 principle to whether a project should be rolled out. So, the article ends as it began, with a question: what next for your organisation?
By Gordon Smith
