MSP® Foundation and Practitioner

Certification Training
5458 Learners
View Course Now!

Transformational Flow Overview Tutorial

Welcome to the Transformational Flow tutorial offered by Simplilearn. The tutorial is part of the MSP® Foundation and Practitioner course. In the earlier lessons of MSP®, we have covered the concepts of program management principles and governance themes. In this lesson, we will discuss the third concept of MSP® framework, ‘the transformational flow.’

Let us start with the objectives of this lesson, in the next section.


By the end of this transformational flow lesson, you will be able to:

  • Describe the program life cycle.

  • Explain the course of governance in tranches.

  • Describe how to monitor and when to close the program.

  • List the documents and information baselines maintained during the program lifecycle.

Let us now review the transformational flow in MSP® framework in the next section.

MSP® Framework

In the image shown above, transformational flow is the innermost circle of the MSP framework. The different processes in transformational flow are as follows:

  • Identifying a program

  • Defining a program

  • Managing the tranches

  • Delivering the capability

  • Realising the benefits and

  • Closing the program

Let us take a quick overview of the transformational flow in the next section.

Program Life Cycle Introduction

Programs normally start as an idea to achieve a strategic goal or transformational change. A program mandate is a key to start the life cycle of a program. Typically, the mandate includes high-level strategic objectives of the program, relevant policies and outline vision which can be further developed as a program brief.

All programs are not strategy-driven since inception. Most of the programs are born due to demands of strategy and are aimed to deliver a transformational change. However, in some cases, a program emerges partway through the projects.

Emergent programs take shape under the following circumstances:

Case 1:

Sometimes, organizations realize that the attempted change is bigger and more complex and it cannot be handled as a project. It is then decided to be converted into a program for a better chance of success.

Case 2:

The other scenario where a program emerges is when there are several projects in an organization and all of them are trying to achieve similar changes. This leads to conflicts.

The programme lifecycle is explained in the image given here:


The programs developed in the scenarios discussed above are called emergent programs. In these cases, the mandate is not enough. Here, achievement of projects and the need to continue or stop a project should be considered.

Once the mandate is received, the next stage is ‘identifying a program’.

Identifying a Program

In this stage, program mandate is confirmed and program brief is created. Preparations are made for the next stage and program preparation plan is made.

Program Brief

The program brief, once approved by the Senior Responsible Owner or SRO and the Sponsoring Group, is one of the major inputs to ‘defining a program’.

Defining a Program

In this stage, all the governance and boundary controls like the business case, blueprints, various strategies and plans are created and reviewed.

In this stage, tranches are identified and schedules are prepared. All these go as an input to managing the tranches.

Managing the Tranches

Within ‘managing the tranches,' capabilities are delivered and benefits are realized iteratively. Program management strategies, prepared in ‘defining a program’ are established in ‘managing the tranches’ by implementing associated plans.

Delivering the capability and Realising the Benefits

The program definition, governance framework and plans are the basis of ‘delivering the capability’ and ‘realising the benefits’.

After each tranche, formal approval to proceed to the next tranche is required.

Closing a Program

Once all capabilities have been delivered, the decision is taken to close the program and lessons learned are recorded for future programs.

In the next section, we will discuss the evolution of program brief.

 MSP Foundation and Practitioner caught your attention? Watch this course preview NOW!

Program Brief

The program brief in MSP is a key input for defining a program. The features of program brief are as follows-

Key input

The information that is a part of the program brief will further provide the basis to prepare the program outcomes and benefits, plans and schedules for tranches and control framework to manage and monitor the program.

Formal Approval

This document needs to be formally approved by the SRO and the Sponsoring Group before it is passed to defining the program.

Defining a Program

The approved program brief is used in defining the program.

All this information can be summarized in the program definition document and can be shared for a quick review with executives.

The next section deals with governance and tranches.

Governance and Tranches

Governance arrangements refer to the plans, boundary documents like vision, business case and different strategies. The course of governance in tranches is shown here:

Create Governance Arrangements

Early governance arrangements are created in the ‘identifying a program’ process as a part of program preparation plan. This is done to manage and control the work in ‘defining a program’ process.

The governance arrangements are developed further in ‘defining a program’ process for ‘managing the tranches’.

Implement Governance Arrangements

Program management strategies created in ‘defining a program’ are implemented in ‘managing the tranches’.

Review Effectiveness of Governance

At the end of each tranche, the effectiveness of governance arrangements is reviewed and refined as part of the preparation for the next tranche.

The result of the review helps in understanding the course of the program towards success. This works as an assurance review point and gives the confidence to involve stakeholders regarding the program.

Deliver New Capability and Outcomes

A tranche formally comes to an end when new capability has been delivered, the transition is completed and outcomes have been achieved. End tranche review will confirm if the program is still valid before moving onto the next tranche with the approval from the Sponsoring Group.

Now, let us review monitoring the program in the next section.

Monitoring the Program

Throughout the program, the progress of the program needs to be monitored. Also, the external environment has to be monitored for opportunities and threats.

