|
The principles in the Project Workout match the principles and aims given in PMI’s Body of Knowledge. The Project Workout does however simplify many of the processes by taking a different approach to documenting them Project management approaches are converging across the world and hence it is no real surprise that there are few differences in base principles. Anyone reading the Project Workout against a background of PMI should have little difficulty in making the connections. The difference is that The Project Workout is simpler in design and hence is a better introduction for those new to project management (be they VPs, directors, managers or whatever). Naturally there are differences in terminology (e.g. phase versus stage) and there is not a direct mapping between processes. However, once one has a basic understanding of projects, the similarities become more obvious.
There are however some interesting differences which I believe show that the Project Workout reflects how things are moving in terms of best practice. The latest PMBoK is an improvement, but it is lacking the essential simplicity and rigour in the way it presents processes.
- Business led. I put a greater emphasis than PMI on “why we are doing a project”. I therefore draw the business environment and project environment together. PMI stays more general focussing on what a project manager does, assuming benefit and the role of a project sponsor, is a matter outside the project environment. In fact the PMBoK is more “project manager-ment” than holistic “project management”.
- Integration. The Preface to the 1996 edition of PMI says that they had to add a ninth knowledge area of PROJECT INTEGRATION. In the Project Workout, there is no need for such a “knowledge area”. This is because the whole approach is already integrated! If it wasn’t integrated, it wouldn’t be a project! For example in Change Management, I say it applies to schedule, costs, quality/scope and benefits. In PMI these elements were distributed around the various processes and hence the need for “integration” to bring them together.
- Staged approach Both PMI and The Project Workout advocate a staged project life cycle. (In PMI stage = phase) But in Section 2.1.1, PMI talk of the end of the stages being review points prior to starting the next stage i.e. a stage should be finished before the next one starts. In practice this is a rule that is often broken! In the Project Workout I say that a gate is the start point for a stage and is not necessarily the end point of a stage. Hence, the next stage can start as soon as it is ready to start (i.e. the gate criteria have been met) even if every aspect of the preceding stage has not been completed. In this way you can overlap stages without increasing risk and without breaking any rules! PMI is also very fuzzy on how stages are started. It says its process areas, Initiating, Planning, Controlling, Executing and Closing can be used at project or stage level, but does not give any guidance on how you achieve this.
- Full lifecycle? Following on from the above, PMI says it is a matter of opinion whether the project life cycle contains the investigative (feasibility) stages. As a matter of principle I say it should. One failing in enterprise-wide project management now is that the link from NEED to PLAN to DO to BENEFIT is broken by not having a life cycle which goes from cradle to grave. in my view, project management is not just about implementation or build although this is a traditionalist view which, thankfully, is gradually disappearing. Successful projects are “made or broken” in the investigative stages.
- Issues and benefits. PMI misses out two controlling processes that I see as essential: Issues Management and Benefits Management. The former is needed to deal with the things that have gone wrong now (see below) and the latter is to keep a focus on why we are doing the project.
- Risks, issues and change. In the Project Workout, I take the view that:
- a risk is something that MIGHT happen
- an issue is something that has (or is almost certain) to happen
- a change is what you may need to do in order to react to an issue and keep the project viable (Change relates to benefits, scope, time and cost).
Therefore a risk may become an issue which may require a change. On the other hand, PMI tends to use the word “issue” as meaning “something to consider” and therefore it has been interpreted by some users as saying an issue may give rise to a risk which may require a change. “Issues management”, as I define it and as a key control tool simply does not exist!
|
