Author: Satya Narayan Dash

Satya Narayan Dash is a management professional, coach, and author of multiple books. Under his guidance, over 2,000 professionals have successfully cracked PMP, ACP, RMP, and CAPM examinations – in fact, there are over 100 documented success stories written by these professionals. His course, PMP Live Lessons - Guaranteed Pass, has made many successful PMPs, and he’s recently launched RMP Live Lessons - Guaranteed Pass and ACP Live Lessons - Guaranteed Pass. His web presence is at https://managementyogi.com, and he can be contacted via email at managementyogi@gmail.com.  

The Risk Management Life Cycle in the Context of Projects, Programs, and Portfolios

“Project Creates. Program Guides. Portfolio Decides.” – from the book, I Want To be A RMP. As I interact with various project, program, and portfolio (PPP) management professionals who use my courses, read my books, and/or attend my webinars, I get many queries on the risk management life cycle approach. While a project is a temporary endeavor to create a unique product (or service/result), a program refers to the coordination of projects, subprograms, and other program activities with the overall intent of obtaining benefits from a product or result. Portfolios, on the other hand, are about management of multiple components, such as projects, programs, sub-portfolios, and other works. Here, we are talking about a collection of said items to achieve strategic objectives of an organization. Risk Management generally exists within the boundaries of its respective project, program, or portfolio of an organization, though in some organizations it can be looked at as a separate function. For example, in project management, risk management is considered to be a “knowledge area” with its own set of processes, inputs, tools and techniques, and outputs. A few questions come to mind: How do we address risks in the entire context of projects, programs, and portfolios? What kind of processes should be taken-up which encompass such “PPP” risk management? To understand risk management fully in this context, first we need to understand the risk management framework. It’s generally built on seven processes, as shown below:   Such a framework informs with a series of phases from start to completion. Similarly, when we talk about the risk management life cycle, we refer to a sequence of logical phases that can be iterated and include the processes of risk management as shown above. These are as follows: Plan Risk Management, Identify Risks, Perform Qualitative Risk Analysis (Perform QLRA), Perform Quantitative Risk Analysis (Perform QTRA), Plan Risk Responses, Implement Risk Responses, and Monitor Risks. When a project, program, or portfolio (or a phase within such) is closed, the risk management processes are terminated and lessons learned are documented for future use. In summary, the risk management life cycle (RMLC) works within the context of a risk management framework. It ensures risks are managed in a structured and integrated manner within an organization irrespective of life cycle approaches chosen. Understanding of the risk management framework across portfolios, programs, and projects is foundational to achieve tangible results coming from risk management. While a project’s risk management life cycle is somewhat known and practiced, there are a number of variations when programs and/or portfolios are taken up in an organization. As a risk management practitioner–current or aspiring–one needs to be aware of the intricacies, variations, and subtleties across all the “P’s.” Unfortunately, many practitioners miss these. For example, the primary purpose of program management is realization of benefits, unlike project management where the primary purpose is to meet project objectives. Hence, risk management in the context of programs will differ when compared with risk management in the context of projects. In my on-demand webinar, we explore the following questions: What is the risk management framework and the risk management life cycle? What should be the considerations for projects? What should be the considerations for programs? What should be the considerations for portfolios? What is the best practice for taking an integrated approach? I hope you’ll join me.  

A Deeper Look: Top Changes in the New 2020 Scrum Guide for Agile Practitioners

