The PMBOK doesn't do the change management process justice either. Once a change has been approved, the project plan changes, the baseline changes. I have seen large organizations that fail to understand what change management does to the project plan. They continue tracking to the original baseline, scope and budget and never require the PM to re-baseline. Not all organizations have the level of project management process built to accommodate. A true PM professional must know and pull these tools from their tool belt.
But what is truly missing is how to classify projects by size, complexity, budget, timing. Program management does a little better job of it. Smaller projects would have fewer quality and budget review points while larger projects obviously would have more, but in the end, it depends on the sponsors and how tightly they want it monitored.
I recently spoke with a civil engineer that just passed the PMBOK, she is managing multi million dollar city water systems. This person complained the PMBOK was geared too much towards software development methodologies. I have also read job descriptions that have "project manager" as a title, but upon reading the duties, it is a lead or architect that they are seeking and nothing about managing scope, budget, very little on timelines, nothing on baselines, or change management.
I look at the PMBOK standard vs methodology using this rule. Can this standard be used for building a new apartment complex, for a city water system and for developing new software? If it works for all, then it should be in the PMBOK. If not, then you are looking at an industry specific standard.
What do you think? Is the PMBOK too software development methodology focused? What other standards (not methodologies) do you see missing from the PMBOK?
Armada Business Consulting, Inc.
Need help getting turning standards into execution? Call me. For more information contact Trish at firstname.lastname@example.org.