4
Stage C: Definition

---

• Have all the activities, deliverables, resources, including enabling technologies and costs, needed to prepare a detailed plan and design for all aspects of the programme been identified?
• Have all the roles been identified and assigned?
• Has the governance plan been prepared and put in action?
• Does the programme sponsor board accept the activities and the costs required to complete the design phase?
• Is there enough information to identify the outputs, outcomes and deliverables?
• Does the programme delivery plan give confidence that the capability will support the realisation of the vision and the benefits?
• Has the extent and nature of the change required to achieve the vision been identified?
• Is there confidence that the actions that have been put in place to resolve any outstanding risks or issues and support a decision to continue to proceed to the next stage?
• Does the programme sponsor board accept the programme design?

---

4.1 Purpose of stage

The purpose of this stage is to provide a detailed definition of how the programme is to be set up, the delivery strategy, the level of resources that delivery will require and the governance controls to be applied, collectively known as the programme delivery plan (PDP).

4.2 Stage outline

Approval of the programme business case authorises the appointment of the principal members of the programme management team, who will then develop the strategy and methodology for the execution of the programme, collectively documented in the PDP (see Figure 4.1).

Figure 4.1 Stage C: Definition.

During the Definition Stage, the elements discussed next must be addressed.

Benefits profiles

The vision statement and programme brief are reviewed in order to develop a greater understanding of each benefit. Benefit profiles are developed, which consider the following:

• A description of the benefit
• The way it will be realised
• How and when this will be achieved or measured
• What measurement mechanism is appropriate
• Dependency on, or relationship with, any other benefit or activity.

The benefit profiles are collated into a benefits realisation plan, which describes how and when benefits resulting from the programme will be obtained

Scope definition and projects register

Preparation of the benefit profiles will enable the development of a project list known as the ‘projects register’, which will be necessary to achieve the programme outcomes. Each identified project needs to be fully scoped, together with the criteria of output, cost and time established. Any across-project dependencies or external constraints need to be highlighted. Delivery strategies for the projects must be stated, along with the managerial resources required and an indication of where these resources will be sourced.

Scope of undertaking

Scope definition is among the key critical success factors often cited by senior managers. These include:

• Scope clarity and innovative design to create value and save time in delivery
• Culture and diversity exemplified by a core team with no-blame culture from the start and with different backgrounds to provide different perspectives
• Strong risk management processes and accountability (intelligent client model to drive value from supply chain)

Scope definition is fundamental to an effective programme control function in order to build the right organisation and set of policies, procedures and processes for delivery. It will guide the programme to:

• Establish a baseline for future reference and realistic standards
• Monitor performance
• Keep the plan under constant review and take action when necessary to correct the situation

It provides a comprehensive summary of a programme, detailing the scope, schedule, budget and risk based on a clear map of the work and how it is broken down in time and space using the WBS.¹

A collectively developed, shared, understood and used WBS or activity schedule is at the heart of programme success.

Also needed is a network of activity that clearly sets out the overall strategy for breaking down the programme that can also be supported by a visual schematic geographical representation to show:

• Discrete stages of the programme and projects including any overlap of stages
• Sub-projects, work streams such as information technology (IT) or infrastructure
• Principal or summary activities
• Milestone and key dates
• Inter-relationships between the activities and sub-projects
• The objective to be achieved at each stage

Stakeholder analysis

As programmes tend to be large and are generators of significant change, their influence has an impact on a wider scale than just one-off projects. Because of their nature, it is also likely that programmes have a higher visibility than do projects. It is therefore essential to the design stage that there is a detailed deliberation of the identification, interest and influence of stakeholders; it is likely the list of stakeholders will be substantial. The large impact of some programmes means there is likely to be higher degrees of opposition or dissatisfaction. As effective stakeholder analysis and management is critical to programmes, a full time stakeholder manager, or even a team, may be assigned to ensure this important aspect is dealt with successfully.

A detailed stakeholder analysis and a stakeholder management strategy will be developed from the initial considerations included in the programme business case. A ‘programme communication plan’ will be created that defines how each stakeholder will be dealt with and the nature, extent and frequency of communications within and outside of the programme team and stakeholders.

Risks, issues, assumptions and constraints

The programme mandate and brief will have identified a number of risks, issues, assumptions and constraints, and these are now revisited in light of further understanding of the programme that is emerging. This is an opportunity to take advantage of a wider consultation on these aspects.

Risks (circumstances that may occur or change, some identified and expected, others unknown and unexpected) will be analysed in a risk register, and a methodology will be adopted for their ongoing monitoring and management. Some financial contingency allowance needs to be calculated for the impact of the risks.

Similarly, issues (things that have already happened and need action) will be listed in an issue register and a methodology adopted for their ongoing monitoring and management.

Initial assumptions need to be reviewed to clarify likely impacts on the programme. Some assumptions may concern factors outside the direct influence of the programme, and these may need to be referred to the project sponsor who may in turn need to obtain further advice from a higher level in the sponsoring organisation. Any additional assumptions made during this stage also should be considered and included on the register. Where appropriate action plans are developed, a methodology for regularly reviewing assumptions also should be developed.

Any constraints need to be subjected to a similar approach. Consideration should be given to devising strategies that avoid major constraints. Constraints may be created by:

• Operational requirements
• Funding issues
• Commercial and political sensitivity
• Regulatory and legal requirements
• Timing issues to do with availability (legal agreements, ownership, resources)
• Key calendar dates

Programme timescale plan

Based on the information contained in the programme brief; the benefit profiles; projects register and risks, issues, assumption and constraints registers, an overall delivery time schedule for the programme is produced. [Note: In common with other CIOB publications, to avoid confusion between terms, ‘schedule’ is adopted throughout this publication rather than ‘plan’ or ‘programme’.] The time schedule estimates anticipated completion of the programme, the anticipated duration and timing of individual projects, and identifies when benefits realisation are expected. It highlights dependencies between projects and any external dependencies. In situations where there is a complex pattern of dependencies it may be helpful to produce dependency charts.

It should be possible to identify the critical path sequence through the programme time schedule as this is helpful information when having to make decisions on resource priorities. It should be acknowledged that, at this stage, it may not be possible to identify all the projects that are required to achieve the programme’s objectives.

In addition to the overall programme time schedule, a more detailed start-up time schedule should be produced describing the timing of activities necessary to mobilise the next stage of the programme once approval to proceed has been obtained.

Programme financial plan

At the point at which the delivery plan and delivery time schedule have been devised, it is possible to prepare a financial statement that collects all the costs that have been identified in relation to implementing the programme.

The financial statement should be compared with the financial information contained in the programme business case and any significant variances highlighted.

