Deliverable 101: Get it done, more or less – how much process is enough?

Deliverable 101: Get it done, more or less – how much process is enough?

An American, German, Italian, Indian and Brazilian meet for a hardware project kickoff to discuss the implementation approach. This sounds like the beginning of a bad joke….actually it what came to my mind as I was thinking about one of my global clients getting FDA examined.

Actually having the above nationals meet for a discussion about project delivery could create quite the disagreement. Happily generalizing: the Germans and Americans (and I am referring to US Americans – so Canadian please don’t be insulted) are somewhat similar in their reliance on process in project management. The main held belief is that project management failures stem from bad planning and too little process. Send an American to PMP training, and when he’s back at the office he will write a 120 pages project plan that covers all the 10 knowledge areas leaving nothing to chance, but the project success. His risk management register is a daunting 7 sheets excel workbook with 25 risk categories. Meanwhile, the change control template is 5 pages long and short of asking the maintenance-staff for change approval, all project stakeholders are required.

What happens next you might ask?  The project fails. Really! Isn’t this somewhat inconsiderate of the project to fail after so much process has been invested? It seems that the documentation breeds a life of its own; the process monster turns to be a separate project running in parallel to the real project. When this is the case I am tempted to condemn all process in project management as a redundant obstacle to project performance.

On the other hand; send an Italian to PMP training and after 10 espressos on the morning of the first day, he will denounce PMI and ask for shortcuts to passing the exam. Back at work and after receiving his PMP, he will use the PMBOK as a paper weight, making airplanes from the risk register that his American (US that is) counterpart has sent him.

However, having too little process is also a hurdle. We need process to create a structure and a basis for communication. The process is our model for delivery and acts as a guide, without it we will be doing the same mistakes over and again.

How much is enough?

A few years ago I was consulting the IT department of a global manufacturing organization. 4 years before, the PMO defined 18 processes for business analysis including templates and work instructions. The crown jewel was a 70 pages project plan with a business requirement document. I asked them how many processes where implemented at present. The answer was, none. We went back to the drawing board, we defined the least amount of process necessary that would still allow top down control on the one hand and burden free development on the other. Yes, it worked, in two years we had a robust and yet lean process for IT product development. It was just what we needed.

Am I saying that you must eliminate 90 percent of process? Not quite. Indeed, most of the process redundant. Some of it is required by regulation such as Sarbanes Oxley while other is truly wasteful. Here is a way to analyze wasteful process. Create a value stream snapshot of your project delivery and analyze process elements built into it. Now, build an alternate bottom up snapshot of delivery that has only the necessary process elements.  Most likely you will find a 30-50 percent difference between the two – can you justify the process steps which constitute the difference?

Based on the two snapshots, define process which adds value to the product, process which is required but adds no value, and process (as well as tools, templates, procedures, work instructions etc.) that isn’t required and doesn’t add value. Chose a pilot project and deliver it with a lean and mean process approach. Let yourself be amazed. Time and again I am surprised how much time of actual delivery is spent on wasteful process.

Going philosophical

How is it that the bigger the company the more process it has? Some argue that process is a way to cover our behind, and the bigger the company the more behind there is to cover. Actually, looking deeper there is a more disturbing reason. We solve our uncertainties with more process. We believe that we get a better grip on reality by having a process that dissects the step into more steps and asks everyone to check, verify and analyze. This seems logical at first, however it really isn’t. How can we possibly reduce uncertainty with process?

Guess what, the added process becomes an obstacle for effective delivery. Since we fail in delivering we create more process to ensure we deliver better next which is naturally counterproductive. Next we create a PMO to manage the complexity and since they have to justify their salaries, create even more process. In an ever down spiraling progression, process always increases. How is that for a metaphysical paradox?

And here is a last thought

Most of process problems are better solved by creating a structure which supports delivery. Agile is an example for a structure that makes process redundant through a change of delivery structure.

Michael is the proud author of: Influence and Leadership Building Rapport in Teams

Leave a Reply

Your email address will not be published. Required fields are marked *