Knowledge Areas
A knowledge area is a subdivision of the body of knowledge that corresponds to a specific set of technical or managerial activities that require a specific set of skills and experience.
There are ten knowledge areas defined in the PMBOK® Guide — such as Time Management, Risk Management, etc. The relationship between KAs and PGs is key to understanding the true role of PGs.
Knowledge Areas and Process Groups
It is at this point that the full value of processes can be seen. For example, in order to be able to manage time effectively in a project, you need to describe the actions clearly, and the process approach has obvious benefits for this. The PGs provide a means of carrying out the analysis and definition of each knowledge area in a consistent manner.[6] The PMBOK® Guide describes the PGs in terms of their action within the life cycle as a whole.
However, I will show that the concept of PGs is much more powerful if it is applied within each KA separately. In any knowledge area, you may need to:
- Do some initial setting-up and define the scope and parameters specific to the corresponding project ("initiating")
- Plan the activities in order to achieve the knowledge-area-related result ("planning")
- These activities will be integrated into a consolidated action plan (this is the link that all of the KAs have to the Integration KA)
- Carry out the actions relevant to the KA ("execution")
- Determine the effectiveness and alignment to the plan ("monitoring")
- Propose additional actions, if any, based on the results of the current status ("control")
- Carry out any knowledge-area-specific actions to terminate some or all of the activities in the KA ("closing")
Since, as explained below, processes aim to provide capabilities required by the corresponding KAs, it is more logical to group them into consistent categories (i.e., PGs) within KAs, rather than defocussing the role of PGs across the entire life cycle.
Knowledge Areas and Processes
The processes for each knowledge area are invoked whenever the need arises — for example, for Risk Management:
- Plan Risk Management (which is really an initiation process, but that PMI has put into "planning") is required in order to determine the overall approach applicable to the rest of the processes (it is known as "Establish [Risk Management] Context" in ISO 31000 [ISO, 2009]). This process needs to be carried out early in the life cycle so that its results can be integrated into the project management plan, but also needs to be reiterated whenever the context is better understood or changes.
- Identify Risks, Analyze Risks (with two categories of analysis), and Plan Risk Responses belong in the "planning" group (Identification is a prerequisite to the Analysis, but is not obviously part of Planning — but there is no "Analysis" PG to place it in).
- Plan Risk Responses is a part of the "planning" group and
- "Monitor and Control Risks" belongs in the "monitoring and controlling" group — although it would be preferable to separate monitoring from controlling.
Note that Monitoring includes:
- Checking the "watch list" of accepted risks
- Tracking symptoms and warning signs of risks for which responses are required
- Identifying triggers for contingency actions
- Verifying the effectiveness of implemented responses
- Watching out for emergent risks
Control implies:
- Executing actions agreed in the approved plan based on validated trigger conditions
- Proposing additional actions to address the current situation
- Requesting risk reassessment (full risk management cycle) under specific conditions such as phase transition, occurrence of major events, etc.
The PMI standards do not propose any explicit "closing" process for risk management[7] although there are a number of closing actions to be carried out. For example:
- When a risk can no longer occur: Exclude it from the active list!
- When the project terminates, transfer the information to the project's recipients, and
- Update risk-related lessons learned.
- Transfer any future, operational uncertainties to the receiving organization.
- Close outstanding project risks and archive the risk register.
A process in one knowledge area can invoke, and provide inputs for, one of the processes in the same or in other knowledge areas. Its execution may require the use of outputs from other processes in the same or in another knowledge area.
Whereas PGs tend to indicate the logical sequence of process activities within a given KA, they are no guide to the order in which processes are invoked between KAs. This feature confirms the earlier assertion that PGs are only really applicable within KAs.
6. Apparently, in the original development of the PMBOK document in 1987, the initial decomposition of the Body of Knowledge was in terms of Knowledge Areas and processes. The concept of "process groups" was introduced later, in the 1996 edition, as a "simplification" in order to cluster together processes with similar characteristics.
7. There is, in fact, only a single process in the "closing" PG in the PMBOK® Guide 6th Edn.
|
Processes
