What Does it Take to Be a PfMP? If It Were Easy, Everyone Would Do It!

Becoming a Portfolio Management Professional (PfMP) from the Project Management Institute (PMI) requires more than just passing an exam. It demands a strong understanding of portfolio management concepts, the right mindset, and consistent preparation. 

Unlike project or program management, portfolio management is strategic in nature and focuses on selecting and governing the right investments for an organization by choosing the right components in a timely manner. 

As I keep on saying:

Projects create. Programs guide. Portfolios decide.

At the portfolio-level, you decide the components to take or drop, the investment to make or cancel, and of course, the strategic business objectives to be met.

Your success in the PfMP journey depends on how well you understand the underlying processes, apply concepts in real-world contexts, and prepare with disciplined practice. 

The following key points provides practical guidance to help you approach your PfMP preparation in a structured and effective way.

These are based on my interactions, experiences with certified PfMPs and enabling many professionals, over the years, to be certified PfMPs. 

--

1. Understand the flow of Portfolio Management processes.

In portfolio management, there are multiple process groups, processes as well as knowledge areas. It's easy to get lost with such vast content. 

This is where understanding the flow of processes becomes important. The flow helps you build a mind map and clearly presents the big picture in a narrative way. When you prepare in this manner, you gain a clear understanding of what portfolio management, as illustrated by PMI, is all about.

Most providers of PfMP courses don’t understand this flow, but it is very important. 

2. Learn with hands-on tools whenever you can.

Portfolio management is fundamentally different from program or project management. You need to learn it with a different mindset. 

Using software tools such as Primavera or MS Project adds clarity. With just theory, achieving that clarity is difficult.

3. Use high-quality questions.

In your PfMP exam, questions will be of a high standard. They are situational in nature and will ask what to do next, what you should do, or even, what you should not do! Rote learning will not help. You must understand the concepts.

You can expect confusing, puzzle-like questions. Sometimes they can be frustrating – for example, all choices may seem valid, or the question itself may not be very clear. 

Don’t expect the questions to be grammatically perfect or linearly structured. They are designed to challenge you. They are not testing your grammar or linear thinking, but these:

• Are you truly suitable to be a portfolio manager?
• Can you apply portfolio management concepts in the real world?
• Are you psychologically prepared to grasp and apply these concepts? 

These insights come from high-quality questions. If you want low-quality ones, the internet is full of them. Everyone claims to be an expert on the web, but reality is different.

4. Always remind yourself: "There is no shortcut. I've to work for it."

You must truly work hard to become a PfMP. As the saying goes: 

On the highway to success, there are no shortcuts. 

You not only need the required portfolio management and business experience, but also sincere preparation. 

If you expect a magic wand or quick tricks to succeed in days or weeks, you will be disappointed. Again remember, there are no shortcuts. 

5. Choose a truly good and simplified course.

Your course must be good, understandable, and digestible. Because portfolio management is vast, it’ll take time to digest. With the right course, your learning will be effective. Of course, real-world portfolio management experience is also important. 

Online learning is preferred because:

• You can access it anytime, from anywhere in the world.
• You can revise as many times as you want.
• You can focus on areas where you are weak.

With a good mentor, you can ask questions and get them clarified.

The course creator plays a significant role in your journey. 

6. Practice, practice and practice.

The old saying “practice makes perfect” is true. The more you practice, the better and more confident you become. This complements the previous one – a good course.

The tools, content, explanations should be top-notch and high-quality. Practicing with high-quality material gives you the best value. You’ll also remember more when you practice more. 

7. Have a different mindset – the strategic mindset.

Portfolio management is strategic in nature, whereas program and project management are usually tactical. Portfolios focus on choosing the right work, while projects and programs focus on doing the work right. 

Selecting the right work for an organization is inherently strategic.

Projects and programs deal with execution, whereas portfolio management is more business-oriented. This is where key investment decisions are made. Hence, while going for the PfMP, you need to have a strategic mindset. 

8. All domains are important – Strategic Management, Governance, Communication Management, and Risk Management.

Your PfMP exam is based on the Examination Content Outline (ECO), not strictly on PMI books, references, or standards. 

The ECO provides the blueprint for the exam.

Unfortunately, many courses follow their own templates without mapping to the ECO domains or tasks. If you prepare this way, you risk failing the exam. 

9. Stay in touch with your coach. 

Throughout your preparation, your coach – most likely the course creator – will be extremely important. He or she will motivate, inspire, and guide you. 

