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

Practical Scaled Agile (CIPSA) Certification: CIPSA Cross-Team Backlog Refinement – What It Is and What It Is Not!

There are meta-events in the CIPSA Framework such as:

• CIPSA Planning,
• CIPSA Daily Stand-ups
• CIPSA Review
• CIPSA Retrospective, among others.

One of the meta-events which usually gets overlooked is the CIPSA Cross-Team Backlog Refinement. 

It’s an ongoing activity for the CIPSA Team. In this article, we will know more on it.

The content of this article is based on the CIPSA Framework. See here. 

Exhaustive explanation is part of the CIPSA Certification Course. See here. CIPSA is world's only Practical Scaled-Agile certification. It supports both Scrum at Scale and Kanban at Scale.

To read all articles of this series use the below link: 

What It's and What It's Not series for CIPSA

CIPSA Cross-Team Backlog Refinement – What It’s and What It’s Not

Among many, the following are some of the top ones. Detailed explanations with practical, hands-on demonstration using real-world projects is part of the certification course.

1. Not Team Specific, but Cross-Team Effort: The Backlog Refinement is not limited to a single team working on its own backlog items, but it's a cross-team effort. 

Representatives from multiple Scrum or Kanban teams who share the same Product Backlog will be participating in this meta-event. This cross-team collaboration meta-event helps ensure that different perspectives are considered, dependencies are identified early, and the upcoming work is understood.

2. Not Optional, but Mandatory: Backlog refinement is not an optional one, but it's mandatory for the CIPSA Team. 

Backlog refinement in the CIPSA context is not an optional or occasional activity that teams perform only when they feel the need. It is an essential meta-event that ensures the Product Backlog remains clear, relevant, and ready for planning. 

Without this refinement, planning sessions may become inefficient due to unclear requirements, missing details, or unresolved dependencies. Do note that the CIPSA Planning meta-event usually happens after backlog refinement. 

3. Not One-time, but Ongoing: The refinement session is not one-time session, but it's an ongoing one throughout the life of the product/service delivery. 

The backlog is not a static list that remains unchanged until planning begins. Instead, it evolves continuously as new information emerges, feedback is gathered, and priorities shift. The CIPSA Backlog Refinement meta-event reflects this dynamic nature - clarify, adjust, reorder, or even remove as needed.

4. Not Isolated, but Aligned: The refinement session is not done in isolation, but it's in alignment with the organization's strategic goals and objectives.

Backlog refinement does not happen in isolation from the broader product strategy and/or organizational goals. Rather, it ensures that the backlog items remain aligned with the product vision, which is in turn is alignment with strategic priorities of your organization. 

5. Not CIPSA Planning, but a Prep for CIPSA Planning: The Cross-team backlog refinement meta-event doesn't replace the CIPSA Planning meta-event, but in a way complements it.

CIPSA Backlog Refinement should not be confused with the CIPSA Planning meta-event itself. Its role is to prepare backlog items so that planning can be effective and focused. It clarifies scope, identifies inter-team dependencies, and ensures readiness beforehand.

6. Not a Commitment Session, but a Forecasting Tool: This meta-event is not a commitment session for the CIPSA team members, but it's a forecasting tool.

The purpose of backlog refinement is not to commit teams to delivering specific items. Instead, it helps create a realistic forecast of what work might be feasible in upcoming Sprints – as in CIPSA Scaled Scrum (see here), or Releases – as in CIPSA Scaled Kanban (see here).  

CIPSA Cross-Team Backlog Refinement – Summary Table

The summary table is shown below. The complete table is part of the CIPSA certification course.

Conclusion

I believe this post will bring a lot of clarity with respect to the Cross-Team Backlog Refinement meta-event. 

The CIPSA certification, based on the CIPSA framework, focuses on practical scaling with hands-on software tools. The CIPSA certification course has a 70%:30% ratio – 70% practical and 30% theoretical. As a matter of fact, it's world's only Practical Scaled Agile certification. 

Want to experience it hands-on? Become a CIPSA. It’s world’s only Practical Scaled Agile certification.

--

CIPSA Success Stories and Reviews:

[1] From CHAMP to CIPSA – Taking Agile to the Next Level with Scaled Scrum and Scaled Kanban

