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 (eg. PRINCE2®)
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.
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 ‘management products’. 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, improved performance 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 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.
Prince® and Prince2® are registered trade marks of the UK Office of Government Commerce
Copyright © Business Transition Technologies Ltd 2012. All Rights Reserved.