A new version of Scrum guide was released last month. There are quite a few changes in the guide, as well as new additions. While the outline and structure of the guide have remained almost the same, as you go through the guide, you will immediately notice three high-level changes: The new guide is a much lighter and smaller version. It’s less prescriptive and seems to be intended for a wider audience group, particularly non-software users. It contains commitments for each of the Scrum artifacts. In this article, I’ll outline the top changes and the deeper meaning associated with each change. My perspective is based on my analysis, my own interpretations, and the interactions I’ve had with Agile practitioners who follow my publications, books, and/or courses.   Product Goal The Product Goal has been defined clearly. It’s not an introduction because it existed earlier, but in the previous version, it was mentioned along with the vision.   As per the guide, the Product Goal is the future state of the product. This definition of the ‘goal’ can create confusion for many who understand project-program-portfolio management and how goals aligns with the vision, mission, strategy, and objectives of an organization. Ideally, the vision is the future of a product or program/portfolio or an organization. A vision is always associated with goals, without which a vision has no value or meaning. However, as you look closely at the new guide, a big picture emerges: The Product Goal is the long-term objective of the team. A team works on and fulfills a single objective at a time. Before tackling another objective, the team has to fulfill (or abandon) the objective they are currently working on. In other words, the goal is written with one or more objectives for the team. As the product roadmap is prepared, it gives further directional clarity to the product goal. The product goal should be linked to the strategic goals of the organization. One could summarize this by saying: The Product Goal is more strategic in nature, whereas, Sprint(s), mentioned as a project in the guide, will be tactical in nature. With each Sprint (iteration), the product moves closer to the product goal. The Product Owner (PO) is the person who is responsible in building, and clearly communicating product goal to the team. The items in the product backlog (PBIs) should map to the Product Goal. Product Goal also reflects one of the values of Scrum: “Focus.” The team, as earlier noted, should focus on one objective at a time. Now, you may be wondering what happens when multiple teams are working on the product backlog? Regardless of the number of teams, there will be a single product backlog, a single PO, and a single product goal. This is depicted in the figure below. Commitment based Artifacts Now, every artifact in Scrum comes with a commitment. The formal artifacts in Scrum are three: Product Backlog Sprint Backlog Increment Now, all these artifacts come with commitments to ensure transparency and progress. For Product Backlog, the commitment is the Product Goal. For Sprint Backlog, the commitment is the Sprint Goal. For Increment, the commitment is the Definition of Done (DoD). While Product Goal is newly introduced, Sprint Goal and DoD (earlier called “done”) existed earlier. In the new guide, all of these have found homes. For example, the home of Product Goal is the Product Backlog.   At this point, it may be useful to note that “Commitment’ is also one of the values of Scrum, others being Focus, Openness, Respect, and Courage. Hence, one can say that commitment-based artifacts are reflections of one of the Scrum’s values. Commitments also increase “Focus,” another Scrum value. I’ve mentioned the values here, because I believe they are very important, but you shouldn’t confuse values such as openness, courage, honesty, etc. with the value that you get while delivering an increment, although the latter is also important. As the saying goes, “Culture eats strategy for breakfast.” In my view, it’s actually the values and value-system which eat strategy for breakfast. Strategy execution is the downstream of culture. Culture is the downstream of human, team, or organizational values. And values are the downstream of the philosophy on which civilizations (or a team/organization) is based. At times, values are thrown around like punchlines, brandished as political weapons, or misused for self-serving interests. It’s true adherence to values that really matters because without values, nothing really works. This is true for a person, team, organization, or even a civilization. As we proceed through the other changes, I’ll continue to reflect on the Scrum values.   Multiple Increments Earlier it was mentioned that an Increment will happen at the end of Sprint. Now, within a Sprint, multiple Increments can happen. An Increment happens when a backlogged item meets the DoD. Hence, an Increment can be created at any point of time during a Sprint. This is depicted in the below figure. As shown, at the end of the Sprint, we have Increments. Increments can also happen at any time during the Sprint. The new guide clearly informs that Sprint Reviews should not be considered “gates” for releasing value. As there can be multiple Increments, the sum of all these Increments are presented to the (key) stakeholder at the Sprint Review.   Introduction of Cadence For the first time, we are introduced of a concept called “Cadence.” This is an important introduction, which is missed by many Agile practitioners. Cadence is used in other Agile frameworks such as Kanban, and is basically a rhythm that gets developed as one continuously follows a set of events over a period of time. In Scrum, the cadence is provided in the form of five events: Sprint – the container event Sprint Planning, Daily Scrum, Sprint Retrospective, and Sprint Review – the contained events within a Sprint I’ll suggest that you read this change along with the previous change of “Multiple Increments.” As you go through these updates together, you can see two things emerge: Development is happening in cadence, whereas, An Increment can be there at any time during the Sprint. You can say development (or build) of the product and incremental delivery have been decoupled. In fact, they can be thought to be of two streams as shown below. As shown, the stream for cadence is decoupled from the stream for increment. The diamond shapes in the cadence stream denote the Sprint Reviews. While there is an increment at the end of the review, on-demand increments can happen at any time, as we see in the increment stream. Cadence helps with inspection, which is one of the pillars of empiricism. This, in turn, drives another value of Scrum: “Openness.”   Lean Thinking Earlier the guide referred to empiricism. Lean thinking has appeared for the first time. Empiricism is a practice which is based on knowledge coming from experience and what you know or have observed. The three pillars are: Transparency, Inspection, and Adaptation. To include and encourage lean thinking, the wording in the guide has changed in quite a few places. For example, the guide notes: “Transparency enables inspection. Inspection without transparency is misleading and wasteful.” Again, remember that “Transparency” (or Openness) is one of the values in Scrum. A key principle of lean thinking is to avoid “Muda,” a Japanese term meaning “waste.” When work is not done after being taken into a Sprint, the result is Muda. With DoD, Muda is avoided. Do remember DoD is the commitment for an increment. With DoD: You know exactly what it means to have an increment. The team is compelled to complete the items taken, not start taking new items. One can say it’s about: Start Finishing, Stop Starting. From that perspective, some elements of Kanban have been absorbed into Scrum.   Introduction of “Why” in Sprint Planning Other than “what” to do in the Sprint and “how” to do it, the “why” aspect has been introduced. Earlier, before the start of Sprint Planning event, two questions were emphasized: Topic – 1: What should be done in this Sprint? Topic – 2: How do we do it within the Sprint? In the new guide, emphasis has been given to Sprint Goal. Hence, we now have three aspects: Topic – 1: Why is this Sprint valuable? Topic – 2: What should be done in this Sprint? Topic – 3: How do we do it within the Sprint? This is shown in the below figure. Sprint Goal has to be collaboratively defined by the entire team. The introduction of Sprint Goal in the Sprint Planning event, reemphasizes a value of Scrum: “Focus.”   Single Scrum Team Earlier, there was a Development Team within the Scrum Team. There is no ‘team within team’ now. A Scrum Team is one, and it consists of the Product Owner, Scrum Master, and Developers. This is a step away from the “us-vs-them” mentality created with the term “Development Team” earlier. It also avoids a “throw-over-the-wall” mentality (i.e. my or my group’s work is done and now is the time to throw it over the wall, so that the other group takes care of it!) Now, the team is considered to be a cohesive unit of people focused on the Product Goal. The PO, SM, and Developers are all intrinsic parts of the Scrum Team. The new version of the guide also notes that the team is the fundamental unit of Scrum. The single Scrum Team concept enables two values of Scrum: “Respect” and “Openness.” With a single team concept, there is less likelihood of “us-vs-them” mentality. Also, a single team concept with no hierarchies creates a culture where everyone knows that the team succeeds or fails together, hence candor goes-up. It’s likely to stop compartmentalization of members, prohibit group or community biases, reduce politics, and cripple finger-pointing, and eliminate blame-games and back-biting. If one team member is failing, it means the whole team is likely to fail with their ability to meet the goals of Sprints, the goal of the Product, or the honoring the DoD. The team moves towards, or strives to be, an indivisible whole.   Self-Managing Team Instead of “Self-organizing,” the team is now “Self-managing.” Agile teams are cross-functional meaning that they have all the needed skills to do the work and create value in each Sprint. Along with that, whereas the team was described to be self-organizing in the earlier edition, the terminology has now been changed to self-managing. There is a subtle difference between these two terms. Self-managed teams go one step ahead of self-organized teams. A self-organizing team chooses who will work and how to do the work. A self-managing team, on the other hand, chooses who, how, and what to work upon. In my view, the team can consider the new aspect of “what,” because the PO is now explicitly part of the team. It’s not that a team will be self-organizing from Day 1 or even within a few weeks of interactions. The team has to go through the stages of team formation, such as forming, storming, norming, and performing. Also, with the introduction of “what,” the team decides which items are to be taken-up for the next Sprint. This, in turn, reflects another aspect of Lean Thinking: “Muri,” another Japanese term meaning “overburden.” As the team decides what items are to be taken-up, Muri is less likely to arise. When what items are determined at the beginning of the Sprint, it reflects another aspect of lean thinking: Just-in-time (JIT).   Not a Servant Leader, but a Leader who Serves The Scrum Master being referred to as the Servant-Leader of the team has been removed. The guide currently notes, “The Scrum Masters (SM) are true leaders who serve the Scrum Team and the larger organization.” This enables the SM to play a larger role in the organization. The SM is not only now accountable for establishment of Scrum, the SM also leads, trains, and coaches the organization on Scrum adoption. He or she also advises the organization on Scrum implementation. In my view, this is a positive change because I’ve noticed that the words, “Servant Leader,” have been weaponized by some teams. The SM is not a clerk or secretary to take notes during Sprint events and send meeting emails or reminders. The role of a SM is much bigger with a focus, not only on the team, but also playing a broader role in the organization. This larger aspect is emphasized by putting leadership first. — As you go through the new guide, you may also notice changes such as: The three questions of Daily Scrum are no longer mentioned. One process improvement item from Sprint Retrospective, which must be taken into the next Sprint’s backlog is no longer there. The term “useable” has been used in place of the term “releasable,” among many others. In this article, I’ve elaborated on some of the top changes. I hope you are not only aware of these, but understand the deeper, philosophical reasonings behind these changes in the Scrum framework.     References [1] Book: I Want To Be An ACP: The Plain and Simple Way, 2nd Edition, by Satya Narayan Dash [2] The 2020 Scrum Guide, by Ken Schwaber and Jeff Sutherland  

