Course Review: MS Project Live Lessons – Enables to Learn and Master the Application to Help in Delivering Successful Projects

By Mukundan Vikkath, PMP

Why this Course?

My whole 25 years’ experience is in heavy equipment manufacturing and construction. For the last 10 years, I’ve been responsible for managing project teams delivering orders with respect to various mega projects in the Oil & Gas and Energy sectors. 

Though I’m skilled enough to monitor schedules and resource allocation across multiple projects, I didn’t have hands-on experience in preparing schedules using software tools. 

I believed having a certain level of fluency and expertise in MS project software tool would be helpful to analyse complex schedules and manage shared resources without too much dependency on schedulers.  

Features in this Course

In my observations, the key aspects of MS Project Live Lessons course are the followings:

• Seamless integration of the theoretical concepts from the Project Management Body of Knowledge (PMBOK) guide to software application usage in MS Project.
• Simple and short videos, which makes it much easier to understand for any level.
• Clarity on each topic has been reinforced by practical and quiz questions at the end of every lesson. 

Following topics helped me mostly in managing my work effectively:

• Analyzing Project: Critical path analysis/measurement (CPA/CPM) and schedule compression techniques.
• Tracking Project: Establishing the baselines for the project and determining the variances.
• Project Reporting: Generating easy to understand infographics.

In this course, other areas such as Resource Levelling, Resource Pooling, Earned Value Management etc. are extremely beneficial and worth highlighting.

I received a number of key-board shortcuts, tips and tricks provided towards the end of the course, and they are very useful. 

Conclusion

I would recommend this course to any project professional, either beginner or experienced to gain an in-depth understanding of the key project concepts along with basic skills to work on the wonderful MS Project software application. 

Mr Satya Narayan Dash is an inspiring teacher, and the entire course module has been compiled brilliantly to suit all kinds of learners at their own pace. 

Brief Profile: Mukundan Vikkath, PMP: Currently working as Project Management Department Manager in a leading Heavy Equipment Manufacturing Company in the Middle-East.

You may also like:

• MS Project 2016 Live Lessons - Guaranteed Learning or Your Money Back
• MS Project 2013 Live Lessons - Guaranteed Learning or Your Money Back
• PMP 35 Contact Hours Online Course - Full Money Back Guarantee

Articles on MS Project:

• Working with Multiple Baselines in MS Project
• 9 Ways to Check Critical Tasks in MS Project
• How to Create an Agile BurnUp Chart with MS Project (Part 1)
• How to Create an Agile BurnUp Chart with MS Project (Part 2)
• Agile Cumulative Flow Diagram (CFD) with MS Project 2013/2016 
• 'Formula Bar' and 'Entry Bar' - Two Different Functionalities in MS Project
• Five Important Tips - Setting Up MS Project 2013
• MS Project 2016 Brings New Agile Features
• Work Breakdown Structure (WBS) in Traditional and Agile Life Cycles with MS Project
• Understanding Velocity in Agile Approaches with MS Project
• Product Prioritization Techniques in Agile Development with MS Project

PMBOK 7th Edition: Principles, Performance Domains and Artifacts – How Do They Plug and Play Together? (Part - 2)

I'd strongly recommend that you go through the first part of this series on PMBOK's principles (PR) and performanc domains (PD) before proceeding with this one. This part is about artifacts and interactions among the PRs, PDs and Artifacts. 

This series: Part - 1

--

PMBOK7 Artifacts *** UPDATED ***

The way to connect the dots and understand this article is also to know the artifacts. An artifact can be an output, a project document, or even a project deliverable.

Considering risk and uncertainty, we mainly have three artifacts:

• Project Risk Management Plan: How to identify, assess, respond, manage, and monitor the risks in a project.
• Project Risk Register: List of identified risks in a project, also known as the Risk Log.
• Project Risk Report: Summary of individual and overall project risks.  

Similarly, when considering other aspects such as Delivery PD, Project Work PD, or Measurement PD, there can be a number of artifacts.

How Do They All Plug and Play Together? *** UPDATED ***

So far, we learned about the PRs, PDs, and artifacts. The final part of the PMBOK7 puzzle is to understand how all these work in unison. This is how.

