Scope Defintion section of Scope Knowledge Area -- 3rd Edition PMBOK Guide (Copyright PMI 2004)
When I saw the pre-release PMBOK Guide 4th edition draft, the new data models attached to each process caught my eye.
I liked the 3rd edition’s attempt to capture data and process flow. However, the approach was a bit clumsy, largely because it was done by knowledge area. To be fair, the 3rd does have a set of process group diagrams in Chapter 3 with a decent overview of the flow.
Scope Definition Process Data Model -- 4th Edition PMBOK Guide (Copyright PMI 2008)
While the big picture view those diagrams provided was nice — versions of them exist in the 4th edition — mapping the data inputs/outputs by process is more rigorous and intuitive IMHO. I was OK with the boxes listing the data I/O, but the models are much more effective visual representations of the individual processes.
I’ve provided a couple of examples of the different approaches FYI.
Filed under: Methodology, PMO, Project Management, Scope Management | Tagged: Data Model, PMBOK Guide, PMBOK Guide 3rd Edition, PMBOK Guide 4th Edition, Process Model, Project Management Institute |
Crossderry Blog 
I wish though they would have used a standard notation. IDEF0, BPML, or something recognizable to those working in the process improvement arena. It’s getting better, but it is still not possible to really connect all the dots across the knowkedge areas and process groups.
It’s time I spent some effort and re-mapping their currenr effort into IDEF0.
Here’s a version from ahile back. Still needs to top level interconnections to make it compliant with IDEF0, but that should easy.
http://www.tech.purdue.edu/Cgt/Courses/cgt426/Reading/SeeskinProjectManagement.ppt.
Hi Glen,
Thanks for the comment and link.
I hear you… we’re going through an end-to-end process renovation (FYI, SAP uses ARIS) so it would be nice to have a more full “connection of the dots.” But that’s OK, this lets us validate what we have, if manually. Besides, I hope we’re ahead of the PMBOK by this point :-)
BTW, I understand why they didn’t go with one of the standard notations. Format wars on this topic often become “religious” battles. The discussions about that topic must have been heated. I’d bet that the team had to go generic to get agreement.
Might be just that. Too bad though. From a bit of inside experince at College of Scheduling and College of Performance Management, the leadership doesn’t “get out much” into the mainstream of process modeling.
I’ve switched to the OGC Project, Program, Portfolio Maturity Model for guideance to our clients. It’s much better in the IT domain. In A&D we use the USAF, NASA, and NAVAIR program management guides which are systems engineering focused. In my opinion, PMI does well in construction and early maturity IT shops.