quantmleap

I’ve recently come across an interesting discussion in HarvardBusiness.org titled “For Startups, How Much Process Is Too Much?“. The author of the article, Eric Ries, discusses the three “Build”, “Measure” and “Learn” stages applicable to start-up businesses. From my perspective, these three stages are very relevant to any new set of processes, irrespective if the business is well established or not. In the context of project management, establishing, or enforcing a set of management and control processes would need to be monitored along these three stages, at least in the early days of process adoption and, most likely, throughout their life-cycle when they get modified and monitored.

Over the years I’ve been involved in a number of governance discussions associated with the integration of a Project Management System (PMS) with a Software Development Life-cycle (SDLC) methodology, resulting in an all-arching Project Management Delivery Framework (PMDF). It never ceased to amaze me how ‘process rich’ (which in this context should be taken as a euphemism for ‘complex’) these frameworks tended to be.

PMP certified project managers who are familiar with the 9 knowledge areas and 5 process groups will be aware of the number of artefacts required to have all the underlying processes managed from a Project Management perspective.

When superimposing the artefacts mandated by the software development methodology (irrespective which one it is) we end up talking about a major overhead imposed on the project, an overhead whose material impact is cost and time for a fixed level of scope.

just to illustrate (very simplistically) the complexity associated with a standard software development project we need to remember that when talking about the PMBOK Execution Process Group, then within the context of a software development project, that will include a number of phases, including Planning, Analysis, Design, Construction, Testing, etc.

Considering the fact that each of these phases can affect or be affected by a large number of factors, including servers, networks, operating systems, security considerations, business areas, software packages, technology limitations, geographical locations etc. it is easy to see why the number of project deliverables (as opposed to product deliverables) could end up being humongous.

The inherent problem with the way most traditional projects are run is that some processes are enforced because they are seen as the only valid way to manage the built-in uncertainty that exists with any endeavour. So rather then following a process because it is ‘the right thing to do’, some (if not many) are followed while the only purpose they serve is providing a control and validation mechanism.

While I don’t have a simple solution to this predicament it is clear to me that in many cases projects are unnecessarily complex and carry a high degree of fat that with some effort could be disposed of. Let’s be honest about it, in many cases, we are so process-holic because we are concerned about the consequences (to us personally) should something go wrong at a later stage and the wolves will be out to look for the scapegoats. We would then need to explain how come we failed to obtain a 3rd revision sign-off to a scope/requirements/design/etc. document from the 9th reviewer/authorizer who happened to be overseas for an extended period of time and neglected to empower another business/technical/customer/etc. person to review and sign-off on his/her behalf.

Changing this situation requires a fundamental cultural change where it becomes ok to make mistakes. I’m not talking about allowing series offenders to rein free in failed projects, but I am suggesting that once we deploy the appropriate professionals into their respective roles we let them collaborate and make ad-hoc decisions to make sure that things are progressing in the most efficient way without being bogged down by prohibitive processes. Let’s empower our teams to agree what is required and what is not required on the way to achieving the project’s objectives. Let’s bring common sense and allow our team members to think about what really needs to be done and not about how to cover themselves should anything go wrong.

Let’s THINK.

Related posts:

1. Good Process Bad Process And Everything In Between
2. Overview of the Earned Value Performance Measurement Process
3. How much process is too much – A tale of two recipes
4. Quote of the day – More on Too Much Process