From the financial plan and the delivery time schedule the expenditure cash flow profile can be calculated. This is a critical document because it informs the funding commitment for the programme. It must therefore be presented, discussed and approved by a senior executive of the sponsoring organisation, such as a financial director, before it can be included in the PDP.

Compared with a project budget, there is a higher degree of uncertainty attached to determining programme budgets as the timescales involved are likely to be much longer and the exact number and scope of projects to be instructed may not be known until later in the implementation of the programme.

The high cost of many programmes creates a substantial risk to the financial standing of the sponsoring organisation; therefore, oversight of the financial aspects of programmes is a crucial function. The role, of programme financial manager must be undertaken by an experienced financial manager who has expertise in dealing with complex issues around tax liability, capital allowances and programme funding.

Transition plan

Prepared principally by the business change manager (BCM), a detailed strategy must be produced to describe the mechanism by which each project output is handed over and incorporated into the final enterprise. How this is achieved will vary depending on the nature of the undertaking. In some situations project outputs can be immediately put into a ‘business as usual’ state, but others may need an assembly of numerous ‘outputs’ from projects from different programmes.

The ‘transition plan’ will explain what management infrastructure must be in place from the new enterprise in order to take ownership of project outputs as they become available. The document should also set out the acceptance criteria for each of the deliverables.

Programme delivery plan

Production of the documents discussed above, as identified earlier in Figure 0.2 and Figure 0.3 in the Introduction, collectively form what is referred to as the PDP. (See Figure 4.2.) The PDP is a detailed description of what the programme will deliver, how and when it will be achieved and the financial implications of its delivery.

Figure 4.2 Contents of the programme delivery plan.

The PDP is presented to the programme sponsor board (PrgSB) for their consideration and, providing it falls within the parameters established in the business case, their endorsement that the programme can proceed to implementation.

In situations in which the sponsoring organisation either has a complex structure or comprises a number of separate legal entities, or where stakeholders have a critical influence on or are significantly affected by, the programme, the PrgSB may require further consultation on, or consent to, the PDP prior to their being prepared to authorise implementation.

4.3 Stage organisation structure

4.3.1 Stage overall structure and relationships

Stage C marks the commencement of the involvement of almost the full programme team as they collectively evolve the programme’s implementation strategy and fully plan how the programme will be executed. See Figure 4.3 for a structure diagram. Control of the progress of the programme, which up to this point has been with the programme sponsor (PrgS), moves to the PrgM, who now has prime responsibility for planning and designing the way the programme will proceed. Reporting to the PrgS, the PrgM is assisted by a range of personnel: a PrgFM, a programme stakeholder/communications manager and a team of specialists within a programme management office (PMO).

Figure 4.3 Stage C: Definition – organisation structure.

The BCM, working in conjunction with the PrgS and PrgM, continues with the function of ensuring at each stage that what is being proposed or delivered matches the requirements of the client. The business change manager takes responsibility for benefits management and for beginning to develop plans for the transition of the undertaking into its finished state.

In accordance with good management practice, the production of a roles and responsibilities matrix is a helpful device for assisting the determination of the level of structure and resource required.

4.3.2 Stage roles of key participants

Programme sponsor’s board

The PrgSB have a number of key roles during this stage:

• Provide advice in relation to the PDP
• Review the PDP
• Resolve any issues raised by the PDP
• Review and give approval to the PDP
• Give approval to proceed to Stage D

Programme sponsor

Having appointed a PrgM to take responsibility for this stage, the PrgS adopts a more strategic role and carries out the following:

• Acts as the interface between the programme management team and the client body
• Provides direction and advice to the PrgM
• Selects and appoints, in conjunction with the PrgM, additional members of the programme management team
• Resolves any queries, ambiguities and conflicts with the PrSB
• Determines the change control process
• Reviews and approve the PDP

Business change manager

During this stage, the BCM continues to focus on the benefits to be delivered and the final outcome of the programme by doing the following:

• Selecting and appointing a BRM (if required)
• Developing benefit profiles to match the outcomes defined in the programme brief
• Developing transition plans
• Confirming acceptance criteria for the programme deliverables
• Reviewing and confirming, in conjunction with the PrgM, the number and nature of projects required to achieve the deliverables

Benefits realisation manager

Depending on the size of the programme, it may be necessary to appoint a benefits realisation manager to support the BCM. The role of the benefits realisation manager during this stage is to:

• Develop the benefit profiles
• Assemble the benefits realisation plan
• Determine the mechanism for realising and measuring benefits
• Determine the critical success criteria
• Determine the acceptance criteria for programme deliverables

Programme manager

Leading this stage, the PrgM has a number of key tasks:

• Identifying the roles of the programme management team that need to be available during this stage
• Selecting and appointing, in conjunction with the PrgS, the remaining members of the programme management team required during this stage [Note: Depending on the individual circumstances these may be internal or external appointments].
• Defining the full scope of the programme
• Arranging for a physical location for the programme team
• Arranging for the establishment of the IT infrastructure to support the programme team
• Overseeing the production of the PDP
• Reviewing and confirming the programme’s time schedule
• Reviewing and confirming the programme’s cost plan
• Reviewing and confirming the programme’s risk analysis and risk register
• Determining, in conjunction with the programme information manager, the information/document system to be adopted
• Reviewing and confirming the programme’s governance policies and procedures
• Reviewing and confirming the programme’s financial policies and procedures
• Reviewing and confirming the stakeholder analysis and communication plan
• Determining the number and scope of projects necessary to achieve the programme’s deliverables

Programme financial manager

The PrgFM has responsibility for ensuring that the programme budget determined during this stage aligns with the business case. The financial manager’s principal activities include:

• Overseeing the development of the overall programme budget
• Ensuring the budget conforms with the sums contained in the business case
• Determining expenditure cash flow forecast
• Determining the risk and contingency allowances to be included within the programme budget
• Confirming the programme’s funding arrangements with the PrgS and PrgM
• Reviewing the cash flow forecast with the funders
• Defining the programme’s financial policies and procedures
• Liaising with the financial director(s) of the sponsoring client on matters relating to the implication of the programme on their financial reporting and tax affairs
• Ensuring prudent financial governance

Programme management board

The programme management board (PrgMB) comprises the senior managers of the programme management structure and provides advice and support to the programme manager. The PrgMB should meet regularly to review the programme’s progress and to highlight and resolve any issues that may be hindering it.

The PrgMB is likely to be composed of the following managers:

• Programme sponsor
• Programme manager
• Business change manager
• Stakeholder/communications manager
• Programme financial manager
• Head of the PMO together with project managers from key projects as and when required

Stakeholder/communications manager

The stakeholder/communications manager’s role includes establishing an understanding of the programme’s stakeholders and a plan determining either their level of engagement or how they will be kept informed of the progress of the programme. This will involve the following:

• Identifying all stakeholders
• Carrying out an influence/impact analysis
• Developing a communication plan for stakeholders
• Developing a communication plan for staff within the client organisation affected by the programme
• Developing a public relations plan for the programme

Programme management office

In addition to requiring a PrgM, this stage requires that the core members of the PMO also be available. These include the head of the PMO and sufficient staff with the necessary technical expertise to carry out the functions required during this stage to develop the PDP and to establish the governance controls. The size and range of expertise required will depend on the nature and complexity of the programme. In some instances the input required from the programme team may be available from within the sponsoring organisation, but in many others it is likely that all the expertise will be externally sourced specifically for the programme. In addition to specialist input on matters such as legal aspects, property and finance, some sponsoring organisations may need to contract with organisations to provide all the programme management delivery capability. These positions include the following:

• Head of PMO: Responsible for setting up the PMO and for ensuring all systems, processes and procedures are established in readiness for the implementation of the programme
• Scheduling manager: Responsible for establishing the planning and schedule infrastructure to be adopted across the programme and its projects and for developing the overall programme schedule
• Cost manager: Responsible for establishing the cost management system and protocols to be adopted across the programme and its projects and for developing the cost budget and cash flow forecasts
• Risk manager: Responsible for establishing the risk management system to be adopted across the programme and for carrying out the process to determine a risk analysis for the programme
• Document/information/IT security manager: Responsible for determining, in conjunction with the PrgM, the document and information system to be rolled out across the programme and for installing this system in preparation for implementation, including ensuring a secure information storage and exchange mechanism
• Data manager: Responsible for data collection, data system management, data reporting and analysis and ensuring data collaboration among all the participants in data exchange
• Administrator(s): Responsible for providing sufficient support to allow the efficient and effective operation of the PMO
• Health and safety manager: Responsible for setting up a system that is appropriate for the health and safety regulations and legalisation existing in the environment(s) in which the programme is being carried out
• Sustainability and environmental manager: Responsible for establishing from the programme brief the sustainability drivers, identifying any statutory and regulatory requirements affecting the programme, and developing a framework for sustainability targets
• Specialist advisors: During this stage it is likely that the project management team will need to obtain the advice and assistance of specialist advisors. These areas could be legal, real estate, financial or a range of technical aspects

Establish programme organisation

• Appoint the remainder of the PMO and any other members of the programme management structure not in place
• Arrange for establishment of a physical location for the programme team
• Establish the IT infrastructure to support the programme
• Set up the programme-wide systems, such as intranet sites and information management (building information modelling [BIM])

Benefits management

• Continually review the contribution project outputs are making towards benefit realisation
• Review benefit realisation against the key success criteria
• Regularly review the benefit profiles in the light of greater knowledge and understanding of the programme, and any changes to the programme’s objectives
• Keep aware of any changing external circumstances that may affect the outcomes of the programme and impact benefits

Change management

• Manage the process of appraising changes as instructed by the PrgS
• Advise the PrgS and PrgSB of the implications for the programme and its deliverables of the changes incorporated

Audits

• Depending on the nature and complexity of the programme, it may be necessary for the PrgS and/or programme manager to initiate either internal or external audits of the programme or projects

Transition

• BCM incorporates project outputs into the business operations of the new enterprise in accordance with the transition plan

Stakeholder analysis

Apart from the stakeholders in Chapter 1, Section 1.7.5, a programme will often include other stakeholders that in one way or another may be affected by the programme. Common stakeholder groups include the following:

• General public (people who are only indirectly affected by a programme but who may have a significant influence on its realisation)
• Community (people who are directly affected by a programme through their geographic proximity to programme works)
• Employees (delivered changes and benefits will directly impact employees of the client organisation)
• Shareholders (individuals or legal entities owning shares in the client organisation that is undergoing change who are affected by the business change)
• Customers (client organisations whose customers will be affected by the business change)
• Interest groups (members who share common interests and control some area of activity, such as non-profit organisations and volunteer organisations)

4.3.3 External environment and relationships: mapping the landscape

Any programme affects the environment that it operates in and at the same time is also affected by the environment. The external environment influences business strategy and the success of a programme.

It is therefore essential not only to identify external drivers in order to shape a strategic change and a programme, but also to identify, map and track programme stakeholders, as this will help develop support and manage programme communications. See the stakeholder map in Figure 4.4.

Figure 4.4 Stakeholder map.

Stakeholders include persons and organisations that have an interest in the strategy of the organisation and programme and have an impact on or are impacted by a programme. Stakeholders normally include shareholders, customers, contractors and vendors, staff and the local community.

Programmes and organisations need to be able to identify their stakeholders and judge the level of power they hold to affect the decisions and outcomes of the programme. A first step for this process will be to create a stakeholder map. This map will include all the stakeholders for his or her organisation with the programme at the centre. Stakeholders include:

• Internal stakeholders: Members of the organisations and those with an economic or contractual relationship with the programme
• External stakeholders: Those with interest in the organisation and programme activities or that might be impacted by the activities in some way. Key examples are governments, public, interest and pressure groups, media and news organisations, local communities and statutory authorities

4.4 Programme management practices

During the definition stage, concurrent with the PDP being developed, work is underway on the assembly of a series of processes and procedures that will describe how the various management governance controls will be implemented for both the programme and individual projects. They provide all the programme participants with a consistent understanding of how the PrgS and PrgM, or indeed the sponsoring organisation, want the programme and projects to be managed.

Processes and procedures need to be developed for the areas discussed next.

4.4.1 Scope management

In the context of programme management, scope for a programme relates to the collective objectives of all the component projects and activities. The responsibility for managing individual project scopes will stay with the project managers; however, the PrgM will be responsible for the overall scope management.

Scope for a programme is underpinned by three key components:

• Scoping of information from initiation documentation as prepared in the earlier phases, such as the vision, mandate, brief and business case
• Definition of requirements, which is effectively a detailed design of programme deliverables
• Delivery of requirements, which continues from the programme design and defines the scope of work for each activity or project

The delivery requirements collectively provide a view of the end state of the programme and must align with acceptance criteria to ensure that the project activities address and satisfy the specific requirements.

The programme initiation documentation outlines the current state and the vision for the future state; it is the scope that defines how the programme will enable the changes to ensure that the transition is effected from the current state to the desired future state.

Where the end state is well understood and has a tangible output (e.g. in construction and engineering), it is usual to define the scope as accurately as possible at the beginning. This potentially reduces the level of changes that may be required and keeps costs from escalating. It is also useful to define what is outside of the scope to avoid misunderstandings. Clearly defining what is in and out of scope reduces risk and manages the expectations of all key stakeholders.