• For every project, while all principles are present, a few principles will be predominantly applied.
• The degree of application of the principles and the way they are applied can vary. It can be based on organizational context, deliverables, project team, stakeholders, etc.
• Performance domains are also present in every project, but then again, we don’t focus on all aspects of the PDs throughout the lifecycle of the project.
• The way PDs relate and apply differ for each project.
• Principles chosen for a project guide the behavior of the project team and project stakeholders, whereas performance domains chosen for the project are areas to demonstrate that behavior.
• PRs influence and shape the PDs to achieve desired outcomes
• The artifacts are used, applied, and can also come from the PDs. 
• Models and methods are also applied on the project to achieve desired outcomes. 

An Example – Risk PR, Uncertainty PD and Artifacts

To understand better, let’s combine the Risk PR, Uncertainty PD, and the associated artifacts. I’ll also inform you of the models and methods involved in this interaction, shown in the figure below. 

Let’s interpret the above figure:

• Principles guide the behavior of the people involved in the project. For example, the Risk Principle guides what to do with the uncertainties and risks in the project.
• Domains are broad areas of focus to demonstrate that behavior. For example, the Uncertainty PD is a broad area of focus to demonstrate how risk responses are optimized.
• The Models are applied on the PDs. For example, considering Uncertainty PD, Stacey’s diagram (a complexity model) can be applied. Another complexity model applied is the Cynefin framework.
• The Methods are also applied to the PDs. For example, the probability and impact matrix is a method that can be applied to the Uncertainty PD.
• The deliverables and artifacts are from the PDs. For example, the risk register and risk report are artifacts from the Uncertainty PD.

That’s it! Was it difficult to understand?

If you have read sincerely and understood so far, you have absorbed the very essence of the new PMBOK Guide.

Video – Key Notes on PMBOK7 *** NEW ***

Now, it’s time to note and recap certain key points with respect to the PMBOK7 principles, domains and artifacts. I’ve prepared this below video [duration: 04m:11s] for your understanding. Reference for this video has been taken from my RMP Live Lessons course.

Guidance for PMP and RMP Exams 

The most common questions I receive in my regular interactions with management practitioners are with respect to the RMP and PMP exams. PMBOK, 7th edition has taken a paradigm shift compared to the PMBOK, 6th and the practitioners want to know their usages and needs in the new versions of the PMP exam.

Is PMBOK7 needed for the RMP Exam?

The short answer is yes.

Elaborating further, one of the RMP exam’s explicit reference sources is the new edition of the PMBOK 7th edition, which has a principle-based standard. This is well-complemented with the PMBOK 6th edition, which is a process-based standard. For your RMP exam, you must refer to both, because the main source of the exam is the Foundational Standard for Risk Management in Portfolios, Programs, and Projects, which follows a process-based approach with a set of risk management principles.

Is PMBOK7 needed for the PMP Exam?

The short answer is no.

You’ve probably seen many sites, portals, and exam preparatory courses inform on the PMBOK Guide, 7th edition as a must-read. In reality, at the time this article is written, it’s a should- or could-read. Nevertheless, knowing the latest management principles, practices, and artifacts is a good idea. Recent PMP and RMP success stories in 2023 from my management sessions confirm that.

Conclusion *** UPDATED ***

To wrap up this article, principles by their very nature are self-evident, true, and real. For example, the principle of “Demonstrate leadership behaviors” applies not only to the project manager but also to every team member.

Principles will light up the path for your practices. Why so? Because a project is almost always executed in an uncertain environment. In other words, your path will be uncertain and sometimes dark and you won’t know how to proceed. Principles act like rays of light guiding your path in an uncertain project terrain. While principles are guidelines, practices are real-world usages. These practices are performed with activities and functions in the performance domains that we have reviewed here.

I hope you now have a big picture as well as a zoomed-in view of the PRs, PDs, artifacts, and how they all fit together. As always, your thoughts, views, and comments are welcome. Please share them in the comment section below.

This series is concluded.

This series: Part - 1

—

This article is dedicated to the memory of my father, the late Harendra Nath Dash, who passed away four years ago on June 11, 2019. It’s a tribute to him, my mother, and their teachings.

Thank you, dear readers, for reading this piece. And, wish you a very happy new year, 2024.

--

This article was first published by MPUG on June 13, 2023. This an updated and refined version. 

References

[1] RMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] RMP 30/40 Contact Hours with Money Back Guarantee, by Satya Narayan Dash

[3] I Want To Be A RMP: The Plain and Simple Way To Be A RMP, Second edition, by Satya Narayan Dash 

