Why is it that some companies struggle to handle feedback about the suboptimal delivery of its projects? Rather than point the finger, organisations have an opportunity to leverage the lessons of failure and move from apportioning blame towards accountability.
Engaging external assurance is often enthusiastically embraced by organisations – provided the news is good. However, where a blame culture exists or there is a low level of project maturity, a project review that reveals weaknesses, issues, or systemic problems will often trigger a reversion to type as the organisation will aim to discredit the review or attempt to shoot the messenger.
Facing the truth – however ugly – is something that organisations with an entrenched blame culture struggle to handle. Shifting blame does nothing to help achieve the intended outcomes and benefits of projects. Instead, it actively undermines the potential for future success. The travesty of reverting to type is the missed opportunity to leverage the learnings of failure as potentially rich insights discovered during the review get lost.
Systemic project failure is intrinsically linked to a lack of independent assurance, which can drive clarity of the ‘real’ status of projects and give management the insights that are needed to improve project delivery. But it can only be effective if organisations first address the blame culture.
The impact of not handling the truth
In past bulletins, we’ve explored the realities of what happens when failure is expected and the executive strategy becomes avoidance of accountability. We’ve seen how this can play out in many projects, but there’s a substantive difference in being willing to accept the baby is ugly vs throwing it out with the bathwater. Two recent reviews illustrate this well.
In the first, the review of a successful project highlighted why it was successful and included some recommendations for improvement. The work was received as excellent and the recommendations taken on board with widespread endorsement from the sponsor down.
The second review was of a troubled project that had many areas for improvement. The review followed the same process and was of the same high standard, was objective, and focused on outcomes, not individuals. The review also provided a roadmap for improvement and a way to deliver the business, user, and technical benefits and outcomes.
It was poorly received by the sponsor and discredited, and subsequently, the effort was focused on justifying the reasons for the issues identified, what led to them, and why it wasn’t anyone’s – and especially not their own – fault. Instead of accepting the truth that the project needed corrective action to succeed and taking the appropriate actions, the defensive reaction to the review’s findings meant that any learnings that could have been taken forward were lost.
The net effect was in the later circumstance a wasted opportunity for the organisation to improve how it delivered projects.
Why Assurance Matters
There are some basic fundamentals that define successful assurance. At its core assurance should help to enable management by exception and act as a trigger for intervention if the projects exceed agreed control limits.
Assurance will test these defined control limits for each project and for the organisation’s portfolio of projects; whether these are appropriate; and highlights whether they have exceeded or are in danger of failing to achieve the required performance in KPIs like:
- Time – Variance against milestones
- Cost – Variance against the planned budget
- Quality – Degrees off the quality target
- Scope – Variance agreed against what will be delivered
- Risk – Limits on identified risks as a percentage of overall budget
- Benefits Realisation – Variance against the level of benefit identified as part of the business justification
- Governance – Variance of the management of the project per the charter
The system should focus on outcomes, not activities and assure the benefits of the project, not the projects themselves, to ensure the project is a success.
It should always be fact-based and should never become an emotional witch hunt.
Driving transparency and collaboration
Projects need a baseline of quality to know what they will be assessed against and assurance necessitates a well-rounded and thorough definition of success, which usually covers three levels in business and ICT projects:
- Business assurance which measures project performance against the projected benefits to the organisation. It asks: “Is this an effective use of the company’s resources for both finances and manpower?”
- User assurance considers the intended recipients of the project outcome – be it a product or service – and whether the user’s requirements are being met.
- Specialist assurance measures how suitable the solution is for software and technical requirements.
Assurance comes into its own because it promotes objectivity in gauging project success and, if implemented and delivered well, starts to drive a culture of shared responsibility by providing information to those that sponsor, govern, and manage a project to help them make better and more informed decisions. It also drives the disciplines around project delivery and identifies where they are followed and flags where they haven’t been.
Taken on board, this then helps to reduce or mitigate the causes of project failure whilst at the same time promoting the right conditions for project success and cost-effective delivery.
It’s not a stick
Assurance is not a stick opposing the proverbial carrot: It is an enabling tool that supports better outcomes and business benefits. Done well, the independent and objective review provides an assessment of whether the elements of successful project delivery are in fact in place and operating effectively.
The process of reviewing a project in-flight or post-delivery can provide informative data that the project’s governing body can use to make sound decisions and take course-correcting measures.
When supported and allowed to do its job, assurance provides organisations with lessons from its failures or missteps and enable a culture of blame to evolve into a culture of responsibility. This is because it facilitates open dialogue between the project board and project delivery team to evaluate the project’s progress, be it negative or positive. Executed well it can unite teams and stakeholders in the pursuit of the common goal of project success.
We believe that quality thought leadership is worth sharing and encourage you to share with your colleagues. If you’re interested in republishing our content, here’s what’s okay and what’s not okay.
To speak to our team about how we can help your business deliver better projects, please contact us.