In two articles written in early January, 2025, I’ve briefly outlined how Artificial Intelligence has been introduced into the new and upcoming PMBOK Guide, 8th edition. Currently, the PMBOK Guide, 8th Edition is in draft form and was made available for public comment in December, 2024.
Artificial Intelligence and its usage in project management are beginning to take shape. A number of small to large AI projects are being launched. It's not just by large organizations that will provide the AI “electricity” for everyone, similar to cloud computing.
Rather, as I’ve observed and experienced with various AI tools, mostly large language models (LLMs), AI will also be powered by smaller companies that have their own AI “electricity supply.” I’ve noted it in another recent article on the upcoming PMBOK guide, 8th edition and AI.
In AI projects, project managers will play an important role. Many areas of project management such as schedule management, cost management, risk management, and resource management etc. can benefit from the support of AI.
The Project Management Body of Knowledge or the PMBOK Guide from the Project Management Institute is one of most widely used guides for project management. If you are a PMP, an aspiring PMP or a project management practitioner, this upcoming event on April 30, 2025, is a must-attend.
In the PMBOK Guide, you not only have Artificial Intelligence as a specific tool and technique (AI) but also related ones.
In my upcoming webinar, we are going to cover many aspects of PMBOK and will see the entry of AI into the guide. It’ll be a comprehensive introduction. This will be conducted by Master Projects for Unlimited Growth (MPUG).
Join us in this webinar to know more on PMBOK Guide, 8th edition and its integration with AI related content.
The links are noted below. Registration is closed.
Webinar: The New PMBOK Guide and Artificial Intelligence – A Comprehensive Introduction
Date: April 30, 2025
Time: 12:00 PM - 1:00 PM EST/EDT, US 09:30 PM - 10:30 PM, IST, India
The Upcoming PMBOK Guide, 8th edition - What's New?
PMBOK Guide, 8th Edition – Principles
PMBOK Guide, 8th Edition – Performance Domains
PMBOK Guide, 8th Edition – Process Groups
The New Process Map in the PMBOK
Artificial Intelligence (AI)
PMBOK and AI - How do they fit together?
It’ll have face-to-face question and answer (Q&A) session.
Quick Note: The image at the top-left of this teaser was generated by an AI model using a recent photo of mine. The model created the image in the Ghibli style.
Join us for this webinar on the PMBOK Guide, 8th Edition and Artificial Intelligence. It's the first such webinar in the world.
The PMBOK® Guide, 8th edition, draft version has been made available on the Project Management Institute’s (PMI®) website. Like process group related processes and performance domains, the content for Agile has also seen changes.
First and foremost, parts of the Agile Practice Guide (APG) have been directly included in the PMBOK Guide, 8th edition. The APG may remain as one of the reference sources. In some areas, it has good content and explanations with respect to certain situations.
This post is in continuation of the earlier post on PMBOK Guide, 8th edition:
While the above linked post is more with respect to the guide part of the PMBOK Guide, this article is about both – the standard and the guide.
Overall, the PMBOK guide (6th, 7th and 8th editions) can be seen as a human – with a head (the standard part), body (the guide part) and legs (the terms, definitions etc. on which the head and body stand). This is shown in the figure to our left.
Again, do note that it’s a draft edition and hence the approved one will have additions, removals and modifications. A number of new contents can also be added.
Now, let’s see the changes briefly with respect to Agile, Hybrid and related content.
Development Approaches
The spectrum of development approaches remains the same in the PMBOK, 8th edition:
Predictive: It’s at one end of the spectrum. It’s used when requirement churn is low.
Adaptive: It’s at the other end of the spectrum. It’s used when requirement churn is high.
Hybrid: It sits in the middle and is a combination of predictive and adaptive.
Do note that the development approach is completely different from the project life cycle. Many confuse the two. The below three are distinct and separate in the PMBOK Guide, 8th edition.
Project Life,
Development Approach, and
Scheduling Approach.
Nevertheless, additional content has been put into various development approaches.
Predictive
This approach is mainly plan-driven. While going for the fully predictive approach (remember it’s a spectrum), one can follow the Inputs, Tools and Techniques, and Outputs (ITTOs) of the earlier mentioned 40 processes.
In the PMBOK 6th edition, there are 49 processes. You can watch it here. If you have understood the processes clearly in PMBOK6, it won't be very hard for you in PMBOK8. However, the most important part is the sequencing, flow of project management activities and understanding of the key ITTOs.
Now, considering PMBOK7 and PMBOK8, there have been big changes in the performance domains, which are governed by a set of principles. As noted in my earlier articles on PMBOK Guide, 7th edition (Part – 1 and Part - 2), the following one is still valid.
Principles guide the behavior. Performance domains are broad areas of focus to demonstrate that behavior.
In addition, there have been changes in the ITTOs. Completely new T&Ts are added for the first time. For example, new T&Ts have been added such as:
Artificial Intelligence (AI)
Machine Learning (ML), which is part of AI
Natural Language Processing (NLP)
The advantage with AI is that it can use vast amounts of project data/information, past data such as historical information, and can also take current, real-time data to make informed decisions, or can augment your ability to make decisions.
In addition, schedule optimization, resource optimization (supply and demand), schedule compression, detecting overallocations etc. can make use of Artificial Intelligence.
Adaptive (Agile)
Agile is both iterative and incremental. It’s a change-driven approach.
As you go through the PMBOK, 8th edition, you will find a number of tools and techniques (T&Ts) to manage Agile project. These are explicitly mentioned in the ITTO tables of the processes, which was not the case earlier. Examples are:
Daily Coordination Meetings,
Retrospective Meetings,
Project Canvas (yes, can be used in Agile too!). [In fact, the concept is used in Lean approaches.]
Backlog Management,
Backlog Refinement, among others
Coming to the inputs and outputs (I&Os), a number of them are newly introduced, such as:
Backlog,
Skill Matrix (in my view, can be used in all approaches),
User Stories, among others.
Hybrid (Adaptive and Predictive)
This is a combination approach using both predictive and adaptive, but is used across industry verticals. In one of my earlier articles in 2024, I noted the following:
As per PMI report, Hybrid usage (31.5%) is more than Agile (24.6%) among project professionals.
Now, the PMBOK, 8th edition (with the standard) outlines four popular hybrid-agilemethods:
Agile Development Followed by a Predictive Rollout
A Combined Agile and Predictive Approach Used Simultaneously
A Largely Predictive Approach with Agile Components
A Largely Agile Approach with a Predictive Component
Launched in 2021, the Certified Hybrid-Agile Master Professional (CHAMP) courseprovides a large number of hybrid models. The certifications is hands-on, practical and in-depth following all three: Hybrid-Scrum, Hybrid-Kanban and Hybrid-Scrumban.
CHAMP is the only such hands-on, hybrid-agile certification in the world.
Conclusion
As the PMBOK Guide changes and brings in new content, of course, there will be an impact on the future Project Management Professional (PMP) exam. It takes time to build on the new exam, which is effectively based on the exam content outline (ECO).
I’d also strongly recommend that you take the PMP exam as soon as you can, if you’ve prepared on the earlier editions of the PMBOK guide and APG. That way you don’t have to go through an entire set of new content.
The PMBOK® Guide, 8th edition is currently available on the Project Management Institute’s (PMI®) website. It’s a draft version. There has been a complete overhaul when you compare the Project Management Body of Knowledge (PMBOK) Guide 8th edition with the 7th edition or the 6th edition. Nevertheless, commonalities remain. One fresh introduction has been with respect to Artificial Intelligence (AI).
You can give your comments by visiting this page within the timewindow:
If you are a Project Management Professional (PMP®) from my sessions and/or have used my courses and books on project management, portfolio management, risk management, agile management among others, I’d strongly suggest that you go through it and give your review comments. PMI has been a pioneer in the field of project-program-portfolio management for decades and has made enormous contributions towards it.
Do note that it’s a draft edition and hence the approved one will have additions, removals and modifications. A number of new contents can also be added.
Now, let’s see the changes briefly on the Process Groups and Performance Domains.
Process Groups (PG)
The Process Groups (PGs) have made a comeback in the PMBOK 8th edition, draft version. Yes, indeed! In the PMBOK 7th edition, it was completely removed with the exception of a few lines in one of the Models-Methods-Artifacts (MMA) sections.
In fact, a note in the PMBOK8 draft is as follows:
“This eighth edition reintroduces the ITTOs and process descriptions within the organization structure of the project management performance domains.”
I agree with this approach and idea. It gives aspiring Project Management Professional (PMPs) to know what project management actually is, with more clarity, rather than high content in abstract. For a newcomer and even with experienced PMs, it’ll be much more useful.
The process groups in the PMBOK, 8th edition, remain the same:
Initiating
Planning
Closing
Monitoring and Controlling
Closing
However, the number, name, content, and sequencing of the processes are different. If you have used my PMP Course, you’d quickly capture and write down the processes on your own in a sequence.
A New Process Map
Following are the processes across the PGs in PMBOK Guide, 8th edition.
In my sessions, books and courses, I explain the importance of the processes and how they interact. It’s a must-know for anyone aspiring to be a PMP. The sequencing of processes should be on your finger-tips to really know and understand project management.
In addition, if you understand the process map and the flow as well as interactions of the processes, it’s much easier to understand the PMBOK Guide.
Performance Domains (PD)
Performance Domains (PDs) are completely changed in the PMBOK Guide, 8th edition. Earlier in the PMBOK Guide, 7th edition there were PDs such as Stakeholders, Team, Development Approach and Life Cycle (DALC), Uncertainty, Measurement, among others.
The PMBOK8 resembles more like the PMBOK, 6th edition. I agree with this approach, as real-world project managers need to know what actually happens on ground. PMBOK6, in fact, was more suitable in this regard.
The knowledge areas (KAs) in the PMBOK6, 6th edition final approved version, were:
Integration Management
Scope Management
Schedule Management
Cost Management
Quality Management
Resource Management
Communication Management
Risk Management
Procurement Management
Stakeholder Management
The performance domains (PDs) in the PMBOK Guide, 8th edition draft version, are:
Governance
Scope
Schedule
Finance
Stakeholders
Resources
Risk
Do note that the two top changes are:
1. It’s not called a knowledge area, but a performance domain.
2. There is no “management” word involved in the PDs, but simply the name of the PD. For example, inplace of Schedule Management, it’s simply called Schedule.
What Happened to Quality, Communication and Procurement?
The first thing (again if you have followed my courses and books or sessions), you’d have noticed are the following:
Integration Management is notthere.
Quality Management is not there.
Communication Management is also not part of the list.
Procurement Management, too, is not part of the list.
So, what happened to them?
Again, as I went through, these are the changes:
Integration Management is now Governance PD.
Quality Management content (significant aspects) has been moved into Scope PD.
Communication Management is moved into Stakeholders PD.
Procurement Management content (some aspects) has been moved into Schedule PD.
For the performance domain, you also have these additions:
Key Concepts
Processes
Tailoring considerations (in many places).
I find these to be very important and useful.
Also, in every performance domain, you’ll have:
Interactions with other domains: For example, how Governance PD interacts with Scope, Risk, Resources PDs, among others.
Check Results (Outcomes): This is another important aspect. You need to know when the respective PD will be considered to be successful.
Knowledge Areas and Performance Domains are two different concepts. You can read these two articles to learn more.
A key and important addition in the PMBOK Guide, 8th edition is the direct addition of rapidly evolving Artificial Intelligence (AI) related content. For example, in Schedule PD, there is a section on AI and ML (machine-learning) based schedule optimization.
PMBOK8, in fact, has a dedicated section on it – X3: Artificial Intelligence.
Among others, this section covers AI in project management context, strategies for AI adoption, and above all, usage of AI in various PDs such as Governance, Risk, Schedule, Stakeholders.
Conclusion
If you are a keen learner of project, program and portfolio (PPP) management, I’d strongly recommend that you go through the new draft for the PMBOK Guide, 8th edition.
The guarantee has no hidden T&Cs—just take the exam!
The free article follows.
--
As I frequently interact with project and risk management practitioners, the below two questions on unknowable-unknowns and unknown-unknowns come up. They are quite confusing for many. The existing literature doesn’t help as they are written with complicated language and/or complex explanations. The questions are:
What are the differences between Unknowable-unknowns and Unknown-unknowns?
Where does emergent risk actually fit in (in the above context)?
To understand, let’s simplify.
The Fundamentals
First, let’s understand, what is the difference between unknowable and unknown?
Unknown: You really don’t know. It’s definitive.
Unknowable: You are not likely (or unlikely) to know. It’s probabilistic.
When we say definitive, it’s certain that you don’t know. For example, it’s possible you don’t know some new technologies, design or frameworks.
When we say probabilistic, a chance factor comes in. There is a chance (usually high) that you don’t know. For example, when disruptive technologies start to pervade, you are unlikely to know the impact.
Simply put:
When we say unknown, it means there is a lack of knowledge or untapped knowledge.
When we say unknowable, it means there is not only lack of knowledge, but also exploration is not probable. In this case, it’s untappable knowledge.
Now, let’s see what are emergent risks and novel risks?
Emergent Risks
As per PMI’s Standard for Risks in Portfolios, Programs and Projects, this is the definition of emergent risks:
“A risk that arises which could not have been identified earlier on.”
I agree with this definition, but not the subsequent explanation of PMI on emergent risks in the context of the unknowable, though I’ve adopted them in my books and courses. In this case, one can say these risks could not be identified because they were unknown at that time, but later on, the risks emerged.
When one says “emerge”, a pattern is forming, but not clear. It’ll emerge.
Novel Risks
I provide this definition for novel risks:
“A risk that arises which was not probable (improbable) to be identified earlier on.”
Here you can say, these risks were improbable to be determined and later it came-up unexpectedly, hence the term “novel” or completely new – not emerging!
When one says “novel”, there is no pattern formation at all. It is completely new.
Also, did you notice the distinction in the definitions?
For an emergent risk, we could not have identified earlier, which can be due to many factors such as lack of knowledge, understanding or considering various scenarios.
For a novel risk, we have a probability factor coming into play. It was improbable to be identified earlier because exploration of such a risk was improbable.
Unknown-unknowns Vs. Unknowable-unknowns
Now, let’s see the difference between these two:
Unknown-unknowns: You don’t know that you don’t know. This is pure ignorance. Knowledge wise, it’s untapped knowledge. It’s part of the Complex domain.
Unknowable-unknowns: You are unlikely to know that you don’t know. This is not pure ignorance. Knowledge wise, it’s untappable knowledge. It’s part of the Chaos domain.
The emergent risks are actually unknown-unknown risks or simply unknown risks, whereas novel risks are actually unknowable-unknown risks or simply unknowable risks. Again, do note that my explanation differs from many, including PMI. The figurative representation is shown below.
I’d also strongly recommend that, you read the followings articles:
Known-known is conscious knowledge or facts. You know that you know.
Known-unknown is conscious ignorance. You know that you don't know.
Unknown-unknown means unconscious ignorance. You don't know that you don't know.
Unknowable-unknown means unexplorable and unconscious ignorance. You are unlikely know that you don't know.
Another question that comes-up is this: How about Black Swans? Is it related to unknowable-unknowns or unknown-unknowns? To a certain extent, black swans are unknowable-unknowns. Because these result in chaos. More specifically, black swans are distinguisged with their very low probabilities, but catastrphic impact. In other words, black-swans comes with a chance factor (very low), but with tremendous effect (very very high).
If you have understood so far in this article, then you have understood the difference between unknowable-unknowns, unknown-unknowns and the associated risks such as emergent risks and novel risks.
Over
a decade ago, I was put in charge of a group of projects. One of the
projects had been running for almost a year, but had never seen a single
live release to the customer! I realized there were too many unresolved
risks, and asked the concerned project manager to put risk management, a
new concept in the organization, as a top priority. Post identification
and qualification of risks, any risk above the risk threshold value had
to be brought down. If that was not done, I advised him no one should be allowed to work on the concerned project tasks.
This touched a raw-nerve.
One
day a senior executive dropped by and asked about the guidance I had
given to the project manager. In his mind, risk identification,
qualification, and addition of reserves et al are sufficient, and I
should not have stopped people from working on tasks.
My
response was: “When you know a cyclone is going to hit in five days, do
you wait to act on the fifth day or do you start immediately working to
mitigate the expected impact?”
To
elaborate a bit more, if a cyclone is about to hit, will risk
identification help? Will risk qualification help? You know it won’t do
much, though needed. How about quantification and adding reserves – say
various cyclone shelters, food stock, etc. – will those help? Yes, but
not fully. What is most needed in such a situation is risk mitigation.
We can’t change the probability of the cyclone, but the first act of
mitigation would be the evacuation of people. Risk mitigation is one
risk response strategy.
In this article, I’d like to explore various such strategies. At
this stage, it’s important to note that risk response strategies are
applicable in cases of both negative risks (threats) and positive risks
(opportunities). You can learn more on individual project threats and
opportunities here.
Risk Response Planning The
Project Management Body of Knowledge (PMBOK®) guide from the Project
Management Institute (PMI®) has a specific process to develop various
risk response strategies. It’s called Plan Risk Responses, and it’s
defined as follows:
Plan
Risk Responses is the process of developing options, selecting
strategies, and agreeing on actions to address overall project risk
exposure, as well as to treat individual project risks.
The
goal here is to develop risk response options, strategies, and actions
for both individual project risks and overall project risk. In other
words, you are planning to minimize the threats (negative risks) and
enhance opportunities (positive risks). With this process, the project
manager allocates resources and inserts items and activities within the
documents and the project management plan, in order to address said
risks.
Obviously, both the Risk Register and Risk Reports are
needed as inputs to address such risks (along with the Risk Management
Plan). Remember, we are addressing both individual risks and overall
project risk. See this depicted in the below flow diagram, with the highlighted process of Plan Risk Responses.
As
shown, once you have the risk response strategies and associated
actions, both the Risk Register and Risk Report have to be updated. You
can learn more about the above flow diagram in this article on risk management framework.
Risk Response Strategies – What Happens? In
the Plan Risk Responses process, for the negative risks, we are trying
to move the High Probability and High Impact risks to be of Low
Probability and Low Impact, by taking response actions. The reverse is
also true.
I’ve explained this in the below video [duration: 3m: 53s], the content of which has been taken from RMP Live Lessons, Guaranteed Pass. For the best experience, you may want to go full-screen in HD mode and plug-in your earphones.
Risk Response Strategies for Threats Now, let’s look at various response strategies for individual negative risks or threats.
Escalate Response Strategy
The escalate response strategy is used when the project team or the project sponsor agrees that:
The threat is outside the scope of the project.
The project manager does not have the authority for the proposed response.
At
this point, the risk is escalated to a program or portfolio or other
suitable level. The project manager determines who should be notified.
The escalated entity should be notified and the entity should also
accept it. After escalation, the risk is not monitored by the team, but
may be recorded in the Risk Register.
Example: A risk occurring in another project is impacting your project, so you escalate it to the level of a program or a portfolio.
Avoid Response Strategy This
response strategy is usually used for high priority risks, i.e., risks
with high probability and a big negative impact. We can do two things
here, either:
Eliminate the risk completely, or,
Protect the project from its impact.
Most of the time, the first (avoidance or elimination) is taken by changing the project management plan.
Example: You use a reliable technology platform for your project, instead of an unreliable, but cutting edge one.
Transfer Response Strategy*** UPDATED *** Transfer
of a risk is done by shifting the impact to a 3rd party, who will own
the response. This method is usually best used for low impact risks. A
risk premium has to be paid to the 3rd party. Example: You go for an incentivized contract, such as Cost Plus Incentive Fee (CPIF), to transfer the risks to the buyer.
For more information about incentivized contracts, go to these articles of point of total assumption and range of incentive effectiveness.
While the former is for Fixed Price Incentive Fee (FPIF) contract, the
latter is for CPIF contracts. Do note that by transferring the risks,
they are not gone! Rather, they will be addressed by the entity to which
risks have been transferred.
Mitigate Response Strategy*** UPDATED *** With
a mitigate response strategy, you try to reduce the probability and/or
impact of the risk. This is used for high priority risks (with high P
and high I values). After reduction, the risk score should be within an
acceptable threshold limit. You can learn more about the usage of risk
threshold in this article on end-to-end risk management.
Example: You first build a prototype for a highly scalable product before going for full-fledged development.
Where mitigation is not possible due to probability, it’s best to look for mitigation responses which pull down the impact.
Accept Response Strategy*** UPDATED *** In
risk acceptance, no action is taken unless the risk occurs. Like
transfer strategy, it’s used for low priority threats or used when it’s
not possible to have a cost-effective solution which addresses the
threat. The Project Management Plan is usually not changed in this case.
A common risk acceptance strategy is to use contingency reserve. Example: If there are frequent climate changes, you may accept such as a risk for your project.
Risk Response Strategies for Opportunities Like threats, there also can be a number of risk response strategies for individual positive risks or opportunities. Escalate Response Strategy It’s
very similar to the one we have seen earlier for negative risks, except
that in this case it is for positive risks or opportunities. It’s used
when the project team or the project sponsor agrees that the threat is
outside the scope of the project and the project manager does not have
the authority for proposed response. Again,
after escalation, the risk is not monitored by the team, but may be
recorded in the Risk Register. This is another key distinction for this
strategy compared to other strategies. Example: A benefit occurring in another project has implications for your project and you escalate such to the level of a program. Exploit Response Strategy With
this risk response strategy, you seek to eliminate uncertainty by
ensuring that the opportunity is realized or that it definitely happens.
It’s used for high priority opportunities. A payment of a risk premium
can be involved for the party taking on the opportunity. Example: Using talented resources to complete work early with less cost. Share Response Strategy In
this case, you allocate some or all of ownership of the opportunity to a
third party. Because it’s a share response strategy, both sides benefit
– the first owner and also the sharing owner. It can be considered the
“mirror” part of transfer response strategy, which we have seen earlier
for individual negative risks. Unlike
transfer, it is not completely handed over to another party. It is
shared; however, risk sharing, like transfer response strategy, often
involves premium payment. Example: Your
organization forms a joint venture or partnership with another
organization to execute the project considering the benefits involved
for both. Enhance Response Strategy With
this response strategy, you increase the probability and/or the impact
of an opportunity. Early enhancement is considered more effective. If
you cannot increase the probability, try to increase the impact. Example: You add more features to a product to sell more products. Accept Response Strategy*** UPDATED *** In
this case, if the opportunity arises, it will be taken advantage of,
but not actively pursued. It’s usually considered for low priority
opportunities or if no cost-effective solution is available. Example: A new project will takes advantage of a tax break, if an expected legislation is passed.
A Real-World Example and Exercise Now that we have reviewed various risk response strategies, let’s do an exercise.
Scenario: You
are driving to reach your office and become aware of possible heavy
traffic on your traveling route through a radio warning or via global
positioning system (GPS). Regardless, you have to reach your destination
to attend an important meeting. You have the following options
available, outlined in the below table.
Can
you tell, based on the situation presented, which risk response
strategy will best fit? Do note that the scenarios presented are for
negative risks, and your response should be one of the strategies for
each question.
I would suggest that you try this exercise on
your own first before checking the solution, but I’ve explained in the
below video [duration: 7m: 20s], taken from my RMP Live Lessons course
what I advise. This clip also addresses an additional question related
to contingency reserve and how it’s used in our scenario.
Comparison As
we reach the end of this article, I’d like to draw a comparison between
the risk response strategies for threats vs. opportunities in the below
table: Finally,
it’s not that an individual threat will have a single response
strategy. If a threat can’t be avoided, then a project manager can
mitigate to a level where it becomes viable to accept or transfer it.
Similarly, if an opportunity can’t be fully exploited, it can be
enhanced to a level where it can be viable to accept or share it.
First, it’s a complexity model and it helps making decisions in a complex environment. The Project Management Institute (PMI) defines complexity as noted below:
"Complexity is a characteristic of a program or project or its environment that is difficult to manage due to human behavior, system behavior, and ambiguity."
Simply put, a complex thing is difficult to manage. The sources of complexity can be human behavior, system behavior, ambiguity, uncertainty, among others. All of these sources and complexity itself can result in risks.
The Cynefin Framework has five problem and decision-making contexts (or domains). This framework helps in detecting the cause and effect relationship, which in turn helps in decision-making.
Now, let’s understand the five domains in this framework. The framework’s five contexts are shown in the below figure. Later, we will learn how to apply it in Risk Management.
Obvious (Simple):
The cause and effect relationship is obvious. You know the questions and know the answers.Hence, little to no expertise is needed.
The approach used here is sense-categorize-respond. You sense the environment/context, categorize them and based on that you respond.
Best practices are applied to make decisions.
Complicated:
The cause and effect relationship is not obvious. You know the questions, but don’t know the answers and hence, seek expert knowledge to analyze and get a range of answers.
The approach used here is sense-analyze-respond. Unlike Obvious context, you use expert judgment to analyze after sensing.
Good practices are applied to make decisions.
Complex:
There is no apparent (visible/demonstrable) cause and effect relationship. You don’t know the questions and don’t know the answers!In such a case, no amount of analysis will help. You have to first probe or experiment.
One uses repeated cycles of probe-sense-respond as complex systems or environments change due to external stimulus.
Emergent practices (practices which are not completely known, but emerging or taking shape) are applied to make decisions.
Chaotic:
The cause and effect relationship is unclear. There is too much confusion. There is no point in searching for questions and answers, because the cause and effect relationship is impossible to determine and constantly shifting. The situation is too drastic or chaotic.
Your immediate and first step is to act or contain and then stabilize the situation. Hence, the approach used here is act-sense-respond. As you can see, you are first acting here, not sensing or probing. You are acting to stabilize.
Novel practices (completely new practice, never known to exist before) can be applied to make decisions.
Disorder:
This is the space in the middle as shown in the figure. In this case, you don’t even know where you are, hence disorder (not unordered).
To understand, you have to break the environment/system into smaller parts and move into one of the other four zones or have contextual links with one of the other four zones of Obvious, Complicated, Complex and Chaos.
Cynefin Framework and Risk Management
Now, let’s see how this framework can be used in the context of Risk Management.
Obvious (Simple) [Known-Knowns]:
In risk management parlance, this is the realm of known-knowns. You know the risk (known), and also the know the amount of work (known) needed.
In other words, these are actually not “risks”, but documented requirements and addressed as part of the scope management.
As noted before, best practices are applied here. Best practices by its very nature come from past practices.
Complicated [Known-Unknowns]:
In risk management parlance, this is the realm of known-unknowns. You know the risk (known), but don’t know the rework (unknown).
These are classic risks or the “known risks” - the known risks with unknown or unforeseen work.
You predominantly apply good practices of risk management in this context. Usually good practices are either known to you or known to someone within the community.
The practices can be iterative processes for risk management, having contingency reserve, having contingency plans etc.
Complex [Unknown-Unknowns]:
In risk management parlance, this is the realm of unknown-unknowns. You don’t know the risk (unknown), and don’t know the rework (unknown).
In other words, these are “unknown risks” - the unknown risks with unknown or unforeseen work.
As noted earlier, you apply emergent practices. Emergent practices are neither known to you or others because it's emerging based on the context.
Chaotic [Unknowable-Unknowns or Unknowables]:
In risk management parlance, this is the realm of unknowable-unknowns or simply the unknowables. You don’t know the risk and exploration is also not possible (unknowable). And of course, you don’t know the rework (unknown).
As noted earlier, you apply novel practices here. Novel practices are completely unseen and no one actually knows till the situation occurs and actions are taken.
Slightly modifying our previous figure, one can have the below figure.
Cynefin Framework and Agile
Agile concepts and approaches are now part of both RMP and PMP exams. The Cynefin framework can also be used in Adaptive (or Agile) environments.
Obvious (or Simple) context: Go for a predictive or waterfall development approach.
Complicated context: One can go either for an iterative or incremental development approach.
Complex context: Here, one can use both iterative and incremental development. Agile is both iterative and incremental.
Chaos Context: Agile development approach can’t be used here. You have to first sense some stability and respond by taking steps to get into the Complex zone.
In my earlier article, The Twins–Communications and Stakeholder Management, I outlined how deeply and closely these two knowledge areas of the PMBOK® guide interact with each other. We saw a good number of overlaps.
Among other knowledge areas (KAs) that you will come across in project management, Resource Management comes in close when considered along with Communications and Stakeholder Management. For example, a plan for resources has information to drive communication and interactions with stakeholders. While other KAs can possibly interact with the twins like siblings in a family, no other area comes as close to the twins as Resource Management. This is why I call it “the close sibling.”
Like in my previous article on the twins, this will be less of a discussion on Resource Management and more about how the knowledge area interacts with its closely related sibling knowledge areas. If you are an aspiring Project Management Professional (PMP ®), your understanding of the interplay between these KAs should be solid.
First, let’s look at the basics of resource management.
Humans Vs. Resources
In my view, the term “human resource” is somewhat dicey. The word human, which is a noble word when combined with the word resources, becomes awkward.
The latest edition of the PMBOK® guide went with “Resource Management,” in place of “Human Resource Management” because this KA covers all possible resources – team resources and physical resources, alike. This is a key distinction to be aware of.
The word team referenced here is specifically referring to the project’s team members, not all the stakeholders. For stakeholders, we have the KA of Project Stakeholder Management. This is another key distinction that is important to understand. On the other hand, physical resources can be equipment, supplies, and materials (among others).
We will see the significance of these two high level categorizations of resources in the upcoming section on process interaction within the Resource Management KA.
Resource Management – What Happens?
Here we see three processes interacting with each other as shown below:
Below are the key points to note:
Plan Resource Management process: First, the “Resource Management Plan” is prepared in “Plan Resource Management” process. It allows the project manager to document how it is that he/she obtains and manages both team and physical resources. The created plan informs on when to hire and/or acquire and for how long. It also provides a plan for how to develop, reward, motivate, and manage team members. For physical resources, it tells you how to control.
The key output for this process is the Resource Management Plan (ResMP).I’m using the abbreviation, ResMP, here in place of RMP, as I’ve previously used RMP within the context of a Risk Management Plan and framework in Risk Management.
Estimate Activity Resources process: This process succeeds Plan Resource Management, and here you estimate the type and quantity of team and physical resources. We see the Resource Requirements for activities (or work packages), as a key output from this process. We also get the Resource Breakdown Structure (RBS), which tells the category and type of resources in a graphical way.
Acquire Resources process: In this process, you actually acquire or hire the estimated resources. After that, said resources are assigned to activities. Team resources result in Project Team Assignments, and physical resources result in Physical Resource Assignments. Another key output of this process is the Resource Calendar reflecting when and how long the resources will be available for.But wait! Can a newly joining team member perform from day one? Unlikely! For that you have to train and manage your team with interpersonal skills, set the ground rules, and possibly co-locate them together during initial stages. This happens in the next process, Develop Team.
Develop Team process: In this process, the decision to give rewards and recognition to team members is considered. Team Performance Assessments are the key output of this process.
Manage Team process: In this process, you track the team member performance, provide feedback, and manage issues when they are raised. You also recognize and reward your team members based on their performances, which you have assessed earlier in Develop Team process.
Control Resources process: While Develop Team and Manage Team processes are for team resources, the process of Control Resources is for physical resources. Here, you ensure that physical resources are continuously available as planned, as well as monitor and control the resource utilization.
The interactions among the processes of the Resource Management KA is explained in this video [duration – 4m:39s], taken from my PMP Live Lessons. For the best experience, you may want to go full-screen with HD mode and plug-in your earphones.
With this understanding of the Resource Management KA, let’s now move to the interaction of Resource Management with Communications and Stakeholder Management.
The Interaction of Resource Management with Communications and Stakeholder Management
We already know that the key documents and plans created in twin knowledge areas are as follows:
Communications Management Plan (CMP)
Stakeholder Engagement Plan (SEP)
Stakeholder Register
In the preceding section, we also just saw that the key plan prepared in the Resource Management is the Resource Management Plan (ResMP).
The ResMP prepared in the Plan Resource Management process focuses primarily on the confirmed and approved scope (Scope Baseline) and contains information on deliverables. These deliverables determine and drive the types of resources needed.
The Stakeholder Register already created in the Identify Stakeholders process acts as an input to Plan Resource Management. This is because some stakeholders have interest/impact on resources being selected and used.
At this stage, the created ResMP will document the roles and responsibilities of team members. This includes those responsibilities related to communications management and stakeholder engagement. Team members are not hired at this stage, and hence, are considered generic resources.
Interaction Point 2
After resource requirements are determined in the Estimate Activity Resources process, the Stakeholder Register acts to inform the Acquire Resources process because of stakeholders’ interests. For example, stakeholders may have a need that is apparent while getting a particular type of resource.
The Stakeholder Register is also updated in this process because new team members are actually acquired or hired in the Acquire Resources process. Such is documented in the stakeholder register. This is very significant because the team members are also stakeholders and their information has to be available in the Stakeholder Register (this is not so in any other document or plan generated in Resource Management).
Now, a project manager doesn’t need each and every resource at the beginning of a project. One of the best practices is to go for Just-in-time (JIT) acquisition. If this is implemented, change requests (CRs) are raised throughout the process.
Interaction Point 3
The ResMP, along with the Stakeholder Register, acts to inform the Plan Stakeholder Engagement process and creates a high-level Stakeholder Engagement Plan (SEP). While the names of stakeholders, including the team members, come from the Stakeholder Register, the roles and responsibilities for stakeholder engagement comes from the ResMP.
Next, the high-level SEP, the ResMP, and the Stakeholder Register created earlier, act as input to the Plan Communications Management process ultimately creating the CommsMP. The CommsMP lists out the communication requirements for all stakeholders, including those of the team members, who are also project stakeholders.
Interaction Point 4
As you prepare the Communications Management Plan (CMP), which comes as output of the Plan Communications Management process, the CMP, along with the ResMP and the Stakeholder Register, acts to inform the Plan Stakeholder Engagement process and a detailed SEP.
Remember, as noted before, the engagement of stakeholders’ responsibilities lies with the team members—those listed in the Stakeholder Register. The roles and responsibilities; however, for engagement are listed in the ResMP, and hence, this plan becomes vital to creating the SEP.
Interaction Point 5
The ResMP, CMP, and SEP prepared are executed in their respective processes–Develop Team and Manage Team for team members, Manage Communications for the execution of communications strategies, and Manage Stakeholder Engagement for stakeholder engagement.
As you develop your team members to improve skills, competencies, and enhance project performance, Change Requests (CRs) can be raised in the process of Develop Team. Similarly, while managing a team, it’s possible to experience staffing changes, reassignment of work, or replacement of team members who leave. In such cases, too, CRs can be raised in the Manage Team process.
Interaction Point 6
The CMP and SEP are monitored in their respective processes, as well. I am referring to Monitor Communications and Monitor Stakeholder Engagement.
Here too, the ResMP acts as input to the Monitor Communications process as it has information on roles and responsibilities related to project communications. Similarly, the ResMP inputs the Monitor Stakeholder Engagement process.
All change requests raised from the processes of Resource Management are analyzed, processed, and addressed through integrated change control, where the change control board (CCB) makes decisions on the fate of the CRs.
Hands-on Exercises
Now that we understand the processes, key inputs and outputs, and interactions among the Resource, Communications, and Stakeholder Management KAs, let’s do a few hands-on exercises.
In the below figure, each box or block represents a process in one of the three areas we’ve been discussing—Resource, Communications, and Stakeholder. I’ve put certain questions in these blocks. Can you answer them by replacing the questions with the name of the processes?
The answers should be one of the processes that we saw earlier within the Resource Management, Communications Management, and Stakeholder Management KAs. All change requests will be addressed via integrated change control.
Scroll down only if you have answered!
. . .
. . .
. . .
The correct answers are shown below:
For a better understanding, I’ve color coded some of the lines in the above figure. For example, unicolor coded lines such as green, orange, pink, or black represent a single input or output throughout the processes and across the KAs. Can you share just one key output for each process? Do not scroll, before you have answered.
. . .
. . .
. . .
Note that in the above figure, the following is true:
The Resource Management Plan (ResMP) is highlighted in green colored lines.
The Communications Management Plan (CMP) is highlighted in orange colored lines.
The Stakeholder Engagement Plan (SEP) is highlighted in pink colored lines.
The Stakeholder Register is highlighted in black colored lines.
The change requests (CRs) are highlighted in purple colored lines.
To explain further, I have another video [duration: 9m:54s] on how the twins and the close sibling interact with each other. The video is taken from PMP Live Lessons.
Guidance for the PMP Exam
The PMP exam tests your understanding on how knowledge areas interact and interplay with each other–why, when, and what inputs or outputs are used in various situational contexts or scenarios. Like with the twin KAs, questions can be tricky when the close sibling, Resource Management, gets involved. There are quite a few subtle differences among the three respective processes and associated documents that confuse many aspiring PMPs.
In my videos and examples here, I’ve referenced several documents and plans to show how all the three knowledge areas interact. Of course, there can be a number of other documents, plans, or subsidiary components of the plans that create other possible flows. Nevertheless, the aforementioned plans will be the most important for you in understanding the interactions between these KAs.
Key Points of Interplay between the Twins and the Close Sibling
Finally, as we close, I’m listing a few key points, out of many, about the interplay between the twins and the close sibling.
Stakeholder Engagement Plan (SEP) is for stakeholders’ engagements, including those of the team members.
The question of how to engage team members is a part of Stakeholder Engagement Plan (SEP), but, the question of how to manage the team members is addressed by Resource Management Plan (ResMP).
The Stakeholder Register includes ALL stakeholders, including project team members.
The names of the project team members are part of the Stakeholder Register, but roles and responsibilities of the team members are part of the Resource Management Plan (ResMP).
The communications requirements for all stakeholders, including the team members, will be part of the Communications Management Plan (CMP).
What do you think? As management practitioners, how important are resource, communications, and stakeholder management KAs for your projects? Is there any other area which interacts closely with the twins and the sibling? I’d love to hear your views and thoughts in the comment section below.
.png)
