Do your major projects have a structure similar to the model sketched below? That is, several stages (perhaps each of several or more months), separated by some kind of review meeting. If so, you are probably following a conventional ‘waterfall-style’ project management approach.
Conventional ‘Waterfall’ Project Structure ModelÂ
PRINCE2® projects are usually structured structured in this way. The conventional structure of projects typically starts with an initiation stage – and that’s not quite the statement of the blindingly obvious it may seem!
A proposal for a project is reviewed formally, or informally. Approval is given for the proposed approach and for the allocation of funding, resources or whatever else is needed. The formality or informality of this and the subsequent stages will of course vary enormously depending upon the scale of the project, the size of the foreseen costs, the management norms of the organisation and so on.
The initiation and approval stages are followed by a series of project stages. Typically, the stages are defined in a sequence such as Requirements Analysis, Design, Build/ Construction, Test, Implementation or Deployment, and project closure. In actuality, the neatly defined stages may well meld into each other – which will injure the manageability of the project. There are good reasons for why the ‘melding’ happens, which we’ll discuss elsewhere.
In the case of PRINCE2, ongoing maintenance or support of what has been implemented is outside the scope of the project. Depending on the methodology, there may then be the ‘retirement’ stage in which whatever has been implemented is deemed no longer serving its purpose in some way, and is decommissioned.
Let’s take a look at why the failure rate for projects following this approach is so dismally high…
Gateways
There may be formal reviews or ‘gateways’ between the stages. The intention is that the completeness of each stage is reviewed by senior stakeholders – folk with an interest in the outcome of the project. The idea is that their approval is needed before further funding and other resources are consumed in the next stages.
In theory, there are several further options available to the reviewers. Those options include; directing that rework is done to achieve the expected requirements of the current stage, redirect the project in some other way (such as change its objectives) or decide the project is not viable and declare its termination.
Unfortunately, the ‘Best Practice’ project structure means that the information generated by the process for discussion in Gateway reviews, has little relevance to the real-world operational or commercial interests of senior stakeholders.
Along with progress against the project plan time scales and budget, Gateway reviews are intended to assess the ‘products’ (generally, documentation deliverables) which are prescribed by the project method to be delivered at the end of each stage. Reviews ask: have products been produced, and to the required quality?
The unfortunate significance is that what is assessed in a gateway review has little connection with whether or not the project will make a useful business contribution in the real world. Gateway reviews are denied that information.
That’s because the project structure – shown in the sketch above, doesn’t put anything into operation in the real world until the final ‘implementation’ stage. The first real-world information feedback or measurement on whether the project has done something useful or not, comes at/after the end of the project. Obviously, that’s too late to provide useful guidance to the project. The money, time and resources have already been consumed.
Hence, Gateway reviews provide little value beyond administrative purposes. Which in turn, leads to the traditional difficulties of getting senior stakeholders either to prioritise the meetings as important – or to attend.
The Problems with Conventional Project Structure Models
Many organisations will have experienced serious problems in delivering useful outcomes and results when using this kind of conventional project management method.
Our discussion here refers primarily to the use of those conventional methods in projects concerned with moving an organisation forward in some way. That is projects such as: business change management; business performance improvement; organisational and business process design/redesign; IT systems implementation and systems development.
These are the kind of complex projects we characterise as essentially learning-processes.
They are ‘learning processes’ because – however confident the sponsors may be in the success of the outcomes, the reality is that the oft-reported failure of 60 to 80% of these types of projects, speaks to the difficulties of predicting exactly how a significant sized project will fare when it encounters the true complexities of a real-life organisation.
To borrow from Field Marshall von Moltke, “no battle plan survives contact with the enemy“.
The Focus is on Tasks – it shouldn’t be
The emphasis in conventional project methods is on tasks, activities and products. Many of those tasks will be concerned with generating documentation deliverables known as ‘products’. PRINCE2 is a product-planning process. Progress tends to be measured in terms of completed products, completed tasks or review stages passed. In effect, conventional project structures place the emphasis upon ‘doing stuff’ or ‘busy-ness’. Although many people in organisations will feel that their job security depends upon looking busy – and their perception is probably accurate, we argue that this emphasis on ‘doing stuff’, on tasks, is misplaced.
Focus on Improvement Results
In our view, the emphasis should more valuably be placed upon delivering useful, practical, improvement results which directly contribute to the achievement of the real objectives of the organisation. Few would argue with that. Many would agree with it, and then go straight back to structuring their projects in the conventional way. They do that because of a mistaken belief that the conventional methods share their aim of achieving results. They don’t.
The aim of conventional methods is simply to follow a defined process in order to deliver a product or ‘solution’ of some kind; that’s distinctly different from the improved performance, efficiencies, compliance or reduced risk exposure wanted by the organisation.
‘Best Practice’ may not be Best
Those shortcomings mean that for many organisations wishing to achieve earlier practical results, at lower cost, reduced risk, with strong stakeholder engagement and in shorter time scales, PRINCE2 will not be an appropriate choice.
Our analysis shows that conventional ‘Best Practice’ project management methods – such as PRINCE2, will generally increase project costs and lead to lengthy phases (each of many months) during which costs accrue and resources are consumed, without benefit to the wider organisation.
Lengthy project phases also means that it is difficult to incorporate changes to requirements, which in turn increases the risk of project failure.
The probability that requirements will change in the real world, is of course, increased when project phases each extend over many months.
‘Freezing Requirements’ – increases Project Risk
If projects are not truly capable of anticipating the emergence of changes to requirements and instead, for example, try to bring stability by postponing changes or freezing requirements, then ironically, the risks of project failure further increase because projects are not meeting the real needs as they continue to emerge in the real world.
If you find that projects are not delivering the results you want, or you suspect they are taking longer than necessary and costing more than needed… the good news is that there are better approaches available.
From Tasks & ‘Busy-ness’ – to Business Improvement
There are alternative approaches which enable business improvement and system projects to be delivered faster, at lower cost, to higher quality, with reduced risk. If you would like to see faster progress with business improvement activities and projects in your own organisation, the simple points outlined in this site may give you some ideas. Alternatively, get in touch and we can take you through how the alternative approaches can be applied to your advantage, to your existing projects.
In response to various requests, we will be publishing our detailed analysis of the shortcomings of the conventional structured project management methods (such as PRINCE2) on this site in the near future.
But if you are already locked into the kind of project management methodology we’ve discussed here, your wisest priorities may be to…
- preserve the appearance of practicing the established methods
- understand and work around their underlying flaws
- quietly incorporate some of the alternative approaches into your projects. You can then begin demonstrating the value of early delivery of practical, commercially/operationally useful business results (and be forgiven for a lower emphasis on compliance with a prescribed project management process!)
And Finally…
Whilst we do not contend that all project problems can be laid at the door of these kind of methodologies, we do contend that it is time to question the faith placed in them, and to acknowledge that there are serious underlying, structural problems to PRINCE2 and related methodologies.
Your views would be very welcome. Please do express your mild agreement, denouncement as arrant nonsense or wherever your views take you, as a comment below.
PRINCE2® is a registered trade mark of AXELOS Limited. All rights reserved.
Copyright © Business Transition Technologies Ltd 2012. All Rights Reserved.
The new Project Delivery Scienceâ„¢ addresses the iesuss above; tightly linking strategy and projects/programs, building the necessary governance, portfolio and program skills within the requisite processes.Our research over the past 20 decades, conducted on real projects not articles, has found that the processes currently in use by most organisations destroy more value than they deliver. They are just not value delivery focused.We cannot blame the project managers as the organisations themselves need to take the lead and manage their portfolios, programs and projects effectively to directly implement strategy. But Prince2, MSP, PMBOK and other methodologies do not deal with these aspects and leave huge gaps in the processes that allow the available value to fall through.The new Science, to be launched in September 2009, addresses these concerns and, for the first time, fully equips all levels of the organization, up to and including the Board, to perform their roles effectively, knowing what to do, when and why.Using the new Science we have consistently doubled the realised returns from projects. Now that’s a start!
The writer shows an astonishing lack of knowledge and understanding of PRINCE2. He objects to Waterfall and its – what PRINCE2 would call – technical stages. He does not know and understand PRINCE2 objects to that as well and only talks about Management Stages, based on risk and on products. Not focused on work as the writer also wrongly suggests.
This was all clearly described on Principles. See: http://www.viergever.info/en/prince2principle.aspx
I totally agree with the observations in this story. I am a PMP and I feel that the volume of documents proposed in pmbok is really quite overkill for most projects. Especially when the organisation has a project office with a standard way of doing projects.
For instance, is there a need for a communications plan, to detail how and when meetings will be held, who chairs each meeting, how minutes will be circulated etc? Is there a need to have a stakeholder management plan that discusses who is more powerful than which stakeholder and how we will ‘manage’ them? Would you even want to put down these things in writing? Is there a need for a quality management plan, to say that periodic inspections will be done, acceptance of deliverables will be by review and signature, how long recipients have to provide signoff, and that tests will be carried out against deliverables to ensure they meet requirements? Is there a need to document in the project plan the roles and responsibilities of the steering committee, the pm, the business analyst etc, when in a project organisation, there would be project management standards documents which would specify these in general for the company as a whole?
Like the author, I believe too much emphasis is given to paperwork and not enough to the real work of project management. The things we want a PM to really do, such as anticipating land mines and helping the project to avoid trouble; managing stakeholders and helping them to make difficult decisions; finding ways and means to save costs and improve delivery schedules, etc– these seem to be less emphasised than getting signoffs on documents whose contents honestly do not vary from project to project and which honestly no one bothers to read after signing.
In my previous organisation, PM’s were not only told to deliver perfect documentation, but also to make impossible things happen. The chair of the steering committee wants more scope– the pm is just to find a way to do it without cost or time impact. The chair wants to change the requirements– again it’s the job of the pm to just make it happen. He doesn’t care if you have to threaten the vendor, make the team work all weekends, borrow system resources from other projects or bau staff, find a way to share the costs of additional staffing with other project managers who are also hit with additional reqmts, etc. The message was always very clear– you as a pm just find a way, beg borrow or steal.
Documents, signoffs etc never bound the business owners who signed them.
Although correct in practice, like many philisophies it is not Prince2 that is the problem, but its practitioners- the dogmaitic priests so to speak.
Prince2 is scaleable, but it is likely that most people don’t know how to scale, nor embed, they just “practice” with limited understanding.
Prince2 requires continual testing and (re-)justification of the business case, but I have yet to find the process where the stakeholders get direct view of intermediate products and can adapt to suit.
Where this DOES happen, the projects (MOD, house building etc) usually go way over time and budget and often still don’t do what is required, ie carriers without planes.
Enhanced stakeholder communication and a cost-controlled mechanism allowing stakeholders to adapt plans would be a welcome ADDITION to current Prince2 practice.
Separately I struggle to see how Prince2 can work well in science where the PM is the main beneficiary of the output (a research paper) and the corporate organisation (university) doesn’t stump up the cash, the research council does.
In a my previous comment, I wrote that PRINCE2 and Waterfall are two very different approaches. Here is a paper on PRINCE2 and Waterfall: http://www.viergever.info/home-en/whitepapers/2015/december/prince2-waterfall/