GRIP for Programmes Release 1 (DRAFT) April Network Rail GRIP for Programmes Page 1 of 104

Size: px
Start display at page:

Download "GRIP for Programmes Release 1 (DRAFT) April Network Rail GRIP for Programmes Page 1 of 104"

Transcription

1 GRIP for Programmes Release 1 (DRAFT) April 2015 Network Rail GRIP for Programmes Page 1 of 104

2 Network Rail GRIP for Programmes Page 2 of 104

3 Forward Purpose This document provides an overview and guidance for the management of programmes at Network Rail. It is hoped that this document will serve to support our understanding of programmes, the potential benefits of managing programmes through the entire lifecycle, and promote further discussion and development of Network Rails programme management capability. What The approach to Programme Management in this document is based on work completed by London Councils EPPM Programme on delivering a simpler and more intuitive approach to Managing Successful Programmes. Why Network Rail delivers in excess 2.5bn on infrastructure projects into use on the operational railway every year. A recent independent report by Nichols on behalf of Network Rail and the ORR recognises our excellence in project management however also notes that we do not have a consistent approach to programme management and provide no tools in the form of guidance or governance. Network Rail is currently assessing the maturity of its project and programme capability using the P3M3 maturity model developed by the OGC. The programme assessment when published will highlight many good aspects that all those involved in programme delivery should be proud of but will also show that due to the lack of a corporate framework and appropriate programme governance (organisational) structure we have only a very limited understanding of the benefits we intend to realise through delivery and the impact changes in projects have on delivering against the regulated performance and capacity targets we commit them to. The programme management lifecycle introduced here will support a more collaborative approach across Network Rail to delivering the benefits identified in our Market Studies and RUSs, delivered by our projects and programmes, and committed to the ORR through the final determination to be realised by the operational Routes. Network Rail GRIP for Programmes Page 3 of 104

4 Network Rail GRIP for Programmes Page 4 of 104

5 Introduction The GRIP for Programmes Lifecycle In developing GRIP for Programmes, attention has been paid to critical areas of programme activity that are essential for successful delivery of the programme. Guidance and templates has been provided for all programme phases. The diagram below illustrates each phase within GRIP for Programmes and the key documents that should be completed. The guidance provides the structure for answering key questions that are critical to the successful identification, definition, delivery and closure of programmes. The Programme Management Lifecycle is split into 4 stages, as specified in Figure 1. The aims and main outputs of the 4 stages are specified in Table 1. Identify Options Define Deliver Tranches Close Figure 1 Stage Aim Main Output(s) Identify Options Define Deliver Tranches Close Table1 Look at the programme from a high level, consider strategic fit, vision, costs, duration, risks and prepare for the future Explore the options for delivering the required outcomes and benefits together with robust and detailed planning for delivery Implement the governance strategies to ensure capability is delivered and aligned to organizational objectives manage the projects. Each programme will have one or more delivery tranches Confirm ongoing support is in place disband resources and infrastructure so that the programme does not drift into normal operations Programme Mandate Programme Brief Definition Plan Blueprint Programme Plan Manage and deliver the Programme Programme Closure Review Network Rail GRIP for Programmes Page 5 of 104

6 Identify Options Define Deliver Tranches Close Develop Programme Mandate Identify, Map, and Profile Benefits Develop Blueprint Develop Programme Brief and Plan for Define Phase Develop Prog. Benefits Realisation Plan Write Definition Report Define Programme Org. Structure Manage the Programme Using : Resources Finances Change Control Information Quality Risks & Issues Reporting Transition to new ways of working based on : Stakeholders Benefits Blueprint Business Case Make arrangements for benefits realization beyond programme closure Programme Review and Closure Define Programme Man. Activities Develop Stakeholder Map & Engagement Plan Network Rail GRIP for Programmes Page 6 of 104

7 Stage 1 : Identify Options Purpose The Identify Options Stage provides an opportunity to consider the programme at a high level. It considers the strategic fit, vision, costs, duration, risks, and culminates in a high level business case for the programme. Completion of the Programme Mandate and Programme Brief support the exploration and presentation of these themes. The Programme Mandate guidance and Programme Brief guidance set out the content of these documents. A further document, the Definition Plan, sets out the work, costs and resources needed to fully define the programme if it proceeds. The Definition Plan guidance explains how to create the Definition Plan. All three documents help the Client to decide (before commissioning a more expensive endeavour) if there is sufficient benefit in the programme to merit a full Definition Phase, including the creation of a detailed business case. Products Product Programme Mandate Questions being answered What is the potential programme? Is the programme aligned to strategic objectives? Should resources be allocated to further explore its potential? Programme Brief Definition Plan What is the programme vision? What are the expected benefits? What are the estimated costs? What are the risks and issues? Does the programme merit a full Definition Stage? What are the costs, timescales, and resource requirements to produce a detailed plan and design for all aspect of the programme? Network Rail GRIP for Programmes Page 7 of 104