Probabilistic Branching and Analysis in Risk Management

Imagine this scenario. You are going to a friend’s house for an important event. It is scheduled with a hard start, meaning you can’t have delays, but as you start traveling, you notice that your vehicle is running low on gasoline. A few options come to mind: Continue driving because you think your available gasoline will suffice. Fill-up your gasoline tank at a nearby gas station and then continue to travel. Use a small gasoline container you have with you to fill-up your tank and then continue to travel. Which option would you choose? What impact will your choice have for the duration of your trip? Can you reach your friend’s house on time? These questions lead to a concept called probabilistic branching and analysis, which is used in quantitative risk analysis and management. Probabilistic branching is one of the ways to represent individual project risks. In every probabilistic branch, you model individual project risks and determine the overall project risk. In this article, we’ll start with the fundamental concepts used in probabilistic branching. I’ll illustrate them with an example, show how to build a project plan with MS Project, help you create the needed probabilistic branching, and provide analysis and interpretations. In conclusion, we will see the significance of this concept.   Uncertainty in Schedule Network Diagram If you consider the options you had running low on gasoline while driving to your friend’s house, a simple network diagram can be built: Start (milestone) – Starting from your home Activity 1 – Starting to travel in your vehicle Activity 2 (an option or branch) – Fill-up the tank at a nearby gas station Activity 3 (another option or branch) – Use the small gas container available Activity 4 – Continue travelling End (milestone) – Reach your friend’s house This seems pretty straightforward, but can you be sure of which option or branch you should take considering your desire to arrive at your friend’s house on-time? It may not be as straightforward as you think due to these activities being uncertain (may or may not happen). Uncertainties mean risks, and these risks can ultimately impact your objective (reaching your friend’s home on-time for the event). Hence, you can give probability or chance of occurrence to these risks on each of the branches. When you assign probability values to each branch, you get a risk-adjusted schedule network diagram. We can modify our previous network diagram and represent as shown: For “Activity 2” and “Activity 3,” I’ve assigned 30% and 40% chances, respectively, as existence values. As you assign probability values to individual branches in response to the risks, the branches in the network diagram are known as probabilistic branches. You can have single or multiple probabilistic branches, though the latter is more frequently used.   Statistically Independent Consider closely our first example: Can you take two options or go for two branches simultaneously? In other words, would you fill-up the tank at a nearby gas station and use the small gas container available? Obviously, you would not, as it doesn’t add any value for you. In fact, these are two independent outcomes–more specifically these outcomes are statistically independent. When you build a schedule network diagram (as shown in previous figure) with probabilistic branches, you model the risk of different outcomes occurring in a project in each branch. Therefore, you could say probabilistic branching is best used when the risks occurring are statistically independent, meaning that one risk occurring in one branch is statistically independent of another risk occurring in another branch. With this background and fundamentals explained, let’s look now at a real-time, project management example and get a bit deeper into probabilistic branching and analysis.   An Example Let’s say that you and your team are excavating in an area to have a new garden prepared for a town’s residents. Your team will remove the soil, dig normally, then fill the hole, and finally plant grass to complete the work. The tasks in this project will occur as shown in the below table. I’ve added duration details for each task or activity. Note that this example is taken from Primavera tutorial and modified with respect to MS Project usage and respective representations in this article. What good can a project plan be, if we don’t know the total duration and end date? In such a case, scheduling software comes to our aid. Using Microsoft Project software, the plan looks as shown below. The project is starting on January 4, 2021 and finishing on April 23, 2021. The duration is calculated to be 80 days. So far, so good. There is no difficulty at all in creating a plan for this simple project. But, as with many projects we manage, we have a twist!   Decide on the Branches Let’s say that you get in touch with local experts and are informed of a possibility of archaeological remains in the area. Obviously, you just can’t go on and just start digging in this scenario. You may think of three possible scenarios or outcomes. Archaeological remains need expert removal. Archaeological remains can be discarded. No actual archaeological remains are found. These scenarios can be modelled using probabilistic branching with three branches for three possible types of outcomes. All these outcomes, as you can see, are statistically independent. Now, because these are probabilistic branches, there will be risks associated with each branch. At this point, we can confidently say the following: Risk 1 (on Branch 1): Archaeological remains are found that need expert removal. Chance of occurrence (probability value) = 5% Risk 2 (on Branch 2) Archaeological remains are found, but can be discarded. Chance of occurring = 25% Risk 3 (on branch 3) No archaeological remains are found. Chance of occurring = 70% As you see above, a probability value is assigned to each outcome or branch. You can decide on the probability values to be assigned subjectively and/or with expert opinion.   Add New Tasks to the Plan Before we perform a risk analysis, we need to include all three of the above branches into the existing plan. In our plan, we have three new tasks representing the three outcomes or branches. The new tasks, along with existing tasks in the plan are: Task – 1: Remove topsoil Task – new: Remains found that need expert removal Task – new: Expert removal Task – new: Remains found but can be discarded Task – 2: Dig normally Task – 3: Fill hole Task – 4: Plant grass Did you notice the branching that occurred after the “Remove topsoil” task? After this task, we now have three possibilities or three branches: “Remains found that need expert removal,” “Expert removal,” and “Remains found but can be discarded.” Next, let’s add these tasks to our MS Project plan with the following durations: Remains found that need expert removal = 2 weeks Expert removal = 4 weeks Remains found that can be discarded = 2 weeks After this step, we see the following modified plan within MS Project. As shown in the above figure, with the addition of the new tasks, there is no change in the project duration, the critical path, or the finish date. However, we are not done with our plan yet.   Link the Tasks to the Existing Tasks We have to link the newly inserted tasks and include the probabilistic branching for each of these tasks. I’ll be linking the tasks as follows: Link the finish of “Remove topsoil” task to the start of “Remains found that need expert removal” task. Link the finish of “Remains found that need expert removal” task to the start of “Expert removal” task. Link the finish of “Expert removal” task to the start of “Fill hole” task. Link the finish of “Remove topsoil” task to the start of “Remains found but can be discarded” task. Link the finish of “Remains found that can be discarded” task to the start of ‘Fill Hole” task. Logically, the above sequence makes sense. For example, if you remove the soil and require expert removal, then these tasks should be linked with FS dependency. Next, the task “Expert removal” will be linked to the task “Remains found that need expert removal” and so on. After linking the tasks, the project plan as created with MS Project will result as shown below. From the task “Remove topsoil,” we have three branches, [v.i.z]: “Remains found that need expert removal” “Remains found that can be discarded” “Dig normally” The branching from the “Remove topsoil” task has been highlighted in green in the above figure. In the above modified plan, the project continues to start on the same date of January 4, 2021, but finishes on May 7, 2021 (it was April 23, 2021). The duration of our project has been recalculated as 90 days (from 80 days) and the critical path for the project has also changed.   Assign Probability to the Branches Next, we will import this Microsoft project plan (.mpp) file into Primavera Risk Analysis software and assign the probability for each of these branches. We will use the following probability values, which we had decided upon earlier. Remains are found that need expert removal – 5% Remains found but can be discarded – 25% Dig normally – 70% The .mpp file will be seamlessly imported and will be depicted as follows: This plan is an exact replica of the MS Project plan that we had created before with branching happening from the “Remove topsoil” task (highlighted in green). In each branch, probability values have been assigned, highlighted in the pink color in the graphical side of the Gantt chart and noted to the left of the bars.  The critical and non-critical tasks are also the same, highlighted in red and blue colors, respectively.   Run a Risk Analysis Next, we have to simply run an analysis on the risk adjusted schedule model, and we will iterate the plan a number of times for simulation. The resultant histogram will show as below, post the simulation (known as the Monte Carlo simulation). I’ve formatted the histogram with color coding, highlighted arrow marks, and other data representation. Let’s interpret the above graph as follows: In our initial plan, the project was supposed to be completed by April 23, 2021. In the new plan, after adding the probabilistic branches, the end date moved to May 07, 2021. The chance of completing the project by May 07, 2021 is 97%, which is mentioned in the “Highlighters” section in the table to the right. The corresponding line projections are highlighted in yellow arrow marks on the graph. The project has a 50% chance of completing by April 21, 2021, and an 80% chance by April 28, 2021. These are highlighted in black (or bold) arrow marks on the graph. A 100% chance of completion is possible by May 19, 2021, which is nearly two weeks beyond our planned finish date with probabilistic branches.   Conclusion Let’s go back to our first example of travel to a friend’s house. It’s not a complex one, and it’s possible that you will be able to calculate the end result in your mind with probabilistic branches. However, in the real-world, projects or programs are expected to be complex, and you will be needing management and simulation software tools to determine the impact of probabilistic branching to your finish time. To use these software tools, you need to have clarity on probability branching, understanding how to create branches and link with the existing tasks in the plan for analysis. If you are aspiring to be a Risk Management Professional (RMP), you can expect questions pertaining to these concepts on the exam. On the other hand, if you are an aspiring Project Management Professional (PMP), you need to have a basic understanding on probabilistic branching and how it’s used as a tool, as well as the technique named “Representation of Uncertainty” in quantitative risk analysis. It is my hope that, within this article, you received a sound understanding on when and why to use probabilistic branching, as well as how run an analysis with an example and hands-on software tools. References [1] Book: I Want To Be A RMP, The Plain and Simple Way, Second Edition, by Satya Narayan Dash [2] Online Course: Practical RMP with Primavera Risk Analysis, Second Edition, by Satya Narayan Dash [3] Online Course: MS Project Live Lessons, by Satya Narayan Dash        