[4] Project Management Body of Knowledge (PMBOK) Guide, 7th Edition, by Project Management Institute (PMI)

PMBOK 7th Edition: Principles, Performance Domains and Artifacts – How Do They Plug and Play Together? (Part - 1)

Over a decade and a half ago my father and mother visited me in a different city, nearly a thousand miles away from home. Being very young, with few years of work experience, I was struggling to cope with the work pressure, compounded by no family or family friends in a new city with a totally different culture, language, food, and even clothing. My father was very concerned and tried to help in as many ways as he could. He even brought breakfast for me. One day, in jest, I told him that I’ll follow a set of principles to make my work and schedule better. A stern and tough father from the outside, but soft inside, he smiled and said: “Can you follow just a few? Try it. It’s hard!”

But why is following a set of principles so hard? As I’ve seen, in project-program-portfolio management, the primary reason is the constraints. For a project, it’s usually the scope, time, and cost, whereas for the programs it’s the delivery of benefits, and for the portfolio, it’s about the value and value optimization, capacity, and capability.  

In addition, saying is always easier than doing. Having principles written in a notebook or project board is always easier than following them. Talking about results from principles is far easier than actually delivering the results!

In this article, however, we will not only learn the principles (PR), performance domains (PD), and associated artifacts, we will also see several examples and applications. Towards the end, I’ll demonstrate how all these fit together. 

This series: Part - 2

PMBOK7 Principles (PR) *** UPDATED ***

A principle is a fundamental norm or truth. Now, before getting into the project management principles (PR) informed in the Project Management Body of Knowledge (PMBOK®) Guide, 7th edition, let’s understand certain top points on these principles of project management.

1. Principles are not prescriptive in nature, unlike the principles in a profession. They are not laws of project management. They are intended to guide the behavior of the team members and stakeholders.
2. Principles of project management serve as guidelines for decision-making and problem-solving in a project.
3. Principles can but don’t necessarily reflect morals. Values defined in PMI®’s Code of Ethics reflect morals. The values of PMI are responsibility, respect, fairness, and honesty.
4. In total, there are four values and 12 principles. The 12 principles are aligned with the four values and complement them, like the principles and values of Agile Manifesto.
5. Principles are internally consistent, meaning that no principles contradict other principles. However, in practice, principles can overlap.

The twelve project management principles (PR) are noted in the below table. Each principle has a principle statement, a principle label, or principle tag(s). I’ve outlined only a simplified part of the principle statement in the table. 

As shown in the above table, there are 12 PRs with principle labels and simplified PR statements. There is also a complete PR statement. For example:

• Complete Principle Statement: Continually evaluate exposure to risk, both opportunities and threats, to maximize positive impacts and minimize negative impacts on the project and its outcomes.
• Simplified Principle Statement: Optimize risk responses.
  It’s the tenth PR in the above table.
• Principle Label/Tag: Risk.

If you are preparing for your Risk Management Professional (PMI-RMP)® or Project Management Professional (PMP)® examinations, you have to remember all the principles, labels and understand the principle statements. Indeed, for latest RMP exam from 2022, the PMBOK 7th edition has been explicitly listed as a reference.

PMBOK7 Performance Domains (PD) *** UPDATED ***

Next, let’s understand the performance domains (PD). PMI defines a PD as follows:

A group of related activities that are critical for the effective delivery of project outcomes.

Simply put, it’s a group of related activities. The top points about the performance domain are the following:

• The PDs are interactive in nature, i.e., all the PDs interact or talk to each other.
• The PDs are interrelated. Not a single PD stands on its own.
• PDs are interdependent. Notice that the word, it’s not dependent on each other or even a better form, i.e., independent of each other, but interdependent, which is the highest form of dependency!
• PDs have outcome-focused measures, not output focused. When we talk of output, it’s usually the end product or service, whereas when we speak of outcome, it’s what one can do with that product or service. 
• PDs overlap and interconnect with each other.
• PDs are present in every project, but the way in which they relate and interact may differ.
• PDs run concurrently in every project – single, multi-phased, or the way value is delivered.

Do note that although the definition of PD refers to a group of interrelated activities, the specific activities to be considered in each PD are determined by organizational context, project, deliverables, project team, and stakeholders, among others.

There are eight performance domains which are outlined in the below table. I’ve simplified the descriptions so they are easier to understand and remember.

