Develop Vision Statement, Program Blueprint, and more excitement!
Create Vision Statement
The high level vision statement in the Program Brief is refined to become the program’s Vision Statement. It provides the basis for communicating and encouraging buy-in and commitment from stakeholders. Its purpose is to communicate the transformed, beneficial future state to the program’s wide audience of stakeholders. There will be times when it is appropriate to engage key stakeholders in refining the vision (e.g. if they have a significant stake in the outcomes). Refining the Vision Statement is often included as an action in the Define the Program workshop.
When a program undertakes transformational change its stakeholders may not align to the program’s vision. The Vision Statement assists in aligning stakeholders and is used to communicate the end goal of the program by being written in a way that describes the desired future state.
Key characteristics of a good Vision Statement include:
• Focussed on the future state
• Easily understood
• Compelling and motivational
• Short and memorable
• Avoids target dates
The SRO is responsible for the Program’s Vision Statement. Overlooking this task could cause the following challenges:
• The program lacks a clear vision that is understood by all program team members
• The vision may not be accurate for the program or may be misunderstood by stakeholders
Exit Criteria
The following criteria should be met before completing this activity:
• The Program Vision Statement is reviewed, agreed and communicated to stakeholders.
Activities to be completed
During this step, the SRO should:
• Review the Program Vision with the Program Organisation and Business Change Owner
• Produce a refined program Vision Statement
• Where appropriate involve stakeholders in the review of the Vision Statement
• Communicate the agreed Program Vision Statement to all stakeholders
Inputs
Outputs
Roles
• SRO
Develop Blueprint, Define Benefits and Plan the Program (and Partnering)
The Blueprint, Benefits Plan (in Business Case) and the Program Plan are all designed in parallel; together they will provide the key information required for a compelling business case. The outputs require close integration to ensure the benefits to be realised are driving the desired transformation.
Blueprint
The Blueprint defines the current state, desired future state of the organisation and the gap between the two. It describes these states in regards to four key areas: process, organisation, technology and information.
Developing the Blueprint may encompass analysis of all the dimensions of the organisation – its cultural aspects, its structure, processes and activities – and how they need to change. Business analysis and design techniques will be required to fully explore the opportunities and options for achieving the capabilities and changes described in the Vision Statement. All options must be considered in order to achieve the best outcome (all options considered will be documented in the Business Case). The Blueprint incorporates the associated costs and change impacts of each option.
The gap, the difference between the current and future states, will need to be analysed to understand the options for change to achieve the future state. This provides the critical input into designing the projects required to deliver the program (Project Dossier section of the Program Plan) and ultimately the Program Plan. The Blueprint does not normally need to be expressed in detail. It will be the responsibility of each of the projects to develop more detailed designs for the future state. The program must own the integration and cohesiveness of the project-level designs, assuring the Blueprint.
The Blueprint’s future state will drive and validate the work required to identify the program benefits (including dis-benefits).
The typical content in a Program Blueprint includes the following information for each of the current state, intermediate future states (providing a Blueprint for each tranche) and final future state:
• Processes and business models, operational costs and performance levels
• Organisational structure, staffing levels, roles and skill requirements
• Technology, IT systems, tools, equipment, buildings and accommodation
• Information and data requirements
Benefits
The Program Brief identifies the high level benefits to be realised from the program, this document together with the identified future state in the Blueprint provide the key inputs to identifying all of the program benefits.
The key steps in the Define Benefits process include:
Establish a Benefits Management Strategy
The Benefits Management Strategy defines the program’s benefit measurement methods and processes, roles and responsibilities for benefits planning and realisation, priorities of the benefit types, tools/systems used to enable measurement, the review and assessment process for measuring benefits realisation. The Benefits Management Strategy must be created in line with the organisation’s existing Benefits Management Framework.
Identify and map benefits
Using the process identified in the Benefits Management Strategy, the benefits are identified and mapped (for more information on how to produce a benefits map, refer to the organisations Benefits Management Framework).
Each benefit (and dis-benefit) requires a complete definition, known as a Benefit Profile. These should be created at this stage for all expected benefits. Benefit Profiles are like product descriptions for benefits and should include: costs of achieving the benefit, the change required to realise the benefit, dependencies, related risks or issues, benefit owner, benefit recipient, measurement, how the benefit measure will be tracked.
Plan benefits realisation
The Benefits Plan (in Business Case) compiles all of the Benefit Profile information into one document, providing a total view of all benefits to be realised.
In order to measure the improvements resulting from benefits realisation, the current state or baseline must be measured and recorded in the profile. Without this there will be no way of assessing whether the future state measurements indicate an improvement.
When setting benefit targets it is advisable to look at historic averages and seasonal trends to forecast expected performance averages over the life of the program.
Each benefit should represent some aspect of the program’s desired outcomes. The first validation of the benefits is via the test of the emerging Business Case.
Program Planning
The projects and activities required to deliver the capability defined in the Blueprint need to be identified along with high-level project and activity information and estimates. These projects and activities form what is known as the Projects Dossier.
Typical content of a Projects Dossier includes:
• The list of projects that will be required to deliver the Blueprint
• Outline information on outputs, timeframes, resource and dependencies with other projects and activities
• How each project contributes to the program outcomes and benefits
• Cross reference to Benefits Map / Profiles.
The program’s projects are organised into logical groupings referred to as tranches. Tranches are designed to deliver step change in order to minimise impact to the organisation and reduce the likelihood of unmanaged multiple changes in any one business area. The projects and activities in the Projects Dossier are scheduled together showing the tranches and their relative timescales and dependencies. Note that for every tranche identified an associated Blueprint will need to be created to show the step changes occurring.
The Projects Dossier and tranches, along with information on resources, timescales, risks, dependencies, monitoring and control are used to form the Program Plan. A high level program schedule showing the estimated relative timescales for the projects is developed at this stage.
It may not be possible to define all of the required projects fully at this point. Further analysis may be required to complete the scoping of later projects after the results from early tranches have been assessed. Early tranches may be designed to explore and prove (or disprove) different approaches to achieve the Vision.
Partnering
Delivery of the program or projects within the program may require a formal partnering with one or more other organisations or entities. If partnering is an option, the organisations Partnering Framework needs to be applied.
Questions associated with ‘Assess the Partnership’ must be completed and if a partnering approach is planned or still possible, appropriate partnering steps should be built into the plan. Refer to the Partnering Framework for detail and required outputs.
Overlooking this task could cause the following challenges:
• Requirements and scope of the future state not correctly defined
• Focussing on wrong or unattainable benefits
• Gap between the current and future state gaps not fully understood leading to a flawed Program Plan
• Incorrect benefits identified or benefits not identified at all
• Benefit measurement and monitoring processes not defined
• No clear baseline measurements against which to measure improvement
• Program delivery is not planned
• Project dependencies not identified
• No clarity for program timings and expected project and tranche delivery dates
• Logical step change for implementation is not employed impacting on business operations.
• Partnering activities not completed as required
Exit Criteria
The following criteria should be met before completing this activity:
- Blueprint produced
- Current and future states defined and gaps identified
- Options assessed for change
- Benefits Management Strategy produced
- Benefits Plan produced (in Business Case), including
- Benefits profiles (Benefit Maps optional)
- Program Plan produced, including
- Projects Dossier
- Tranches definitions
- Partnering activities completed as required.
Activities to be completed
During this step, the Program Manager should:
• Ensure the current and future states are defined along with the gap between the two
• Ensure options are assessed for the required change
• Document findings and recommended option in the Blueprint document
• Produce the Benefits Management Strategy
• Produce the Benefits Plan (in Business Case)
• Design the Projects Dossier (part of Program Plan)
• Identify the tranches (part of Program Plan)
• Develop the Program Plan.
• Conduct any Partnering activities required by the organisation’s Partnering Framework.
During this step, the Business Change Owner should:
• Produce Benefits Map (part of Benefits Plan, optional)
• Produce Benefit Profiles (part of Benefits Plan)
Inputs
• Program Brief
• Vision Statement
• Organisation Strategy
• Enterprise Architecture Model
• High level project activity information and estimates
Outputs
- Program Blueprint
- Benefits Management Strategy
- Benefits Plan (in Business Case), including
- Benefit Profiles
- Benefits Map (optional)
- Program Plan, including
- Projects Dossier
- Defined Tranches
- Outputs required by the Partnering Framework (as appropriate)
Roles
• Program Manager
• Business Change Owner