Two-Pass Technique with MS Project

  Project Management Institute (PMI)® Professional Development Units (PDUs): This Webinar is eligible for 1 PMI® PDU in the Technical category of the Talent Triangle.   Event Description: In schedule management, one of the scheduling approaches to develop a project or program schedule is the Critical Path Method (CPM), which determines the critical path. You, as a management practitioner, would have heard about CPM because it’s a widely scheduling approach. The main way to determine the critical path is to use the forward pass and backward pass technique. This is also known as the two-pass technique. With this method, one can find out the early start (ES), late start (LS), early finish (EF) and late finish (LF) for every activity in a network diagram. This method also determines the total float (TF) or total slack, which informs about the flexibility of schedule. In this webinar, we explore: How to conduct forward pass and backward pass calculations How to determine the total float/slack for the activities What are the significances of total float, ES, EF, LS and LF? How does Microsoft Project software address two-pass technique? How does Microsoft Project software determine total float/slack?   Presenter Info: Satya Narayan Dash is a management professional, speaker, coach and author of six books.  His video courses, PMP Live Lessons – Guaranteed Pass and PMP 35 Contact Hours Online, have created many successful PMPs. His course of MS Project Live Lessons, is one of most used courses by management practitioners. Over 1,500 aspirants have successfully cracked the PMP examination with his leadership and there are 84 documented PMP Success Stories in detail. His web presence is at https://managementyogi.com  and he can be contacted at managementyogi@gmail.com.   Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]  