As noted earlier, all eight PDs interact with each other, which is depicted in the below figure.

Specifically considering the Uncertainty PD, which is associated with Risk Management, the following figure can be inferred.

As shown, the Uncertainty PD works in collaboration with all other PDs. For example, considering Uncertainty and Measurement PDs, one can have a risk reserve burndown chart, which shows the amount of contingency reserve available compared to the amount of risk remaining in the project. It’s a variant of burndown charts and can be presented in the Dashboard.  

Principles and Performance Domains

Now you may be wondering how the PRs and PDs work together? This concept is very foundational to know as a project, program, portfolio, agile, or risk management practitioner.

The most important aspect of PR and PD synergy is this:

Principles guide the behavior of the people involved in the project. Performance domains, or simply domains, are broad areas of focus to demonstrate that behavior.

This is shown in the below figure.

Let’s take the example of Risk principle (PR – 10) and Uncertainty domain (PD – 8) to understand the above aspect.

The Risk PR guides the behavior of the people involved in the project and advises them to maximize opportunities, minimize threats to the project and optimize risk responses. Among others, the Risk principle also tells us to address risk continually, understand risk parameters such as risk attitude, risk appetite, and risk threshold, and subsequently manage and monitor risks in a project.

However, the Uncertainty PD is the broad area of focus to demonstrate what one learned with the Risk PR. Questions such as:

• How to maximize opportunities?
• How to minimize threats?
• How to plan and optimize the risk responses?
• Should one consider one risk or multiple risks?
• Should one consider individual risks, overall project risks, or both?

These questions are answered through demonstration in the Uncertainty PD. In addition, there are other areas such as volatility, ambiguity, and complexity (from the VUCA acronym) in the Uncertainty PD. Therefore, this PD becomes a “broad area of focus” to apply to the Risk PR.

This series: Part - 2

References

[1] RMP Live Lessons – Guaranteed Pass or Your Money Back, by Satya Narayan Dash

[2] RMP 30/40 Contact Hours with Money Back Guarantee, by Satya Narayan Dash

[3] I Want To Be A RMP: The Plain and Simple Way To Be A RMP, Second edition, by Satya Narayan Dash 

[4] Project Management Body of Knowledge (PMBOK) Guide, 7th Edition, by Project Management Institute (PMI)

Understanding PMI Exam Score Reports

While preparing for Project Management Institute (PMI) related exams, it’s highly important to know how the scoring happens and what basis the scoring happens. It’s equally crucial to know when and why you will be considered to have passed or failed the exam. 

PMI provides a number of certification exams. Some of them are:

• Project Management Professional (PMP) Exam,
• Risk Management Professional (RMP) Exam,
• Agile Certified Practitioner (ACP) Exam,
• Portfolio Management Professional (PfMP) Exam,
• Certified Associate in Project Management (CAPM) Exam.

In this article, we will know the importance of ECO, how the exam rates your performance and dissect the PMI Exam Reports. Going forward, I’ll be using scores from varieties of PMI exams, including PMPs because I’ve seen hundreds of them personally. This is also important to know for you as an exam taker. 

In all my PMI exam related books and/or courses, including Agile, I’ve consistently emphasized on the Exam Content Outline (ECO), on which every PMI exam is based upon. For example, the PMP Exam as popularly believed is actually not based on the Project Management Body of Knowledge (PMBOK) Guide, but on the ECO! The RMP Exam is also not based on the Standard for Risk Management in Portfolios, Programs and Projects, but again on the ECO for the RMP Exam. Similarly, it’s applicable to all other exams such as PfMP or others.

Importance of the ECO

The ECO is important because you will be evaluated on the domains of the ECO. For example, in the PMP Exam, there are 3 domains:

• Domain I - People
• Domain II – Process
• Domain III – Business Environment

You will be evaluated on these domains, the associated tasks and enablers. 

For the RMP exam, there are 5 domains:

• Domain I – Risk Strategy and Planning
• Domain II – Risk Identification
• Domain III – Risk Analysis 
• Domain IV – Risk Response
• Domain V – Monitor and Close and Risks

Again, each of the above domains will have tasks and enablers. You will be evaluated on each domain. 

Now you might be thinking, how do you know you have passed or will pass the exam?

For that, you have to understand the performance rating categories. 

Performance Rating Categories

There are four performance rating categories:

• Above Target (AT): Your performance exceeds the minimum requirements for this exam.
• Target (T): Your performance meets the minimum requirements for this exam.
• Below Target (BT): Your performance is slightly below target and fails to meet the minimum requirements for this exam. Additional preparation is recommended before re-examination.
• Needs Improvement (NI): Your performance is far below target and fails to meet the minimum requirements for this exam. Additional preparation is strongly recommended before re-examination. 

The targets are expressed in ranges. It helps you to see how you scored in the exam with respect to the performance domains. It’s overall performance across all the exam domains. 

A sample exam report has been shown below, where the candidate has passed the exam.  

As you’d noticed in the above figure, it’s clearly written on top: PASS. It means the candidate has passed the exam. 

But then there are multiple zones (ranges) mentioned for the performance categories with multiple color coding. What are they?

Let’s take a real exam report to understand.

Some Real PMI Exam Reports

The below snippet is from a real PMP exam. Here the candidate PMP has successfully cleared the exam and is a certified PMP. You can read the PMP Success Story.

 

As shown above:

• The exam report is divided into two zones: Failing Zone and Passing Zone.
• The final score pointer (the black vertical line with the marker 'YOU' on top) is showing the final result. 
• If the pointer is falling in the failing zone, then you have failed. If the pointer is falling in the passing zone, you have passed the exam. 
• Sometimes the pointer is exactly in the middle! But again, it will still be in the passing or failing zone. 

For the above one, the pointer is in the AT zone (Above Target) and obviously the candidate has scored AT in all PMP exam domains. 

I just informed you that the pointer can be exactly in the middle. Did you read that line? If you have, again note that scoring will still happen! 

The below score report is from a real PMI exam. The candidate was very unlucky here. Just one or two questions correctly answered and the candidate would have been a certified RMP. Sigh! I felt very sad to see this report. 

In the above figure, you can see the pointer is exactly in the middle, but it’s touching the far-end border of the Below Target (BT) zone! If it would have been the near-end border of Target zone, then the candidate would have passed the exam. 

There are others like the two shown below. Again, these are from real PMI exams. As seen, candidates mostly fail because they follow the wrong providers or coaches. Your provider and coach matter. Both will be instrumental for your successes in the exams.

Another one is shown below from a PMI exam.

Again, notice the statement in the above figure with a pointer in BT zone: The performance is slightly below target. With additional preparation, you have a high chance to clear the exam. 

Now, while for the first one, the pointer is in the Needs Improvement (NI), for the second one the pointer is in the Below Target (BT) zone. 

Also, did you notice the color coding?

If not, re-look at them again. This is typical Red-Orange(Yellow)-Green color coding. 

• If it’s in the NI zone, the color coding will be red.
• If it’s in the BT zone, then the color coding will be orange/yellowish.
• If it’s in the T zone, then the color coding is blue. 
• If it’s in the AT zone, then the color coding will become deep blue. 

At this stage, another question comes-up:

How does this overall performance rating category relate to individual domain related rating categories? 

Let’s take an example to understand. 

This the expected segregation of questions as per the ECO.

Domain Based Segregation

In this case, I’ll take the Risk Management Professional (RMP) Exam. In this case we have five domains and any of the above four performance categories can come for these five domains. 

Let’s say a candidate has scored the following: 

• Risk Strategy and Planning: T 
• Risk Identification: AT
• Risk Analysis: BT
• Risk Response: AT
• Monitor and Close Risks: AT

In this case as the candidate has scored AT and T in most of the domains, except one. Obviously the candidate has passed the exam. And of course, the score pointer will be under the passing range. 

The individual domain related scoring for the above case is shown below. 

As shown above, each domain has a performance rating category and they are color coded. This comes with a pie chart, whereas the overall performance rating category will be in the bar chart.

Various Possibilities 

Now, one of the most important parts is to know if you have passed or failed the exam. In other words, what are the possible combinations in which one can definitely say to pass or fail the PMI exams. 

With absolute certainty, one can say the following:

• If you are scoring Above Target (AT) and/or Target (T) in all exam domains, then you’re definitely going to the exam. Mark the word ‘definitely’. 
• If you are scoring Below Target (BT) and/or Needs Improvement (NI) in all exam domains, then you will definitely fail the exam! Again, mark the word ‘definitely’. 
• If you can score AT in the vast majority of the domains (4 out of 5) and not fall under NI for any domain, then you will pass the exam.

Conclusion

