The curious case of the familiar file

In attempting to manage uncertainty, many companies go to great expense to develop protocols and procedures. Then they set them in stone hoping that compliance will lead to project success. Things rarely work out that way.

Large complex projects do require a lot of processes, of course. So why does this approach so often fail? Allow me to illustrate with a rather (and, I hope, uncharacteristically) smug story.

Often, a project team brings us in for an appraisal to make sure their existing processes are fit for purpose. During one such kick-off, I was handed a thick, bound document. This, our client explained, was their set of project management and control procedures.

‘Unfortunately,’ they said, ‘they’re not really working for us.’

After a cursory flick-through, I told them I was familiar with the contents and whoever wrote it really knew their stuff.

‘But,’ I added, ‘these processes aren’t going to work for you.’

‘Why not?’ the client asked, a bit taken aback.

‘Because,’ I said, trying to contain my inner Hercule Poirot, ‘I wrote them myself!’

Now they were more confused. ‘But if you know your stuff, as you claim, why don’t they work?’

I explained I’d compiled the document some ten years earlier for a different company and for a completely different and singular project context. Now, this organization found itself with a ‘Frankenstein system’, plagiarized from the work of others (in this case mine) with little thought as to whether the directives and protocols reflected the approach their projects required.

A company’s generic project management system should help define the failure boundary of required acceptable performance. But it can only ever be a starting point. There’s no one-size-fits-all. And if you’ve cobbled together a Frankenstein collection, it’s more than likely it’s one size fits none.

So what to do?

First, take a ‘project narrow’ view of the specific needs of the context in front of you. Then decide which companywide processes make sense to implement and which ones you need to enhance.

Project readiness beats corporate robustness

Standardization does make sense in many instances, such as equipment, physical systems, or safety measures. But when it comes to handling the inherent risk in large projects, it can lead to the opposite effect than intended. It’s like trying to design a safer aircraft by building the whole thing out of the material used for the black box. It just won’t fly.

That’s why we say ‘project readiness beats corporate robustness’.

If you’re wondering if I took legal action against our clients’ personnel for the plagiarism, I didn’t. Instead, we developed a governance system for them with some standard, consistent processes across projects while requiring reviews and enhancements for every endeavour.