[2] Scaling Agile: Key Insights from the CIPSA Framework Introduction

CIPSA Sample Videos and Questions:

[1] CIPSA Sample Video List (Choose a Video)

[2] CIPSA Video Playlist (Complete Playlist)

CIPSA Certification:

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

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

The Hybrid Imperative: 10 Lessons for an Aspiring CHAMP

Hybrid-Agile management is complex, unlike traditional waterfall or pure Agile. The latter has been accepted and used in various industry verticals, but not all projects fall into either of these camps. A number of projects demand different approaches. 

As many professionals and practitioners use the Certified Hybrid-Agile Master Professional (CHAMP) course, and I listen to them; I also learn a number of things from them. 

So, what are the lessons can we draw from them? Here they are.

--

1. Never, ever and under no circumstances should you learn Hybrid-Agile without hands-on learning and hands-on software tools. 

Theory without knowing how to apply theory is effectively useless. Nobody has learned swimming, cycling, or driving by reading theoretical content.

You’ve to get your hands dirty. You may fail a few times, or many times; but then that’s how you learn. That’s why it’s known as the best form of learning. It teaches you the most. Software tools such as MS Project are heavily used in the CHAMP course for this purpose. In fact, it's 80% practical. See here.

2. Never, ever and under no circumstances, believe that one methodology fits all projects.

Pure Agile and pure Waterfall are frameworks, not religions to follow. The moment you treat one framework as universal, immutable and dogmatic; you lose the flexibility that Hybrid approaches bring.

3. Never, ever and under no circumstances should you abandon structure in the name of agility.

Sprints without right long-term planning become chaotic in the long run. Scrum projects also need governance. Because flexibility without direction becomes an endless drift. I’ve seen many such teams working in that mode. 

Hybrid means disciplined adaptability, not improvisation without accountability.

4. Never, ever and under no circumstances should you freeze requirements in a changing environment.

Markets evolve, stakeholders rethink, risks materialize, team members leave, technologies change. A Hybrid leader plans firmly, but revises the plan when evidences are there. You, as a leader in hybrid-agile environments, should never freeze requirements completely. 

This is because some parts of the projects will have churns. And that’s reason to use Hybrid in the first place! 

5. Never, ever and under no circumstances should you measure performance using only one lens.

In Agile/Scrum, there will be Burndown/Burnup charts. There will be Release Histograms. But they can hide technical risks. On the other hand, in Traditional/Waterfall, Gantt Charts can hide flow issues in the team. 

Hybrid management demands both predictive metrics and adaptive indicators. In fact, with MS Project software tool, you can have board views both predictive and adaptive parts. This is applicable for all: Hybrid-Scrum, Hybrid-Kanban, or Hybrid-ScrumBan. 

See here for Hybrid-ScrumBan. It's an in-depth, hands-on article. 

6. Never, ever and under no circumstances should teams operate without transparency.

As is the case with monetary debt, technical debt too multiply. People take huge monetary debt to lead rich lives only to realize much later debt truly accumulates. If you don’t pay it off fast, it’ll be exponential in nature. Technical debt is similar! 

It happens to many teams. Hence, your boards should be visible to all. Milestones should be clearly noted. Reporting must be honest. 

Transparency is one of the foundations of trust. Trust is the foundation of leadership. See here. Hybrid-Agile management is no different. 

7. Never, ever and under no circumstances should you confuse speed with progress.

Speed is not a good indicator of progress. Progress can be time-consuming and at times very frustrating – but it’s much more important than speed. In many parts of your Hybrid projects, speed can be less, but there will be progress. 

These can be seen with progress indicators as CHAMP shows. The MS Project software tool indeed has indicator columns, which can be color-customized.

8. Never, ever and under no circumstances should teams be organized in silos while expecting cross-functional outcomes.

In one of the principles of Hybrid-Agile management, I informed about frequent integration. Specifically, it’s Principle – 7. See here. 

Hybrid success requires integrated collaboration and integration between predictive and adaptive parts. Integration doesn’t happen on the final day or last few days/weeks of project completion. It happens frequently. This removes silos and truly improves collaboration. 

9. Never, ever and under no circumstances should planning be treated as a one-time ceremony.

In traditional approaches, the well-known saying is planning is indispensable, but plans are useless. And as we know, irrespective of that, we do plan as it’s essential. 

