The failure of project specific process descriptions

Admitted, the headline is a bit of an overstatement, but it got your attention, right?

The inspiration to write this came when I actually had to look at our project processes, which project it is doesn’t really matter, if it happened to us, it probably happened to someone else too.

Don’t get me wrong, for a very long time I have been advocating tailoring and choice of processes to be used in a project. But - and to all you trained facilitators the “but” is used intentionally – when opening the projects process description document actually invokes a physical reaction, I feel that we in some way have gone in the opposite ditch here. And to those wondering, no it is not a violent reaction nor a reaction involving bodily fluids, it’s just the sensation telling you “this can’t be right”. In the project in case we now have 56 pages of process descriptions, and I for one have trouble keeping my concentration reading just a couple of pages.

The first process described is a process for developing/describing processes – now here I’m already starting to get that weird sensation that something is not right, and then when I start to actually read the process and come across the sentence:

“The purpose of this process is to establish a process for establishing project processes. “

When I read this the first time, I actually had to say it out loud and start making jokes about it, just to make sure I was still at a reasonable sanity level – and fortunately I was, so I started to investigate why this had happened.

Reading through some of the described processes, alright I admit it I have not read them all thoroughly, I started to understand why this strange feeling had occurred – I already knew what the process was, but how can this be true if the process is project specific? And here is the point where the headline start to make sense, the processes are not project specific, they describe what is already in the development model or just common practice.

This lead me to investigate what the development model actually says about project processes, the following is taken from the description of the work product “Process descriptions”.

“Process descriptions for the project makes it possible to describe the project’s processes in the same way as processes are described in the Development model”

That is all well it makes sense that we describe the processes we adhere to in the same way no matter where we store them.

The description in the actual template makes it even clearer:

“The purpose of this template is to describe both simple and complex processes, which are necessary to carry out in the project and which are not already described in the Development model.”

Aha - here lies what I consider to be the failure of the project specific process descriptions. If we take all what is already described in the development model, because we think we have to fill out every field in the template, we have failed. No one wants, or has the time to, read something of which they already know 80-90 percent in order to gain the last 10 percent of knowledge.

The project specific process description should include, and ONLY include, that which is changed from already described processes - and argue why this is valuable to the project.. This is where they can be valuable, because it is now obvious to everyone where we have chosen to do something different and why.

Now why did I feel it was necessary to take the time to write this? Well – for one thing it made me feel better, thus making sure I am capable of continuing with other tasks. And for those worrying about my physical state, I am now much better – thank you. Furthermore, if this can help others to save time describing and reading the project specific processes, I think the time is well spent.