Assurance is your friend. I’ve heard it described by a mentor as the “conscience of Delivery.” It exists to ask two questions: “Are we doing the right things?” and “Are we doing them in the right way?” Whilst many senior managers in the change community claim to welcome the existence of Assurance, many will sabotage that function, sometimes intentionally. Here’s a brief guide to undermining your Assurance function if you are so motivated.

1. Style over substance. You’ll know you’re going down this route if you’ve hired someone called an Assurance Analyst. They will spend all day checking RAID entries and plans, not to see if they make sense but to see if they comply with in-house styles. They will obsess over making sure project stages are properly labelled in plans and that risks are articulated in a consistent manner. It’s useful, but ultimately they are concerned only with how things will appear in reports. If it’s in style and has no obvious glaring errors it’s fine, even if the information contradicts itself or misses out key information. As the analyst isn’t delving beyond the high level view, they aren’t seeing the detail. Inevitably things will go wrong and the question raised will be “why didn’t Assurance spot this?” for which there is little defence. Eventually the analyst will get replaced and the cycle repeats itself. Well, until PPM tools get enough AI to replace the analyst. Then it’s the scrap heap for those guys.

2. Inexperienced experts. When good sponsors and senior stakeholders hear that Assurance is watching their projects, they relax a little. Some of the pressure is eased. The assumption is that experienced, discerning professionals are looking into their projects. These professionals will have run complex projects, had successes and learned from mistakes along the way. They will be well placed to add value to the project by warning of pitfalls, spotting warning signs and sharing wisdom. So when they find you’ve actually placed someone with no experience in delivering projects into the post, they can lose confidence in the whole function.

3. Politics. Effective project management is supposed to work like a machine. Every role, function, process, report, etc is there to deliver change in an optimal manner. Sadly this is never the reality and instead of the machine we get politics. Politics is driven by personal ambition, reputation and personal branding, which makes systems and chance wasteful and inefficient. A politically motivated senior manager will never welcome any feedback on the projects other than glowing endorsements, which makes Assurance a threat to them. They will deliberately seek to undermine confidence in the individuals and function itself if it deflects from anything that can be perceived as their failure.

4. Compromised Assurance. Projects can fail, but sometimes they fail so badly that even execs accustomed to hearing the many excuses for failure can be shocked into action. They or – if it’s gone really badly – regulators can demand an audit to understand what went wrong. The audit will find poor sponsorship, lack of controls, poor reporting, a blame culture and lack of stakeholder engagement (seriously, find me an audit that doesn’t say this after a disaster!). The audit will recommend having independent assurance created within the business. Everyone will agree that’s a great idea, but no-one will really want to pay for it. It will likely end up being included in the Delivery department as technically it was Delivery that got us into this mess in the first place so they should pay for it. So technically it’s no longer “independent” assurance as the function is paid to assess and potentially challenge their paymasters. It takes a brave professional to do the right thing in this situation, chances are they won’t last long.

5. Unwanted Assurance. Following on from the previous example of an audit enforced Assurance function being created, everyone will agree it’s a great idea – to begin with. Later the reality of having independent professionals looking into projects and creating their own reports of progress and control starts to grate. Whilst lip service will continue to be paid about the importance and value of Assurance, in reality it is seen as an problem by any managers with challenging projects. If enough managers feel this way and if enough time has passed since the disaster that forced the audit (approx 1 year), they can make enough noise to get the function removed on the grounds that it doesn’t add value, or that Assurance resources should be reassigned to higher value work (such as delivering projects rather than assuring them). Keep in mind that this is often taking place against a backdrop of ongoing project failures which will only continue.

6. Unvalued Assurance. The Assurance Manager can undermine themselves and their team by failing to track and record the impacts and value provided by the Assurance function. An Assurance Manager will need to be aware of the threats listed here and cynical enough to expect them from their first day on the job. If they aren’t recording success stories in advance of the inevitable battles over the existence of the function, then they are setting themselves up for failure.

Now you know how to completely wreck your Assurance function. You also know how to preserve or rescue it. Consider how you would like to use this information.

Then ask yourself “Am I doing the right thing?”