Other than the above ones, nothing can be conclusively said, except the following.

• Never ever fall into the Needs Improvement zone. It will pull your overall score down and highly likely that you will fail the exam. 
• Considering 5 domains, if you have 2 or more NI ratings, then you’d definitely fail the exam!

In other words, don’t leave any domain unprepared (not underprepared). Go through each domain, learn as much as you can, practice as many questions as you can before you appear for the exam. 

I hope you understood the importance of ECO, related domains and how you should target to prepare for PMI related exams.

I wish you all the very best for your PMP, RMP, ACP, PfMP and/or other PMI related exams.

References:

• PMP Live Lessons – Guaranteed Pass or Your Money Back
• RMP Live Lessons – Guaranteed Pass or Your Money Back
• ACP Live Lessons – Guaranteed Pass or Your Money Back

Portfolio Management and Benefits Dependency Map

While interacting with aspiring Portfolio Management Professionals (PfMP), some of the questions that come-up are these:

• Why should a Portfolio be worried about benefits and benefits management?
• Is not benefits management part of a Program with a dedicated domain?

Also, in the PMBOK Guide, 6th edition as well as 7th edition, benefits management has been informed in many places! Indeed, in the PMBOK Guide, 6th edition aspiring Project Management Professionals (PMP) specifically need to know about the Project Benefits Management Plan, which acts as input while building the project charter.

In addition, (Project/Product) Managers and Scrum Master speak mostly in terms of features, not benefits! In this article we will understand the importance of benefits and its significance in portfolio management. 

Features Vs. Benefits

First the key distinction between features and benefits:

A feature is something available in a product or service, whereas a benefit is something you gain from the product or service.

Let's take a few examples to understand:

1. A chatbot in a Web-Site is a feature, but the 40% reduction in customer response time due to the chatbot is a benefit.
2. Spell-check is a feature in a word-crunching software, but error-free document built with the software is a benefit. 
3. Taking a day-to-day example, reverse-osmosis (RO) in a water-purifier is a feature, but drinkable and much better quality water because of the RO are benefits.

So, while features are needed and prioritized depending on the framework/methodology followed, customers or buyers only understand in terms of benefits. Isn’t it? 

For example, when you buy a water-purifier with RO functionality, your first question is this – “how does it benefit me?” You, as a customer, are not much worried about the technicalities or nitty-gritties of RO, but really care about the benefits before you make the purchase decision. In fact, for any product you buy, you actually look for benefits coming from the features provided in the prouct!

So, benefits are important not only for project or program management, but also portfolio management. 

Benefits Realization and Portfolio Manager

As a portfolio manager, you need to clearly know both the fiscal and non-fiscal benefits to your organization. Of course, you must have a sound understanding of your organization’s vision, mission, goals, strategies and associated objectives. This will help you to understand not only benefits management, but also aid in benefits realization and optimization of benefits realization. 

Specifically considering portfolio benefits, portfolio value is delivered when benefits coming from portfolio components (e.g., projects, programs, operations) are realized in the hands of portfolio beneficiaries such as customers. Value is generated when beneficiaries use the benefits. And I can’t emphasize the below figure enough.  

As shown above, benefits translate to value. And it’s this value that your organization gets when the customer pays for its worth.

Now, a portfolio manager must understand how to relate an organization's strategic goals, objectives (or simply strategic objectives) and priorities with the portfolio component plans such as project or program management plan to achieve the organization’s strategic objectives. 

But why and how so?

The answer to it lies in the Benefits Dependency Map (BDM). The benefits dependency map is also called the Benefits Break-down Structure (BBS).  

The Benefits Dependency Map 

The vision (future state) and mission (purpose) of an organization along with the strategic objectives of an organization are documented in the Organization's Strategic Plan. Some of these strategic objectives are met by a portfolio and they are documented in the Portfolio Strategic Plan.

When you build the BDM/BBS, your starting point will be from the vision, mission and strategic objectives leading to benefits. This is shown below. 

As shown in the above figure, the vision and mission lead to the strategic objectives of an organization. Each strategic objective of an organization will be met when the benefits are delivered. In our case:

• Strategic Objective 1 is achieved when Benefit 1, Benefit 2 and Benefit 3 are delivered.
• Similarly, Strategic Objective 2 and Strategic Objective 3 will be achieved when the associated benefits are delivered.

