Appendix A: Programme information
This appendix provides an explanation of the information that is required to manage a programme successfully. It explains what documentation you should establish, where the information could be sourced from and what to consider including in the contents. You will also find details on who should be involved in creating the documentation and what their role should be in the process.
The format for the information is indicative and intentionally non-prescriptive. This enables organizations to structure, store and integrate information with their existing corporate governance frameworks; it is more important for organizations to identify and maintain the information to support their programme in a form that is appropriate to them. The following information descriptions should be seen as flexible checklists rather than rigid templates.
For example, the programme brief contains information that many organizations would also include in an outline business case. Therefore, the use of either term should be seen as acceptable. It is the process of developing, capturing, analysing and acting on the information rather than the title that is important.
A.2 WORKING WITH PROGRAMME INFORMATION
A programme exists within a dynamic environment. As such it is likely that information will be changing constantly; the programme’s knowledge will increase and this should be reflected in the information that is used to maintain context and manage delivery.
This appendix is not intended to provide templates; it is guidance on what should be included when constructing your documentation and when you should review and update the contents.
It is perfectly acceptable to integrate information into aggregated documents to make life easier; for example, governance strategy plans could be integrated into the programme plan if it is practical or the governance strategies themselves could be consolidated into one, as much of the information is replicated. The level and structure of programme information should be appropriate to the needs of the individual programme or organization.
Bear in mind that there is core information within a programme that is cross-referenced in multiple documents; you may need to create an indexing system within your programme to enable cross-referencing of this core information. For example, the benefit profile states that you should identify risks to the achievement of the benefit. These risks should also be contained within your risk register, where the impact assessment should include reference to the implications of the risk on that benefit and contributing projects, which in turn could create a project-level risk. This necessary replication of information requires careful tracking to ensure that all instances of the same information are updated so as to maintain integrity throughout the programme documentation.
An example of a common structure that could be used for all the governance strategies (or to integrate them) could be:
Roles, accountabilities and responsibilities
Processes, tools and techniques to be used
Standards to be applied and any subject matter expertise that is required, including legislation and policies
Escalation routes and triggers for interventions
Criteria for measuring success and assurance/review arrangements
Definition of key terms.
A.3 PROGRAMME INFORMATION EVOLUTION
Table A.1 outlines the information that is described in the section, when it is created and maintained, and to which information baseline it is allocated. There are three categories of information, which are reflected in their information baseline.
Table A.1 Information baselines
| Information baseline | Description of purpose |
|
Boundary |
Those which set out the direction and the scope of the of the programme |
|
Governance |
Those that set the standards and frameworks within which the programme will be delivered; defines ‘how’ the programme will be managed |
|
Management |
Those that are created and used to manage the delivery of the programme; defines ‘what’ activities will be undertaken by ‘whom’ to deliver the programme |
The following points should be considered with respect to information baselines:
Baselines help the planning and development of the programme information
The completion and approval of the set of documents in each baseline represents a step forward in the development of the programme
Reviews of effectiveness can be scheduled – for example, the governance baseline could be reviewed as part of a health check
Classification helps programme teams understand their purpose and maintenance regimes; for example, management information is in constant use, so the management baseline would be regularly updated, whereas the boundary baseline would be relatively stable, with a change potentially having a major impact on the programme’s viability
Baselines of documents interrelate; if one is changed, the impact on the others should be considered.
Table A.2 illustrates where and when documents are created and how they are managed over the programme lifecycle. Information will be continually changing; the programme information must be maintained to reflect the changing environment within which the programme exists and to maintain context. Section A.4 describes the individual documents in terms of their purpose and content, and Table A.3 shows who produces, reviews and approves each document.
Table A.2 Document management over the programme lifecycle
| Title | Identifying | Defining | Managing the tranche start | Managing the tranche end | Deliver capability | Realize benefits | Closure | Information baseline |
|
Benefit profile |
CR |
RU |
IM |
RU |
Boundary | |||
|
Benefits management strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Benefits map |
CR* |
IM |
RU |
RU |
RU |
Boundary | ||
|
Benefits realization plan |
CR |
RU |
IM |
RU |
Management | |||
|
Blueprint |
CR |
IM |
RU |
RU |
Boundary | |||
|
Business case |
CR* |
RU |
RU |
Boundary | ||||
|
Information management plan |
CR |
IM |
RU |
RU |
Management | |||
|
Information management strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Issue management strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Issue register |
CR* |
RU |
RU |
RU |
RU |
RU |
Management | |
|
Monitoring and control strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Organization structure |
CR |
IM |
RU |
RU |
Governance | |||
|
Programme brief** |
CR |
Boundary | ||||||
|
Programme communications plan |
CR |
IM |
RU |
IM |
IM |
RU |
Management | |
|
Programme definition document |
CR |
RU |
RU |
Boundary | ||||
|
Programme mandate** |
RU |
Boundary | ||||||
|
Programme plan |
CR |
IM |
RU |
RU |
Management | |||
|
Programme preparation plan |
CR |
IM |
Management | |||||
|
Projects dossier |
CR |
RU |
RU |
IM |
RU |
Boundary | ||
|
Quality and assurance plan |
CR |
IM |
RU |
RU |
Management | |||
|
Quality and assurance strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Resource management plan |
CR |
IM |
RU |
RU |
Management | |||
|
Resource management strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Risk management strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Risk register |
CR* |
RU |
RU |
RU |
RU |
RU |
Management | |
|
Stakeholder engagement strategy |
CR |
IM |
RU |
RU |
Governance | |||
|
Stakeholder profiles |
CR |
RU |
RU |
RU |
RU |
RU |
Management | |
|
Vision statement |
CR* |
Boundary | ||||||
|
CR = create; IM = implement, manage and refine; RU = review and update *This information is initially created as part of the programme brief. **These are ‘moments in time’ documents that are no longer referenced once the information has been expanded in other documents as the programme develops. However, they are important for retrospective assessment; hence they are part of the boundary baseline. | ||||||||
A.4 DESCRIPTION OF DOCUMENTS
A.4.1 Benefit profile
A.4.1.1 Purpose
Used to define each benefit (and dis-benefit) and provide a detailed understanding of what will be involved and how the benefit will be realized.
A.4.1.2 Typical content
Reference number or identifier
Description of the benefit (or dis-benefit)
Programme or organizational objectives supported and the related observable outcomes from the programme implementation
Category or categories that are appropriate to the benefits
KPIs in the business operations that will be affected by the benefit, both immediately after realization and for the future
Current or baseline performance levels, and improvement or deterioration trajectory anticipated
Benefit realization and business change costs
Capabilities required for the benefit to be realized: the project(s) within the programme directly related to the realization of the benefit
Outcomes that will need to be in place to enable the benefit realization
Business changes required for realization (to process, culture, people, policy)
Related issues and risks to the full realization of the benefit
Any dependencies on contributory events, programmes or projects outside the boundary of this programme
Who is responsible for realizing this benefit (typically the BCM for this area of the business)
Attribution: the benefit owner and the operations area that will receive this benefit
Measurement (financial wherever possible)
A.4.2 Benefits management strategy
A.4.2.1 Purpose
Defines the approach to realizing benefits and the framework within which benefits realization will be achieved.
A.4.2.2 Typical content
Scope and explanation of which areas of the business will be covered by benefits management and realization activity
Measurement methods and processes that will be used to monitor and assess the realization of the benefits (including the level of granularity to be applied in the benefits realization plan)
A description of the functions, roles, accountabilities and responsibilities for benefit planning and realization, aligned with the programme’s organization structure
Priorities for the programme in terms of benefit types to be sought (e.g. cashable direct), to inform and focus the filtering and prioritization process
Processes to ensure that benefits are not double-counted and that cumulative benefits are achievable
The relationships between capabilities and the benefits
Clarity, if necessary, as to opportunities to be managed in relationship to risk management
The relationship with other programme information
Categories to be used by the programme or inherited from a portfolio
Any organization-specific information or headings that should be included in the benefit profiles
Tools, systems and sources of information that will be used to enable measurement
Critical success factors against which the effectiveness of benefits management should be measured
Clarification of benefits-related terminology appropriate to the organization
The review and assessment process for measuring benefits realization, covering who will be involved in the reviews, and how and when the reviews will be carried out
Standards for identifying, mapping, monitoring and reviewing the programme’s benefits.
A.4.3 Benefits map
A.4.3.1 Purpose
Illustrates the sequential relationship between benefits.
A.4.3.2 Typical content
Benefits and dis-benefits, including short- and long-term benefits
Outputs
Capabilities
Outcomes
Strategic objectives
Dependencies:
Between benefits
On project outputs
On capabilities and outcomes
Additional business changes to enable realization of benefits
Other external dependencies.
A.4.3.3 Notes
Can be adapted to be included within the benefits realization plan.
A.4.4 Benefits realization plan
A.4.4.1 Purpose
Used to track realization of benefits across the programme and set review controls.
A.4.4.2 Typical content
A schedule detailing when each benefit, dis-benefit or group of benefits will be realized (typically as a chart with benefits of the same measure aggregated over time intervals through the life of the programme’s business case)
Appropriate milestones for benefits reviews to take a forward view of the likelihood of ongoing success
Estimated effort and costs associated with the plan
Detail of transition schedules
Benefit reporting schedule, which is submitted to the programme board
Relationship between outcomes and benefits in the schedule
Dates when specific outcomes that enable the benefits will be achieved
Dependencies external to the programme
Details of any handover and embedding activities, beyond the mere implementation of a deliverable or output, to enhance the process of benefits realization after the capability has been delivered; this part of the benefits realization plan is also referred to as a transition plan
Reference to how the benefits realization will be maintained after programme closure.
A.4.4.3 Notes
This may be incorporated as part of the overarching programme plan and could include the benefits map.
A.4.5 Blueprint
A.4.5.1 Purpose
Used to maintain focus on delivering the required transformation and business change.
A.4.5.2 Typical content
Processes and business models of functions, including operational costs and performance levels, of the required vision of the future state; may be expressed in a number of ways, including flow and process graphics
Organization structure, staffing levels, roles and skill requirements necessary to support the future business operations; any necessary changes to organizational culture or style may also be included
Technology, IT systems, tools, equipment, buildings and accommodation required for the future business operations together with details of re-use of existing infrastructure or implementation of new infrastructure to support the vision of the future state
Information and data required to effectively manage the future business operations
The complete blueprint document may contain several sections: the current ‘as-is’ state, sections for the intermediate future state for each tranche, and the final future ‘to-be’ state for the end of the last tranche.
A.4.5.3 Notes
The blueprint for a programme can, and should, take many different forms: prototypes, models and workshops can all assist in describing the future state. It describes the future capability that the programme is to deliver but may also include intermediate states aligned with tranches. It is sometimes referred to as the ‘target operating model’.
A.4.6 Business case
A.4.6.1 Purpose
Used to validate the initiation of the programme and the ongoing viability of the programme.
A.4.6.2 Typical content
The strategic objectives for the programme, reflecting the vision statement, and aligning with the organizational context and business environment
The expected benefits, with recognition of the organization’s ability to achieve the necessary transformation and change
The overall risk profile, indicating the major risks to programme delivery and benefits realization; detailed risk assessment will be part of the programme’s risk register
Estimated costs and overall timescales; detailed scheduling of programme milestones will be part of the programme plan
Investment appraisal
Forecasts of cash flow and expenditure over the programme timeline
Options and approaches that have been considered, including likely costs, benefits and risks.
A.4.7 Information management plan
A.4.7.1 Purpose
Sets out the timetable and arrangements for implementing and managing the information management strategy.
A.4.7.2 Typical content
Timetable to achieve:
Information storage systems
Configuration management
Release management
Information change control
Naming conventions
Security controls
Information, filing and documentation structures
Schedule for availability of templates to support the programme governance
Estimated effort and costs associated with the plan
Schedule for the extraction and delivery of information to support review, or similar procedures that are stipulated in activities in other plans
How and when information management work will be monitored and reported, to include alert mechanisms that warn about serious violations of the programme’s information assets
Who will be responsible for the actions identified in the plan
A.4.7.3 Notes
This may be incorporated as part of the overarching programme plan.
A.4.8 Information management strategy
A.4.8.1 Purpose
Describes the measures, systems and techniques that will be used to maintain and control programme information.
A.4.8.2 Typical content
Standards and processes to cover data and records management
Naming conventions and versioning controls
Use of terms, e.g. policy, strategy (could be a glossary)
Systems that will be used to store information
Responsibilities for management and maintenance of information
Levels of confidentiality to be applied
How information integrity will be maintained
Criteria to assess effectiveness (cross-referenced with the monitoring and control strategy)
Any information audit requirements which need to be met
Release management arrangements for updated baselines or individual configuration items, and the relationship to the programme communications plan
Approach to information availability
Configuration management procedures, including:
Configuration management responsibilities and systems and storage arrangements
Configuration management naming conventions and policies that will be used; these may be adopted from broader organizational policies
Explanation of how configuration management baselines will be implemented within the programme
Information security arrangements to maintain confidentiality, integrity and availability of information within the configuration management arrangements
Documentation standards and any relevant templates that will be used and in what circumstances.
A.4.8.3 Notes
Quality and assurance may cover similar topics as the information management strategy, so it is worth considering combining them if it is more efficient.
A.4.9 Issue management strategy
A.4.9.1 Purpose
Used to describe the mechanisms and procedures for resolving issues.
A.4.9.2 Typical content
How issues will be identified, captured and assessed
How issues will be managed across the programme, projects and operations
Responsibilities for the effective management and resolution of issues within the programme and for authorizing changes
How issue responsibilities will be allocated within the programme and between programmes, projects and operations
Process and explanation of how change control will work in the programme
Change control procedures for authorizing changes resulting from issues
Procedures for implementing and controlling the changes
How exceptions that may take the programme beyond its tolerances will be managed
How the likely impact of exceptions will be assessed
How responses to issues will be identified and by whom; who will carry out and manage the required responses
Definition of what constitutes a project- or programme-level issue, and how issues will be escalated or allocated between projects and the programme
Criteria for allocating severity ratings to issues; categories for severity might be ‘critical’, ‘major’, ‘significant’ and ‘minor’
Categorization mechanism for filtering issues, e.g. technical, business process, organizational, programme process
How responses will be monitored and evaluated for their effectiveness
Any organization-specific heading information that will be required to be recorded within the issue register, other than the generic issue register template
Criteria used to assess the effectiveness of issue management within the programme
Other strategies used to support the issue management strategy.
A.4.9.3 Notes
The information required for the issue management strategy and the risk management strategy is often very similar; it may make sense to include them in one document.
A.4.10 Issue register
A.4.10.1 Purpose
Used to capture and actively manage programme issues.
A.4.10.2 Typical content
Unique reference for each issue raised
Date issue was raised (and resolved)
Who raised the issue
A description of the issue
Description of the cause and impact of the issue
Severity rating, for example ‘critical’, ‘major’, ‘significant’ or ‘minor’
Categorization of the issue, e.g. request for change, issue, stakeholder question
A description of the issue response action to be undertaken, and by whom
Issue owner – the named individual who is responsible for the management and control of all aspects of the issues assigned to them
Issue actionee – the named individual responsible for the implementation of a given issue response action, the current status of the issue, and progress on its resolution, including providing feedback to the source
Cross-reference to change control procedures where appropriate
Description of how the issue was resolved and lessons learned from the actions taken.
A.4.10.3 Notes
Headings must meet the needs of the issue management strategy and be coordinated with the risk register.
A.4.11 Monitoring and control strategy
A.4.11.1 Purpose
Defines how the programme will apply internal controls to itself.
A.4.11.2 Typical content
What controls will be in place, including project decision authority, change activities and tolerance
Criteria to assess efficiency and effectiveness
How projects will be started and monitored
How the programme’s internal process effectiveness will be monitored
What standards will be applied to controlling the projects (e.g. PRINCE2)
Information that will be required for monitoring
Margins within which the programme will operate
Escalation routes for managing exceptions
How dependencies will be controlled
Performance criteria to be used to assess effectiveness.
A.4.11.3 Notes
This strategy is deployed as part of the programme plan and may also be referred to as the ‘internal control strategy’. Can also be integrated with the quality and assurance strategy as it covers internal performance, so quality and assurance would be relevant.
A.4.12 Organization structure
A.4.12.1 Purpose
Description of the management roles, responsibilities and reporting lines in the programme.
A.4.12.2 Typical content
Programme organization chart; the programme organizational structure
Description and responsibilities of individuals on the sponsoring group and programme board
Role descriptions or terms of reference for the individuals within the programme’s management team
Business change management organization and responsibilities
Expectations of responsibilities of organizational governance authorities, e.g. risk, compliance, accounting etc.
Terms of reference for sponsoring group, programme board and any other bodies established to support the programme
Allocation of assurance responsibilities within the programme
How professional development and performance will be developed for the team.
A.4.13 Programme brief
A.4.13.1 Purpose
Used to assess whether the programme is viable and achievable.
A.4.13.2 Typical content
Outline vision statement for the programme, containing a clear statement of the end goal of the programme
Outline description of the benefits or types of benefits that should be delivered by the new capability, an estimate of when they are likely to be achieved, and an indication of how they will be measured (also including significant dis-benefits). This could take the form of a benefits map
Estimated costs, timescales and effort required to set up, manage and run the programme from initiation through to delivery and realization of the benefits
Risks to the programme that can be recognized at this point in time, any current issues that may affect the programme, and any known constraints, assumptions or conflicts that may potentially affect the programme. These should also reflect levels of stakeholder support and engagement
Options for delivery that are known about at this stage, including the potential impact of ‘do nothing’
An initial listing of the candidate projects or activities required, together with rough timescales and explanations for any projects that will be terminated
Assessment of the current state, the current business operation and performance in the areas that will be impacted by the change.
A.4.13.3 Notes
May also be referred to as the outline business case. The information initially referred to as the programme brief will evolve into a number of other documents, including the vision statement, issue register, risk register, business case and benefit profiles.
A.4.14 Programme communications plan
A.4.14.1 Purpose
Sets out the timetable and arrangements for implementing and managing the stakeholder engagement strategy.
A.4.14.2 Typical content
Schedule of communications activities
The objectives of each communication
The key messages of the communication, and the level of detail to be included
Stakeholder audience for each communication, with an assessment of any sensitivities and their reaction
Timing of the communication
Description of channels to be used for each communication.
Individual(s) responsible for undertaking the communication
Feedback mechanisms
Estimated effort and costs associated with the plan
Reference to any supporting projects and business operations communications activity
Information storage systems
Possible stakeholder objections to the communication.
A.4.15 Programme definition document
A.4.15.1 Purpose
A document that is used to consolidate or summarize the information that was used to define the programme.
A.4.15.2 Typical content
Objectives for the programme
Executive summary
Justification and context for the programme
Criteria against which it should be measured
Vision statement
Blueprint summary
Programme roles and responsibilities
Governance principles that have been applied
Summary of the current state
Explanation of tranche delivery structures
Assurance arrangements
Description of outcomes
Summary of risks
Summary of projects dossier
Stakeholder summary
Benefits map
Timescales, milestones and tranches
Information baselines, status and content.
A.4.15.3 Notes
A programme may choose to have a single document that includes all the information developed during definition. This provides a single point of reference but may prove difficult to maintain under change control because of its size and complexity. Smaller programmes are more likely to find a single document more appropriate.
A.4.16 Programme mandate
A.4.16.1 Purpose
Used to describe the required outcomes from the programme, based on strategic or policy objectives.
A.4.16.2 Typical content
The strategic objectives of the programme
The programme’s context and the organizations that are likely be involved and affected (internal and external)
Critical success factors against which the programme will be assessed
What the programme is intended to deliver in terms of organizational improvements from new services and/or operational capability
Boundaries within which the programme will work
Possible strategies and approaches for delivery
How the organization(s) involved will be improved as a result of delivering the new services/capability
Initial assurance arrangements
Expectations in terms of timescales and costs, benefits, potential constraints and deadlines that will need to be met
Information on current or anticipated initiatives that will be included within this programme (for emerging programmes)
Reference to any external drivers or pressures that may define the way in which the programme approaches the challenge: for example, where the driving force for change is coming from
Summary of the ‘as-is’ state – the starting point at which the programme is being commissioned
How the programme fits into the corporate mission and goals, and any other initiatives that are already under way or will be under way during the lifetime of the programme
Initial budget.
A.4.16.3 Notes
Some organizations may use terms like strategic or embryonic business case; this may have similar information, and as such could be used as an alternative to the programme mandate.
A.4.17 Programme plan
A.4.17.1 Purpose
Used to control and track the progress and delivery of the programme and resulting outcomes.
A.4.17.2 Typical content
An overall programme schedule showing the relative sequencing of all the projects in the projects dossier.
Dependency network illustrating project input and output relationships
Cross-reference to the risk register to explain any planned risk response activities
Explanation of the grouping of projects and major activities into tranches, and the points at which end-of-tranche reviews will take place
Risks and issues referenced during planning
Transition planning information and schedules
Programme-level management activities required to implement the monitoring and control strategy.
Details of programme tranches
Estimated effort and costs associated with the plan
How the monitoring and control strategy will be deployed.
A.4.17.3 Notes
Individual plans that can be consolidated into the programme plan include resource, quality and assurance information, benefits realization, and programme communications.
A.4.18 Programme preparation plan
A.4.18.1 Purpose
A plan that details how Defining a Programme will be undertaken.
A.4.18.2 Typical content
Resources required and where they will be sourced from. This should include key potential resources of the future programme management team, e.g. BCMs and programme manager
Boundaries within which the team will work during definition
Description of the deliverables from definition
Governance and controls that will be applied to the defining team
Assurance arrangements for Defining a Programme process
Schedule of activities to achieve the outputs
Membership of the programme board
Estimated effort and costs associated with the plan.
A.4.19 Projects dossier
A.4.19.1 Purpose
Provides a list of projects required to deliver the blueprint, with high-level information and estimates.
A.4.19.2 Typical content
The list of projects, with descriptions and their objectives, which will be required to deliver the capability defined in the blueprint
Outline information on outputs and resource requirements needed to deliver them
Timescales and dependencies associated with each project, including dependencies on other projects
Detail on initial requirements for each project, drawn from the blueprint
High-level budgets allocated to individual projects that were used in the creation of the business case
Links showing what contribution each project and major activity will make to the programme blueprint and benefits
Issues and risks relating to the delivery of each project.
A.4.19.3 Notes
This may also be referred to as a project register. The information in the projects dossier should provide the basis for the project brief that will be provided to the project team.
A.4.20 Quality and assurance plan
A.4.20.1 Purpose
Sets out the timetable and arrangements for carrying out the quality and assurance strategy.
A.4.20.2 Typical content
Schedule of activities required to implement the quality and assurance strategy
Explanation of how the assurance arrangements will be deployed
A description of who will undertake quality assurance, review and control activities aligned with those activities in other plans that produce items that require assurance or review
A description of how and when the programme will carry out audits, health checks and reviews (or be subject to independent audit and review)
Information on how and when quality of work will be monitored and reported, to include the collection, aggregation and analysis of quality-monitoring data from projects
Estimated effort and costs associated with the plan
Schedule for planned assurance reviews.
A.4.20.3 Notes
This may be incorporated as part of the overarching programme plan.
A.4.21 Quality and assurance strategy
A.4.21.1 Purpose
Used to define and establish the activities for managing quality across the programme.
A.4.21.2 Typical content
Details of the processes that will be used to track programme performance against the principles and key areas; for example, people development
Integrated assurance arrangements for the programme
Aspects of the programme that will be subject to review and control and the quality criteria to be applied
A description of the functions, roles and responsibilities for quality management, aligned with the programme’s organization structure
Any links to independent assurance such as gated reviews
A description of what will trigger these activities (time-based, event-based, or associated with risk occurrence)
A description of what actions will be taken depending on the results of quality checks and the thresholds for escalation
Criteria for assessing programme success
Explanation as to how continual improvement and lessons learned will be managed
Interfaces with and dependencies on corporate management systems, including information requirements to support corporate quality management
Interfaces with the monitoring and control strategy
Responsibilities for assurance and quality
Interfaces with the organization’s internal audit functions
Guidelines to ensure the appropriate use of audits and health checks
Specific standards, regulations etc. that need to be adhered to, and which subject matter experts will be required to support quality management with regard to these areas
Explanation of how the results of assurance reviews will be processed.
A.4.21.3 Notes
Some organizations may refer to the quality and assurance strategy simply as the assurance management strategy.
A.4.22 Resource management plan
A.4.22.1 Purpose
Arrangements for implementing the resource management strategy.
A.4.22.2 Typical content
Schedule of activities to implement the resource management strategy
Who will be responsible for resource management activities such as procurement, contract management, recruitment, budgeting, resource-sharing
Tracking of use of resources (cross-referenced to the programme plan where appropriate)
Timings of reviews and monitoring activities
Explanation of how resources will be managed between the programme and projects; for example, will there be a pool or will each operate independently?
Estimated effort and costs associated with the plan.
A.4.22.3 Notes
This may be incorporated as part of the overarching programme plan.
A.4.23 Resource management strategy
A.4.23.1 Purpose
Used to identify how the programme will acquire and manage the resources required to achieve the business change.
A.4.23.2 Typical content
Funding requirements; accounting procedures for costs and expenditure; budgets for programme management resources and funding sources
Procurement approach and reference to current contract frameworks or arrangements that will be used
Cost and expenditure profile across the programme, expenditure approval procedures, financial reporting procedures
Profile of resources that are shared across more than one of the projects within the projects dossier; should indicate the expected use by each project of the shared resource within time periods
Explanation of how the resource requirements of the programme and projects will be achieved; consideration should be given to how the business operations capacity to resource the consequences of programme change will be managed
Assets required, such as buildings and office equipment, to deliver the programme
Technology and services required
Which specialist skills and subject matter experts will be required and how they will be sourced
Description of how the human resource requirements of the programme will be managed
Explanation of how the mix of internal and external resources to the programme and projects will be managed
How any necessary skills and knowledge will be transferred into business operations to establish the ongoing change
Approach to dispute-resolution where resourcing conflicts occur with business-operational requirements, other initiatives and programmes.
A.4.24 Risk management strategy
A.4.24.1 Purpose
Defines the programme approach to risk management.
A.4.24.2 Typical content
Roles and responsibilities for managing risk in the programme, covering both threats and opportunities
The process to be used and how it has been adapted from the organization’s risk management standards, where they exist
Any preferred techniques to be used for each step of the process described above
The interface with the benefits management strategy for the approach to managing opportunities
Scales for estimating probability and impact, giving the criteria to be used for each level within the scale
Guidance on calculating expected value for all the risks associated with a programme
Guidance on how proximity for risks is to be assessed
Risk response categories, including threats and opportunities
Any risk templates to be used, including the programme’s risk register
Relevant early-warning indicators
Timing of risk management activities; when formal risk management activities are to be undertaken, e.g. as part of end-of-tranche reviews
Information flows and reports that are to be produced, and their purpose, timing and recipients
Criteria and processes for escalating risks in the programme
Criteria to be used to assess the effectiveness of risk management within the programme
The external or internal risk management standards to be applied.
A.4.24.3 Notes
In some implementations, the information required for the issue management strategy and the risk management strategy may be contained in the same document. The content is derived from the organization’s risk management policy and risk management process guidance.
A.4.25 Risk register
A.4.25.1 Purpose
Used to capture and actively manage the risks to the programme.
A.4.25.2 Typical content
Risk identifier – a unique reference for each risk; may need to be reflected in project risk registers when the risk could impact on one or more projects as well as the programme
Description of the risk, including the cause of the risk, the event (description of the threat or opportunity) and its effect (summary of the likely impact on the programme and or its projects)
Probability of the risk occurring; should be done for both the before and after state (i.e. before and after any risk response action has been implemented)
Impact on the programme should the risk materialize, taken from the scales defined in the programme risk management strategy (where appropriate, this should show pre- and post-response action impacts)
Proximity of the risk, which is an estimation of the timescale for when the risk might materialize
Description of the proposed risk response
Any residual risk after the response has been implemented
Risk actionee – the individual responsible for the implementation of a risk response(s)
Risk owner – named individual who is responsible for the management and control of all aspects of the risks assigned to them, including the implementation of the selected responses to address the threats or to maximize the opportunities. It should be noted that responsibilities for the probability reduction responses may be different from those of the impact reduction responses
Response to the risk, which is dependent on whether the risk has been identified as a threat or an opportunity
Current status of the risk itself and progress of any actions relating to the management of the risk
Cross-reference to the programme plan to identify where risk response activities have been scheduled.
A.4.26 Stakeholder engagement strategy
A.4.26.1 Purpose
Used to define the framework that will enable effective stakeholder engagement and communication.
A.4.26.2 Typical content
Criteria on how stakeholders will be identified, grouped and tracked by the programme; it may be necessary to track specific key individuals and roles as well as groups
Explanation of the process for adding to or changing the programme communications plan
How the importance, influence, interest and impact of a stakeholder to a programme will be measured and assessed
How stakeholder analysis information will be processed and stored, with reference to confidentiality of personal data
Review cycle for stakeholder management information
Explanation of how projects and the programme will interface on communications and stakeholder activities, including guidelines on where there is an overlap
Responsibilities for delivering key messages and other information about the programme
Process for identifying and handling objections, including the approach to managing negative publicity
Description of how the programme will engage with all stakeholders, including appropriate channels and mechanisms for encouraging, receiving and responding to feedback from stakeholders
Any policies on types of terminology and language that will be adopted within the programme
Measures to determine the success of stakeholder engagement, including how well the communication process is engaging with stakeholders
Description of the overall responsibilities for stakeholder engagement within the programme
Explanations of the process for approving and integrating communications from the projects and business change teams to provide clarity and avoid overlap.
A.4.27 Stakeholder profiles
A.4.27.1 Purpose
Used to record stakeholder analysis information.
A.4.27.2 Typical content
Stakeholder map showing programme’s stakeholders and their areas of interest
Stakeholders’ individual areas of concern/sensitivity
Level of support for the programme
Areas of the programme that stakeholders are interested in and why
Levels of stakeholder influence on the programme and why, i.e. do we need them or do they need us?
Any developing trends that are relevant to the programme
Influence/interest matrix showing current and target positions for each stakeholder in terms of engagement
Benefits distribution, showing which stakeholders receive which benefits, and which will experience dis-benefits
Key influencers within the group, possibly those who have specialist knowledge or a relevant track record.
A.4.27.3 Notes
A summary document illustrating the key information about each stakeholder could be referred to as a stakeholder register.
A.4.28 Vision statement
A.4.28.1 Purpose
Used to communicate the end goal of the programme; could be seen as providing an external ‘artist’s impression’ of the desired future state.
A.4.28.2 Typical content
Clear statement of end goal of the programme; short and memorable
Any imposed constraints
Context for the programme and project teams
Any relevant information to help set expectations and context within the broader business context
Any information to support the justification for change; for example, a description of the current reality.
A.4.28.3 Notes
Sufficiently flexible to remain relevant over the life of the programme. Terminology used should be suited to all stakeholders and the context of the programme.
A.5 PROGRAMME INFORMATION RESPONSIBILITIES
The following list explains the levels of responsibility associated with the creation and maintenance of the programme information in Table A.3:
Approver The individual accountable who signs off acceptance of the content, outcomes defined and fitness for purpose.
Producer The individual who writes the document, or ensures that it is written, possibly consolidating information gathered from a number of sources.
Reviewer Groups or individuals who would be given the opportunity to contribute to and approve the contents, but without executive responsibility.
Table A.3 Programme information responsibilities
| Document title | Approver | Producer | Reviewer |
|
Benefit profile |
SRO |
BCM |
PgM |
|
Benefits management strategy |
SRO |
PgM |
BCM |
|
Benefits map |
SRO |
BCM |
PgM |
|
Benefits realization plan |
SRO |
PgM |
BCM |
|
Blueprint |
SRO |
PgM |
BCM |
|
Business case |
SRO |
PgM |
BCM |
|
Information management plan |
SRO |
PgM |
BCM |
|
Information management strategy |
SRO |
PgM |
BCM |
|
Issue management strategy |
SRO |
PgM |
BCM |
|
Issue register |
SRO |
PgM |
BCM |
|
Monitoring and control strategy |
SRO |
PgM |
BCM |
|
Organization structure |
SRO |
PgM |
BCM |
|
Programme brief |
SG |
SRO | |
|
Programme communications plan |
SRO |
PgM |
BCM |
|
Programme definition document |
SRO |
PgM |
BCM |
|
Programme mandate |
SG | ||
|
Programme plan |
SRO |
PgM |
BCM |
|
Programme preparation plan |
SRO |
PgM |
BCM |
|
Projects dossier |
SRO |
PgM |
BCM |
|
Quality and assurance plan |
SRO |
PgM |
BCM |
|
Quality and assurance strategy |
SRO |
PgM |
BCM |
|
Resource management plan |
SRO |
PgM |
BCM |
|
Resource management strategy |
SRO |
PgM |
BCM |
|
Risk management strategy |
SRO |
PgM |
BCM |
|
Risk register |
SRO |
PgM |
BCM |
|
Stakeholder engagement strategy |
SRO |
PgM |
BCM |
|
Stakeholder profiles |
SRO |
PgM |
BCM |
|
Vision statement |
SG |
SRO |
BCM |
|
SRO = senior responsible owner; BCM = business change manager; PgM = programme manager; SG = sponsoring group | |||
The programme office will have an important involvement with all the documents, which will be dependent on its authority within the programme and broader organization. Its involvement could include:
Advice on content
Broader corporate governance that applies
Provision of standards or templates
Configuration management librarian
Release management arrangements.
In addition there will be corporate functions that should also be consulted, in particular in the design of the governance documents.