8 Stage 2 : Define Purpose The Define Stage is a combination of exploring options for the delivery of the required outcomes and benefits with detailed planning for delivery. The stage completes with the publication of a Definition Report to the Client which sets out the recommended option and supporting business case. Documentation created, and updated, during the Define Stage provides the necessary evidence to answer vital questions that should be considered by the Client before the programme progresses to the next stage. Products Product Benefits Map and Benefits Profiles Questions being answered Is there an adequate understanding of the benefits? Do the benefits align to the Clients strategic objectives? Have benefits reviews been considered for key stages of delivery? Blueprint Is there a clear description of the Future State in accordance with the vision, outcomes, and benefits? Is there an understanding of the extent and nature of the change required? Is there enough information to enable identification of the projects and activities required to create the Future State? Programme Plan Is there a complete list with timescales and costs of projects and activities needed to fulfil the Blueprint? Is there a complete list of programme-level activities, including benefits realisation, risk management, stakeholder engagement, programme planning, monitoring and control and have these been defined? Has a plan been created that is robust and realistic and allows for the tracking of outputs, outcomes and benefits? Are all the step changes that are defined in the Blueprint clearly visible in the Programme Plan? Change Control Is there a process for managing and authorising changes that impact the programme? Network Rail GRIP for Programmes Page 8 of 104

9 Risk Log Is there a good understanding of the programme risks? How will programme risks be documented and mitigated? How will risk be actively managed? Issues Log Is there a process for managing and escalating programme issues? Programme Organisation Stakeholder Engagement and Communications Definition Report Has the organisation structure required to run the programme been identified? Have stakeholders been identified and analysed? Have plans for engaging and communicating with stakeholders been made? Network Rail GRIP for Programmes Page 9 of 104

10 Stage 3 : Deliver Tranches Purpose For the programme to be successful, clear and robust management and delivery activities are essential. GRIP for Programmes sets out the core activities for ensuring progress and control of the programme according to the programme plan. Management Control Activities Resource Management Engineering Management Financial Management Change Control Information and Document Management Quality management Risk and Issues Management Progress Reporting Delivery Activities Blueprint Management Benefits Management Stakeholder Engagement and Communications Business Case Management Transition Management Network Rail GRIP for Programmes Page 10 of 104

11 Stage 4 : Close Purpose Formal recognition of completion with associated activities. Programme Closure guidance sets out how to answer the following key questions to ensure a proper closedown of the programme. Products Product Programme Closure Review Questions being answered Has a review of the programme taken place? Have the Lessons Learned been captured and is there an understanding of how the lessons will be shared? Have outstanding issues and activities been captured and responsibility for who will take them forward been assigned? Have benefits which have yet to be realised been assigned to an appropriate organisation to ensure they are realised? Is there a process in place for tracking benefits delivery after the programme has closed? Has authority been given to close the programme? Network Rail GRIP for Programmes Page 11 of 104

12 Network Rail GRIP for Programmes Page 12 of 104

13 Guidance Programme Mandate (Guidance) This guidance explains how to create a Programme Mandate. The purpose of the Programme Mandate is to enable the Sponsoring Group to decide whether to allocate resources to fully explore the potential for a programme in this area. This guidance is accompanied by a template for creating a Programme Mandate. Identify Options Define Deliver Tranches Close Develop Programme Mandate Identify, Map, and Profile Benefits Develop Blueprint Develop Programme Brief and Plan for Define Phase Develop Prog. Benefits Realisation Plan Write Definition Report Define Programme Org. Structure Manage the Programme Using : Resources Finances Change Control Information Quality Risks & Issues Reporting Transition to new ways of working based on : Stakeholders Benefits Blueprint Business Case Make arrangements for benefits realization beyond programme closure Programme Review and Closure Define Programme Man. Activities Develop Stakeholder Map & Engagement Plan Network Rail GRIP for Programmes Page 13 of 104