Choose a coach who genuinely cares about your success. Some may charge high fees but won’t provide proper support or guidance. In such cases, success becomes difficult.

Your determination matters greatly – and there is no substitute for it. Consistent support is also important. 

10. Never give-up.

Success is not final, and failure is not permanent. Life itself is a continuous learning process. We learn every day until the end. 

When you understand this, giving up is not an option.

Becoming a PfMP is not easy, and as the tile of this article goes – if it were easy, everyone would do it.

You've a dream to be a PfMP. Pursue that dream. Dreams do come true and many have become PfMP with my PfMP courses and/or PfMP book.

--

There are very few PfMPs in the world, unlike PMPs, which have around 1.5 million certified professionals. In comparison, the number of PfMPs is significantly lower. In fact, it’s not even 1% of the number of PMPs! Yes, not even 1%!

However, this isn’t surprising. As mentioned earlier, and as highlighted in one of the key points above, a strategic mindset is essential. Very few PMPs develop this mindset, and many struggle as a result.

But you don’t have to.

ManagementYogi’s PfMP courses have a proven track record, with many candidates successfully becoming PfMP certified. Some even achieve this without holding a single PMI certification beforehand.

These courses and books will help you understand, learn, and apply the required concepts and ultimately become a certified PfMP.

PfMP Exam Courses and Book:

[1] PfMP Live Lessons - Guaranteed Pass or Your Money Back, by ManagementYogi.com

[2] PfMP Exam Prep Online Course with Money-Back Guarantee, by ManagementYogi.com

[3] PfMP Exam Prep Book – I Want To Be A PfMP, First Edition, by Satya Narayan Dash, CIPSA, CHAMP

Program Change Request Management (PgMP) and Flow – The Standard for Program Management

Change is inevitable in every walk of our lives. Project, program, and portfolio management (PPP) are no different. However, the way changes are handled will differ in respective P-P-P management. 

Projects handle change with respect to the baseline and success is typically measured in terms meeting various constraints such as scope, schedule, cost, quality etc. Programs, on the other hands, takes a group of interrelated projects (and/or subprograms) to deliver benefits, which is otherwise not possible if you manage them individually. Hence, the program success is mainly about delivering benefits coming from outcomes of a program's components. Programs accept and adapt to change to optimize delivery of benefits. For portfolios – in sharp contrast – it's fundamentally about managing strategic changes.

Hence, I keep on saying in my interactions with Program Managers:

Projects are agents of change. Programs are coordinators of change. Portfolios are strategists of change. 

In this case, I'll focus on Program Change Management, which is key topic to know for aspiring Program Management Professionals (PgMPs) from Project Management Institute (PMI). 

For PMP change management flow, refer to this article. It’s one of the most-read articles. To understand deeply with lots of visuals and exercises, refer to the Guaranteed PMP course.

For PfMP change management, refer to this course: PfMP Live Lessons – Guaranteed Pass, which goes deeper into the strategic change management.

Note: There is no concept of processes or knowledge areas in PMI's Program Management Standard (SPgM). Rather we have various supporting activities and of course, the core activity of Program Integration Management. 

Program Management is much complex compared to Project Management as it’ll have a number of interrelated components driven together to deliver benefits. Hence, it’s best to simplify in understanding Change Request management for programs. The simplified flow diagram is shown below.

10 Key Points to Understand Program Change Request Management and Flow

Here are the 10 key points about program change request management. The reference for it taken from the Standard for Program Management from PMI.

1. A Program Change Request (PgCR) is a formal proposal to modify any program document, deliverable, or baseline. A PgCR can be a corrective action, preventive action or an update to program-level document.
2. During program formulation, we have the change assessment in the Program Change Assessment activity (shown above). The output of this activity is the Program Change Assessment. It happens with other assessments related to scope, schedule, financial, information, risk, quality etc.
   This helps in preparation the Program Charter (PgC), which in turn enables the preparation of the Program Management Plan (PgMP).
