This post was also published on Go Ahead, Manage.
I’ve been studying to get my PMP certification this fall. The interesting thing about studying for the PMP exam is that good project managers will naturally go through most of the processes, so there aren’t so many new concepts to grasp. However, there is a LOT of theory and terminology to learn!
To help myself make sense of it and study it more efficiently, I’ve made myself an Excel workbook with all the processes inputs and outputs. I thought I would share it here, it may be helpful to you too: Project Processes INs and OUTs -Excel 2007 / Excel 2000-2003 (these have been updated for the 4th edition of the PMBOK Guide)
Happy studying!
No related posts.
{ 7 comments… read them below or add one }
Hi Karine,
What you have done is “OK” but you better add in the Tools and Techniques in addition to just the inputs and outputs. That is, if you want to pass……
If you want a REAL challenge and want to get a good idea why using the PMBOK to manage your project won’t work, try flow charting the inputs and outputs using Mind Map, Visio or any decent flow charting or drafting software……
BR,
Dr. PDG, Jakarta, Indonesia
http://www.getpmcertified.com
Hi Karine,
What you have done is “OK” but you better add in the Tools and Techniques in addition to just the inputs and outputs. That is, if you want to pass……
If you want a REAL challenge and want to get a good idea why using the PMBOK to manage your project won’t work, try flow charting the inputs and outputs using Mind Map, Visio or any decent flow charting or drafting software……
BR,
Dr. PDG, Jakarta, Indonesia
http://www.getpmcertified.com
Paul –
Re flowcharting the inputs and outputs … we actually did this for the 1996 version (by hand; the tools weren’t as readily available then), and everything “worked” in the sense that outputs from one process were mostly shown as inputs to other processes. There were some exceptions, but those were intentional: we were only trying to show the most important interactions.
In addition, the flows were intended to be conceptual. EVERY knowledge area includes the following statement in the introduction: “Each process generally occurs at least once in every project phase. Although the processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here.” Too many people IGNORED this vital information.
In the 2004 version, they got tangled up in their underwear. They discarded the idea of core processes and facilitating processes, and completely dropped the absolutely critical idea of iteration and feedback. By trying to force a high level process description into a low level data flow diagram that was organized by knowledge area rather than process group, they created confusion rather than insight.
Take one simple example … many of the 2004 planning processes have an output called “requested changes” that is an input to “Integrated Change Control.” Adding this output to the flows creates extra lines that don’t really provide any insight into what is really going on: the likelihood that “cost estimating” is to going to generate a change request is extremely small. Heck, there isn’t even a baseline yet!
The fact that change requests are being generated and fed into “Overall Change Control” was already fully captured in the 1996 version.
Duncan
Paul –
Re flowcharting the inputs and outputs … we actually did this for the 1996 version (by hand; the tools weren’t as readily available then), and everything “worked” in the sense that outputs from one process were mostly shown as inputs to other processes. There were some exceptions, but those were intentional: we were only trying to show the most important interactions.
In addition, the flows were intended to be conceptual. EVERY knowledge area includes the following statement in the introduction: “Each process generally occurs at least once in every project phase. Although the processes are presented here as discrete elements with well-defined interfaces, in practice they may overlap and interact in ways not detailed here.” Too many people IGNORED this vital information.
In the 2004 version, they got tangled up in their underwear. They discarded the idea of core processes and facilitating processes, and completely dropped the absolutely critical idea of iteration and feedback. By trying to force a high level process description into a low level data flow diagram that was organized by knowledge area rather than process group, they created confusion rather than insight.
Take one simple example … many of the 2004 planning processes have an output called “requested changes” that is an input to “Integrated Change Control.” Adding this output to the flows creates extra lines that don’t really provide any insight into what is really going on: the likelihood that “cost estimating” is to going to generate a change request is extremely small. Heck, there isn’t even a baseline yet!
The fact that change requests are being generated and fed into “Overall Change Control” was already fully captured in the 1996 version.
Duncan
You are awesome to do this. I started doing the same thing and decided to GOOGLE to see if anyone else did. Since you shared with me take a break, relax and I will share my artwork with you.
http://www.feelingpurple.com
Hey Karine,
I found it pretty good. Appreciate your efforts. Thank you very much. Keep up the good work.
Qhaled
Thank you!
It seems very usefull!
{ 1 trackback }