Every time I am delivering a course or workshop on the PMBOK® Guide it is like love-hate relationship.
Project management is my passion and what I have been enjoying full-time for at Mounir Ajam Personal Website. I have also been a PMP (was) since 1998 and have been involved or using the PMBOK® Guide since 1997. This is why when I am helping people learn about project management it is a sheer pleasure. However, when I am delivering a workshop on the PMBOK® Guide it is a mix feeling.
I think the PMBOK® Guide is a very good book but there are so many areas in the PMBOK® Guide that is misunderstood by practitioners and I am usually defending and re-explaining the PMBOK® Guide in those situations; like the difference between process groups and phases and that the process groups repeat across the project life cycle with every phase.
On the other hands, I often see areas in the PMBOK® Guide that seems like wrong or not consistent. Since PMI does not offer us a person or a unit to answer questions – we are left without understanding or explanations.
Here are some points:
In the 4th edition of the PMBOK® Guide, in defining the charter, it listed, “the charter is the document that authorizes the project or phase”; in the fifth edition it became “the charter is the document that authorizes the project”. The phrase “or phase” was dropped. Why? Was it an error? Was it on purpose? If on purpose – does it mean the definition of the charter is different now?
Audit is not mentioned enough in the PMBOK® Guide.
Every time I am leading a class on the PMBOK® Guide I ask the participants “when you hear the word audit, which process group do you relate it to?” Often the answer is control since audit is a review function. However, here is the way the PMBOK® Guide deals with audit.
Quality audit is listed as part of quality assurance and quality assurance is listed as an executing process. Some practitioners believe quality assurance should be in control but PMBOK® Guide keep it in executing; fine let us accept that audit is executing.
Risk audit is listed as part of control risk; a controlling processes. I guess it would not be possible to put it in executing since risk does not have an executing process. However, are we creating an inconsistency here?
Let us move to procurement. Procurement has executing process and controlling process. In this case where would audit go? Is it an executing or a controlling? It is in closing.
Can anyone explain the above?
Control the Team
There are control processes for every knowledge area – except human resource management. Why? Do we have activities to control the team? Adding resources, reducing resources, rewarding or warning a team member – are not these control activities?
Two editions ago, the process manage team was in control and we are assuming because the process name has the word “manage” it was moved to executing. Does that mean the 2004 edition (or earlier) was in error to have a control process for HR? If not – was moving the process wrong?
What we think is that process should have been split like there is manage stakeholders and control stakeholders; manage communication and control communication.
In planning, when we create the WBS, we end up with a list of work packages. Work packages are the deliverables that we produce – while executing. When we are done with them – we validate scope; meaning validating the work packages.
Therefore, it makes sense:
- In planning we decide on work packages
- In executing we deliver them
- In controlling we validate them
Oops …. There is no executing process in scope management? Then where is the deliver work packages process? For some reason – the assumption is that the integration process “Direct and Manage Project Work” cover this. Does? Does the PMBOK® Guide clearly says this? Here I want to be picky – the name of process is Direct and Manage so it is about oversight – management – not physically “doing” the work. Are we missing something here?
I can visualize the answer but what do you think?
There are other areas but enough for today – I need to start my class and talks about project management failures that contributed to the Titanic disaster.