These are noted in the Portfolio Benefits Realization Plan and/or the Portfolio Performance Variance Report, which is one of the key Portfolio Reports. 

But then, who delivers these benefits? 

The benefits are delivered by the portfolio component programs and component projects. 

Remember that a program is a set of interrelated projects or subprograms managed together to give you benefits, which is otherwise not possible if you manage them independently. And a project is a temporary endeavor which gives a unique product, service or result (output).

So, we are going to expand our previous BDM figure.

"How-Why" Logic of Benefits Dependency Map

I’ve expanded the previous, initial-cut BDM to include the outcomes and outputs. It’s depicted below.

As shown above:

• Benefit 1 will be achieved with one outcome coming from the output, i.e., from a project, program or subprogram.
• Benefit 2 will be achieved with three outcomes coming from three outputs – again from project or program.
• Benefit 3 will be achieved with two outcomes coming from two outputs – again from project or program.

As you move from left to right in the above BDM, the question is "how", i.e., how will this strategic objective be met with these benefits? But when you move from right to left, the validity of the BDM is verified by asking the question “Why?”. For example, why should we take this component project. 

This "how-why" logic helps to structure the map. This also clearly shows the link between your organization's delivery capability with projects and strategic objectives.

To know more on benefits, outcomes and outputs, you can refer to this article of Fundamentals of Value-Driven Delivery. Though this linked article is with respect to projects using Lean/Agile approaches such as Scrum or Kanban, the fundamental concepts are very much applicable for waterfall or hybrid projects.

Final Words

So, there it is! 

At the portfolio level, we also talk about benefits, benefits management and benefits realization, because only at the portfolio level we make decisions on which component to take, drop, suspend or resume based on the expected benefits from the components. 

These benefits help in achieving the organization’s strategic business objectives, which in turn helps in meeting the vision and mission of the organization. 

References

[1] NEW Book – I Want To Be A PfMP, the plain and simple way, by Satya Narayan Dash

[2] The Standard for Portfolio Management, by Project Management Institute (PMI)

From PMP, PgMP to PfMP: Project and Program Risk Management Vs. Portfolio Risk Management

Project and Program Risk Management when compared with Portfolio Risk Management will have many fundamental differences. Indeed, there are a large number of differences that you have to know, if you are coming from a project management or program management background. 

Many of my course and/or book subscribers are Project Management Professionals (PMP®), Risk Management Professionals (RMP®) and some of them want to pursue Portfolio Management Professional (PfMP®) certification. There are also aspiring PfMPs, who don’t have any other formal project or risk management certifications, but they understand risk management. As I spoke in a recent international webinar one can directly go for PfMP, without being a PMP or (Program Management Professional (PgMP®).

In this article I’ll elaborate on a number of differences between project risk management and portfolio risk management. To have a basic understanding of portfolio risk management, I'd recommend that you read the following article.

PfMP Exam Prep: Fundamentals of Portfolio Risk Management

This article is for both PMPs or PgMPs who want to be PfMPs and also for professionals and practitioners who directly aspire to be PfMPs. Again, you need NOT be a PMP, PgMP (or RMP) to be a PfMP as this article informs.

Now, let's see the differences. These are fundamentals and will be very useful for your PfMP exam.

Difference – 1: The Definitions

The differences start with the definitions. And the differences can’t be more contrasting! 

The definition of a project risk is as follows:

An individual project Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

On the other hand, the definition of a portfolio risk is:

A portfolio risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more strategic business objectives of a portfolio.

Did you notice the differences? While the former is about project objectives, the latter is about strategic business objectives. These can also be with respect to the success criteria of the portfolio, which are documented in the Portfolio Charter.

Difference – 2: Risks and Components

A project will have deliverables, whereas a portfolio can have components such as projects, programs, operations, business cases etc. 

Project risks (individual or overall) are ONLY about the project or any other sources of uncertainties impacting the project objectives. You can learn more on individual and overall project risks in this article.

On the other hand, in portfolio risk management, we consider risks arising out of the components. For example, when a project risk can’t be addressed at the project level and the project manager believes it can be addressed at the portfolio level (and it’s accepted at that level), then the risk will be escalated and managed at the portfolio level.

In fact, in portfolio risk management, we build the Portfolio Risk Component Chart, which is not applicable in project risk management.

Difference – 3: Interdependencies

In a portfolio, the components will have interdependencies, which can be visualized with Portfolio Roadmap. Risk management becomes critical and crucial when there are interdependencies among high-priority components. In such a scenario, the cost of failure of a portfolio component can significantly impact other components.

In project management, however, we don’t have any interdependencies among components, though there can be dependencies among the deliverables. These will be addressed by overall project risk. Remember that overall project risk is the effect of uncertainty on the project as a whole, arising from all sources of uncertainty including individual risks. 

Difference – 4: Maximizing Opportunities, Minimizing Threats Vs. Maximizing Financial Value

Project risk management is primarily about increasing the probability and/or impact of positive risks and decreasing the probability and/or impact of negative risks in order to optimize/increase project success. One can also say project or program risk management is concerned mostly about risks that arise with a project or program. 

However, a portfolio will have components such as projects and programs. Hence, a portfolio is concerned about:

a) Maximizing portfolio’s financial value,