14 Introduction Creating a formal Programme Mandate document is an important discipline as it sets out the purpose of the proposed programme and the proposed improvements that are expected as a result. The Programme Mandate could stem from Network Strategy & Planning, the Routes, or the DfT. Therefore, much of the information needed for the Programme Mandate document will be pulled together from already existing documents and reports e.g. Strategic Business Plan, Market Studies (previously Route Utilisation Strategies), or HLOS. In most cases a Programme Mandate is requested and will be reviewed by the business units Management Team or a member of it. If, after the Programme Mandate has been reviewed, further work on the programme is commissioned, the same Management Team will typically act as the programme s Sponsoring Group until an organisation structure for the programme has been set up. The Programme Mandate s primary purpose is to act as an instruction to do an initial investigation of the value of the programme and to plan more detailed work to establish why and how the programme should be run. Content Business Need The first part of the Programme Mandate sets out why the proposed programme is needed. The business drivers for the programme need to be identified. The following questions will help you to determine what the business drivers might be: Is it a legislative requirement? Is it a government department requirement (DfT, TS)? How does it fit with the Network Rails priorities and strategic plans Is there a specific business or operational need or a problem that needs to be resolved how does the current service fall short? What evidence is there that this proposed programme is needed? o Market Studies? What are the risks to the business if we don t do this? Outcomes The Programme Mandate should briefly articulate the outcomes that the programme is expected to achieve, how they contribute to the organisation s strategic objectives, and how they fit with other initiatives. Next Steps to Complete the Identification Stage If the Programme Mandate is accepted by the Sponsoring Group/Client and further work is commissioned, the next step in the Identification Stage will be to complete a Programme Brief, which outlines the vision, costs and benefits of the programme. Along with the Programme Brief, a plan of what needs to be done to completely define the Programme (Definition Plan) needs to be written. Therefore the last section of the Programme Mandate details the activities, time and resources required to complete the Programme Brief and the Definition Plan. Sign Off The Programme Mandate needs to be signed off by the Sponsoring Group/Client who will commit the resources to develop the Programme Brief and Definition Plan. Network Rail GRIP for Programmes Page 14 of 104

15 Programme Mandate Checklist Does the Programme Mandate satisfactorily answer the following questions? Programme Mandate Key Question Section Sub Questions Should resources be allocated to fully explore the potential for the proposed programme? Business Need Strategic Fit Outcomes Next Steps Sign-Off Why is the programme needed? How will the programme contribute to the strategic objectives and fit with other initiatives? Have the business changes expected as a result of this programme been defined? What activities, time and resources are required to complete a Programme Brief and Definition Plan and what will it cost? Does the Sponsoring Group agree to the next steps? Network Rail GRIP for Programmes Page 15 of 104

16 Network Rail GRIP for Programmes Page 16 of 104

17 Programme Brief (Guidance) This section explains how to create a Programme Brief. The Programme Brief enables the Sponsoring Group to decide whether to commission the detailed planning and design work to fully define the programme. It presents the high level business case for the programme and addresses the key question: How much potential is there for a programme in this area? This guidance is accompanied by a template for creating a Programme Brief. Identify Options Define Deliver Tranches Close Develop Programme Mandate Identify, Map, and Profile Benefits Develop Blueprint Develop Programme Brief and Plan for Define Phase Develop Prog. Benefits Realisation Plan Write Definition Report Define Programme Org. Structure Manage the Programme Using : Resources Finances Change Control Information Quality Risks & Issues Reporting Transition to new ways of working based on : Stakeholders Benefits Blueprint Business Case Make arrangements for benefits realization beyond programme closure Programme Review and Closure Define Programme Man. Activities Develop Stakeholder Map & Engagement Plan Network Rail GRIP for Programmes Page 17 of 104

18 Introduction The Programme Brief is a key document to complete. It is a high-level business case which follows and expands on the Programme Mandate and includes the following information: Vision Benefits Risks and Issues On the understanding that the content of the Programme Brief may be subject to change during the Definition Phase, enough information is provided for the Sponsoring Group to: understand the potential scale and impact of the programme assess the priority of the programme against strategic objectives, other programmes and activities currently being undertaken and available resources make an informed decision on whether to proceed The Programme Brief will be presented to the Sponsoring Group together with the Definition Plan which sets how the full definition of the Programme will be undertaken. Content Programme Vision The Programme Brief provides an opportunity to begin to think about the programme vision. The vision describes a compelling picture of the future that the programme will enable. It describes the new and/or improved services or capability and how they will look and feel and be experienced in the future. The vision is the basis for engaging with and gaining commitment from stakeholders. This guidance suggests two methods for expressing the vision: A Postcard from the Future : This is useful for communicating the vision quickly and powerfully such as in brief conversations, or as a summary in documents A Letter from the Future : This provides enough detail to enable further definition of the programme, as well as being a communication tool for creating a deeper understanding of what the future will be like Both are concise, the letter being an elaboration of the postcard. Benefits and Dis-Benefits The Programme Brief should describe both the benefits and dis-benefits associated with the programme. Benefits are measurable improvements resulting from a programme which are seen by a stakeholder to be positive and worthwhile. For example, increasing Performance or Capacity on a Route. Dis-benefits are the outcomes from a programme which are perceived as negative by one or more stakeholders, e.g. new operational costs, or loss of green space in an area due to the building of a new station. The same change can be seen by different stakeholders as both a benefit (net cost reduction through fewer staff) and a dis-benefit (job losses). These dis-benefits can be classified, managed and measured in the same way as benefits. Dis-benefits can be confused with risks, whereas risks may be avoided dis-benefits will definitely be created by the programme and the task is to manage their impact. It is important to understand which stakeholder will lose out so that this can be managed. Network Rail GRIP for Programmes Page 18 of 104

