Project Success: What Is That?
Project Success: What Is That?
By John Taylor
I prefer to adopt an adaptive or agile approach to project management, but why is that better? I think it makes projects more successful, but what does that mean? We need to look at projects and see how successful they are.
The Standish report on IT project success regularly updates us on how successful IT projects are. The 2009 figures show:
“32% of all projects succeeding which are delivered on time, on budget, with required features and functions… 44% were challenged which are late, over budget, and/or with less than the required features and functions, and 24% failed which are cancelled prior to completion or delivered and never used.”
These figures are not great, it is not a lot of successful projects.
I have a number of concerns about the data and analysis behind these figures. Mostly I am not sure the definition of a successful project is right; it ought to assess whether sufficient value was delivered rather than focus on the uncertain knowledge from the start of the project. Maybe the project delivered 80% of the value for 20% of the cost/scope. Then this is a failure for missing features? Or maybe cost overran by 10% to double the return, so why has that failed?
My real concern is not with detailed figures but the mindset that defines success in such restrictive terms. The approach that says success is only delivering on time, on budget and with all required features will favor a deterministic approach to delivery. To be successful you need a big list of requirements, a big design showing how to deliver them and a big plan and schedule. And at the end you can tick or cross the three big boxes; on time? On budget? All features?
But that ignores the reality that often, even mostly, you don’t know all the required features, or which are more valuable, or turn out not to be. And then if you spend any time at all the requirements change; competitors bring out new features, prices change, customers change, suppliers change, technology changes. So your big plan is out of date, and delivering it is a limited success at best. It is preferable to spend less time planning up front, but to deliver little and often, seek feedback and find where the value really is. Then replan often to make sure you deliver that value to your customer, not just a tick in the three boxes.
If you keep chasing the value, and deliver it for the customer then he will be happy, and will want to do more. That is a success for both of you.
John Taylor has extensive business change and project management experience. Having started in IT he discovered the importance of integrating with the rest of the company, and now likes to manage the business change side as well. Above all he likes to focus on the value the project is supposed to deliver and chases that, to ensure the business gets what it is paying for.
