The Lessons Failure Teaches

Share on linkedin
Share on twitter
Share on facebook
Back to top

If you read all of the research on the topic, you’d be forgiven for concluding that failure in technology-enabled programs and projects is almost a foregone conclusion — and not because the technical skills are lacking. Unfortunately though failing fast is quite in vogue right now – project failure is not.

Given that the causes of project failure are commonly known in the industry, why does the trend of failure continue? After all, as Bill Gates famously declared, “It’s fine to celebrate success but it is more important to heed the lessons of failure.”

Maybe it’s time for us to reframe the common causes of what might be called initiative failure — to “heed the lessons of failure” — and consider what you can do about it.

This Much I Know: Key Causes of Project Failure

The lessons I’ve learned from the many project reviews I’ve participated in over the years always come down to a handful of factors that play a role in initiative failure:

The absence of strong and clear leadership.

All programs need a vision requiring leaders that know when and how to intervene to head off failure and, importantly, inspire people and set an initiative up for success. It’s the failure of leadership, in my view, that stands out as the primary cause of failure — bar none. After all, leadership touches every aspect of an initiative and culture starts at the top.

Too much complexity within the governance of a program.

Complexity compromises effective decision-making. It’s incredibly important that your governance model retains some independence, for example, by appointing specialised non-executive directors or NEDs. Equally important is simplifying requirements down to a discrete set of manageable work packages rather than aiming for a “big bang” moment.

Poor decision-making in the selection of delivery partners.

Does the supplier actually have the capacity to deliver? It’s often the case that the honeymoon period ends and you realise that you have chosen the wrong partner. Either they’re not capable of delivering the quality of resources the project requires or their plan doesn’t hold true. I have seen this time and again over my career. You should always probe a supplier’s planning assumptions and resourcing model. Pcubed also highly recommends that you obtain some independent program assurance to help make your service provider assessment.

A failure to deliver cultural change.

While technology can deliver organisational transformation, it’s people who break programs — and they often do. If you don’t bring people on board by ensuring your program is vision-led, your chances of failure increase exponentially.

Over-confidence and optimism bias.

All too often at the business case stage an optimism bias exists with respect to the identification of benefits and how they will be obtained. This optimism bias can also extend to other stages in an initiative right up to the very moment of failure. It’s important to be realistic in your expectations, to promote good governance and to assure that program teams are independently assessed.

A failure to identify and properly manage strategic risks.

Every initiative may have a risk register. But good risk management is more than just maintaining a register. For example, you might consider having a separate risk and assurance board within your governance framework for a major program populated with specialised NEDs. This can be useful in tackling key strategic risks that, left unchecked, could kill your project.

Additional Reading: our complete guide about  PMO.

Increasing complexity of proposed solutions.

We’ve all seen it — endless customisation and changes in the program lifecycle, more commonly known as scope creep. It’s not all the supply side’s fault. Often a failure on the part of the project team to manage the expectations and desires of stakeholders leads to the design of an impossibly complex solution that tries to keep everyone happy. What ends up happening is that the project costs more, is delivered late and sometimes won’t be delivered at all. Keeping it simple and managing requirement delivery through phased release is the best tactic you can adopt to boost your chances of success.

There’s probably nothing on this list you haven’t seen yourself. But if these causes of project failure are so common, how come we haven’t learned how to eliminate them?

Here’s the rub: All too often failure is accepted almost as the cost of doing business. People may lose their jobs, a supplier contract may be cancelled, and everybody else moves onto the next initiative, only to repeat the cycle.

In my experience when failure occurs, as it inevitably will, it’s crucial that the lessons learned from mistakes be embedded into an organisation and the delivery mindset of its people. How do you do this?

MI-GSO | PCUBED’s expert advisors have ample experience in helping organisations review projects and programs to cull lessons learned and help embed continual improvement into the culture. Contact us to learn more about our Program Assurance interventions.

We advise conducting a detailed independent review to examine the causes of program failure in each unique instance. Through a mix of documentation review (a look back), interviews, workshops, and consultation, a “lessons learned” review can yield significant benefits and have a high impact on an organisation’s performance at relatively little cost. Conducting such a review sidesteps the problem of people moving on before the lessons worth learning have been identified and the improvement opportunities embedded.

I think this is what Bill Gates meant. Take it seriously, make an investment, hold people accountable for their own learning and boost your chances of program success the next time around.

Of course, you don’t have to wait for your program to fail. Consider investing some time up front to learn from others with experience in working on projects in your segment during the early stages to set yourself and your organisation up for success by learning from the mistakes of others.

References:

Bloch, Michael et al. (October 2012) “Delivering large-scale IT projects on time, on budget, and on value.” McKinsey & Company Insights & Publications.

Rollings, Michael. (March 28, 2013) “Why projects fail? Hint — It’s not technical skills.” Gartner Blog Network.

Flyvbjerg, Bent et al. (September 2011) “Why Your IT Project May Be Riskier Than You Think.” Harvard Business Review.

Kevin Quinlan

Kevin Quinlan

Client Partner
@ MI-GSO | PCUBED UK

Loved what you just read?
Let's stay in touch.

No spam, only great things to read in our newsletter.

We’re committed to your privacy. MI-GSO | PCUBED uses the information you provide to us to contact you about our relevant content and services. You may unsubscribe from these communications at any time.
For more information, check out our privacy policy