19 Types of Benefits Benefits can be classified in a number of ways. A distinction can be made between financial benefits, which are measured in monetary terms, and non-financial benefits that cannot be directly measured in monetary terms. Financial benefits are further categorised as cashable, those that give rise to immediate bankable returns, e.g. capital receipts from the disposal of assets, or non-cashable, e.g. an efficiency gain leading to less time to complete a required task but this cannot be converted into a reduction in staffing or cost. Non-financial benefits include improvements across services and corporate functions (e.g. HR, GBS) that can be measured using KPIs and the results of customer surveys. Identification of benefits To help ensure a thorough identification of the benefits refer to existing documents (e.g. the Programme Mandate and the vision) and engage colleagues with knowledge of the programme area to brainstorm potential benefits or carry out a Benefits Identification and Mapping exercise. Wording the benefits It is important to state the benefits in terms of how the organisation will be able to do new or better things. This means that the wording in these statements should express the improvements in terms of: Effectiveness: higher quality of service, e.g. fewer errors, increased customer satisfaction, etc. Efficiency: lower cost, less resource, less waste, more efficient teams, quicker turnaround of work, etc. Baselines and Values The current or baseline value, together with the target value to be achieved, should be stated for all benefits. In some cases, for example, with a new benefit, or one that is hard to quantify, there may not be an easily identifiable current value, or target value. In these cases, it is still important to list the benefit. For example, improved innovation, is an important benefit but may not be easy to measure. Programme Activity & Projects The Programme Brief should describe as far as is possible at this stage, what activities and projects are needed to deliver the programme outcomes, what they will cost and how long it will take to complete the work. Programme activities are pieces of work needed to set up and effectively manage the programme. They include : programme planning programme engineering management stakeholder engagement and communication benefits management programme level risks and issues management programme financial management programme reporting The lead person and team responsible for each activity should be included if known at this point. Network Rail GRIP for Programmes Page 19 of 104

20 Quick Wins The Programme Brief should describe what business or operational activities should start, be done differently or cease, in order to achieve quick wins. The identification of early outcomes and benefits will demonstrate the viability of the programme to all stakeholders. It is therefore worth considering which activities could deliver an immediate benefit in the context of the programme. Key Risks & Issues Risks are things that may happen and could throw the programme off track. Issues are things that have happened or are current situations that are a cause for concern. In both cases, they are things that could undermine the achievement of the programme outcomes and the realisation of benefits. The key risks and issues are included in the Programme Brief because it is important to think about them in the early stages of the Programme. A decision by the Sponsoring Group to proceed to the Definition Phase should not be made without an evaluation of the key risks and issues as they are understood at this point in the programme. When identifying risks and issues, your business unit approach to risk and issue management should be used. Financial Information The financial information should include: an estimate of the overall costs involved and how they will be spread over the duration of the programme any funding sources identified any new management or operational support costs required to sustain the way the organisation will operate once the programme has finished, e.g. the costs of additional staff, new systems and services required. the split between capital and revenue income and expenditure Costs that are often overlooked include programme management, legal services, procurement services and communications. So think widely about all potential cost implications. The projections made and how they are distributed over the life of the programme may also be subject to accounting rules (e.g. discounted cash flow). Your business unit Financial Director will need to be involved in determining the best approach and confirming the accuracy of the information being provided. Constraints The Programme Brief should list and explain any known constraints that apply to the programme. The following should be considered: Legal or regulatory constraints to the organisation Commercial constraints Operational constraints Technology constraints Timing constraints Network Rail GRIP for Programmes Page 20 of 104

21 Assumptions The Programme Brief should describe any assumptions that were made to quantify or justify the benefits and costs of the programme, and which underpin the justification for the programme. The validation of assumptions will need to be included in the appropriate project or programme activity when the Programme Plan is developed. If an assumption can t later be validated or fails validation, it becomes an issue. Programme Capability It is a good idea to describe how the organisation will provide the necessary programme management resources and capability required to carry out the proposed programme successfully. Think about and list the key roles in the programme and skills required. This may include the need for: a Sponsor (if not already in place) a Programme Manager (if not already in place) Business Change Managers support from other business areas e.g. GBS; Legal; Finance; a Programme Board a Programme Team Project Managers If there are capability and capacity gaps these should be noted. Sign Off The Programme Brief should be signed off by the Sponsoring Group or a representative of the Sponsoring Group to confirm its acceptance. Network Rail GRIP for Programmes Page 21 of 104