However, plans must breathe and the planning documents should be living documents. Hybrid planning is continuous. For example, there can be strategic quarterly alignment combined with tactical Sprint refinement sessions.

10. Never, ever and under no circumstances should you forget that Hybrid is about outcomes and value, not frameworks.

Ceremonies, artifacts, and roles matter less than delivering value on time. At the end of the day, it’s value – coming from the outcomes, capabilities, and benefits – to the customer what actually matters. 

Hybrid-Agile management is about that value and its delivery in the best possible way to the customers. 

--

Finally, I'll conclude with the following. 

Many organizations either worship Agile as a miracle cure or cling to Waterfall as a symbol of tradition, power and control. Some believe flexibility means freedom from discipline. Some others believe structure means protection from uncertainty.

But in many scenarios, as we’ve learned in the previous article (see here), they may not work at either end of the delivery spectrum – be it Adaptive or Predictive. 

As a management practitioners and a keen learner, you'd know that it's not a matter of superiority, but maturity – the maturity in knowing that they are different ways to deliver, depending on the type of project. 

My experience in Hybrid-Projects, learning from professionals who use my courses, and above all the CHAMP certified professionals teach me the following:

Hybrid-Agile management with CHAMP is not a compromise between two camps – Agile and Waterfall – but, a deliberate, thoughtful and principle driven approach to go with both predictability and adaptability. 

If you are serious about knowing Hybrid-Agile management, there is no better way to know than using the CHAMP course. Start today and get into a deep-dive mode. 

Hybrid is no longer optional – it’s the reality of modern project delivery. The future belongs to hybrid-ready leaders.

ManagementYogi's CHAMP Certification Course:

• Certified Hybrid-Agile Master Professional (CHAMP)

CHAMP Reviews and Success Stories:

• CHAMP Course: Excellent One for Mastering MS Project in both Traditional and Agile Environments
• CHAMP Success Story: A Niche Certification –Never Seen Anything Like this Before!
• CHAMP Success Story: One of the Best Hybrid-Agile Certification Courses I Ever Attended

Free CHAMP Questions:

• 20 CHAMP Free Questions with Answers (Part - 1)
• 20 CHAMP Free Questions with Answers (Part - 2)

Tips for Hybrid-Agile Management:

• 5 Tips for Hybrid-Agile Management
• 5 More Tips for Hybrid-Agile Management

Seven Principles of Hybrid-Agile Management:

• Seven Principles of Hybrid-Agile Management (Part - 1)
• Seven Principles of Hybrid-Agile Management (Part - 2)

The Rise of Hybrid-Agile: Why and How CHAMP is Filling the Gap

Nearly two years ago, I wrote this:

“The waterfall or predictive mode of development has been there for quite sometime, and it’s here to stay. Some industries can’t follow Agile, e.g., making a movie. Will you release a movie in a theater every two or four weeks in parts? Will customers come to watch such a movie? 

Similarly, Agile is also here to stay. Agile is used when there is rapid churn in requirements and high uncertainty in the technology platform being used.”

And I continued:

“As a Certified Hybrid-Agile Master Professional (CHAMP), you will know both waterfall and Agile and you are going to combine them both. This way, you will get the best of both and apply them in real-world projects.”

Since then though the development world has moved fast, the fundamentals have remained the same. Fundamentals, like principles, never change. 

What I do I mean by these fundamentals? 

All organizations exist to create value for their stakeholders – employees, customers, users, shareholders, and others. Organizations can be profit-based, non-profit-based or run by governments. Irrespective of the nature and type of organization, everyone of the them is focussed on (business) value creation. 

The Rigidity of Waterfall 

Traditional waterfall models were designed long before – in the mid-last century. These follow techniques such as:

• Up-front planning, 
• Critical path method (was in the 1950s!), 
• Network diagramming, 
• Change control with Change Control Boards (CCBs),
• Strict documentation,
• Command and control management paradigm etc.

This mode of development is effective in various industries – specifically the regulatory-heavy ones. But these are not much applied where requirements – or the market itself – change rapidly. Agile comes in here. 

The Pitfalls of Agile

There are many Agile team-based approaches such as Scrum, Kanban as well as Scaled Agile approaches such as the CIPSA  framework. All of these are used around the world. Such approaches emphasize collaboration, iterative and/or incremental value delivery and high adaptability. 

