ITIL Blog - Featuring ITIL Training and Online ITIL Resources

Why Projects Fail - Part 2

Why Projects Fail (Mastering the Monster) – Part 2.

By Brian Sutton, Director of Learning – QA Training & Consulting.

Towards a more Robust Model for Assessing Project Success

Success is not binary. It is not as simple as succeed or fail – there are degrees of success and failure.

To aid understanding, I would point to four distinct levels of success, each having its own discipline, tools and techniques. Excellence at each level is critical for overall success.

• Level 1 may be termed Project Management Success
  
  
  • Put simply: did the project produce the desired output?
    • Here we are concerned with the management of the work to be done. Key skills are clear scope and deliverable definition, thorough and continuous risk assessment and business case monitoring, planning to an appropriate level of detail, good estimating practices, appropriate scheduling and use of resources, cost and schedule tracking

    • Invariably success at this level is measured in terms of the traditional triangle of Cost, Schedule and Performance. Did it cost what we said, did we deliver on time, did it do what we agreed. Some practitioners include Quality but this should not be considered a variable as the unscrupulous will cut corners on quality to maintain performance against the other variables
      
      
      

• Level 2 may be termed Repeatable Project Management Success
  
  
  • Put simply: do our projects consistently produce the desired outputs?
    • Here we are concerned with the consistent application of good project management practice. Although we are still predominantly concerned with the management of the work to be done, we are looking for organisational structures that are designed to share and support best practice and to ensure predictability of outcome

    • Success at this level can only come when project management is exercised within the auspices of an organisation wide methodology, supported by standards and a mechanism for learning from experience
      
      
      

• Level 3 may be termed Project Success
  
  
  • Put simply: did the project outputs produce the desired outcomes?
    • Here we are concerned with an assessment of how well the project has delivered the business benefits that were claimed at the outset. This requires that the outputs of the project are fully and appropriately integrated into the business operation and that process adjustments and people skills are developed in tandem

    • Measurement of success requires good metrics and an understanding of baseline conditions. Improvements at this level tend to come from a thorough understanding of benefits logic and from initiatives designed to assign individual responsibility for the realisation of benefits. This needs to be supported by a regime to capture and share lessons learned
      
      
      

• Level 4 is inextricably linked with Corporate Success
  
  
  • Put simply: do the outcomes produced have the intended impact on Business Strategy?
    • The primary concern is with project selection and portfolio management, i.e. out of all the possible things in which we could have invested, have we chosen the optimum mix of projects that, when taken together, will most effectively contribute to the advancement of our stated business strategy?

    • Measurement of this level of contribution requires a programmatic approach to organisational initiatives and probably a balanced score card approach to organisational performance measurement

This model shows graphically that, when we talk of project failure, it could occur at any one of the four levels. What should not be surprising is that each independent level of failure has a corresponding different level of corrective action. Too often I see organisations that only know that they are failing, they do not stop to analyse why before they adopt corrective measures, and then invariably wonder why they make no progress.

The message is simple: understand where and how you are failing and then target the measures that produce the greatest likelihood of success.

Matching Corrective Interventions to Problem Levels

It is worth reminding ourselves that we are dealing with two types of project. Type 1 projects have shown themselves to be amenable to a range of measures that improve successful completion. By contrast, Type 2 projects remain largely impervious to our efforts at improvement. This is particularly the case when dealing with level 1 success.

Level 1 Success

For Level 1 success we need to answer the question: “did the project produce the desired output?” There are a number of very positive things we can do at this level:

• Product based planning will help produce consensus on the nature of the output required and the quality criteria to be applied in its assessment

• Robust risk management practices have the biggest impact upon on-time delivery.

• Rigorous change control procedures impact directly on cost performance

• Good project reporting practices, such as earned value analysis, have a direct impact upon cost performance but also ensure that the project is truly in control

• A project culture that rewards, rather than penalises, fault reporting will affect both cost and schedule. For if there is anything more damaging to a project than rework – it is undiscovered rework. Undiscovered rework is a project killer and it is most prevalent where deadlines are tight and project teams live in fear of their manager