22 Programme Brief Checklist Before signing-off the Programme Brief, the Sponsoring Group or its representative should confirm that it satisfactorily answers the following questions: Programme Brief Key Question Section Sub Question The Programme Vision What is the compelling picture of the future that the programme will enable? How much potential is there for a programme in this area? Benefits Programme Activity and Projects Quick Wins Key Risks and Issues Financial Information Constraints Assumptions Programme Capability Sign-Off What are the measurable improvements that the programme will achieve? What needs to be done to deliver the programme outcomes, what will they cost and how long will it take to complete the work? What business activities should cease, start or be done differently to achieve quick wins? What are the key risks and issues that could undermine the achievement of the benefits of the programme? Have the costs of the programme been identified over the life of the programme? Have potential funding sources been identified? What are the constraints that apply to the programme? What assumptions underpin the justification for the programme? How will the organisation provide the programme management resources and capability to carry out this programme? Does the Sponsoring Group or its representative agree that it is worth undertaking the detailed planning and design work required to fully define and cost the programme? Network Rail GRIP for Programmes Page 22 of 104

23 Definition Plan (Guidance) This section explains how to create a plan for the work to be carried out during the Definition Phase of the programme. This guidance is accompanied by a template for creating a Definition Plan. Identify Options Define Deliver Tranches Close Develop Programme Mandate Identify, Map, and Profile Benefits Develop Blueprint Develop Programme Brief and Plan for Define Phase Develop Prog. Benefits Realisation Plan Write Definition Report Define Programme Org. Structure Manage the Programme Using : Resources Finances Change Control Information Quality Risks & Issues Reporting Transition to new ways of working based on : Stakeholders Benefits Blueprint Business Case Make arrangements for benefits realization beyond programme closure Programme Review and Closure Define Programme Man. Activities Develop Stakeholder Map & Engagement Plan Network Rail GRIP for Programmes Page 23 of 104

24 Introduction The Definition Plan sets out the activities, timescales, costs and resources needed to fully define the programme. It is presented with the Programme Brief to the Sponsoring Group for review and sign-off. If both are signed off, the programme proceeds to the Definition Phase. It may be that the programme is agreed in principle but not enough information has been provided to enable a decision to be taken. If this is the case, further work may be required. Definition Activities The work needed to fully define the programme should be identified and documented. The table below is one example of how this information could be presented. Programme Definition Activities: expected duration 3 months Activity Description Programme Management Complete Design Stakeholder Engagement and Communications Deliverable Resource Timescales Costs (type) Programme Plan Organisation Mgt. structure Controls for delivery Blueprint Benefits Mapping Benefits Profiling Develop Project Dossier Stakeholder analysis Plan for consultation and engagement Programme Manager (IP) Programme Manager (IP) Programme Engineering Manager (IP) Route Asset Manager (Route) Commercial Manager Strategic Planner (NS&P) Communications Manager 3 months 3 months 10 weeks 12,000 (internal secondment) 20,000 (internal secondment) 3,000 (external consultant) 5,000 (internal secondment) Team and Management Processes The team structure, roles, who will be assigned to them and the reporting lines for the Definition Phase should be determined and documented. An organisation chart is a useful way of showing the reporting lines. As well as an organisation chart, a table, as in the example below, can be used to record members of the Definition Team and their roles. Network Rail GRIP for Programmes Page 24 of 104

25 Programme Definition Team Role / Area Name Job title Responsibilities Programme Sponsor/ Senior Responsible Owner (SRO) tbc Principal Strategic Planner Sign off Definition Plan Programme Manager tbc Programme Director Business Change Manager Programme Support Officers tbc tbc Route Asset Manager Programme Support Officer Ensure production of Definition Plan Assist with the production of the Definition Plan Support the production of the Definition Plan Management Processes for the Definition Phase The Definition Plan should say how the definition work will be managed, assured and aligned with the expectations of the Sponsoring Group. It needs to address management processes for: Controlling risks and issues Managing information to ensure that documents produced are the latest version, correctly named, filed and easy to find Progress monitoring and reporting including escalation routes The Definition Phase could be managed as a project, in which case good project management disciplines should be applied. Sign Off The purpose of the sign-off is for the Sponsoring Group to agree that there is an effective plan for completing the Definition Phase and that they are prepared to make the required resources available. Network Rail GRIP for Programmes Page 25 of 104

26 Definition Plan Checklist Does the Definition Plan satisfactorily answer the following questions? Definition Plan Key Question Section Sub Questions Is there a robust plan for completing the Definition Phase? Definition Activities Team and Management Processes Sign-Off Have all the activities, deliverables, resources (people and time) and costs to complete a detailed plan and design for all aspects of the programme been identified? Who will be assigned to each role and what will the reporting lines be? How will the work be managed, assured and aligned with local governance? Does the Sponsoring Group agree to the activities and costs required to complete the Definition Phase? Network Rail GRIP for Programmes Page 26 of 104

