As I write this post, the UK is in the middle of campaigning for the 2010 General Election. One feature of this election campaign has been the first televised debates between the leaders of the three main parties. The first of these debates has stirred up the campaign significantly as Nick Clegg, the Liberal Democrat leader, by most accounts won the debate. This was an unexpected outcome as the Lib Dems have been the third party for many years.

This blog post is not a political post, but considers how winning may be assessed, particularly in a business context.

As the campaign has progressed, it has been fascinating to compare how each party and the different media outlets have treated both the debates and the overall campaign. Each party consistently claims that they are winning (no surprises there!). Many of the newspapers have a historic bias to either Labour or the Conservatives, most of these  have claimed their favoured party won the debate and that Nick Clegg was present for the debate. The main news channels appear to have been more balanced in their reporting. We will only know who the winner is following the election on the 6th May.

This made me think about definitions of success in business, particularly relating to business change projects. These can be similar to the election campaigning process mentioned above in that differing parties will be claiming success or failure based upon different characteristics:

  • Typically the project manager and main contractor will claim a success, often based upon the criteria of cost and timescales
  • Directors and seniors managers who sponsored the project may declare it a success based upon the above recommendation
  • Other directorates may decide whether a project was successful based upon whether the interfaces to their own processes are succesful
  • General business users may decide whether a project was successful based upon the quality of training, change communication and ease of system/process use
  • BI teams may decide whether a project was successful based on whether all their existing reports have been migrated to, or recreated, in the new system
  • Super users/power users may decide whether a project was successful based upon whether the system is more powerful and usable than the previous system
  • Line managers may decide whether a project was successful based upon whether their work becomes easier or harder
  • Customers will decide whether the project was a success based on the success of any dealings they have with staff
  • Some staff, managers and users who are resistant to change will always claim that the previous system or process was far better than the new one

It is not unknown for there to be very different views about the success, or otherwise, of a project. Sometimes it is only after more time has passed and stakeholders are able to reflect more widely about the impact of a project that there is agreement on the success of a project.

In order to avoid such debate and uncertainty, organisations should develop a set of success criteria very early in the life of the project, preferably at feasibility stage. This could be based on the MoSCoW Method, which should also be adopted during requirements gathering, in order to determine what Must be delivered, what Should be delivered and what Could be delivered. These could then be used as success criteria, for example:

  • All “Must have” criteria should be delivered for the project to be declared a success (this should also include cost and timescale criteria), and
  • No more than two “Should have” criteria should be met for the the project to be declared a success

If these criteria are agreed early in the life of a project and assess and published at the end of the project, then all will have a clearer view of the overall success of a project.

How have you managed to ensure that there is a clear and consistent view of whether a project has been successful?

Tagged on:                     

3 thoughts on “And the winner is…..

  • 26th April 2010 at 15:21

    Excellent post Julian,

    It brings to my mind two quotes.

    First, most of the time when I have asked clients to clearly define their success criteria at the beginning of a project, they essentially respond with a MoSCoW variant:

    “We would, if we could, but we can’t, so we won’t.”

    Second, most of the consulting firms that I have worked for in my career have defined their success criteria at the end of a project as:

    “Declare victory — and walk away.”



    P.S. Early polling numbers indicate that this was a great blog comment. The error margin in the poll is +/- 51% 🙂

  • 27th April 2010 at 00:07

    Where I have personally witnessed total project failure is in an implementation that excluded from consideration any input from the business users (see my article “Is user spelled with an L?”). Early computer systems often required or expected users to conform to system needs, not the other way around, and certain patronizing behaviour from some IT staff tended to make this situation worse. Fortunately today end users are usually seen to have a pivotal role in systems design as computer applications have evolved to become more and more user-friendly. But even yet if users don’t understand or fully appreciate the benefits of a new system, it will remain un- or under-utilized, likely impeding or undermining project success.

  • 27th April 2010 at 12:08

    Jim, Scott,

    Thank you for your comments.

    I have seen too often the effects of consultants walking away from systems declaring them a success. Sometimes, it is only once the initial euphoria/hype around a completed project has subsided that an objective evaluation of success is achieved.

    I agree that systems can often be underutilised for a variety of reasons. Sometimes this can be a lack of awareness of this gap in benefits, otherwise, an over bureaucratic governance process prevents users from promoting projects to ‘finish off’ systems.

    Since the rate of IT project failures is between 62 and 68% (depending on which source you use), it is intriguing that organisations are not more focused on ensuring the success of projects and properly understanding where and why they have not met expectations. In the ‘real world’ people are used to many devices to reduce the risk of failure (e.g. Anti-lock brakes in cars) and to mitigate the consequence of failure (e.g. airbags), yet the same approach to mitigating business risk from projects is absent. Another example of the differences in approach between systems/data and the physical world that was explored in our blog post “Would you allow this…

    It is also intriguing that there is not more recognition of the ongoing work needed to maximise the benefits that can be delivered from a system or business change project.

    I guess we all need to keep banging the drum on these issues….. 🙂



Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.