BTW I am a program manager ... not an engineer (anymore) so I live the stigma. You forgot about the 9 knowledge areas:guysmiley said:You definitely bring up some good points and I believe they capture the stigma associated with PM’s in general (a good portion of which may be founded)
Using the Scrum methodology under Agile, you have “Scrum Masters” which help facilitate daily meetings and maintain Product Backlogs, Sprint Backlogs, and the Burn Down chart. The entire Sprint is given a timebox and each meeting has a status check on tasks accomplished, tasks planned, and roadblocks. Looking at the PMBOK 5:
Initiating – Getting the Scrum team together and defining feature as a part of the whole
Planning – Product Owner putting Stories into the Product Backlog. Creating the Sprint Backlog
Executing – Coding the Sprint backlog
Controlling – Daily meetings, Burn-down, timeboxes
Closing – Burndown closeout, budget closeout, celebrating, next feature selection
The PMBOK itself states several times that the stages of the lifecycle can be iterative and may overlap. Just like any good MD doesn’t rely solely on the Physicians Desk Reference nor does any good CA rely solely on GAAP, good PM’s shouldn’t rely solely on the verbage in the PMBOK.
Where I do think there is a disconnect is that “traditionally” trained PM’s believe that each stage should be clearly defined (especially requirements/planning) and that ambiguity (defined as a change in project scope) is undesired (hence, practically in most projects, CR processes often discourage change). Engineers typically view these types of PM’s as bureaucracy bringing little value- especially when time they can spend coding is being tied up by requirement sign-offs and approvals. Any PM who does not utilize their resources to accomplish defined project goals as soon as they are available to do so is wasting time, IMO.
Project Integration Management
Project Scope Management
Project Time Management
Project Cost Management
Project Quality Management
Project Human Resource Management
Project Communications Management
Project Risk Management
Project Procurement Management
Scrum Masters are not managers of most of these. They focus on a 2 or 3 week chunk out of a project that may take months. In truth no one knows how long it will take or even if you will build what you thought you would at the start. What you will build is what the customer decides they need in the moment.
But anyway ... we've both proven to the world how dweebie we are ... so probably the sooner this example of geekfestery terminates the better. (i.e. you get the last word).