27 Blueprint (Guidance) The purpose of this guidance is to explain how to create a Blueprint that contains a detailed description of the Future State based on the vision, outcomes and benefits described in the Programme Brief. A detailed description of the Current State and an analysis of the gap between the Future and Current State. This guidance is accompanied by a template for creating a Blueprint. Identify Options Define Deliver Tranches Close Develop Programme Mandate Identify, Map, and Profile Benefits Develop Blueprint Develop Programme Brief and Plan for Define Phase Develop Prog. Benefits Realisation Plan Write Definition Report Define Programme Org. Structure Manage the Programme Using : Resources Finances Change Control Information Quality Risks & Issues Reporting Transition to new ways of working based on : Stakeholders Benefits Blueprint Business Case Make arrangements for benefits realization beyond programme closure Programme Review and Closure Define Programme Man. Activities Develop Stakeholder Map & Engagement Plan Network Rail GRIP for Programmes Page 27 of 104

28 Introduction The Blueprint contains a detailed description of the Future State based on the vision, outcomes and benefits described in the Programme Brief, and if already undertaken the outputs from the detailed benefits mapping exercise. It enables the Programme Board to decide whether an appropriate programme design has been developed which will deliver the anticipated benefits. It should describe: what the Future State will look like what the Current State looks like what the key gaps are between the Current State and the Future State (Gap Analysis) the major step changes from the Current State to the Future State the outputs that will need to be delivered in order to achieve the step changes towards the Future State any areas of the Future State where it is not yet clear how they might be delivered any assumptions and constraints used in compiling the Blueprint The work to create the Blueprint, identify the project outputs and to define the programme benefits needs to be integrated as shown in the diagram below. Work should start with defining the expected outcomes for the Future State and gaining a better understanding of the benefits sought. This in turn provides the basis for what needs to be in the Blueprint and the Blueprint determines what the projects need to produce as outputs. The process becomes iterative and previously unidentified benefits can emerge as more detail about anticipated benefits are identified during the development of the Blueprint. Benefits Map & Profiles Programme Plan Blueprint Project Outputs The Blueprint is a living document. It is refined as the programme progresses. As each step change in capability is achieved during the Delivery Phase, the next tranche of the Programme as described in the Blueprint is defined more clearly. The expected project outputs for the next tranche will also be identified and the expected benefits from achieving these outputs will be refined. The Future State becomes ever clearer as the programme progresses. Network Rail GRIP for Programmes Page 28 of 104

29 Content The Future State The Blueprint needs to describe what the Future State will look like and what needs to be put in place to achieve it. This will need to include: What the new processes will be This includes business processes; performance levels and operating costs What the organisation structure needs to look like This will include the revised structure needed, revised job descriptions and person specifications/ competencies etc. What technology / infrastructure needs to be in place This includes assets needed for the Future State, e.g. for an Electrification Programme a new Maintenance Training Centre may be required to increase the capability of existing and future staff to maintain any new infrastructure delivered. What information will need to be provided This includes management information and data required to operate the Future State. Current State and Gap Analysis The Blueprint should identify the extent and nature of the change required to achieve the Future State. Each programme has to plan and manage the journey from where the organisation is today (Current State) to the future as described in the vision. To achieve this, an understanding of the Current State and the gap (the difference between Current and Future States) is essential, as is identification and understanding of the key changes along the way to achieving the Future State. To produce the gap analysis the following information will need to be identified: Current processes in place that are impacted by the Future State Organisational structure for the part of the organisation impacted by the Future State Technology / infrastructure currently in place Information currently available The next step requires the identification of the gaps between the Current State and the Future State or any other changes that will need to occur, such as the decommissioning of old assets that will no longer be required. Preferably, the Delivery Phase will be managed in tranches (or phases), where each tranche achieves a step change in capability towards the Future State. Therefore the Blueprint should define not only the final Future State but it should outline the intermediate states along the way. However, if a programme is to have a short timescale and its path to completion is very clear, then the Blueprint may not need to define the key step changes from the Current State to the Future State. Finally, as it is not always possible to have all the information available to complete the Blueprint, actions needed to resolve any outstanding issues and any queries should be included in the Blueprint. This information will then enable the Programme Board to determine whether the programme should proceed to detailed planning. Network Rail GRIP for Programmes Page 29 of 104