But then large organizations or industries don’t always want to follow pure Agile. There are various constraints, which prohibits them to take a full-fledged adaptive route. 

Below are some scenarios, which I’ve come to know while interacting with Hybrid-Agile practitioners:

• Budget uncertainty: Agile budgeting is mostly just-in-time, though a high-level budget can be there for the releases. See here for Agile Release Planning. 
• Portfolio Governance: Portfolios stand at the highest-level of management in organization as it drives the organization’s strategic goals and objectives. See here.
• Industry itself: For example, construction industry, mining industry or film industry still follow the waterfall model, though some elements can be in adaptive mode. 

This brings in Hybrid-Agile.

The Rise of Hybrid-Agile Management with CHAMP

Pure predictive models (like traditional Waterfall) struggle to adapt quickly. Pure Agile models such as Scrum and Kanban excel at team-level delivery but often lack enterprise governance structure.

Purely predictive/waterfall models struggle to adapt quickly. Purely Adaptive models such as Scrum or Kanban excel at team-level delivery, but lacks the enterprise-level governance, its framework and enforcement. In addition, many roles in an organization can't be thrown away just because Agile has to come-in.

This, in turn, creates frictions:

• Top executives want forecasting, control and predictability.
• Teams want flexibility, autonomy as well as mastery.
• Regulators want documentation and in fact, many times very particular about it.
• Customers want rapid innovation and quick return on investment (ROI).

Hybrid-Agile Management emerged as the practical answer. However, until recently, there was no clear professional path dedicated to mastering it. All certifications in Hybrid-Agile management are theoretical in nature, which helps the least to understand. 

This is where CHAMP steps-in and rises to the occasion.

The Value and Importance of CHAMP

CHAMP (Certified Hybrid-Agile Master Professional) is a credential designed to equip professionals with the capability to design, lead, and manage hybrid-agile environments.

ManagementYogi’s CHAMP focuses on:

1. Integrating Agile delivery with Waterfall.
2. Designing and working with a large number of hybrid models.
3. Learning and applying various hybrid-agile management principles. Check out the principles here - Part 1 and Part 2.
4. Learning all possible ones – Hybrid-Scrum, Hybrid-Kanban, and Hybrid-ScrumBan. One example of Hybrid-Scrum is here.
5. Generating a large of reports for not only communication, but also compliance. 

Rather than positioning Agile and Traditional methods as opposites, ManagementYogi’s CHAMP teaches how to intentionally mix them as per your needs.

CHAMP is especially suited for:

• Large enterprises undergoing digital transformation, but struggling with pure Agile.
• Regulated industries where documentation is equally valued and some-times phase-based approach is mandated.
• Project/Program Management Offices (PMOs) seeking modernization or to shift into Hybrid mode.
• Organizations caught between Waterfall and Agile approaches as they need both.

Conclusion

As I wrote in the beginning – both Waterfall and Agile are here to stay. The CHAMP credential does not discard one and favors another, but integrates them as many industries require it. Below are some examples.

1 # A bank launching a digital platform must move fast, but also meet regulatory requirements.

2 # A healthcare provider must innovate, but document thoroughly. 

3 # A government program must adapt, but maintain audit trails.

4 # A fintech startup releasing a new mobile payment feature (I've worked in such project in the early last decade) must iterate rapidly, but also pass stringent audits.

5 # A telecom company rolling out a new service must respond quickly to customer demands, but also follow regulatory rollout plans.

As you’d have noticed in the all the above cases the former is Adaptive/Agile, whereas the latter is usually Predictive/Waterfall. And as noted earlier, there can be various other Hybrid-Agile models – not just Agile followed with Waterfall.

With CHAMP certification, you learn, nurture, and apply various models with real-world projects. Start learning today and have a deep understanding on Hybrid-Agile management. 

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

CHAMP Reviews and Success Stories:

• CHAMP Course: Excellent One for Mastering MS Project in both Traditional and Agile Environments
• CHAMP Success Story: A Niche Certification –Never Seen Anything Like this Before!
• CHAMP Success Story: One of the Best Hybrid-Agile Certification Courses I Ever Attended

ManagementYogi's CHAMP Certification Course:

