So if you read my previous post, you’re probably wondering just what this has to do with Project Portfolio Management, ITIL and Fractal Organizations – or why I equate PPM and ITIL – and probably some of you are wondering just what ITIL is exactly. Well, today, let’s talk about Project Management, specifically the processes identified in the PMBOK (2nd through 4th editions if you’re particular), and how a project is a system just like the Honda factory described in my first post.
As anyone of the PMP sheep-dipped flock would readily agree, the PMBOK identifies five process groups:
- Initiation
- Planning
- Execution
- Control
- Closing
What you’ll note in this post and in the next couple of posts is that these are the same processes in PPM, in change management, in an ITIL shop, and pretty much in any organization that’s still semi-successfully fighting the forces of entropy. A “viable” organization is one that has structure in place to fight entropy, and that isn’t about to collapse into chaos a la Enron ‘01.
What is the output of Initiation and Planning? A project management plan….a clearly defined statement of goals and objectives of what the project should achieve, and how it will achieve it.
Skipping execution for a second, what then is the output of the control processes? Like in an assembly line, control processes are put in place to detect variances between the actual world and the desired world, in a sense to identify problems.
And here we have to define our terms. What is a problem? For all intents and purposes, and with a nod to Dr. David Hansen whom I had the pleasure of working with for a couple of years, a problem is a discrepancy (or perceived discrepancy) between a current state and a desired state. The problem identification process then leads to the generation of a solution which is designed to convert the desired state into a possible future state and thence to the new present state.
(In a nutshell, that incidentally describes the entire gamut of project and portfolio management. Consider that for a second.)
At this point we could go off on a tangent about how problem definition requires the identification of values, and perhaps mention the theory that values cannot even exist without problems – or that problems cannot exist in the absence of values…but as I am sure my colleagues would point out, I digress.
Going back to the control processes, their job is to identify any variance between reality and the plan, and then to identify potential corrective mechanisms – or adjustments to the original plan.
Said adjustments pass back into the planning process and get incorporated into the latest and greatest execution plan.
If we take the 30,000 meter overview of a project, in theory it’s a self-correcting organism with a goal and with the sensing mechanism to identify variances, then roll those variances into a revised execution plan – and then roll the feedback from the new path back into the existing control processes. Like even some of the most rudimentary organisms, the project has the following systems:
- Goal/Values Identification Mechanism
- Execution Mechanism
- Problem Sensing Mechanism
…just like the automotive plant in the previous post. There, we had a governance structure which set goals for continual process improvement, the assembly or execution mechanism, and a problem sensing mechanism – the employees who were invited to submit their suggestions.
Next up…..ITIL.