If you are suffering Level 1 failures use the above list to help target the practice that will impact your particular problem. If you are setting up a new project and are concerned about Level 1 performance in your organisation dwell upon this statistic from Standish Group regarding challenged US IT projects: on average they were 189% over budget when challenged! There is only one way to avoid this horrifying possibility and that is to get the project steering committee to set tolerances on the project – typically 15%. Then institute a rigorous earned value reporting regime that insists both on open reporting of progress and routinely reforecasting time and cost to complete, based upon trends observed from actual performance. This doesn’t stop your project being challenged but it at least ensures that you are no more than 15% over when the challenge happens.

Finally if you are engaged in a Type 2 project, the first and foremost concern should be to take actions that change elements of its character so that it behaves more like a Type 1 project. For example:

• Select a development cycle that helps remove ambiguity about outputs / success criteria. For example, a discovery prototyping strategy to identify essential functionality or time-boxing using facilitated workshops of stakeholders to agree scope limitation or targeted functionality

• Use simulations or pilot implementations to better understand the likely benefits and the time profile in which they can be realised

• Establish project control boards and proper project steering to ensure continuity of purpose, should significant stakeholders change or move on

• Identify interim deliverables or phase the introduction of functionality so that early benefit can be delivered to those powerful stakeholders who are least supportive of the project

Once the above are in place the project will be more amenable to Level 1 success criteria.

Level 2 Success

For Level 2 success we need to answer the question: “do our projects consistently produce the desired outputs?” Level 2 success is independent of the nature of the project. Therefore the guidance below is equally valid for Type 1 and 2 projects. The emphasis is to move from success based on individual excellence to success based upon consistent and repeatable processes. We are therefore looking to implement structures that promote and sustain organisational learning.

The sorts of things that impact upon Level 2 success are:

• A simple, widely accepted and practiced standard vocabulary for project management
  • This is most likely to be achieved by the implementation of some form of methodology, or by a collection of best practices
    
    

• The consistent application of best practice
  • This is most likely to be achieved through the auspices of some form of “project support office”. Whether it is physical or virtual is of less importance than its ability to influence the consistent application of procedures relating to:
    • Project initiation

    • Risk management

    • Change control

    • Estimating – through the provision of accurate historical data

    • Project planning (at the detail level)

    • Project reporting, including the capture of actual performance
      
      

• A mechanism for the capture and sharing of experience and lessons learned from projects and project reviews (not the same as post implementation reviews)
  
  

• The fostering of a community of practice amongst project managers from across the organisation
  
  

Level 3 Success

For Level 3 success we need to answer the question: “did the project outputs produce the desired outcomes?” Many project managers consider this to be beyond their remit, in that generally benefits are delivered or taken during operation after the project output has been delivered. The reality is that the ability to reap the benefits is often inextricably linked to actions that are, or should have been, taken before the end product was delivered. Benefits measurement of Type 1 projects is relatively straightforward as generally they rest on easily traceable revenue and maintenance streams.

However, Type 2 projects have far more complex benefits models, as there is often ambiguity about the desired outcomes that were to be produced. We are also often faced with the “serendipity effect” in that Type 2 projects are more likely to generate unpredicted side effects that could contribute to either cost or benefit.

The organisational initiative that impacts upon Level 3 success is:

• Proactive Benefits Management
  • This requires rigorous benefits logic to be applied to the identification of benefits in the business case and regular reviews of the business case whenever a major change request is applied to the project

  • Clear ownership for the realisation of benefits

  • Clear metrics agreed at the project outset about how benefits will be assessed

  • Rigorous post implementation review processes, that hold people accountable for the delivery of benefits

  • A clear mechanism for the capture and enculturation of lessons learned from ongoing projects

Level 4 Success

For Level 4 success we need to answer the question: “do the outcomes produced have the intended affect on the Business Strategy?” Here we have moved beyond the realms of a typology for projects as at this level all projects exhibit essentially the same behaviour.