30 Assumptions and Constraints Assumptions and any constraints that will apply to what is described in the Blueprint should be noted. These are those things that, if they turn out to be false, would invalidate the Blueprint or drastically increase the cost of its implementation. An example of an assumption: Government funding through the CP6 Determination identified to deliver the Programme will be secured to deliver the Programme. An example of a constraint: xxx Sign Off The Programme Board should sign off the Blueprint. It is important to review the Blueprint against the Vision and make sure all aspects of the vision are covered. The Blueprint is reviewed and signed off at the following stages in the programme lifecycle: Definition Phase before starting every new tranche of the programme, i.e. before embarking on the next step change towards the Future State when there are major changes to the scope, there are developments that impact the feasibility of the Blueprint, or the planned benefits of the programme are changed before transitioning to the new state (confirming readiness of all capabilities to start the new way of working) after transitioning to the new state (confirming that all capabilities are in place to support the new way of working) Blueprint Checklist on next page Network Rail GRIP for Programmes Page 30 of 104

31 Blueprint Key Question Section Sub Question Is there enough information to identify the projects and work streams required to create the capabilities of the Future State? Future State Current State and Gap analysis Intermediate States Outstanding items for Future State Has the Future State been described in enough detail to give confidence that the capability will support the realisation of the vision and benefits? Has the extent and nature of the change required to achieve the Future State been identified? Have the step changes from the Current State to the Future State been described in enough detail to give confidence that they are a good path to follow? Is there confidence that the actions that have been put in place to resolve any outstanding issues support a decision to proceed to detailed planning? Sign-Off Does the Programme Board accept the Blueprint? Network Rail GRIP for Programmes Page 31 of 104

32 Network Rail GRIP for Programmes Page 32 of 104

33 Programme Planning (Guidance) The purpose of this guidance is to explain how to create an effective programme plan to enable the Programme Manager and Business Change Managers to track, control and deliver the programme outcomes and benefits. Programme plans will take different forms dictated by the nature of the programme, the available tools and the preferences of the individuals concerned. For this reason this guidance is not accompanied by a template. Identify Options Define Deliver Tranches Close Develop Programme Mandate Identify, Map, and Profile Benefits Develop Blueprint Develop Programme Brief and Plan for Define Phase Develop Prog. Benefits Realisation Plan Write Definition Report Define Programme Org. Structure Manage the Programme Using : Resources Finances Change Control Information Quality Risks & Issues Reporting Transition to new ways of working based on : Stakeholders Benefits Blueprint Business Case Make arrangements for benefits realization beyond programme closure Programme Review and Closure Define Programme Man. Activities Develop Stakeholder Map & Engagement Plan Introduction Effective programme planning is the key to ensuring that the Programme Manager and Business Change Managers are able to track, control and deliver the programme objectives and benefits. Network Rail GRIP for Programmes Page 33 of 104

34 The Benefits of Programme Planning Programme planning is a key activity during the Definition Phase of a programme. There are many ways to approach it, but ultimately, it is about ensuring that the projects and activities needed to deliver the outcomes (business changes) and benefits are organised in a way that is coherent and manageable. The benefits of a robust Programme Plan include: an integrated view of the projects, activities and benefits so as to understand the relationship between them and the knock-on effects of changes to one part of the plan on other parts minimising the risk to the programme by using the plan as a tool to control and monitor delivery ensuring that individual project and activity plans work within the constraints of the Programme building confidence among senior stakeholders, the Programme Manager and Business Change Managers, that there is a workable plan to deliver the programme and to achieve the benefits ensuring a demonstrably coherent approach to delivery managing expectations in terms of overall delivery timescales Creating a Programme Plan The initial creation of a Programme Plan is an iterative process and the plan is built bottom-up and top-down. If the programme is an emerging programme (i.e. it is the collection of a set of existing stand-alone projects into one programme governance structure), the first draft of the plan may be built bottom-up through consolidating the individual project plans. It will then need to be reviewed and adjusted from the perspective of the key milestones and dates set at the programme level and any interdependencies between the individual projects. For all other programmes, the first draft will usually be at the programme level. The Programme Manager will work out the timing for the major step changes (tranches) in the programme. Then for each tranche, using the Blueprint, Benefits Map and relevant Benefits Profiles, the major deliverables that will be required and the benefits to be enabled or realised as a result of achieving these deliverables will be identified. The first tranche will be planned in detail during the Definition Phase and will have firm estimates for time, effort and costs. Later tranches should be planned in detail when their activities can be realistically estimated and validated and will therefore only have outline estimates in the initial programme plan. The creation of the Benefits Map, the Blueprint and the Programme Plan is an iterative process and is integrated as shown in the diagram below. The Blueprint is developed when there is a good understanding of the benefits and the project outputs needed are considered once the Blueprint has started to take shape. All three elements are continually adjusted during the Definition Phase as more detail emerges. The project outputs needed inform the list of projects that will go into the Programme Plan. It should be noted however that the very nature of programmes is that not all projects will be known at the outset. Many will be defined when the programme is underway. Network Rail GRIP for Programmes Page 34 of 104

