Working in business transformation means that I have had the privilege to work on and lead many successful projects and programmes. I confess that I find delivering a successful project and realising the hoped-for benefits to be very satisfying, both personally and professionally. However, I would never claim that all of my projects went smoothly from start to finish. Far from it. Resolving issues is all part of the cut and thrust of discrete change, and sometimes it can feel like there is more going wrong than there is going right. Despite this, the teams I have worked with have always managed to get there in the end. But as well as delivering new projects from start to finish, I have been called in by clients on many occasions to quality assure and/or rescue failing projects. Saving a failing project can be doubly satisfying of course, but not all projects are worth saving and then you have the pain of switching them off, losing the sunk cost (which can be tens of millions of pounds), and sometimes even losing members of staff. Even when projects are saved, they can be extremely hard work and stressful. There is often a lot of negative emotion around a failing project, with disappointed customers and sponsors throwing blame at exhausted and disheartened teams. I once spent three years turning around and finally delivering a major project that had gone badly awry, and often questioned my own sanity in doing so. With over 20 years of doing this sort of work, I thought I would share with you some of the common themes that I see in failing projects. If all I do by writing this piece is to stop one project going awry, then I will be happy. My major observation is that projects rarely fail because someone did bad work halfway through the project. Almost every failing project that I have ever come across was hobbled early on at the definition stage. A lack of clarity and objectivity about the true need for the project is a common theme. For example, individuals or teams deciding for themselves what customers want and then going ahead and building it without really listening to the customers in the first place. When I am called in to QA a project I work hard to identify who the customer is, and then I go to see them (all of them if needs be – or certainly a representative sample). I have long since stopped being surprised by the response from customers:
“All I really wanted was for them to fix the current system / process / service / product; but instead they have gone off and started a one / three / five year project to build a new one. In the meantime I am supposed to keep using the broken one.”
Another variation on this theme is a lack of clarity about the problem that is supposed to be solved by the project. Despite working on projects for much of my career, I know that projects are a difficult and risky way to deliver change, compared to continuous improvement, so should not be entered into lightly. If you do not have a clear handle on the problem to be solved then how can you decide what is the best way to solve it (or even if the problem really exists, is important, and needs to be fixed at)? A further variation on this theme is a lack of clarity on the desired outcome. Some project management methodologies are so process heavy that it is easy to forget how conceptually simple the desired outcome actually is, and what you are trying to achieve. We should focus on the baton not the runner as Craig Larman says. You will notice that I did not mention a lack of clarity about the desired solution. That is because humans are very good at generating ideas for solutions – and that in itself can be a problem as many projects start with a solution and then go looking for a problem to solve. Many of the problems listed above around clarity of need, clarity of problem, and clarity of outcome arise not from incompetence (though lack of experience can sometimes be an issue), but rather from the dreaded ‘Three P’s’ – people, power and politics. For example, I often find that sponsors and other members of the governance board had doubts about the need / direction / leadership of the project from day one but either said nothing or more commonly said something once and were made to feel that they had said the wrong thing so kept quiet thereafter. Unfortunately, projects are sometimes created to further someone’s personal agenda and these are often the most ill-conceived initiatives. In theory, formal governance and project initiation procedures should stop these sorts of issues arising, but unfortunately these processes can often be exercises in box ticking where no real critical examination of the need etc takes place. Where project definition processes fail to stop bad projects, the next step is to be the person who stands up and points out that the emperor has no clothes. Of course this risks you becoming a shot messenger, but the consequence for your organisation of not challenging the need / goal / approach for projects can be serious. I hope my experiences give you food for thought. Of course, there are many other reasons why projects fail – and even the definition of ‘fail’ needs to be unpicked – but the themes above have been fairly common in my work across various sectors and project types.
Article kindly provided by Cliff Moyce, Independent Management Consultant – please click here to email Cliff Moyce.
If you’re seeking advice on outsourcing and implementing systems development staff for your organisation please contact Jenrick IT on 01932 245 500.