Where the objective is less tangible or subject to significant change, for example, business change or some IT systems, a more flexible approach to scope is needed. This requires a careful approach to avoid escalating costs.

It is important to recognise that, particularly for large and complex programmes, it is most likely that initial scoping will be required to undergo changes as risks, issues, and changes in the wider landscape emerge. The programme design must enable a robust and effective change management process to deal with the scope variations and changes, and most importantly, must be capable of identifying and flagging where a change in scope occurs.

It is the responsibility of the PrgM to flag any changes to the scope (be it at project level or programme level) to the PrgS and all changes to scope must be authorised by the PrgSB.

In practice, the majority of scope change requests will be generated at the project level; it is critical that scope change approval is not done at the project level. Those involved in projects can see their own work, but they can’t see the interdependencies that exist between projects. Therefore, those working on the projects don’t have the right level of understanding as to the impact of scope change requests across the projects. This requires that project scope changes be escalated to the programme level for a decision.

Scope is typically managed both at programme and project level.

• Programme scope: This is owned by the PrgM, and changes to programme scope are managed at the programme level. This may lead to changes necessary at project levels as well
• Project scope: The PDP will identify the processes required at the project level in terms of managing scope. Project scope changes must be examined at the programme level to ensure they are monitored and actively managed. These project scope changes must be elevated to the programme for approval. The impact of an approved scope change request is communicated to the affected projects for management

Managing programme and project scope change is one of the primary responsibilities of the PMO.

These methods are used to identify the activities that are necessary to achieve the programme’s objectives:

• Work breakdown structure
• Scope statement
• Acceptance criteria
• Exclusions from scope
• Assumptions

4.4.2 Benefits management

At this phase, it is necessary to define how benefits will be managed, from identification through to realisation, in alignment with the programme vision and the business case.

The key considerations at this phase will include the following:

• How will the benefits be identified – for example, through benefits mapping workshops
• Who needs to participate – typically PrgM, BCM and relevant stakeholders and participants from the programme delivery team
• How will the benefits be monitored/reviewed and when – It is important that benefits are regularly reviewed as the programme delivery progresses to allow for requirement changes, risks, issues and changes to the initial assumptions
• What are the key criteria for reviewing – for example, is there focus on the right benefits, can the targeted value of each benefit be improved, can the costs associated with each benefit be reduced, are there any additional benefits that can be targeted, are the risks and issues associated with benefits being dealt with

The considerations and outputs generated at this phase must be subject to a change control process, and benefit profiles can be used to capture any changes or amendments. The benefit realisation activities in the PDP will also need to be amended to reflect any approved changes.

4.4.3 Risk Management

Risks will be identified, recorded, monitored and managed in the following ways.

• Risk management methodology
• Risk register
• Risk review process

Risks, issues and opportunities (RIO): managing uncertainty

As technical and commercial issues get more complex and financial metrics tend to proliferate, finance and programmes often end up measuring performance and risks in different ways, using various sources of information and, in many cases, using a different language. Risk assessment is not an exact science, and there are a number of different methods to measure or quantify risk.

Effective risk management begins with realism – seeing things as they are – and continues with a joined approach and common understanding at all levels of an organisation or programme. A strong corporate risk management culture and consistent risk-rating methodology are fundamental to the success of a programme in order to focus on the risks that matter.

The guidance below offers a structured common sense-based approach to risk management.

Success factors

The key success factors are as follows:

• Identification and control of risk
• Alignment to business value drivers
• Awareness of changing risk profile and risk appetite
• Comprehensive approach to risk management

Risk categories

Risks will generally fall under the following categories:

• Financial risks
• Reputational risks
• Health and safety risks
• Operational risks

Objectives

The objectives of effective programme risk management are as follows:

• Provide a mechanism for the early identification and resolution of risks that may arise
• Ensure that risks are escalated to and mitigated by appropriate levels of management
• Provide for the visibility of risks that may affect or are affecting high-priority projects
• Provide accountability for the mitigation of project risks
• Provide guidance for the correct control and administration of the recorded risks
• Provide a basis for determining the level of financial contingency required for the programme

Definitions

Risk is often defined as ‘an effect of uncertainty on the objectives²’. Risk can be categorised as the following:

• Hazard – risk of adverse events
• Uncertain outcome - not meeting expectations
• Opportunity – exploiting the upside

An issue may be defined as:

• Any unresolved problem which could jeopardise programme outcomes
• A risk that has materialised
• An uncertainty, which was not previously raised on the risk register, has occurred

It is imperative that all issues are recorded on the project issue log; however, an issue should be reported to the PMO only if the project team cannot resolve the issue or if the project manager determines that the issue impacts other projects that are outside the PMO’s scope of responsibility. The issue process implemented by the PMO is to ensure that the appropriate management team is engaged to help resolve problems.

At the portfolio level, risk management and change control is supported centrally, which brings together a set of essential functions to support the successful delivery of programmes and projects, including:

• Coherent upward reporting to the management board on its key programmes and projects to support effective decisions
• Timely sharing of information and lessons learned through outward relationships … and beyond
• Inward support to help deliver programmes and projects with the right expertise when needed

Quantitative risk assessments (QRAs) based on experiential understanding of the effect of uncertainty in relation to the programme out-turn cost (or anticipated final cost [AFC]) and schedule delivery will be performed at key stages of a programme. Certainty of outcome will become greater as the programme approaches its final stages. Probability management will store uncertainties as data in a model that is actionable, additive and auditable.

For this purpose, three-point estimating (as illustrated in Figure 4.5) can be used as a tool for estimating cost and schedule value and assessing overall risk.

Figure 4.5 Three- point estimate triangle.

The following areas will need to be considered during this process:

• Accuracy of data and assumptions
• Inconsistencies in data set
• Data errors
• Need for a wide range of perspectives
• Consideration to risk mitigation plan that can limit risk impact

Given the number of estimates and activities on a programme, the three-point estimate can sometimes be misleading. Another estimating technique is to enter variances of the probability distribution around the most likely estimate. This technique is based on an integrated holistic understanding and current knowledge of the programme’s inherent risks. The estimation of uncertainty is illustrated in Figure 4.6.

Figure 4.6 Estimation of uncertainty: illustrative example.

A QRA undertaken on the programme will confirm the appropriate level of contingency (also known as ‘overall risk pot’) required to deliver the programme and shared between funding organisation, programme and projects. This includes the assessment of risks within individual projects in addition to cost and schedule risks across the programme.

The basis of the risk model should be an agreement of risk allocation between funders. The level of contingency proposed in the budget should represent those risks agreed to be under the influence and control of funders, programme and projects. The funders contingency relates to risk that does not sit with the programme and projects. The programme contingency relates to risks that do not sit within the individual projects and are not covered by project contingencies.

