Further to my post on Lessons Learned from project delivery, I’m going to take a calculated risk by standing up for the pragmatic application of process. Yes, that’s right, process.
Now, people seem to enjoy a bit of process-bashing, and I get that: nobody wants to have their working lives organised for them to the point where they become a soul-less, heartless, brainless robot, but I am proposing the idea that processes are an organisation’s memory.
Let me illustrate this with a well-known story – the Fable of the Five Monkeys. If you don’t know this story, Eddie Obeng tells it beautifully in this very short (2½ minutes!) video.
Here is the story in a nutshell:
- Five monkeys were kept in a cage with some bananas at the top of a ladder. Whenever one of the monkeys climbed the ladder to get a banana, all the monkeys were hosed down with cold water. Soon, the monkeys began to beat each other up to stop any other monkeys from climbing the ladder and getting them all hosed.
- Eventually, the threat of cold water was removed, but the monkeys didn’t realise that and still stopped each other from getting bananas anyway.
- Then, one monkey was replaced with a new monkey. This monkey didn’t know about the cold water, so when he tried to get a banana, the other monkeys beat him up to stop him.
- One by one all the monkeys in the group were replaced, and all of them would stop each other from trying to get the bananas, even though none of the original monkeys were there, none of them had been sprayed with water and in any case the cold water had been turned off.
- Effectively a culture had been created within which you get beaten up if you try to get a banana, but none of the monkeys understood why.
The meaning of this story is that to begin with, an organisation adopts a particular course of action – let’s call it The Process (e.g. ignoring the tempting bananas) for Sensible and Compelling Reasons – the result of lessons learned from a project perhaps (if you go for the bananas, you get hosed).
The organisation encourages everyone to use The Process (and beats them up if they don’t). However after a while, people change and no-one remembers what the Sensible Reasons for implementing The Process were, and all you have left is a secondary, cultural reason – because “we have always done it that way” (if we don’t use The Process, we get beaten up).
This situation has the following possible outcomes, each with their pros and cons:
- The organisation carries on using The Process because “we have always done it that way”.
- Pro – It may still be perfectly sensible to use The Process because the original Reasons for implementing it still apply (the person with the hose is still there, or the bananas were always poisonous). However,
- Con – It may no longer be sensible to use The Process because the Reasons for creating it have disappeared (the hose person has gone). Using The Process may be at best inefficient, or at worst, dangerous (ignoring the handy supply of bananas may lead to starvation).
- Someone new to the organisation cannot understand why The Process is being used, and implements The New Process, which they think is far more sensible.
- Pro – It may be perfectly sensible to implement The New Process if the Reason for The Original Process is no longer applicable (the hose person has gone), or The New Process by pure luck addresses the original Reason. However…
- Con – If the Reason still applies and The New Process doesn’t address it, then the organisation is in for trouble (we’re all going to get hosed!)
So, it seems to me that there is nothing wrong with having a process embedded into organisational culture so it becomes “the way we do things round here”, provided that the people that use the process know why that process exists, and the process is reviewed periodically to ensure that it is still appropriate.
Under this approach, the monkeys in the story would know that they must not touch the bananas or they will all get hosed. They would periodically review the approach to ascertain whether the Reason for The Process is still applicable (the hose person is still there), and to change the approach if the circumstances have changed.
By now, you are probably wondering how this applies to Project Management.
Whilst it may or may not be appropriate for an organisation to codify the management of an entire project as a process (there are many popular books and courses on the market that have done that already), I think there is a case for an organisation to document and manage any special ways they have developedof doing certain project stages (Start-up, Initiation, Execution, Closure, etc.) and often-repeated aspects of project management (e.g. Risk Management, Procurement, etc.) as processes, with a documented purpose, objective, and review schedule.
That way, someone (the PMO?) is responsible for looking after, say, the risk management process, and is periodically reviewing it with a view to improving it in the light of Lessons Learned by the organisation.
An approach I have used in a Portfolio Office role to embed lessons learned with some degree of success is to pre-populate the organisational Risk Register template with issues that have cropped up in previous projects, scored initially with a medium to high probability – this prompts the Project Manager to actively assess that risk in relation to their own project, and reduce the risk likelihood or impact if it is felt that it is either not relevant, or that the risk has been mitigated.
This approach makes it easy for the Project Manager to draw on previous organisational lessons (making it very clear why they might want to do things in the recommended way), and also puts the control and responsibility in the hands of the Project Manager, who can use their own (and the team’s) experience to judge whether a particular pre-loaded risk is relevant for the project in hand.
How does your project organisation ensure that people know why they do things, and that the organisational project management approach (or process, or methodology) stays up to date and relevant? Let me know in the comments.
This idea (and plenty more besides) are explored further in Ken Burrell’s book Learning lessons from projects, available from Amazon.