Marginalia
• In the beginning of the chapter «Project Scope Management» the PMBOK® mentions the first time, that the processes " although [...] presented [...] as discrete components with well-defined interfaces [...] in practice [...] can overlap and interact [...] " (comp. PMBOK3, page 103). This is a good and a bad message: On the one hand this sentence announces that there is a gap between the theory of the PMBOK® and the praxis of the project managers. In some situations they have to act in a still undocumented way. On the other hand this sentences announces that the project managers have an expert knowledge which still can't be fixed in an algorithm. myPmps focusses on the explicitely documentable structure: following some basics of the AI we believe that we have only understood what we have covered in an expert system. Naturally we know that there is still a very long long way to go before we have the project managers inside of our computers. But the integrated sequential survey of all project management processes offerd by myPmps and the structure of the myPmps Process Cards following the IO-Paradigma are two little steps in that direction.
(2) Project Scope Management
Task of the Project Scope Management is to ensure, that all of the required targets will be met ... and nothing more: This knowledge area contains those processes which are "[...] primarily concerned with defining and controlling what is and is not included in the project" (comp. PMBOK3, p. 103).
For being able to fullfill this task, the Project Scope Management has also an internal structure which follows the pattern of «plan», «execute», and «control»:
- At first the management of scope has to be planned. It's the process which "[...] documents how the project scope will be defined, verified, controlled, and how the work breakdown structure [...] will be created and defined".
- Then the scope has to be defined by writing the project scope statement. Briefly spoken the project scope statement contains what the project will deliver.
- After having fixed what the project shall deliver one has to write down on the one hand, how the targets shall be reached, namely which steps must be executed to reach the aim. This is the act of creating the work breakdown structure by "[...] subdividing the major project deliverables and project work into smaller, more manageable components".
- After having fixed what the project shall deliver one has to specify on the other hand how the project can proof that the demanded deliverables really have been delivered.
- And finally one has to control (and integrate) the changes of the scope: The real world is a collection of changes. One can not act in the world without reacting on changes.
(comp. PMBOK3, p. 103)