35 Benefits Map & Profiles Programme Plan Blueprint Project Outputs Building the Project List A project list may have already been started as part of the Programme Brief. However, other activities carried out during the Definition Phase may have brought to light the need for new or changed projects. For example, in building the Benefits Map, it may have become apparent that the original anticipated list of projects is not adequate to deliver the benefits sought. The Project List in the Programme Brief should therefore be checked against the Blueprint and the Benefits Map to ensure that all required projects have been identified. Key information about each project should then be recorded as follows: Project Name Project Description / Output Project Executive Project Manager Project Team Duration Milestones Dependencies Contribution to benefits Costs The above information will be expanded in the Project Management Plan (PMP) when the project is kicked off. Identify Programme Activities As well as listing all the projects, it is also essential to list all other programme activities, both for the initial setting up of the programme and ongoing throughout the delivery of the programme. For example, as part of the initial set up there should be an activity to undertake a stakeholder analysis and to design the Communications Plan. Throughout the programme there should be further activities to reflect the agreed engagement and stakeholder activities set out in the Communications Plan. Network Rail GRIP for Programmes Page 35 of 104

36 Similarly, the initial set up should involve risk analysis activity to identify the risks of the programme and any mitigating actions required. Both the risks analysis activity and the individual actions identified to help mitigate the risks should be included as activities in the overall Programme Plan. The Activity List should include information about the time needed to deliver the activities; who is responsible for their delivery and any costs that will be incurred. Together with the project list information the activity list will provide a complete view of what will be involved in the delivery of the Programme. Determining the Tranches Once all the projects and activities needed for delivering the programme have been identified, the next step is to divide the work up into manageable chunks, or tranches. Tranches are groups of projects structured around major step changes in the delivery of the benefits associated with those step changes. The end of a tranche is a major programme milestone, after which the achievement of one or more benefits can be proved. For example, in an electrification programme the first tranche might deliver the training centre to develop and train commissioning engineers for future tranches and ultimately development of operational staff who will maintain and operate the assets at the end of subsequent tranches and the programme. The first tranche might take a year to complete, whilst the second tranche due to its complexity will take longer and might have to be planned over several years. In this case, benefits will start to be accrued immediately after delivery of the first tranche. The main aims when deciding which projects to include in each tranche are: To achieve cost savings through avoiding duplication of effort, for example the more projects you have the more project reviews you need to carry out To reduce inter-project dependencies where one project cannot progress as planned without a deliverable from another project such dependencies are a major cause of risk in programmes. Deciding how to break down the programme into tranches will also affect the number of projects in the project list, (some may be brought together into bigger projects or large projects may be split). Therefore the work to define the project list and to determine the tranches is best done in parallel and over a number of iterations. It is useful to define those projects that will deliver products, systems, etc. separately from those projects that will deliver business change, since they often have very different project cultures. Once the projects in each tranche have been identified, the next step is to examine each tranche to ensure that it is manageable in terms of the resources available; the amount of change involved; the capability of the organisation. Where projects appear to be too large it is advisable to try to reduce their scope or split them up. The key thing to remember is that most choices regarding the number and type of projects you have and how they are grouped into tranches will represent a compromise in terms of speed, cost, effectiveness or risk. Using the approach described here will help you understand those compromises. Building the Plan The Programme Manager and the Business Change Manager(s) need to be satisfied that the Programme Plan contains all the elements needed to deliver the outputs, outcomes and benefits and that it is realistic. As such, it is recommended that the Business Change Manager(s) ensure that the timing of project deliverables and all business transition activities are acceptable to the continuity of business as usual as well as ensuring that the benefits realisation activities are feasible. Hence, whenever significant changes to the Programme Plan are envisaged, the Programme Manager should consult the relevant Business Change Manager(s). Network Rail GRIP for Programmes Page 36 of 104

37 The following is a suggested list of minimum requirements for the content of a robust Programme Plan: Tranche objectives, start and end dates Projects with their duration, key milestones and dates Other activities and their duration, including benefits realisation activities Dependencies between projects Indication of what human and other resources are needed for the successful completion of each project or activity Any major reviews e.g. Stage Gate Review; audit reviews Major meetings and events that are critical dates for the programme, e.g. Cabinet meetings The Programme Plan will capture at high level all the relevant information needed to track and control the programme. There will usually be individual project and activity plans that feed into it. The Programme Plan will also be a reference point for extracting information about key milestones for stakeholders such as the Programme Board or the ORR. This is illustrated in the diagram below. High Level Milestone Plan Programme Plan Project Plan Project Plan Project Plan Sign Off The Programme Plan should be reviewed and signed off by the Programme Board at the following stages in the programme lifecycle: Definition Phase Before starting every tranche of the programme When there are major changes to the definition, scope, delivery status and expected benefits of the programme Before transitioning to the Future State (to confirm the understanding of stakeholders) Network Rail GRIP for Programmes Page 37 of 104