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 Risk Breakdown Structure (RBS) is mostly used in Risk Management, whereas the Work Breakdown Structure (WBS) is in Scope Management. But then they can be combined to provide you better value from both the breakdown structures.
"RBS can be used in combination with WBS to identify potential sources of risk. For example, the XYZ work package of WBS can be technical, environmental and political risk categories."
In my interactions with management practitioners, when I inform them, surprised looks come-up with certain questions:
How can RBS be used with a WBS?
What are the advantages in having a combined structure and analysis?
In this article, we will explore just that!
Let’s start with a sample WBS.
A Sample Work Breakdown Structure (WBS)
I’ll reuse another WBS from one of my previous articles. This is depicted below. I’ve modified the WBS from the linked article a bit.
As shown above, it’s only up-to Level 2 (L2). The reason is that I’m not going to identify the risks at the lowest level, but at a higher level. This way, I can refine more as I build the final-cut of RBS. This will be based on the areas identified in the WBS.
Also, you’d have noticed that I’ve added another level (L0), which is the overall “Book Project”. Interpreting the above figure, you can say:
At Level – 0, we have the Book Project. I’ve added L0 so that the WBS is synchronized in its structure with the RBS.
At Level – 1, we have, Book – Risk Management.
At Level – 2, we have Manuscript, Write Book, Edit Book, Publish Book.
Next, let’s take a look at the sample RBS.
A Sample Risk Breakdown Structure (RBS)
For the sample RBS, I’ll use it from my previous article (with modifications for the book) as well and I’ll keep the structure at a higher-level (L2).
As shown above:
The Book Project is at the highest level, which is Level - 0 of the RBS.
Under it, at Level – 1 of the RBS, there is Book – Risk Management.
Next, at Level – 2 of the RBS, we have multiple risks such as Writer’s Risk (e.g., writer’s block), Hosting Risk (e.g., online hosting problems), Editing Risk (e.g., wrong interpretation of meaning), Publishing Risk (e.g., publisher being unavailable).
Finally, we are going to combine the RBS with the WBS, which will help us in identification of risks.
Combined RBS and WBS
While combining, I’ll keep the WBS in the X-axis (horizontal) and the RBS in the Y-axis (vertical).
Let’s understand and interpret the above figure:
The risks are identified by considering the L2 of RBS and L2 of WBS.
In the lowest row of the table shown with tick marks, the “Writer’s Risk” category of the RBS is associated with “Write Book” and “Edit Book” of the WBS.It means one can have a cluster of writer’s risks while going for the deliverables of Write Book and Edit Book.
Taking another example, in the topmost row of the table with tick marks, the “Publishing Risk” category is associated with “Manuscript” and “Publish Book” deliverables.
Hence, considering the second bullet point above, one can say that a number of writer's risks (from the RBS) can be found while writing the book and editing the book (from the WBS). Similarly, one can say a number of publishing risks can be found during the development of manuscript and of course, while publishing the book.
Conclusion
When you combine the RBS and analyze the risk categories with the WBS, you can find the areas when the project is most likely to exhibit the most risk.
As demonstrated in the final figure, one can quickly find the areas of the project, where you can find various categories of risk. In turn, it helps to build a more refined Risk Register.
Management Reserve and Contingency Reserve are two widely used reserves in Project Management, Program Management. It can also be used in Portfolio Management and Agile Management, though the way there are used will be somewhat different. However, there are many misconceptions about these two reserves. In this article we will see what those myths are and check upon the facts.
The needed content is also available as part of the PMP 35 Contact Hours, RMP 30 Contact Hours, ACP 21 Contact Hours and CAPM 23 Contact Hours courses.
Note: First go through the myths on your own and try to answer yourself. That way you will get a better value from this article.
Hope you are tried to do the exercise on your own first! I'll also suggest that you go through this article to learn more:
Myth – 1: Addition of contingency reserve to activity cost estimates (or activity duration estimates) will create a rubber baseline.
Fact: Contingency reserve can be at the activity level or work package level etc. If it’s at the activity level, then it need not be at the work package level. The reserves from lower level estimates will get rolled up to the work package level. Hence, there is no chance of having a rubber baseline.
As you can see in the above block representation, the contingency reserve can be at the activity level, or work package level. Otherwise, you can have an overall contingency reserve at the project level.
Myth – 2: Contingency reserve is not applicable for the project schedule, it’s only for the budget.
Fact: It’s applicable for both project schedule and project budget. You can have contingency reserve calculation while determining the duration estimates of tasks or cost estimates of tasks.
Refer to the previous diagram to see overall contingency reserve.
Myth – 3: Any reserve can be tracked with a reserve burndown chart.
Fact: Usually, contingency reserve is tracked at the project level, but management reserve is not. The reason is simple. Project Managers know and manage the contingency reserve as it’s part of the performance measurement baseline.
So, the reserve burndown chart that one creates and manages at a project level is with respect to the contingency reserve, not for management reserve.
Myth – 4: If the reserve is unused, then it can be part of project profit!
Fact: This is another big myth propounded. But you can’t take the unused reserve as part of the profit. It’s meaningless because you have added the reserve for unforeseen circumstances.
Threats – if the reserve is unused then, it has to be removed or given back.
Opportunities – if the reserve increases because you exploited the opportunity, then yes, for this you can consider it to be a profit.
Re-read the previous line! In risk management, both threats and opportunities are considered, but the way they are treated will be different.
Myth – 5: Reserves have little to no role to play in S-curve interpretation.
Fact: In fact, it’s the other way around. You should be worried when the reserve starts getting depleted while doing your S-curve analysis. The Budget at Completion (BAC) in earned value calculation should include the contingency reserve (CR).
Sometimes the estimate at completion (EAC) can go beyond the available contingency reserve and may eat-up the management reserve (MR).
As shown in the above S-curve, the trend for Actual Cost (AC) curve is upward and it may consume not only the contingency reserve, but also the management reserve for the project.
Myth – 6: Slack or float can be a replacement for contingency reserve.
Fact: Slack and reserve are two completely different concepts. Many confuse the two.
Total slack is about how much time you can delay a task without delaying the project end date. Free slack, simply put, is how much you can delay a task without delaying any successor task.
Reserve or allowance on the other hand protects you against the delay in the current activity, not next activity’s start date!
Myth – 7: Contingency reserve and contingency response planning are one and the same thing.
Fact: Contingency as we know is the reserve for known risks, but unknown amount of rework. It’s for risks which are accepted or known risks with active risk response strategies.
Contingency planning, on the other hand, consists of two plans: Contingency Plan and Fallback Plan. Simply put, these two plans are Plan A and Plan B, respectively that we use in our day-to-day risk management.
Myth – 8: Agile projects don’t have all these reserves available.
Fact: In Agile projects, too, you may require contingency and management reserves. Consider an Agile project with mandatory regulatory requirements and one of the needs to meet the budgetary regulations with earned value calculations. In such a case, you need to have the reserves.
Myth – 9: Management Reserve is a budget category, and not applicable for Schedules.
Fact: This is another myth, which is widely circulated. While management reserve is usually a budget category, you can also have it for schedule. In fact, the definition of Management Reserve as per the PMI-PMBOK guide is this:
An amount of the project budget or project schedule held outside of the performance measurement baseline for management control purposes that is reserved for unforeseen work that is within the project scope.
Can you see that the management reserve can also be part of project schedule (not just budget)?
Myth – 10: Contingency Reserve and Contingency are one and the same thing.
Fact: Contingency is an event or occurrence that could affect something, e.g., a task, a work package or the execution of the project. Contingency reserve, on the other hand, is the time or money allocated for known-unknown risks. However, contingencies can be accounted for with reserves.
There are many other myths, which circulate on these two reserves. What are the other myths you think are not correct for contingency reserve and management reserve?
If you have any questions, suggestions or feedback, do share your comments in the comment section of this article.
Any genuine management practitioner will tell you that a project has to be closed, irrespective the methodology or framework being used. If it’s a traditional project and/or a project having multiple phases, then not only the project has to be closed, but each project phase has also to be closed.
[ This post is part of the Agile Asanas series.
To read all posts in Agile Asanas series, use this link. ]
Closing a project entails a number of activities and it’s advantageous for the project manager to do so.
Now, because a Sprint is considered to be a mini-project, it also has to be closed, irrespective of the decomposition patten being followed such as:
Project, Release, Feature, Sprint, Use Story
Project, Feature, Release, Sprint, Use Story
Project, Epics, Feature, Sprint, Use Story
Project, Sprint, User Story
Going forward, I’ll be using the decomposition pattern of Project > Release > Sprint > User Story.
Recently, I wrote a couple of articles regarding project closure and Sprint closure. I’d strongly recommend that you read both of them along with this piece.
In this article, we are going to explore the differences between project and Sprint closures. For management practitioners, who want to be proficient across the spectrum of project life cycles and development approaches, it’s important that you know the differences.
*********
First the definitions.
A project is defined by the Project Management Institute (PMI) as follows:
A project is a temporary endeavor to create a unique product, service or result.
Do note that the definition says that a project creates something unique. It can be a product, service result. This definition is not about a deliverable or increment at the end of the project – rather, it’s a finish product.
I define Sprint as follows:
A Sprint is a time-boxed iteration event within the Scrum framework.
The Sprint event contains four other events: Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective. Each Sprint can be considered to be a short project as noted in the latest Scrum Guide, 2020.
An increment of value is delivered at the end of the Sprint or prior to the Sprint. An increment is a step towards the Product Goal. You can learn more on increments and Product Goal in the below article:
With these foundational understanding, let’s see the differences one by one.
Difference – 1: You close a Project once, but close Sprints many times.
A project is closed only once. If a project has multiple phases, then each phase is closed separately and these steps can happen multiple times. However, the project closure is the final one and happens once.
On the other hand, the Sprints are closed multiple times. After all, a project can have many releases, which in turn will have many Sprints.
All these Sprints can be closed within the life cycle of a project.
Difference – 2: Final increment is at the end of the Project, intermediate and/or multiple increments can happen anytime within a Sprint.
As we saw earlier, a project creates/builds a product (or service or result). Basically, it’s a deliverable or collection of deliverables. A deliverable is a uniquely verifiable product (or service or result) that is produced to close a project or phase.
On the other hand, an increment (similar to deliverable) is produced at the end of the Sprint or prior, but within a Sprint. The increment given at the end of the Sprint is a sum of previous increments. An increment is not a finished product.
Difference – 3: Resources are released when a project is closed. Resources are likely to remain when a Sprint is closed.
When a project is closed, all the resources are released. You, as a Project Manager, has to do it because you are accountable for the time spent and cost involved for the resources.
But when you close a Sprint as a Scrum Master, you don’t release the resources. Because those will be needed in the upcoming Sprints.
Do note that in Agile, the team is cross-functional, self-organizing and self-managing, but procurement, hiring and release of resources (both human and non-human) are facilitated by the Product Owner and/or the Scrum Master.
You can learn more roles being played in Agile and Traditional environment in the below article:
Difference – 4: Final Report is given at the end of the Project, whereas usually Burndown Chart is enough for a Sprint end.
The final report given at the end of the project is quite exhaustive. This is the summary of project performance. It informs if the scope, schedule, cost and quality objectives are met, the achievement of business needs/objectives of the project, among others.
But, when a Sprint is closed, there is no such exhaustive reporting or documentation. Usually, Burndown Chart is enough to inform on the work completed.
If you want, you can show certain additional information in your Sprint Report such as features completed vs features planned, velocity (story completed vs planned), issues faced, risks register and addressed. But remember, in Agile, one the values is this:
Difference – 5: Usually Projects will have Lessons Learned Meetings, whereas Sprints will have Retrospectives!
You may have noticed that Lessons Learned Meeting and Retrospectives are used interchangeably. But there are subtle and important differences.
Lessons Learned Meeting is a periodic meeting, where the team meets to determine what they could do better in the future with a focus on improving team performance. Lessons learning happens throughout the life cycle of the project. However, the final Lessons Learning Meeting happens at the of the project. The ‘lessons learned’ is then archived into the organizational repository.
Retrospectives, on the other hand, happen for the iterations or Sprints in our case. It has a recurring pattern and specificity. Here, the team meets how they can improve the process and product in the upcoming Sprints.
Retrospective is a form of lessons learned meeting, but they are not the same.
Difference – 6: Project documents are closed and archived. A Product Backlog is not closed or archived.
Project documents such as Requirements Documentation, Scope Statement (part of the Project Management Plan) are closed/completed/reviewed and archived at the end of a Project.
A Product Backlog used in a Scrum Project is not closed and archived when a Sprint gets closed. It’s a live document and continuously gets updated.
In fact, at the end of the Sprint, the backlog is likely to get updated with the improvement items coming from the Sprint Retrospective event. Again, notice that it’s Sprint Retrospective, not Sprint Lessons Learned Meeting! I’ve already differentiated the two in the earlier point.
Difference – 7: A project is a temporary endeavor with a longer time-span, whereas Sprint is a short time-boxed event.
This comes from the definition itself, which we saw earlier. A project is not timeboxed, i.e., when the time is over the project is over! The time-span of a project can be elongated or shortened.
On the other hand, a Sprint is always a timeboxed event. If the Sprint duration/length is of two weeks, then the Sprint has to be closed at the end of two weeks.
It doesn’t matter if the work taken to be completed within the Sprint is complete or not. It has to be closed!
Difference – 8: Formal activities for contract closure happens at the end of the project, whereas contracts can be closed within a Sprint.
This difference is slightly tricky.
At the end of the project, one considers both contract closure (all final payments made, no outstanding claims etc.) and administrative closure of the contract (confirming formal acceptance of deliverables, finalizing open claims etc.)
A contract can be closed during a Sprint when the deliverables have been given by the contractor and accepted. However, the administrative closure of the contracts can be time consuming and a Sprint is timeboxed. Hence, it’s not preferably done in a normal Sprint.
Difference – 9: Project Audits happen at the end of a project, but doesn’t usually happen within a Sprint.
The project audit is mainly to check the project success or failure. The success criteria are documented in the Project Charter document.
However, an audit usually doesn’t happen at the end of a Sprint. Audit is time consuming on its own and hence, a short time-boxed duration of Sprint can’t really accommodate the need.
Also, as the customer (or proxy of the customer, which is the PO) is directly involved daily in Sprint, one need not go for an audit to check the success and failure for a project.
--
Similarities
There are also similarities between the closure of a project and a Sprint. Below, I've noted some examples:
Acceptance of deliverables/increments happens at the end. For a Sprint, the acceptance (or rejection) happens in the Sprint Review event.
The increment is handed over to the operations (in Project).
In Agile, the increment is directly deployable and hence, usable or can be with the ops team (DevOps).
Both Project and Sprint closures focus on value delivery. Increment must be of value to the end customer/user when delivered, so also a Project’s deliverables.
A project can be prematurely closed, so also a Sprint.
A project can be abnormally terminated, so also a Sprint.
I believe with this you now have a fair understanding of the various differences between project and Sprint closures. If you have more things to add or have other comments and suggestions, do leave them in the comments section below.
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.