• Certified Hybrid-Agile Master Professional (CHAMP)

Free CHAMP Questions:

• 20 CHAMP Free Questions with Answers (Part - 1)
• 20 CHAMP Free Questions with Answers (Part - 2)

Second Trailer: Certified Hybrid-Agile Master Professional (CHAMP) – World's Only Practical Hybrid-Agile Certification

Hybrid-Agile management is complex and demands solid understanding of both traditional and Agile concepts. The Certified Hybrid-Agile Master Professional (C.H.A.M.P or simply CHAMP) course demonstrates and uses real hybrid projects with hands-on software tool. 

Top 10 Reasons to Go for CHAMP Certification

The CHAMP certification course is dynamic, not static. It is continuously updated to reflect the latest trends and practices. [See here.]

Hybrid is everywhere in our daily lives. Consider these examples:

• When day meets night at dusk, it’s hybrid time.
• When night meets day at dawn, it’s hybrid time again.
• When a dancing wave embraces the shore, that zone is hybrid.
• When the shore blends into the land, we see hybrid once more. 

In the same way, Hybrid-Agile project management mirrors real life. It’s widely adopted across organizations, yet many people only learn the theory and struggle to apply it in practice.

That’s where CHAMP stands apart. Being hands-on and practical, it is radically different—yet as natural as the everyday hybrid moments.

The below trailer (1m: 21s) informs more. For the best experience, go full-screen HD mode and plug-in your headphones.

A brief tabular differentiation between CHAMP and other certifications is shown below. 

To know more about the CHAMP certification course, see here.

To have the complete course breakdown, check here.

For this course, many FAQs have been answered. See here. 

If you have any other questions or clarifications, please send an email to managementyogi@gmail.com.

CHAMP Reviews and Success Stories:

• CHAMP Course: Excellent One for Mastering MS Project in both Traditional and Agile Environments
• CHAMP Success Story: A Niche Certification –Never Seen Anything Like this Before!
• CHAMP Success Story: One of the Best Hybrid-Agile Certification Courses I Ever Attended

ManagementYogi's CHAMP Certification Course:

• Certified Hybrid-Agile Master Professional (CHAMP)

Free CHAMP Questions:

• 20 CHAMP Free Questions with Answers (Part - 1)
• 20 CHAMP Free Questions with Answers (Part - 2)

Tips for Hybrid-Agile Management:

• 5 Tips for Hybrid-Agile Management
• 5 More Tips for Hybrid-Agile Management

Primavera P6 Pro Live Lessons – Understanding and Applying Crashing and Fast Tracking

There are many ways to compress a schedule. You can add more resources, change the relationship among the activities or tasks, run activities in parallel, reduce the float in certain cases, among others. 

However, two schedule compression techniques are quite popular and they are:

1. Crashing
2. Fast Tracking

Crashing, by introducing more resources, increases cost. On the other hand, fast tracking, by ignoring relationships (dependencies), increases risks. Crashing can also increase risks. Fast tracking can increase cost as well! 

In Primavera P6, we can apply both these schedule compression techniques. In this post, we will learn how to use such techniques. If you are aspiring to be a Project Management Professional (PMP®), or Risk Management Professional (RMP®), you’ll quickly understand. Nevertheless, if you are not one, but aspiring to be one, then also you will understand. 

The content of this article is taken from the Primavera P6 Pro Live Lessons course – an exhaustive course covering various functionalities and capabilities Primavera P6 Professional with respect to project management. There, I've used and explained with live P6 projects.

Now, let’s briefly understand the background concepts of these two techniques.

Understanding Crashing

Crashing compresses the schedule by adding more resources. This technique used shortens the schedule duration for the least incremental cost. 

Examples: A real-time example is working overtime. Another real-time example is paying more to deliver faster.

As more resources are added, cost increases. Risk may also increase. Let us take an example. We've 3 activities: 

• Activity A1, A2 and A3 with one resource assigned. 
• The activities are sequential, i.e., A3 will follow A1 and A2 will follow A1.
• The duration for each activity is 2 days. 
• The total duration is 2 + 2 + 2 = 6 days

Next, we added one more resource for each activity to crash. So, now:

• Activity A1, A2 and A3 have two resources assigned. 
• The duration for each activity will be reduced to 1 day.
• The total duration is 1 + 1 + 1 = 3 days.