If project managers consider delivering benefit to be beyond their remit, then the idea that they are engaged in the realisation of business strategy is so alien as not to be worth consideration. Whilst it is true that the mechanisms that I will recommend below are generally outside the working remit of the project manager, the reality is that programmes and projects are commissioned specifically to deliver strategy and unless everyone thinks along these lines we should not be surprised if we create a culture whereby projects within a programme succeed at the expense of other, perhaps more important, programmatic efforts.

The sorts of organisational practices that can be put in place to impact upon Level 4 success are:

• Portfolio Management
  • This means adopting a proactive portfolio approach to the selection and initiation of projects. This requires attention at the highest levels to ensure that we only approve those projects that complement the desired strategic direction. This inevitably requires a broader base for selection than just financial measures such as ROI. Indeed, I would expect consideration on the benefit side to be given to such things as: contribution to competitive advantage (or competitive response), fit with the business strategy, fit with the architecture etc. On the cost side, we should see considerations such as organisational risk, technical risk
    
    

• Programme Management
  • If we are managing projects as a financial portfolio it will be necessary to embrace strong programme management practices. We cannot rely on individual project managers to instinctively know or act in accordance with the greater good – we need to manage to ensure that this happens

• Organisational Performance Measurement
  • Most organisations have poor mechanisms for monitoring progress against business strategy; indeed most have incomplete or inaccurate ideas about what actions lead to what consequences. In order to manage programmes effectively we need effective measures of performance – evidence seams to suggest that these are best achieved through the application of some form of “balanced scorecard”. Furthermore measuring is not enough, we must learn from what we measure and adjust actions and belief structures accordingly – this requires the balanced score card to be used as an enabler of organisational learning

Final Thoughts

In this article I have provided a simple model of the multi-dimensional nature of project management success. It is neither prescriptive nor entirely robust; its value lies as a lens through which to view the problem. In the final analysis it does not matter whether there are three, four or five layers of success in your model – the important thing is that there is more than one. For once you admit to layers of success, there must be corresponding layers of appropriate corrective actions. If you are serious about improving the success of projects in your organisation use this model to help you target the practices that are likely to make a difference and match your project control structure to the nature of the project in hand.

Resources:-

Access Free White Papers on Business Process Management

Free Articles and Guides about IT Governance

Why Projects Fail.

Most ITIL implementations are delivered into the organization through the delivery of projects or as a series of continuous improvements which often are run as mini-projects. In this first part of a two part article, Director of Learning for QA Training and Consulting, Brian Sutton provides an extensive insight into the reasons why projects fail and provides evidence for these failures. Importantly Brian helps us to clearly understand what we can do to address these failures and prevent costly mistakes within our own organization.

Brian shares many years of experience with us in his work and there is a lot to take on board and absorb to help us - in our growing ITIL community - learn from the mistakes of others and (hopefully) avoid similar mistakes in the future.

The articles are placed in the context of all projects (not just ITIL one's) but regularly refers to “IT Systems Projects” which should be used as the marker when considering the two figures and the overall context of the article.

Re-Produced with kind Permission from QA Training and Consulting.

“Why Projects Fail (Mastering the Monster – Part One)”

by Brian Sutton, Director of Learning QA Training and Consulting.

“If you are one of those project managers who struts the corporate corridors braying that you have never missed a deadline, have always delivered to budget and that anyone who can’t has no right to call themselves a professional, then read no further for your treatment is beyond my meagre skills. However, if like me, you have spent most of your professional life wondering why so many skilled and well meaning people can get it so badly wrong most of the time – then what follows may help.

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

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

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.

In the first part of this article I provided two lenses through which to examine the phenomenon of project failure. I postulated two types of projects: Type 1 projects, characterised by tangible outputs with intrinsic value and general consensus about purpose; and Type 2 projects, by contrast, characterised by ambiguity over purpose, competing stakeholders, lack of tangible outputs and outputs that have no intrinsic value and frequent change of ownership, and hence impetus. I showed how the two project types mapped onto a grid of complexity versus fuzziness and argued that knowledge of position on the grid permitted informed decision-making on appropriate deployment strategies.

In this second article I will detail a four level model of success and identify specific best practices associated with success at each level.”

Access More White Papers on Project Failure