In summary, an s-curve will represent the likely exposure of the total risk across the programme (see Figure 4.7). Based on the agreed allocation of risk (at the 80th percentile), the contingency requirement, inclusive of VAT, will be estimated – that is, there is an 80% likelihood of not exceeding this contingency. The curve will also indicate that, from the analysis, an additional £xxxm would be required to secure a confidence at the 95% level.

Figure 4.7 S-curve detailing the cumulative contingency requirement.

The s-curve will indicate an upper limit that is significantly greater than the 80th percentile; to some extent this is influenced by the probabilistic model and the potential for uncontrollable acceleration costs or design risks. This suggests an increased maximum out-turn cost, albeit at a low level of probability. It is important that funders recognise increased exposure throughout the programme as it represents a substantially higher potential cost above the level at which the programme contingency is calculated.

There are other ways to represent risk and probability graphically as tornado diagrams or bar charts using Monte Carlo analysis and proprietary software for cost and time probability assessment.

It is apparent from programme delivery history that the risk of strategic misrepresentation remains high for complex programmes. Senior managers will need to consider the level of optimism biased (the tendency to overestimate the achievability of planned actions) for any programme. Benchmarking, due diligence, and historical local performance analysis will allow the programme to avoid blind spots and prepare the organisation for black or grey ‘swan events’ – low-probability high-impact risk (terrorism or major temporary design failure) or unknown unknowns (natural disaster).

4.4.4 Governance of programme management: steering for success

Governance defines the structure, roles and responsibilities to set objectives and report and monitor performance in order to make decisions and to steer a programme towards its anticipated destination.

The Organisation for Economic Co-operation and Development (OECD) defines governance as a set of relationships between an organisation’s owners, its board, its management, and other stakeholders. This provides the structure through which the organisation’s objectives are set and the means of attaining those objectives and of monitoring performance are determined.³

The APM (Association for Project Management) defines governance of programmes and projects as follows: governance of programme management concerns areas of corporate governance that are specifically related to programme and project activities. Effective governance of programme management ensures that an organisation’s programme is aligned to the organisation’s objectives, is delivered efficiently and is sustainable. Governance of programme management also supports the means by which the board, and other major project stakeholders, are provided with timely, relevant and reliable information.

The governance of programmes will cover the following areas:

• Leadership and sponsorship, clear and documented roles and responsibilities
• Strategic direction, a multidimensional roadmap to reach the final destination
• Programme management methodology, including a set of policies, procedures and processes to control programme trajectory against baseline
• Integrated assurance – transparency and disclosure to all stakeholders via operational (projects), functional (PMO, department) and compliance (risk and audit) lines of defences

The terms of reference for a programme board will typically cover the following:

• Requirement – why?
• Role – what?
• Composition – who?
• Conduct – when?
• Proposed delegated authority – how/how much? This is based on funding agreement and contingency allocation

Optimal governance, programme change control, risk management and reporting of an approved baseline scope will allow a business to manage risk, deliver value and drive programme and project decision-making while saving time and efforts. See Figure 4.8 and Figure 4.9.

Figure 4.8 Change management, risk management and reporting.

Figure 4.9 Ability to impact and commitment to the change.

Establishing and implementing a measurement and reporting system is a complex and evolving process based on the simple business principle that what can be measured can be managed. ‘Too much data, not enough information’ is a common complaint among business managers who have to keep track of the status of programmes while relying on information that is incomplete, out of date, inaccurate, late or simply irrelevant.

Reporting requirements will change as projects and programmes move from inception through their life cycles. It is important that the reporting system is designed to focus on metrics that matter at the relevant stage.

The critical success factors that underpin the operation of effective reporting are the following:

• Strategic objectives – Performance measures need to be aligned with the strategic objectives of the organisation. These objectives must be clearly communicated and understood by employees and external stakeholders
• Baseline management – The baseline scope, programme timescales, resources and budget cost for the approved brief are clearly and consistently communicated to all parties
• Work breakdown structure – A WBS is designed to provide a common basis for linking the scope of work, estimates, budgets, schedules, earned value progress, performance and cost reports, based specifically on the customer’s brief
• Progress management – As the programme progresses, the actual delivery times, resources and costs are recorded, analysed and compared to the baseline
• Change management – All changes from the original baseline are managed and incorporated into subsequent controlled copies of the original baseline called ‘the current baseline’. The current baseline is progressed to reflect the current situation and subjected to analysis
• Reporting – All baseline and progress information is collected, analysed and reported in a simple yet robust manner based around schedule, cost and quality performance reports, clearly communicating the status of the delivery brief to all parties, including the client

The measures that matter for effective control should be simple and reliable.

Key performance indicator themes should be reported and agreed upon by each functional area or, in leading global organisations, across a portfolio of projects or a programme to deliver strategic objectives. The indicators are then aggregated into project, programme and executive board reports to assist in meeting the needs for information, control and governance. As the programme progresses through its life cycle, the quality and availability of key performance data available to the different functions will develop.

Performance measures should be based on the key performance indicators that are most commonly associated with the built environment and include key objectives such as cost, time and quality.

Organisations will also seek to measure and report other success factors that align with their strategic objectives, such as environmental sustainability and corporate social responsibility themes. The importance of these performance indicators and measures will change as the capital projects and programmes move through the various stages of their life cycle (investment planning, design, procurement, manufacturing, construction, commissioning and operations).

Once this process is in place and data and information are flowing more or less painlessly, it is then down to management to trust it and act on it, as there is often no worse decision than no decision at all – even a bad one.

This trust will undoubtedly be reinforced by a level of checks at all levels of the organisation, or integrated assurance.

4.4.5 Issues management

As outlined in Section 4.4.3, issues management is an ongoing programme management function, akin to risk management. The programme’s approach to issues management must be clearly defined and endorsed by the PrgS, including the decision-making procedures.

The approach should include roles and responsibilities in relation to management of issues during the programme and may include the following:

• How issues will be flagged, passed up the hierarchy, recorded and assessed
• How issues will be monitored and controlled (both at project level and programme level)
• Who will generate the report and when, and who will receive the reports and determine action
• What will be the regular review points
• What will be the escalation procedures

Initial issues will have previously been recorded as part of the completion of the brief and the business case – the initial registers can be turned into the live issues register with assigned ownerships as the programme progresses.

4.4.6 Time scheduling

In its simplest form, a schedule is a listing of activities and events organised by time. In its more complex form, the process examines all programme activities and their relationships (interdependencies) to each other in terms of realistic constraints of time, budget and people, that is, resources. In programme management practice, the schedule is a powerful planning, control and communications tool that, when properly executed, supports time and cost estimates, opens communication among personnel involved in programme activities and establishes a commitment to programme activities.