With crashing, we reduced the combined duration of three activities from 6 days to 3 days. This is a form of schedule compression. Isn't it?

Understanding Fast Tracking

Fast Tracking compresses the schedule by making the activities parallel instead of sequential. This can happen for a portion of the schedule. 

Examples: Preparing the test plan along with the approval of the Product Requirements documentation. Another real-time example is cooking two items together, but on two separate burners of your stove.

As activities are executed in parallel and original relationships are changed, risk increases. Cost may also increase due to rework. 

Let’s reuse our previous example. We've 3 activities:

• Activity A1, A2 and A3 with one resource assigned. 
• The activities are sequential, i.e., A3 will follow A1 (FS relationship) and A2 will follow A1 (FS relationship).
• FS stands for Finish to Start relationship.
• The duration for each activity is 2 days. 
• The total duration is 2 + 2 + 2 = 6 days

Next, we changed the relationships among the activities to Start to Start (SS) or Finish to Finish (FF) in order to fast track. So, now:

• The activities are parallel, i.e., A3 will start with A2 (FF relationship) and A2 will start with A1 (SS relationship).
• The duration for each activity remains as 2 days. 
• But the total duration is now 2 days as all activities are done in parallel.

In this case of fast tracking, we reduced the combined duration of three activities from 6 days to 2 days.

This is another form of schedule compression. 

Primavera P6 – Applying Crashing

Primavera P6 exactly follows our previous explanation of Crashing. Again, we will reuse our example for crashing.

As shown below, we have three activities – A1, A2 and A3, each with one resource. These are done in sequence. (click on the image to enlarge) 

The total duration as shown above is 6 days.

Next, we added more resources – one more resource for each activity. With it the total duration was reduced.  

The total duration now shown above is 2 days. Note that we have added two resources (Res1 and Res2) for each activity.

Hence, we can say with crashing we compressed the schedule. 

Primavera P6 – Applying Fast Tracking

Here too, Primavera P6 follows the previous explanation of Fast Tracking. We will reuse our example for crashing.

As shown below, we have three activities – A1, A2 and A3, each with one resource (Res1). These are done in sequence or have Finish to Start (FS) relationship.  

The total duration as shown above is 6 days with all in FS relationships.

Next, we changed the dependencies among the activities. With it, the total duration was reduced.  

The total duration now shown above is 2 days. Note that the relationships have changed among the activities. 

Hence, we can say that with fast tracking we can also compress the schedule. 

Demonstration and Explanation

The below video [duration: 5m, 15s] explains Crashing and Fast Tracking using Primavera P6. In the Primavera P6 Pro Live Lessons, we will use a live, real-time project to demonstrate both crashing and fast tracking. 

To have a better audio-visual experience, plug-in your earphones and go full-screen HD.

Key Points to Note

Now that you understood, learned and also learned how to apply Crashing and Fast Tracking, following are the key points to note. Detailed explanation with a number of key points is part of the Primavera P6 Pro Live Lessons course.

• Use crashing for critical activities. Only with the reduction in remaining duration of critical activities, the project schedule will be reduced.
• Ensure that the duration type, activity types are proper when you apply crashing for the activities. 
• Also ensure that the Calendars is properly applied to the activities during crashing and/or fast tracking. For example, you are fast tracking two activities, for the concerned resources are not available for the second activity!

It’s important to note that activity type, duration type and calendars etc. will be considered while going for schedule compression.

Finally, be judicious in applying the schedule compression techniques. Running activities in parallel does not mean resources will actually work in parallel on the ground. Understand the limitations.

Nevertheless, both Crashing and Fast Tracking are powerful techniques to be used. As we can learn with this article, they can be effectively applied with Primavera P6. To know, learn and apply like a pro, subscribe to the course of Primavera P6 Live Lessons. 

References

[1] * NEW * Course – Primavera P6 Pro Live Lessons, with Full Money-Back Guarantee, by ManagementYogi.com 

[2] Article: Primavera P6 - Understanding Various Activity Types, by Satya Narayan Dash

[3] Course: Practical PMP with Oracle Primavera P6, by Satya Narayan Dash

[4] Course: Practical RMP with Oracle Primavera Risk Analysis, by Satya Narayan Dash