This first article starts by exploring the reasons for project failure and provide a simple classification system that can serve to identify at risk projects at, or before, project initiation. The second part of the article will develop a four level model of project success and identify areas of best practice associated with each level. The conjunction of these ideas allows problem projects to be predicted, development strategies to be selected and appropriate control structures and tolerances to be put in place.
Projects are not all the same
It is blindingly obvious that all projects are different and that different projects suffer different points of failure. What may not be so obvious is that most are not so different as might at first appear. This paper will propose simple criteria that divide projects into one of two types. It will further contend that problems of failure stem as much from trying to apply successful solutions from one camp to inappropriate problems from the other. But first lets get clear in our mind the features that distinguish the two types of project.Type 1 projects – these are concerned with the delivery of some sort of artefact; e.g. a construction project - an office block, bridge, ship etc. With these types of project there is consensus at the outset about the desired output and outcome (output and outcome may be indistinguishable and concurrent). There is a tangible end product and at the point of project closure (i.e. output) and that end product has an intrinsic value. Further, the end product can be described in some detail at the start of the project and, in all probability, an accurate model can be constructed. Type 1 projects may be complex, but the complexity tends to be detail in nature.
Type 2 projects – by contrast these projects are designed to bring about some form of organisational or societal change; e.g. congestion charging, a new performance related pay system, and virtually all information systems developments. These projects tend to have multiple powerful stakeholders, often with competing agendas. Under these circumstances it may be possible to gain consensus on the output of the project but the purpose or intended outcome may be more ambiguous and even contentious; therefore it may be impossible to gain agreement on the appropriate measures of success. The output of the project may have no intrinsic value. Value can only be accrued as a result of the outcomes that come about through the usage of the output – outputs and outcomes may be separated in time and space. Ownership, or sponsorship, often changes during the life of the project and with every new sponsor comes a new interpretation of purpose. The projects are always complex, they may or may not exhibit detail complexity but they will always display dynamic and political complexity.
Finally, Type 2 projects invariably represent the greatest strategic value. They generally have repercussions beyond the bounds of the organisation in which they are conceived and they suffer far greater levels of failure than Type 1 projects.
Perspective on Project Failure
Standish Group findings on US IT Projects53% of all projects surveyed were challenged, at point of challenge they were on average:
|
Studies on project success and failure, especially in the information systems world, are easy to find and often make for depressing reading. Many of the findings relate to experiences from the USA but there is no evidence to suggest that the performance is significantly better in Europe. Gartner Group studies suggest that 75% of all US IT projects are considered to be failures by those responsible for initiating them; by failure we generally mean that they did not do what was agreed or they missed deadlines and/or came in over budget. Indeed half of the projects exceeded budget by 200%.
A Standish Group study, again in the US IT industry, found that 31% of projects were cancelled outright and that the performance of 53% of the all projects was so worrying that they were challenged. Setting aside for a moment the obvious lack of proper project control structures that allow projects to get into this state before being challenged, it must by now be clear that a trend is emerging. If my classification is correct, most of these projects were type 2 projects. So what of the performance of Type 1 projects?
Studies and experience from the construction industry shows remarkable progress over the last 20 to 30 years. Now 3% over budget is considered to be cause for a public enquiry and projects are routinely delivered early and inside budget. There is of course the odd, spectacular and public failure – like the dome – but when we examine these cases it is clear that they are more typical of Type 2 projects than the typical Type 1 construction project.
By way of a final piece of evidence lets look at the results of a recent European survey conducted by Dr T. Cook-Davies (presented in Towards Improved Project Management Practice: Uncovering the Evidence for Effective Practices through Empirical Research, 2001); this compared the performance of 136 projects across 23 organisations. It should be understood that these projects were a mix of construction and IT projects and were all conducted in organisations that had a strong project management culture, robust practices and a commitment to project management excellence. Whilst there were still cases of budget excess the average performance was 4% over budget and 16% late.
Traditional Excuses for Project Failure
Top Reasons for Project Failure
|
Project failure is not new, nor is it confined to the IT world. Numerous studies show that between 75% and 80% of all business transformation and re-engineering initiatives are also considered failures, and perhaps unsurprisingly the reasons given for this bear a striking resemblance to those given in the table to the left. The usual suspects are: lack of top management support and poor sponsorship. Whilst it is undoubtedly true that poor management control and attention will exacerbate problems, the expression ‘unsupportive management’ covers a multitude of sins and is particularly unhelpful in diagnosing actual problems and recommending remedies. I find the rest of the list equally unhelpful, for even the most inexperienced project manager must realise that inappropriate project selection is both organisationally and qualitatively different than producing an inadequate work breakdown structure.
In any case, one thing we can be sure of without extensive research is that the major project disasters we read of do not happen because someone could not produce a work breakdown structure or because they couldn’t calculate the critical path. These may have been contributory symptoms of a deeper malaise, but of themselves they are never sufficient to endanger projects. Most projects that fail are in trouble before they start.
The root cause of the problem is over optimism and biting off too much in one go. We see this particularly with Type 2 projects that are initiated without full agreement between sponsors and inappropriate steering arrangements. We see issues with complex projects kicked off without tolerances set, no change control and no exception reporting structures in place – how else could we ever be 200% behind schedule and still be working? Recognising project characteristics at the outset, and associating them with broad outcome behaviours, can help with the prediction and management of future problems, but only if you pay attention to the signs and then take action accordingly.
The Environment in Which Failure Occurs
Figure 1 shows project complexity plotted against fuzziness. By fuzziness I refer to the extent to which the functional requirements can be accurately specified at the outset of the project.
Figure 1
Projects in quadrant 1 represent work that is both well defined and relatively simple to achieve. A quick inspection of this grid would lead most project managers to declare that only an idiot would agree to take on the management of a project in quadrant 4, i.e. no clear idea of what we are trying to deliver, to what standard, to what acceptance criteria and if that were not enough, highly complex in nature.
Let’s now return briefly to the idea of two types of projects. Using this analysis it is not difficult to see that generally Type 1 projects which are characterised by tangible outputs that have intrinsic value, tend to reside in quadrants 1 and 2, whereas Type 2 projects invariably occupy quadrants 3 and 4, as shown in Figure 2 (many Information Systems projects are firmly in quadrant 4). Also remember that Type 2 projects suffer from significant levels of political complexity and ambiguity about desired outcomes.
Figure 2
This perspective, when combined with my outline definition of the characteristics associated with the two types, does much to explain why the construction industry has made excellent progress in on-time, to budget delivery whereas the IT/IS world and organisational change management is still mired in failure.
The message is a simple one, if you are engaged in a Type 2 project and you adjudge it to be operating in quadrant 4 of the graph, no amount of project management heroics are likely to see you through to successful completion and more importantly the tools and techniques that proved valuable in Type 1 projects in quadrants 1 and 2 are of little value for the issues are fundamentally different.
Final Thoughts
In this article I have provided a simple model of the nature of project failure. I have argued that over confidence combined with the rather touching, but naïve, belief that hard work and the rigorous application of technique will win through, are at the heart of many failures. The reality is that the seeds of failure rest in the very nature of some projects. If this is indeed the case then relief is more likely to come from strategies aimed at controlling the nature of the project rather than the actions encompassed within it.In the second part of this article I will go on to develop a four level model of success and point to best practice associated with each level of the model.
Brian Sutton is Chief Educator for QA. He is a Chartered Engineer, a member of the APM and a PRINCE2 practitioner.
This article is reproduced here with the permission of QA, one of the UK’s leading IT training companies, and winner of VSJ magazine’s 2005 Reader Award for “Training Company of the Year”.
Comments