The Close Sibling of Communications and Stakeholder Management: Resource Management

In one of my earlier articles, 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: 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: In the preceding section, we also just saw that the key plan prepared in the Resource Management is the Resource Management Plan (ResMP). The interactions among these knowledge areas will focus on these four documents and how they are flowing across the various processes of these knowledge areas, as well as cutting across the process groups. Interaction Point 1 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: 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. 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. References [1] PMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash [2] PMP 35 Contact Hours Online Course, by Satya Narayan Dash [3] I Want To Be A PMP: The Plain and Simple Way To Be A PMP, 2nd edition, by Satya Narayan Dash [4] Project Management Body of Knowledge (PMBOK) Guide, 6th Edition, by Project Management Institute (PMI) Related Articles Resource Management Training

The Two-Pass Technique

In schedule management, one of the scheduling approaches to develop a project or program schedule is the Critical Path Method (CPM). This is one of the oldest and widely used scheduling methods. The CPM determines the shortest possible time the project can complete, along with the end date of the project. The main way to determine the critical path is by using the forward pass and backward pass technique. This is also known as the two-pass technique. With this method, one can find out the early start (ES), late start (LS), early finish (EF), and late finish (LF) for every activity. This method also determines the total float (TF), which informs about the flexibility of schedule. This helps any management practitioner, because, with this technique, you can also determine the flexibility of individual tasks/activities and can assign, replace, and add resources based on the demand of the project or program. For example, a new resource can be put into an activity, which has high flexibility (i.e., a high total float (TF) value). The advantage of using MS Project is that it auto-calculates everything for you: ES, LS, EF, LF, the critical path, and the TF. This is highly useful as schedules changes over the course of a project/program. It’s also possible that you may have constraints added, removed, or modified into the project, which will impact these values. The software re-calculates these values. There are multiple ways to calculate the critical path and the values related to forward and backward pass techniques, but MS Project calculates them in a very specific way. In my on-demand webinar, we explore: How to conduct forward pass and backward pass calculations How to determine the total float for the activities The significances of total float, ES, EF, LS, and LF? How Microsoft Project software address the two-pass technique How Microsoft Project determines total float Watch the session on-demand.  