3. Our next activity is the Program Change Management Planning activity (shown above) in Program Definition phase. Here we create the Program Change Management Plan (PgCMP). It's a subsidiary plan of the PgMP. 
4. The Program Change Thresholds are also decided in the above-mentioned planning activity. The thresholds inform the level of change thresholds that should trigger the change process. For example, above 10% budget impact will be handled at the program level. 
5. The Program Change Management Plan (PgCMP) has the approach for capturing the change requests, evaluating each change, determining how to dispose the change, and communicating the decisions to the (impacted) stakeholders. 
6. The PgCMP is then fed into the next activity, i.e., the Program Change Management activity (shown above). It has both executing and monitoring & controlling aspects. This activity belongs to the Program Delivery Phase of the Program Life Cycle. 
7. All Change Requests are logged in a program-level document called Program Change Log. This log is created during the Program Delivery Phase and it’s created in the Program Change Management activity.  
8. The Program Steering Committee (also known as Program Governance Board) decides to approve or reject a requested change. Whatever may be the decision, it's recorded in the Program Change Log and the decision is communicated. Program Change Control ensures it. 
9. The PgCR, if approved, is called Approved Change Request. It is then implemented based on their urgency and impact assessment and the one most likely to deliver program's intended benefits is selected. Implementation can result in the updates to component plans as well subsidiary plans of the PgMP. 
10. The Change Decisions are always in the accordance with the Program Governance.
    The Program Governance Board or an appropriate body is responsible for defining the types of changes that a program manager can independently authorize/approve or that would require further discussion prior to approval.

--

The three key activities in Program Change Management cleanly maps into the various phases of the Program Life Cycle. It's shown in the below table.

That’s it! 

Was it difficult to understand? I believe it’s not. 

Again, do note that I’ve highly simplified the concept of program change management. As you go deeper, you’ll find many aspects to program change management. 

Nevertheless, simple things are always easier to remember, recall, and apply. 

Finally, as I close, I'll say this:

For projects, it's about integrated change control. 

For programs, it's about program governance and coordinated change control. 

For portfolios, it's about portfolio governance and strategic change management. 

Change Management:

[1] Change Request Flow (PMP) - PMBOK Guide 

[2] PfMP Live Lessons - Guaranteed Pass or Your Money Back

[3] PMP Live Lessons - Guaranteed Pass or Your Money Back

The Practical Scaling Imperative: 10 Lessons for An Aspiring CIPSA

 

The Certified in Practical Scaled Agile (CIPSA) framework helps professionals navigate scaling complexity by providing principle-driven, hands-on guidance for multi-team delivery. 

Based on the experiences of professionals who have taken the CIPSA course, the following lessons highlight the imperatives, mindset, and practices every aspiring CIPSA must embrace to succeed in real-world scaled Agile delivery.

I interact with them frequently and keenly listen to them. And I learn from them. 

Following are some of the lessons for aspiring CIPSAs.

--

1. Never, ever and under no circumstances think only at the team level.

A CIPSA must always see the bigger team, i.e., the CIPSA team, at scale. It is not about the individual Scrum or Kanban teams. To know more on CIPSA team, see here.

Scaled delivery succeeds only when teams understand how their work contributes to the larger product outcome. Thinking only at the team level leads to local optimization, local efficiency, but global ineffectiveness and inefficiency.

2. Never, ever and under no circumstances learn scaling without hands-on approach and software tools.

There is a plethora of Scaled Agile approaches, worldwide. However, not one – I repeat, not even one – tells how to do scaling in a practical, hands-on manner.

Nobody has truly learned anything by reading theoretical content. To learn, you have to do it hands-on. Agility scales through practice, not theory. 

You don’t scale by adopting a framework. You scale by doing the work. 

3. Never, ever and under no circumstances maintain multiple product backlogs for the same product.

One product demands one backlog. Vision at any time is only one and it’s part of the backlog. Multiple Scrum or Kanban teams under the CIPSA Team must move toward one shared vision. 

When teams maintain separate backlogs at the product level, priorities diverge, coordination collapses, and above all, nothing can really get accomplished. The single backlog ensures that all teams pull from the same prioritized source of work.

However, do note that there can be individual team backlogs. All these team backlogs will constitute the CIPSA Backlog – be it CIPSA Sprint Backlog (see here) or CIPSA Kanban Backlog (see here). 

4. Never, ever and under no circumstances ignore cross-team dependencies.

Dependencies are inevitable in scaled environments. In fact, you, as the Principal Scrum Master or Chief Product Owner, must know these dependencies. 

The responsibility of a CIPSA is to identify, visualize, and manage them proactively. Hidden dependencies often become the biggest delivery risks and stifle the delivery of CIPSA Integrated Increment (see here). 

5. Never, ever and under no circumstances refine work (backlog refinement) in isolation.

Backlog refinement in a scaled environment must involve multiple teams when work overlaps. It’s a dedicated meta-event for the CIPSA team and happens periodically. Without this event, the CIPSA Backlog can’t be properly prepared in the CIPSA Planning meta-event. 