However, it is not always practical or realistic to prepare a time schedule for programmes – in many instances there may be additional constraints (e.g. output delivery dates may be set by parameters beyond the control of the delivery team or a target may be set for commencement of benefits realisation for certain outcomes); it is often the case that, especially for programmes with intangible deliverables, while a realistic time schedule can be prepared for individual projects and activities, the overall programme time scheduling remains a bit of an unknown until the commencement of the implementation phase. However, almost all business cases will allocate a certain time for any programme even if only for funding purposes, and it is the responsibility of the PrgM to ensure that a detailed programme schedule is prepared at the definition phase identifying each individual component and that it is regularly reviewed for any variance. The PrgSB will be made aware of the variances through the programme highlight report and should decide on the appropriate course of action.

4.4.7 Financial management

Business today needs finance officers who understand how engineering and production processes are really managed to help with establishing:

• clarity in budget and contingency allocation between funder, programme and projects
• understanding of reporting requirements at corporate and programme level in order to prevent misalignment, inconsistencies and misinterpretation

Difficulties in aligning and reporting for business and programme purposes are not uncommon. Financial reporting normally spans a fiscal year, whereas programmes, due to their nature, may span a number of years. Additionally, financial and programme professionals do not necessarily talk the same language or have the same reporting needs.

Communication is the key aspect of prudent financial management. Opacity in budget allocation leads managers to make assumptions and decide on the basis of their current knowledge over time. Particularly on major programmes, it is of vital importance that meaningful and timely information is generated from the vast amount of data that would be available. Figure 4.10 sets out the individual roles of the key personnel in context of programme management at this stage.

Figure 4.10 Financial management roles and responsibilities.

Funding arrangements

Once funding arrangements, share of contribution, delegated authority and contingency allocation is apportioned and agreed upon to form a fund, a budget developed in parallel can be managed and its change controlled through the programme gates.

Budget, including contingency, can be represented by a WBS element using a tabular format or a bar chart as seen in Figure 4.11.

Figure 4.11 Programme budget for transport programme (example).

It is essential to capture baseline assumptions as part of a budget to allow for all parties to understand the associated risks. Assumptions will typically include: scope, design, construction, schedule, cost, inflation, currency, commercial, procurement, land and property, legal framework, operations, and asset management.

Changes and contingency management related to scope (schedule, cost and quality), including design development, valuation (value engineering), new scope, sequencing or acceleration cost (also known as de-risking in some programmes), cost savings or procurement and delivery model adoption (for example engineering procurement and construction as opposed to in-house delivery) can be identified and communicated using a waterfall or bridge diagram.

Waterfall charts⁴ are commonly used in business to show how a value changes from one state to another through a series of intermediate changes. Waterfall charts are often called bridge charts (particularly in financial jargon) because a waterfall chart shows a bridge connecting its endpoints.

4.4.8 Cost management

Traditional cost and performance measurement systems often fail to distinguish between cost incurred and physical progress made. Under these systems, it is difficult to analyse separately cost variances and schedule variances. One answer to this is earned value management (EVM).

There are two key primary objectives of an earned value system: (i) to provide programme project managers with a reporting system that gives them better control over cost and schedule management and (ii) to provide customers a better picture of the status of work. See Appendix T5 for a Monthly Programme Report template.

Cost performance indicators (CPIs) and schedule performance indicators (SPIs) are gaining popularity as performance measurement systems in the construction industry and are acknowledged to make a positive contribution to the planning and overall control of a major construction project or programme. CPI = 1 and SPI = 1 means the programme is on track.

CPI and SPI are the two principal components of EVM (see Figure 4.12) and allow project and programme to:

• Measure programme and project progress
• Forecast completion date and final cost
• Identify schedule and budget variances along the way

Figure 4.12 Delivery/project performance – programme EVM summary.

There are several secondary objectives for measuring CPI and SPI on projects across a major programme. These include:

• Providing a timely ‘early warning’ signal for prompt corrective action
• Comparing the amount of work performed during a period of time indicating whether the project is behind or ahead of schedule
• Comparing the budgeted cost of work performed with actual cost, indicating whether the programme is over budget or under budget
• Encouraging contractors to use effective internal cost and schedule management systems

By integrating these measurements, EVM aims to provide consistent indicators to evaluate and compare the progress of programmes and construction projects. EVM compares the planned amount of work with what has actually been completed to determine if cost, schedule and work accomplished are progressing as planned. Work is ‘earned’ or credited as it is completed.

CPI and SPI are not absolute measures of progress and should not be viewed in isolation. The indicators should be viewed in conjunction with other progress reports and performance measures such as monthly milestone and variance reports. The information is processed and published in progress reports on a monthly basis and, in conjunction with other project progress information, can be used by both the client and supplier(s) to monitor performance and encourage a greater degree of control and proactive decision-making.

To make a positive contribution, the measurement system is dependent on two key factors:

• Implementation and integration of a collective and accurate breakdown of the construction works that capture the planned schedule (time) and budget costs throughout the lifetime of the project or programme. This is referred to as the cost loaded schedule
• Implementation of a robust and rigorous system to regularly capture actual time and cost data in order to compare it with that planned

Programmes will also report an annual spend forecast (Figure 4.13) or fiscal year performance and provide long-term projections (Figure 4.14) based against the approved baseline. This should be aligned and coordinated with financial reporting.

Figure 4.13 Programme fiscal year performance (annual spend forecast).

Figure 4.14 Four-year programme cost projection.

Although a source of many frustrations, integration, as illustrated in Figure 4.15, is key to programme and financial reporting alignment and will drive accurate reporting and inform decision-making.

Figure 4.15 Reporting integration.

One method is to set up the main accounting systems to track cost and billings by WBS line item. Most ERP (Enterprise Resource Planning) packages will track inventory movements by item type or by project code.

Project- and programme-oriented businesses need to be able to relate the use of material and labour to one key ‘manufacture’ or ‘procurement’ item number at a WBS level, allowing:

• Meaningful comparison between the estimated or budgeted cost of work performed (BCWP) and the actual cost of work performed (ACWP)
• Real-time update of the estimates or standards for costs to complete against actual cost based on incurred costs

Best practice strategies for improved cost control include:

• Cost management planning
• Supplier involvement
• Value engineering
• Cost reporting
• Programme cost change management
• Cost forecasting
• Risk reporting

Financial management

Finance will control the programme expenditure at year end and monitor actual against forecast (AFC) expenses and budget. Profit and loss and balance sheets will be also compiled for business-reporting purposes and will include programme cost to date and any other additional costs outside programme control. (See Figure 4.16.)

Figure 4.16 Full year programme expenditure example.

4.4.9 Change control

