Search for ‘project failure statistics’ and you’ll find lots of reports talking about failure rates of anywhere between 40% and 75%. It’s also easy to find training providers and consultants who tout the one guaranteed way to project success.
But just what do we mean by project failure or success? Before we can really start to talk about improving success rates, surely we need to understand this. I host a community of PMO professionals in Melbourne – we call this community P3C – and we recently discussed just this point.
This blog looks at what we learned. But first, what is P3C? P3C meets every month to discuss all things Portfolio, Program and Project. In other words, we talk about topics that we find fascinating but that our friends and families find a little, well … a little bit dull.
This community is helping our members develop their skills. It's a safe place to explore ideas that we can use in our professional lives. So...
...what does project failure mean?
The discussion about what success or failure of a project means was, initially, not all that controversial. We talked about how:
- there is no such thing as absolute project failure or success, or at least it is very rare – projects tend to fail or succeed by degrees
- project success is relative to the perceptions of the stakeholders, so it’s practically impossible to come up with an absolute definition for it - we'll come back to this later
- projects can be successful from a delivery point of view (time, budget, cost, scope, perceptions) but fail from a business point of view (benefits not realised, risk not mitigated etc.).
After about mulling this over for a bit, things became more interesting. We came up with another aspect of success. This came about when a member of the P3C community described a project that, while achieving most of its delivery goals, didn't meet a critical business outcome (stakeholder acceptance). As a result, the delivery team undertook significant soul-searching and ended up changing the way in which they delivered projects, which made them much more successful in the long run. We can also see this starting to play out in areas where the Agile mindset is prevalent – creating a safe environment where fast failure is encouraged.
So a third mode of success or failure for projects is:
positive impact on the growth of organisational capability.
The "Aha!" moment
We thought we’d gone pretty deep on this last point, identifying three forms of success - it felt like a deep and meaningful discussion. But it was at this point that the discussion got really interesting.
One of the quieter P3C members threw a real spanner into the works.
‘Hang on’, she said, ‘I think there may be three forms of success. In our portfolio, we had a project, quite an important one, that was delayed by about a month, and the delay didn’t have a big impact on the benefits delivered by the project. So from both the delivery and commercial points of view, the project was more a success than a failure. But that one-month delay actually prevented us from starting another important project, compromising the success of our whole portfolio. So it definitely wasn’t a success from the whole portfolio point of view’.
Oh wow! Does that mean that the contribution to overall portfolio success is another form of success or failure for a project?
We soon had several more examples to think over. There was an IT project whose delay forced the cancellation of an enterprise-level release, which led to a million-dollar loss. There was an environmental project where a delay caused an unfillable hole in the capital spend for the year. There was also a project that didn’t meet all its defined scope and went over budget, but it did deliver a critical shared component that enabled a number of other projects to succeed.
Here’s what we’d agreed by the end of the discussion. Projects can succeed, or fail, in at least four different ways:
- delivery process
- business outcomes
- positive impact on the growth of organisational capability
- portfolio contribution
Portfolio management: planning for success
This is a really interesting insight. It has implications right across the board. The important thing here is that portfolio management and clear planning has a direct impact on how organisations perceive project success and failure.
At the portfolio level, we need to know what success looks like. We need to have a clear picture, agreed by the stakeholders, for what "value" means and use this to clearly define "the role and fit" of each project in the portfolio. We typically call this process "project prioritization".
Research from the University of New South Wales points at just two valid methods for project prioritization, the analytic hierarchy process (AHP) and DEA. I have worked with the team at TransparentChoice on project prioritization and their AHP-based approach really does help to bring into focus what "value" means and to drive agreement across the whole team.
This lets you make decisions about which projects are most important. It lets you manage the trade-offs when one project over-runs, for example, in a clear, quantitative fashion.
Next, at the project level, it's really important to document what the business goals are. Again, explicitly defining and prioritizing the business goals of the project AT THE START means that we know what success (or failure) looks like. If you use something like AHP to do this, it will help you get all the stakeholders on the same page before you begin.
This isn't just about measuring success, it's also about managing scope. If you have a clear set of business drivers set out at the beginning, you can then measure feature requests (or whatever the appropriate unit of "stuff to be done" is in your environment) against that definition and come up with a "value score". In other words, this approach lets you measure "value for money" for your change requests and, therefore, makes the discussion around scope a quantitative, rational discussion.
Finally, by being really clear about what our project "is for", what the business goals are, and by putting that at the heart of every project, it means that everyone working on that project can make better, more "aligned" decisions. This leads to less "non-aligned" work, less waste and quicker, more reliable projects.
What does this all mean?
Well, it means that you probably want to have a discussion with your executive stakeholders about what success really means.
I wouldn't stop measuring things like delivery-to-time or budget overruns, but I would probably shift the focus more onto benefits realization, capability development and strategic alignment. And I'd look at the project prioritization and planning process to make sure it's fit for purpose.
About Peter Houlihan:
Peter spends his working life in that often messy junction between strategy and delivery. With over 20 years of change delivery experience he is a trusted coach, leader and manager. With humour, grey hair and scars, he brings experience to those he works with. He passionately believes that if you set direction, empower people and then get out of their way, people achieve great things.