This helps in assessing crucial questions such as-

  • Whether the program is on track

  • If the benefits are achievable.

  • It is necessary to ascertain at frequent intervals that the chosen business case is valid and relevant to the program.

  • Answers to these queries help in realizing what changes are needed or if any change is required to realign the program according to the organization’s strategic objectives.

The program may lose its focus due to a change in organizational strategy and policies and needs to change its course to remain meaningful. The next step is to close the program.

Let us focus on ‘closing the program’ in the next screen.

Closing the Program

A program can be closed if -

  • The blueprint has been delivered; and

  • All the capabilities required to achieve the vision statement have been implemented and benefits have been realized.

Once the program is closed, steps to be taken are:

  • It needs to be decided whether the program was successful.

  • There needs to be confident while closing the program that the realized benefits will sustain, even if there is no program support. In these cases, there might be a need to make some supporting arrangements.

  • The supporting arrangements may include continuation of new communication arrangements created during the program.

We will discuss these in the further lessons. A plan for further review after the closure of the program might be needed. The review plan helps to assess and measure the continuing realization of benefits.

In the next section, we will discuss the reasons why programs can be closed.

Reasons for Closing the Program

Programs can be closed as per plan or due to some external or internal changes which force a premature closure. The reasons for closing a program are as follows:

Planned Closure

Planned closure is a scenario in which all the planned work has been successfully completed.

External Environment Change

There may be a scenario where the external environment changes like legislation or government policy, which may render a program invalid and thus lead to its premature closure.

Change in Organization Strategy

If the organization changes the strategy midway through a program, it may also lead to a program facing premature closure. Please note that strategy change may not be due to external environmental changes.

Invalid Business Case

A program can be closed, if it is realized that the planned business case is no longer justified and it does not make a good business sense. This scenario can be a result of multiple internal or external factors.

80/20 Rule

According to 80/20 rule, the cost of the remainder of the program is compared with additional benefits. If it is realized that the program does not make good business sense, it will be closed with what it has achieved till the date of closure.

Availability of Alternative Means

A program can also be closed when cost-effective alternative means to deliver the same outcomes are available.

In the next section, we will see how documents are managed in the transformational flow.

Document Management over Program Life Cycle

Many documents across information baselines are maintained during a program life cycle. They are described below-

Identifying a Program

In ‘identifying a program,' the documents that are created are program brief and program preparation plan.

The program mandate is reviewed and updated. The program mandate is the trigger for the program and so it is created before the program starts.

Defining a Program

In ‘defining a program,' all the governance, boundary and management documents are created, except the documents created in ‘identifying the program’ process. Program preparation plan is implemented in this process.

Some of the examples are vision statement, program plan, blueprint, business case and all relevant strategies and plans.

Managing the Tranches

At the beginning of ‘managing the tranches,' all strategies are implemented. For example, benefits management strategy, benefits map, quality and assurance strategy, and plan, stakeholder management strategy, etc.

The documents that are reviewed and updated during the process are issue and risk register, project dossier and stakeholder profile.

During the end of ‘managing the tranches,' all relevant strategies, plans, and boundary documents are reviewed and updated with exception of program brief, program mandate, program preparation plan and vision statement.

These documents have already served their purpose during the initial phases of the program.

Delivering the Capability

During ‘delivering the capability,' the focus is on implementing the program communications plan and projects dossier.

This process also continues updating issue and risk register and stakeholder profiles.

Realizing the Benefits

During ‘realizing the benefits,' the focus remains on benefits, risks and issues and communications.

So all baselines like benefit profiles benefit realization plan and program communication plan are implemented.

Closing the Program

During the program closure, all relevant documents with exception of program brief, program mandate, program preparation plan and vision statement are reviewed and updated.

Note that these baselines are divided into boundary baselines, governance baselines, and management baselines. Boundary baselines comprise benefits profile, benefits map, blueprint, business case, program brief, projects dossier and vision statement.

Governance baselines are composed of all strategies like benefit management strategy, information management strategy, organization structure and others.

Management baselines include all ‘plan’ documents like quality and assurance plan, benefits realization plan, and others. Issue and risk registers are also management baselines.

The table on the shown below, provides the list of documents and information baselines maintained during a program life cycle.


Let us summarize what we have learned in this transformational flow lesson:

  • Programs normally start as an idea and progress through various stages namely, ‘identifying a program,' ‘defining a program,' ‘managing the tranches,' ‘monitoring the program’ and closure.

  • Governance arrangements are created and developed during the ‘identifying a program’ and ‘defining a program’ stages.

  • The progress of the program, as well as the external environments, need to be monitored for opportunities and threats.

  • A program can be closed if the blueprint has been delivered and the capabilities required to achieve the vision have been implemented to realize the planned benefits.

  • The governance, boundary and management documents are created during the identifying and defining processes of the program.


With this, we come to an end of the chapter Transformational flow. In the next chapter will discuss on Program Organization.


  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

Request more information

For individuals
For business
Phone Number*
Your Message (Optional)
We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Work Email*
Phone Number*
Job Title*