As the saying goes, the only constant is change. At the definition phase, it is critical to ensure that a robust change control and management procedure is designed to enable formal identification, evaluation and decision-making required for accepting or rejecting changes to aspects of the programme.

Procedures should be put in place to manage changes, both at programme level and project level. Changes to scope, PDP, business case, benefits and budget will affect the overall programme and must be managed at the programme level.

Programme level changes must be signed off by the PrgSB and be managed by PrgM.

Typically, programme highlight reports should contain a change register.

4.4.10 Information management

Process and systems to be used for managing and storing information include:

• Programme level BIM system and process
• Responsibilities for issuing, distributing and maintaining information
• Archiving and retrieval protocols

Information management: sharing knowledge

At the heart of a programme is information and how it is communicated. Information has to flow within a programme in a way that will allow management, project managers and project teams to achieve business objectives while transparently keeping all stakeholders informed.

Communication is the process of transferring information from one source to another. Effective communication is a two-way process in which technical information, analysis, commentary and comments are conveyed through reports, speech and other mediums to a specific audience so that the intended audience will be informed, perform an action, or reach a decision based on this information.

The fundamental purpose of information management is to communicate effectively and with consistency relevant and accurate data to project stakeholders at all stages of the programme life cycle and beyond using effective information systems and models – BIM. The provision of good quality, timely information is an essential deliverable for any programme. Systems and procedures should be defined to enable effective management of information through the life cycle of the programme from inception to the delivery of operational assets. An effective information management system should facilitate direct relationships with the relevant information enabling storage and ‘retrievability’ of the following:

• Document ID
• Document location
• Document classification
• Document function
• Document status (cost and time)
• Document criticality and confidentiality

Integration

Integration is the combination and co-ordination of multiple sources of related information so that sources work together and form an ‘integrated’ whole with the ability to provide a snapshot of progress status at any chosen reporting milestone. The integration process will allow for interdependencies and design, procurement, construction, commissioning, departmental, organisational and supply chain interface issues to be identified and addressed from a single source. Key information (variance, exception) will be captured, assessed and forwarded to the relevant authority for a decision to be made and implemented.

The level of integration will vary from loose to tight integration depending on the current programme stage, agreement of a common purpose, set of objectives and level of process and systems standardisation. Programmes are usually carried out by a project team under the overall direction and supervision of a PrgM. In practice, there will be many variants of this structure, depending on the nature of the programme, the contractual arrangements, type of project management involved (external or in-house) and client’s requirements.

As the programme evolves, it is essential to strive for an integrated information repository to manage increasingly detailed information. All integrated programme assets or documents should be coded and linked to a programme database. In the context of a physical asset programme, BIM is a powerful tool that will allow a programme to be integrated in a multidimensional model created for management purposes.

In summary, programme management systems need good quality sources of information on which to base their decision-making and manage operations post-delivery. Management reports, project summaries, reporting systems and data will include the following:

• Programme and project costs incurred to date and current estimate also known as out-turn cost (i.e. how much will it all cost in the end?)
• Cash flow status on programme and project and estimated cash flow forecast for the remaining period of programme
• Earned value measures of schedule variance and cost variances for project work packages and overall programme
• Status of risk management actions in relation to the database of programme risk registers
• Estimates of risk and uncertainty remaining in the key elements of the programme

4.4.11 Communication/stakeholder management

The process developed for communicating with the programme team and stakeholders may include:

• Responsibilities for generating and for distributing communications
• Nature of communications to be issued
• Methods of communications to be utilised
• Stakeholder analysis
• Frequency of communications

Stakeholder identification and management

A stakeholder management plan aligned to business and programme objectives can be designed in six steps to communicate effectively to the programme audience and gain support along the way.

1. Define, restate and clarify objectives (link back to strategic change objectives).
2. Identify stakeholders, internally and externally.
3. Analyse and map stakeholders by proximity into top tiers, second tiers and so on.
4. Plan management of stakeholder communications and reporting.
5. Identify the right channels to effectively engage with your stakeholders.
6. Monitor progress in stakeholder engagement, persuasion and advocacy levels against a programme timeline.

Defining stakeholder segments starts during the strategy and programme definition phases.

Programmes and organisations need to be able to identify their stakeholders and assess the level of impact they will have in meeting the objectives and outcomes of the programme. A first stage for this process will be to create a stakeholder proximity map. This map will lay out different tiers of stakeholders according to their potential to affect the reputation or the progress of the project or organisation, with the programme at the centre.

Stakeholders will be identified, captured and mapped for proximity to the programme in terms of direct impact or interest, influence and control in the programme landscape, based on the following questions.

• Who makes up the most important tiers of stakeholders for this programme?
• How great is their impact on the programme progress or reputation?
• How great is their influence on other important stakeholders, for example those who control resources?
• What is their level of engagement in the present time: are they in favour, against or indecisive?
• How easily can they be influenced, persuaded and brought on board as long-term advocates and supporters, especially in times of issues and crises?

Once the stakeholder map and landscape is understood, a tracking tool articulating what reengagement activities are required for each stakeholder will allow tracking progress. The tracker will identify the stakeholder relationship owner in the programme – a person accountable for managing and directing the stakeholder relationship.

Making the link with the communication team

It is a common experience in a professional’s life to have the urge and necessity to communicate a message that, at that time, was thought to be right, needed to be communicated without delay and needed to be communicated to a group of colleagues and line managers. It is also fairly common, with the benefit of the hindsight, to think about an e-mail that has been sent and should not have been. If this communication is scaled up to a very large organisation and programme and the way this message communicated the message is considered, particularly in times of critical decisions, the importance of clear, efficient, effective and appropriate communication can perhaps be put in some context.

In simple terms, communication is the process of transferring information and knowledge from one source to another.

Effective communication of the relevant information is a two-way process in which data, evidence, analysis, commentary and feedback are conveyed through reports, speeches and other media to a targeted audience to perform an action or reach a decision based on this information

Once the stakeholder audiences are defined, it is paramount to define a set of key messages and positioning statements to address these audiences in their questions, concerns, and other key requirements. A series of pre-defined lines to adopt should also be prepared and ready to use, especially in cases of crises or issues. It is important that messages are continuously updated and aligned with the programme’s variables or changing milestones.

Communications strategy and management

A good communication strategy and plan will ensure that the programme audience is informed in a targeted and timely manner.

Based on the stakeholder analysis, the communication plan will list the messages and interventions to be communicated to which audience group, when, how (medium), why and from whom.

Communication mediums can be categorised as high or low impact and commitment building and will include:

• One-to-one coaching or small-group workshop
• Intranet, social network, knowledge transfer
• Large group, conference
• User guides, reminders, online help

Key communication principles include the following attributes:

• Benefit led
• Messages that pinpoint the benefits that are relevant to stakeholders
• Timely, accurate, up to date, regular and consistent
• Appropriate in language and media for stakeholders and staff
• Whenever appropriate, use existing channels
• Encourage two-way dialogue and feedback

4.4.12 Quality management

The method and responsibility for assessing the ‘fitness for purpose’ of the project outputs, outcomes and programme deliverables will need to be defined. This might be through specifying the acceptance criteria and/or the performance criteria. For programmes with tangible deliverables, for example, a new facility, it is relatively easier to define the quality acceptance criteria; where programmes include intangible deliverables, it may be necessary to rely on secondary assessment methods to quantify acceptance or performance criteria.

It is advisable to introduce periodic reviews of the quality management procedures at key stages of the programme life cycle to test the adequacy and the effectiveness and enable any changes or amendments as necessary.

4.4.13 Procurement and commercial management

Procurement is the process by which the resources (goods and services) required by a project are acquired. It includes the development of the procurement strategy, preparation of contracts, selection and acquisition of suppliers, and management of the contracts.

The benefits of contracts and procurement are that:

• A project in which procurement is aligned with the programme deliverables is more likely to meet its objectives
• Procurement often represents a major portion of project spending and hence needs careful consideration to ensure value for money is realised
• It ensures that all parties involved in the project are legally protected

Effective procurement and contract management is core to a successful programme. The procurement policy, procedures and processes should be established to guide the procurement of a range of contracts and projects.

It is important for companies to develop purchasing policies and procedures that include the following:

• Supply chain management
• Strategic partnerships
• Market knowledge
• Cost reduction
• Sustainability

Based on the above, managers will develop a ‘contract packaging’ approach which will break down the entire programme of work for delivery into suitable elements for procurement. This will be refined in discussion with the potential suppliers and contractors. To meet the programme objectives, on time and in the given budget, often managers will procure a large number of contracts and projects of varying size and value.

A robust, fair and transparent approach to procuring, managing and monitoring these agreements is essential, as is carefully managing the risks associated with the overall programme and related projects. A programme will often have to operate in the procurement framework set out by international procurement legislation and national regulations.

For major programmes, it is also recommended to give advance notice of contracts through a ‘future opportunities’ website – the equivalent of market building for supply chain members – and adopt e-tendering practices.

To operate effectively in the marketplace, programmes will use standard procurement documentation and contracts such New Engineering Contract (NEC)/Fédération Internationale Des Ingénieurs-Conseils (FIDIC) and CIOB’s.

Managers will award contracts according to broader objectives and values. Ahead of every contract competition, programmes will develop a ‘balanced scorecard’ of selection and award criteria that will inform companies of the commercial and technical factors their bids will be scored against. This should include time, quality, safety and security, equalities and inclusion, sustainability and legacy.

Appropriate criteria will be added and different weights applied to each criterion on a contract-by-contract basis, according to the nature of the goods, services or works being procured and best practice guidance from the Office of Government Commerce. To avoid costly and time-consuming disputes, the programme should seek to make clear agreements with all parties while agreeing and managing contracts.

Best practice suggestions to manage the risks in this area include:

• Developing a procurement plan
• Establishing vendor selection criteria
• Having an overall buying strategy for negotiation
• Establishing quality-control procedures and a set of performance measures.

Key performance indicators to measure the performance of the procurement or buying processes include:

• Unit price for comparison
• Total cost of supply
• Number of suppliers
• Average purchase order size
• Number of contract out, placed or closed
• Value of contract placed
• Satisfaction indices

Figure 4.17 illustrates an example of progress of procurement and commercial management presented graphically.

Figure 4.17 Invitation to tender (ITT) and signed outline contract (SOC) plus value of contract placed.

Resources management: building a team

Managers need to ‘design’ their organisations and programmes to embrace change and deliver programmes effectively.

The following criteria will need to be considered in order to design and agree on resource profiles that are fit for their purposes and align with the delivery model so that the right level of resources are allocated to a programme at the right time:

• Work breakdown structure (WBS) – a key tool for efficient and effective resource allocation to create resource profiles for delivery
• Scope/size – Bill of quantities (BoQ) and work packages; scope definition, including a hierarchical list of materials, components, assemblies and sub-assemblies required to make a manufactured product
• Organisation breakdown structure (OBS) and organisational policies: Structure and a clear statement of company policy on key areas such as staffing, subcontractors’ issues and procurement policies
• Benchmarks and historical information. Information from past records
• Team experience and clear roles and responsibilities (using a RACI model) within a programme and down the supply chain with appropriate level of “man marking and risk transfer”

The above criteria will depend on the delivery model adopted, but leading PrgMs focus on building an intelligent client organisation to lead delivery and maintain the right level of control. This is a key factor in successful cost management. It needs to be established at start of programme so that appropriate resources are allocated. Where necessary, certain elements may then be outsourced, subcontracted or bought according to a build or buy model.

4.4.14 Health and safety management

Programmes will need to formulate health and safety management policies and procedures both at the project level and the programme level. It is the responsibility of the PrgM to ensure that at the definition phase the health and safety goals, requirements and procedures are set and that the processes are put in place to transfer these to the project levels as necessary. In some instances, specific key performance indicators or targets may be set to measure performances both at the project level and the overall programme level. It is advisable to also set specific review stages to assess whether the health and safety management policies and procedures are performing as desired across the programme.

4.4.15 Sustainability/environmental management

It is often said that sustainability is essentially not a methodology but a dimension of thinking. The perception of sustainability is shaped by people’s values, behaviour, attitude, ethos and interaction with the wider environment. Programme management is concerned more with outcomes than outputs. With emergent input in a changing environment, a PrgM makes use of current information to identify options for comparison and decision. Once the decision is made, the PrgM will take over the project(s) where sustainability is a consideration. In other words, for sustainability in programme management, the PrgM emphasises the learning loop leading to the preferred options: the PrgM has to assess the suggested programme options in the dimensions of economic sustainability, environmental sustainability, and social sustainability before recommending the options. In most cases, the organisation commissioning the programme will have sustainability and environmental management policies at a wider level or, indeed, may have certain aspirations and targets specific to the programme. The PrgM must ensure that the goals and targets, as necessary, are defined and translated to procedural requirements at the project level.

Notes

1 WBS stands for work breakdown structure, a hierarchical and incremental subdivision of elements necessary to achieve the end objective.

2 Definition obtained from ISO 31000:2009 – ISO guide 73.

3 OECD Principles of Corporate Governance (2004), OECD, Paris. Available at: http://www.oecd.org.

4 A waterfall chart is a form of presenting the data in a visual manner that helps make it easier to understand the cumulative effects of positive and negative values in sequence.