A lot of organisations use project or programme assurance as a means of checking people’s homework. The stance of assurance is something like a particularly robotic teacher marking an exam. Getting the right answer matters, and the right answer is the answer in the book. Sometimes there’s flexibility to be interpretive, but often there isn’t; and the people who work in assurance are never going to be rewarded, recognised, or praised for being lenient. It goes even beyond this into the realm of trap laying in some cases: the assurance function are there to catch you out, to spot the kind of inconsistencies which might be poor practice, or deliberate malpractice, and ensure punishment ensues.
The attitude of change teams towards this kind of assurance is, unsurprisingly, defensive. If the best outcome you can have from interfacing with assurance is that they don’t give you a kicking, there’s no way the change team can gain anything, and everything assurance require of you is a pure imposition.
What if there was another way, a better way?
Assurance can be a very different experience indeed. If you provide Assurance functions and activities with a clear, simple goal: improve the outcomes of our projects/programmes/whatever; and staff them with experienced operators in the field they are assuring; if you give them a direct link to feed back to update the methodology when new things are found, and ensure they share the good things they find liberally, there’s a completely different dynamic available.
You can go to assurance, and come out with suggestions on how to fix things; a fresh perspective on problems you’ve been tackling alone; even a public pat on the back for finding a different way of doing things which isn’t the standard process (yet) but works better. “Works better” could mean “takes less effort input for the same result output” or maybe “gets to the same result faster” but if you’re really lucky it’s “takes less input, gets better output and faster too”.
At the very least, you’ve made sure that whatever problems you are facing are transparently visible. This can help to overcome the still-common cultural problem of burying bad news. Everyone has access to assurance, and that means there’s a route to getting problems aired which doesn’t get blocked by, for instance, an incompetent sponsor.
This depends on what the reason for assurance is. If you are putting assurance in place because you want to improve project outcomes, or the ratio between inputs and outcomes (cost, effort, time versus benefits), a well constructed and appropriately targeted assurance function is just the thing.
If you’re putting in assurance because a lot of projects are going wrong, and your processes aren’t being followed, well that can help too – but it needs to be backing up and supporting a review of the clarity of your processes, and almost certainly some additional training.
If you’re responding to the discovery – possibly by an audit – that you haven’t got good control over your projects, you’ve come to the wrong place. Adding assurance isn’t how you get better control; reinforcing control is how you get better control, and while there are many different ways to achieve that, simply forcing people to get better at covering up their mistakes – which is the result of adversarial assurance (as described at the start of this piece) – isn’t going to get you better control; it might well make things worse.