Want To Be A PMI-ACP? The Primary Steps to Take

Project Management Institute (PMI)® Professional Development Units (PDUs): This Webinar is eligible for 1 PMI® PDU in the Technical category of the Talent Triangle. Event Description: The Agile Certified Practitioner (ACP®) certification from The Project Management Institute (PMI®) is one one of the fast-growing certifications since its inception. As of May 31, 2020, there are over 35,000 ACP credential holders, worldwide. Unlike many other related Agile certifications, which can be easily done in 24 hours or max 72 hours with little to no effort or learning, the ACP certification takes sincere effort on your part to earn. Also, unlike other related Agile certifications, which quite individualistic in nature, i.e., focus on a single approach such as Scrum or Lean, the ACP certification covers many areas such as Kanban, BDD, TDD, XP, Crystal etc., including Scrum and others. In this webinar, we will discuss the following: How to become a Candidate ACP from an Aspiring ACP How to become an Actual ACP from a Candidate ACP How to continue being an ACP How to approach the ACP exam in a world impacted by Covid19 virus crisis Presenter Info: Satya Narayan Dash is a management professional, speaker, coach and author of six books, including the book: I Want To Be An ACP. Under his leadership, over 100 professionals have earned the Agile Certified Practitioner (ACP) and many have written their detailed success stories. He frequently writes on Agile topics, including the Agile Asanas series, which brings-in innovative practices. His web presence is at https://managementyogi.com, and he can be contacted at managementyogi@gmail.com. Have you watched this webinar recording? Tell MPUG viewers what you think! [WPCR_INSERT]