b) Tailoring its fit into organizational strategy, and 

c) Balancing the portfolio components.

One can also say that portfolio risk management is about increasing the probability and/or impact of positive risks and decreasing the probability and/or impact of negative risks in order to increase the portfolio value, strategic fitness and balance of the portfolio. 

Again, can you notice the differences? Aren’t they very different?

Difference – 5: Contingency Reserve

I’ve written a number of articles on contingency reserve and management reserve. I’ve also informed the myths and facts about these reserves. 

Specifically considering contingency reserve, contingency reserve is at the individual project level. The earlier linked article informs more on its calculation, which happens during quantitative risk analysis.

However, for portfolio management, you as the portfolio manager have to provide contingency reserves across a pool of component projects and programs. 

Difference – 6: Equity Protection

This is another term, which you will come across for the first time in portfolio management, unless you have some prior understanding in financial management. Usually, it’s by financial asset management or insurance companies.

As noted, Equity Protection is a distinct concept in Portfolio Risk Management. This for all constituent projects and programs. The portfolio management holds an aggregate contingency reserve for all the components. These are usually for risks with low probability, but high impact. 

In project or program risk management, we don’t have any such concepts of equity protection. In portfolio management, equity protection can be for both threats (negative risks) and opportunities (positive risks).

Difference – 7: Risk Management Processes

On of the biggest confusions for professionals coming with PMP, PgMP or RMP certification is with respect to the risk management processes and how they interact with each other.

In project risk management, going by the PMBOK® Guide, one can find seven processes, which are:

• Plan Risk Management,
• Identify Risks,
• Perform Qualitative Risk Analysis,
• Perform Quantitative Risk Analysis,
• Plan Risk Responses,
• Implement Risk Responses, and
• Monitor Risks.

However, considering the Standard for Portfolio Management®, there are only two processes! 

• Develop Portfolio Risk Management Plan, and 
• Manage Portfolio Risks.

Now, as an aspiring PfMP you may be thinking the risk management planning happens in Develop Portfolio Risk Management Plan process. You are right! But then:

• What about risk identification, qualification and quantification?
• Where the risk responses are planned and implemented?
• How to monitor so many risks (because we are also considering component risks)? 

This is where the understanding has to be very clear. Briefly put risk management planning, qualification, quantification, response planning and implementation as well as risk monitoring (controlling is the word used in Portfolio Management Standard) are covered in the above two processes of portfolio management. There are some overlaps, too! These are covered in-depth with a number of diagrams in my new book: I Want To Be A PfMP.

There are many other differences such as with respect to Risk Register, Issue Register (and the processes in which they are created), risk owner, risk response/action owners as analysis such as Monte Carlo analysis, among others. These are also covered in the book.

Nevertheless, I believe with the above seven differences between project/program risk management and portfolio risk management, you have understood the basics. As you would have realized by this time, they are quite different, though the foundational aspects of risk management permeate in all – be it project risk management, program risk management or portfolio risk management. 

References:

[1] NEW Book - I Want To Be A PfMP, The Plain and Simple Way, by Satya Narayan Dash

[2] Book - I Want To Be A PMP, The Plain and Simple Way, 2nd edition, by Satya Narayan Dash

[3] Book - I Want To Be A RMP, The Plain and Simple Way, 2nd edition, by Satya Narayan Dash

[4] Article – PfMP Exam Prep: Fundamentals of Portfolio Risk Management, by Satya Narayan Dash

[5] Standards for Portfolio Management (multiple portfolio management standards referred), by Project Management Institute (PMI)