I found it pretty good. Appreciate your efforts. Thank you very much. Keep up the good work.

Qhaled

http://www.feelingpurple.com

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

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