Becoming an Agile Certified Practitioner

Those who adapt, survive. Those who adapt and act, thrive. This is the essence of Agile. –from the book, I Want to Be An ACP. Project Management Institute’s (PMI®) Agile Certified Practitioner (ACP®) certification is relatively new when compared with the Project Management Professional (PMP) certification. As of January 2020, over 1,000,000 professionals globally hold a PMP certification, and the main reference guide, the Project Management Body of Knowledge Guide, has seen over 6 million downloads. Though ACP certification is new, it’s been one of the fastest growing certifications since its inception. As of May 31, 2020, there were over 35,000 ACP credential holders worldwide. In my view, this is primarily due to the following facts: The certification is coming from PMI, a well-recognized and trusted body globally within the project, program, and portfolio management community. Unlike many other certifications, which can be easily done in 24 hours or at max 72 hours with little to no effort, the ACP certification takes sincere effort to earn. I have seen people who never did a single Agile project in their career suddenly become ‘experts’ in Agile or ‘masters’ in Scrum, after a certification earned in only two days! How is that even possible? It insults common sense. When studying for the PMI-ACP certification, aspirants learn a whole gamut of frameworks and methodologies: XP, Scrum, Lean, Kanban, Crystal, FDD, and TDD, among many others. The ACP certification is not tied to any single Agile or lean framework. The exam is well structured, well administered, tested professionally, and recognized within the Agile management community. The certification is constantly changing and evolving to accommodate the needs of the Agile practitioners. For example, PMI added quite a few reference books in the latest change for the ACP exam in 2019. Another aspect is that Agile driven methodologies (or frameworks) have seen wide acceptance in the industry today. In industries, where requirement churn is high, Agile approaches are often considered and used for product development. In my on-demand webinar, we discuss the following: How to go from an Aspiring ACP to a Candidate ACP? How to go from a Candidate ACP to a Successful ACP? How to continue being an ACP? How to approach the ACP exam in a world impacted by COVID-19? This webinar is based on my teachings, interactions, and what I’ve learned from professionals aspiring to be ACPs and from professionals who are already ACP credential holders. I hope you enjoy the session.