Collaborative refinement ensures that teams understand upcoming work, dependencies, and integration points.

6. Never, ever and under no circumstances allow events to happen without synchronization. 

Scaled Agile delivery depends on synchronized events, e.g., in CIPSA Scaled Scrum, the Sprints are synchronized across teams. See here for an in-depth understanding on Sprint synchronization for multiple-teams. 

With it, all teams stay aligned and dependencies are managed effectively. Even if individual teams are performing well, lack of synchronization can cause misalignment, delays, and integration issues. Under no circumstance should a CIPSA allow teams to operate their events in silos when their work contributes to a shared product increment.

7. Never, ever and under no circumstances deliver work that cannot be integrated or cannot deliver an Integrated Increment. 

The purpose of scaling Agile is not parallel development. It’s about integrated delivery. The end goal in every Sprint or Release is to have a CIPSA Integrated Increment. 

You, as a CIPSA or an aspiring one, must ensure that increments from multiple teams combine into a cohesive product increment. See here for CIPSA Integrated Increment. 

8. Never, ever and under no circumstances allow lack of transparency across teams.

Visibility is the lifeblood of scaled agility. CIPSA team-level metrics should be shared clearly. Dashboard should be visible to all. Progress tracking to be on information radiators and entire team should be able to see it. 

This ensures transparency for all team members and stakeholders.

9. Never, ever and under no circumstances avoid CIPSA retrospectives.

The CIPSA framework has meta-events such as CIPSA Planning, CIPSA Retrospectives etc. I’ve consistently maintained that retrospectives and follow-up actions based on these retrospectives are of paramount importance. See here on the importance of retrospective. 

Some of the most critical improvements lie between teams rather than within the teams. Cross-team retrospectives help address systemic issues affecting collaboration, coordination, and flow – the latter in CIPSA Scaled Kanban. See here.

In fact, in the early stages of scaling, it’s CIPSA retrospectives that will bring the most value to your team. 

10. Never, ever and under no circumstances choose a “branded” framework over practical result.

The philosophy behind CIPSA emphasizes practical implementation. It’s a framework with ample guidance on how to proceed with hands-on software tools and scaling. 

Thorough explanation has been given on the implementation part taking real-world projects. This enables you to learn in the most effective way. 

What good is a “brand” if you can’t apply your learning in a hands-on manner from Day-1?

What good is a “brand” if you’ve paid loads of money, but have no real-world, practical use?

--

In conclusion, I’ll say the following. 

Many organizations proudly claim they have “Scaled Agile” and doing “Agile Transformation,” yet what they often have is a collection of independent Agile teams moving in different directions in Brownian motion. 

I’ve asked many Scaled Agile Practitioners who have been certified on “branded frameworks”:

• Can you show me a Scaled Backlog?
• Can you show the cross-team dependencies in a Scaled Agile Team?
• Can you show how you add the Meta-Events and how to track them?
• Can you create an integrated Burn-down/up chart for the entire team?
• Can you demonstrate how to allocate scarce, yet critical resources and resolve overallocations?
• And many more practical ones.

They don’t know and can’t demonstrate. And it’s certainly not their fault. 

They’ve just got a “branded certification” to show to their employers. They’ve flocked to it due to end-less marketing, promos and sometimes even film-actors parroting it! But it has no real-life value, no practical use other than “some branded tags”.  

Some believe that simply adding more Scrum or Kanban teams automatically leads to scalable delivery. It does not! Some others assume that coordination will somehow emerge organically once teams adopt Agile practices. The ground reality is far different and harsher. 

My experience in multi-team Agile environments in early last decade, learning from professionals who use my courses over the years, and above all the professionals pursuing the Certified In Practical Scaled Agile (CIPSA) course teach me the following:

True learning, implementation, and delivery happen in a practical, hands-on manner. No other methods come close. The best companies in the world understand this and ask their engineers to do it hands-on from the very beginning. 

If you are serious about understanding how Agile truly works at scale, there is no better way to learn than by immersing yourself in the CIPSA course.

👉 [Enroll Today] Pay via PayPal/Bank transfer. Email: managementyogi@gmail.com. Enroll in 24hrs.

CIPSA Certification:

[1] NEW Scaled Agile Certification Course: Certified In Practical Scaled Agile (CIPSA)

[2] Frequently Asked Questions (FAQs) - CIPSA Certification  

[3] New Practical Scaled Agile Framework – The CIPSA Framework Guide