Tasks for Programme Manager >

Create an idea document for evaluation.

There should be an impact assessment on the Corporate and other strategic plans, including the portfolio plan.

There should be an assessment of impacts of changes in  external factors, such as legislation, external funding, partner organisations.

Identify and make initial assessment of risks to the idea.

Identify potential risk impact on other parts of the portfolio.

Identify risks – discuss with key stakeholders. Consider holding an initial workshop involving key stakeholders (those promoting the idea, those who will have to implement it, those running the service area affected), to identify and capture key risks associated with the idea.

Also, remember to look at potential risks to other projects or activities that this new idea might create

Look at how risk are shared with funding or partner organisations – has the right mix of risk and reward been achieved in the proposal?

Assess risks – estimate cause-event-effect, evaluate probability, impact, and proximity.

Make an overall assessment of the “riskiness” of the idea (if appropriate, do this for each participating organisation too), which should be included in the business case alongside the costs and benefits to enable an overall judgement of desirability to be made at Decision Gate 1.

Identify the resources that will be required to deliver this idea in the timeframe.

Identify likely level and type of resources required to implement the idea.

Identify potential resource clashes with other ideas/programmes/projects.

Identify any specialist or technical resources needed, and where they will come from. Assess whether they are available within the organisation or will they have to be procured. Ask whether partner organisations involved with the idea have resources that can contribute.

Evaluate the organisation’s capability to take advantage of this idea, even if it is attractive. 

Estimate costs and prepare outline business case.

Start to create high-level costs and benefits for inclusion in the strategic business case going forward. At this initial stage, it is probably just guess work so use ranges and factor in optimism bias. If this is something that has been done before, try and find information to help with cost estimating.

Factor in costs and benefits for other organisations.

Assess affordability – is the money available to invest in the idea?

Create an idea document for further evaluation.

Record idea into log and evaluate details.

There should be an impact assessment on the Corporate and other strategic plans, including the portfolio plan.

Sources of internal ideas are likely to come from process, people, technology or management information changes, it is useful to consider the whole impact of the idea against these headings.

Identify and make initial assessment of risks to the idea.

Identify potential risk impact on other parts of the portfolio.

Check the risks, the could be positive or negative and consult with key stakeholders who may have a view,  a workshop on developing the idea should consider the risks that could come about.

Also, remember to look at potential risks to other projects or activities that this new idea might create, there will certainly be knock on effects somewhere.

Make an overall assessment of the “riskiness” of the idea, which should be included in the business case alongside the costs and benefits to enable an overall judgement of desirability to be made at Decision Gate 1. The Strategic Assessment Framework should be able to address this.

Identify the resources that will be required to deliver this idea in the timeframe.

It would be helpful to estimate the likely level and type of resources required to implement the idea.

If there are potential knock on effects of resource clashes, these should be recorded as risks to this idea or other initiatives already running.

Identify any specialist or technical resources needed, and where they will come from. Assess whether they are available within the organisation or will they have to be procured.

Can the organisation’s capability to take advantage of this idea, even if it is attractive. Over optimism is often the root cause of failure so now is the most cost effective time to check for optimism bias. 

Estimate costs and prepare outline business case.

Start to create high-level costs and benefits for inclusion in the strategic business  case going forward. At this initial stage, it is probably just guess work so use ranges and factor in optimism bias. If this is something that has been done before, try and find information to help with cost estimating.

Assess affordability – is the money available to invest in the idea?

Develop an outline time scale for the plan.

Provide an overview of how long this is likely to take and check for lessons learned.

The mind map should provide what is required; from this a basic plan may be possible.

At this stage it is probably only going to be a guess, but there may be other examples of similar projects that you can base it on.

Clarify the obstacles that will be faced.

No change will be plain sailing, so it is important to record the challenges as risks and prepare for any potential issues (problems) that you will face.

Issues are problems you know you will face, risks are less predictable and you will need to think about them, better now than later.

At this stage, a simple list of obstacles  is sufficient.

Identify what effort will be needed to develop the project proposal.

At this early stage you should think about what resources will be required and the type of skills that will be needed to deliver the idea.

Identify who will need to be involved and how much of their time will be needed.

Present  an outline  estimate of the types and numbers of resources that will be needed so that the overall impact is clear.

Identify likely costs of the project.

It is necessary to have some idea of the costs so they understand what they are committing to.

Outline details on costs that may be available.

It will be recognised that these are only rough estimates but it is always good to have some figures on which to assess the value of the investment.

Further develop the information provided in the ideas template in preparation for workbook completion in the next process.

Ensure the risks to the idea are documented in the risk register.

Ensure the main control, which is currently the mandate, sets out the scope and timescales for the work.

Controls themselves may be informal up to this point but once the board has met then formality around supporting the board and establishing timescales and decision processes should be in place.

The Risk Assessment should be reviewed by the board to ensure that no risks have been missed or wrongly assessed.

The individuals on the board should have a terms of reference based on your organisations governance model.

The availability of the board and any individuals they include in the process should be tested and estimates of their time made.

Carry out early work on identifying where the costs are likely to come from.

The selection of the governance model may provide an indication of the route that is being taken and therefore provide an insight into the funding source.

Design the governance model based on your organisations standard model.

There is a standard model for programme and project structures that should be applied. There may need to be adjustment, liaise with the PMO to check how this can be achieved.

You should also update the Brief documentation to reflect the governance model.

Place the brief under version control once agreed.

Identify issues and include them in the issue log.

Define the control arrangements for the initiative.

Define the assurance plan for the next stage.

The direction of the initiative is becoming more formalised and the controls need to become more formal. It could be a new programme, a project within a programme or a standalone project, so the controls will vary depending on the risk profile

The scope and exclusions should be defined and the formality around project controls should now start to integrate with the programme.

If appropriate, project reporting and monitoring into the programme should begin at this point.

The Vision should be cross referenced against corporate objectives to ensure alignment, it may be appropriate to mention corporate objectives in the vision to help with context.

An assurance strategy should be defined at this point.

Ensure known risks linked to the initiative are logged.

Ensure strategic risks are included in the brief.

Review aggregating effect of project risks if it is a programme.

The brief offers opportunities to head off resistance by including clarification, equally avoiding key issues may avoid early resistance but this may return to haunt the programme.

Acknowledging major risks in the vision will help the audience appreciate the reality of what is being aspired to.

Watch out for aggregating project risks that a common across the programme as these may be better managed at the programme level.

Programme level risks are principally associated with:

• Strategic alignment
• Levels of operational change
• Inter programme dependencies
• External events beyond the programmes control

Suitable skills to undertake the analysis of the requirements and should be allocated.

Any specialist skills specific to the type of change may need to be externally sourced.

There are some specific resources that will be required to complete the next stage.

There are likely to be a lot of facilitated workshops and senior management engagement to gain commitment to a vision.

In terms of resource, a key element will be knowledge, about how the organisation works, the business strategies and the ultimate outcomes.

At the completion of the brief there should be a resource plan for the stage but the view of the wider programme or project will not be clear until later.

The case for change should be evident in the vision and the brief.

Headline estimates of major costs should be included in the brief.

The Vision Statement will be a key consideration when evaluating options, as the Business Case completes.

Ensure that the final version of the brief is ready for sign off. 

If the project is being run external of a programme then the control arrangements will need to be put into place.

You will need to facilitate the work to get everyone aligned and signed up to the Vision Statement and brief, maintain version control and an audit trail of processed comments so if there is a need to re-visit this area there will be useful lessons and reference information.

The programme or project brief should completed with as much detail as possible.

Ensure that:

• the appropriate scaling of controls has been undertaken
• the scope of the change has been clearly defined
• there are internal controls in place to cover issues and change control and
• quality and testing arrangements have been defined.

There should be an up to date Risk Register in your organisations format. 

The risks listed should reflect both the short and long term risks. The risks should be related to delivery and the impact on the areas that will be affected. The risk profile has been updated and is still acceptable.

Develop a resource plan, based on the planning estimates.

There are development activities planned to establish and develop the delivery team. The team has the right level of knowledge and skills based on your organisations professional development framework. Procurement guidelines are being followed.

Ensure the cost estimates have been captured and are captured in the brief.

The cost estimates are sufficiently extensive and there is a risk rating associated with them. There should be justification for a ‘Go’ decision into programme or project definition.

Receive the recommendation from the review, provide any additional information and ensure the schedule to address recommendations is agreed.

You may well need to support the Project Executive with presentation material if they have to present to the Portfolio Board, or additional information about the project.

Once completed the PMO will advise the result of the gate and any issues or recommendations that will need to be dealt with.

Ensure investment decisions and commitments balance the use of portfolio budget.

Ensure expenditure is properly recorded and reported through Highlight reports.

The portfolio needs to get the “biggest bang for its buck” and limited resources must be used to maximise benefits. Good business cases are essential to enable choices between competing initiatives.

It is important that the current position is accurate and up to date. Overspends and underspends present threats and opportunities and need to be managed.

Assess the overall financial risk profile of the portfolio.

Ensure this is monitored through regular risk reviews at project, programme and portfolio level.

Ensure risk capacity and risk appetite are defined and communicated and that the mechanisms for financial evaluation are effective.

Look out for the cumulative effect of risks, and for secondary risk arising from actions and decisions are being valued.

Stakeholders have different perceptions of risk, and can help identify risks and possible solutions and funding options.

Create a resource plan showing profiled use of staff and other resources.

Resource constraint can affect delivery. External, specialist resources can be expensive and hard to acquire. Ensure resource requirements are fully costed and included in business cases and plans.

Create a portfolio level financial plan showing profiled capital and operating expenditure budgets and forecasts.

Decide how much financial contingency to retain at portfolio level.

Financial contingency is a reserve to address cost escalation on current programmes and projects and to fund new initiatives.

The corporate financial accounting systems should be aligned with the portfolio accounting to ensure that overarching controls are in place.

Ensure decision making and highlight reporting focus on benefits.

Check that the information being used for decision making is validated.

Assess whether outcome is sufficient in relation to the current strategic objectives.

The portfolio needs to get the “biggest bang for its buck” and limited resources must be used to maximise benefits. Good business cases are essential to enable choices between competing initiatives.

Business cases should be kept under regular review to ensure that benefits still remain relevant and achievable.

Projects should be considered for premature closure in favour of other initiatives if their contribution to benefits or return on investment is insufficient.

The management controls associated with benefits delivery are often weak, which leads to change being avoided. It is critical that there is objective monitoring of controls across the portfolio to ensure that all projects and programmes are aligning their plan to deliver benefits.

Establish risk appetite. The risk appetite for the portfolio should be reviewed for impact on benefits achievement.

Test that the risk profile of the benefits is realistic and being updated.

The level of risk associated with the benefits forecast at project, programme and portfolio level should be monitored.

The portfolio is likely to contain a balance of projects with different risk profiles (i.e. some high risk/high reward as well as some low risk/low reward projects)

The risk appetite will affect the ability to gain benefits. So if there isn’t an appetite to deal with big risks such as public opinion, then the ability to achieve risks will be reduced.  Consequently the risk appetite should be a driving factor in the level of ambition attached to benefits.

High risk benefits should be monitored closely.

The resource management plan should align with the benefits realisation plan.

Resources must be allocated in line with portfolio priorities and decisions to the projects delivering the greatest benefits.

Ensure that investment is balancing the short, medium and long term returns on investment.

Business cases should include a cost/benefit analysis to support investment appraisal and decision making. Cost/benefit analysis should be used to ensure the projects with the best rate of return are selected for investment.

Decision criteria should reflect need to achieve or retain statutory compliance.

Regular progress reporting should identify and track compliance projects.

Compliance projects – those needed to achieve or retain statutory compliance – are often time dependent (for example, implementing new legislation to a set timetable such as the Care Act 2014).

Compliance projects may need to be given priority within the portfolio.

Ensure risks of non-compliance are captured.

Compliance projects can be implemented in different ways that have different risks within the options. Investment appraisal should consider the relative risks (threats and opportunities) for different implementation options.

Ensure that adequate resources are being dedicated to changes that may impact on compliance.

Confirm that suppliers and partners understand the compliance issues.

Compliance projects often have priority within portfolios. Once the priority is established as part of overall prioritisation, resource allocation should be actively managed to match the priority of the compliance project.

Financial diligence and transparency of investment decision should be reported as part of compliance.

Compliance projects can be implemented in different ways that have different costs. Implementation can often incorporate other benefits (e.g. streamlining existing processes, IT solutions etc).

Regular progress reporting should include business change plans.

Check business outcome achievement against Enterprise Architecture.

Agreed portfolio reporting processes should be used to deliver consistent, accurate, timely reports of progress.

It is important that the integrity of the current and future Architecture of the organisation are maintained, otherwise gaps and overlaps may appear and the organisation will not operate efficiently or effectively.

Review the risk profile relating to the rate of business change.

Check the overall risk profile of the portfolio and review on a regular basis.

Check for root causes that are undermining the rate of change and revise mitigation plans.

Assess effectiveness of dependency identification and management.

Encourage and reward an open culture in which everyone is encouraged to report, raise and discuss risk at all levels. Suppressing risks benefits no-one. The earlier risks can be identified, the better the chance of addressing and overcoming them.

Deep dive exercises can help identify root causes of risk. Use the “cause-event-effect” formula to get a deeper understanding of the root causes.

Failure to identify and manage dependencies effectively can lead to significant delay and cost escalation within the portfolio. Regular communication across the portfolio will increase visibility and enable improved performance.

Regular reporting against the resource management plan.

Check that the level of operational support is adequate.

Check that the organisational capability to deliver the changes is adequate in the portfolio.

Focus on blockages, conflicts, scarce or expensive resources.

Operations needs to contribute throughout the change process. This is on top of day-to-day service delivery. Lack of operational capacity to contribute to change is one major reason why changes are not effective and fail to realise the intended benefits.

Review the progress against the financial plan on a regular basis.

Review the performance against business cases.

Check that the financial projections adequately cover the investment in change management.

Review should include spend against budget, cost overruns and cost escalation as well as underspend.

Regular review of performance against business cases will help identify trends and improvements in financial forecasting and business case development.

Implement the revised controls for the closure stage.

Review the project control effectiveness and include in the closure report.

Review the programme control effectiveness and include in the closure report.

Review the business performance and change control effectiveness and include in the closure report.

Undertaken impact assessment of programme closure and ensure residual activities have a handover transition plan.

A formal review of documentation will need to be scheduled to ensure that the Information Management Strategy and Plan have been complied with.

Preparations for handling information that has legal implications will need to be undertaken to ensure compliance and archiving obligations are met.

Formal Programme Review needs to be scheduled to ensure that there is full recognition and documentation of lessons learned (both positive and negative). It is important that the Critical Success Factors that were set at the outset of the programme are included in the review.

As part of the closure, there should be a formal review of the programme and the way it has performed.  The areas that it should look at, apart from the reviews specific to other Themes, would be:

• the effectiveness of HR management by the programme team
• the delivery of coherent outcomes that met the final business needs
• how the programme remained aligned to evolving business strategy and environment
• quality and efficiency of the processes used
• alignment with corporate governance and legislation
• lessons have been learned and acted upon along the way
• quality and effectiveness of internal strategies and controls
• effectiveness of supplier management
• quality of project management
• quality of business change management
• achievement of the programme Critical Success Factors.

Identify and allocate mitigation actions for risks that will be created when programme is closed.

Ensure that existing risks have owners post programme closure.

Update Corporate risk team on residual risks.

Review programme risk effectiveness.

Include risk lessons learned in the closure report.

The Issue Log will need to be reviewed to identify which issues can be resolved by the programme, and which will remain once the programme has closed. A plan for bringing early resolution or passing issues to another body needs to be put into place. Ownership of risks that will remain after the programme closes will need to be considered.

Release resources from the programme.

Provide debriefs and feedback to individuals.

Hold lessons learned sessions with suppliers.

Archive individual and supplier performance data.

Archive lessons learned relating to resource management.

Handover of physical resources used during delivery back to owners.

The scale of this will vary depending on the maturity of the programme when it enters closure.

If the programme has followed the delivery strategy and the tranches, this should be a gentle landing with a structured shut down of resources in line with the original plans.

If the programme is shutting down prematurely, the situation could be far more complex.  There may be long term contracts in place that will need to be managed.

Staff expectations and morale are likely to be impacted by an early shut down as well.

Organise audit reviews of financial compliance.

Ideally the Business Case will have been satisfied now. If it has not, then the programme may be closing early, possibly due to the lack of funding or that the benefits were not achievable. Formal auditing of the programmes budgets should be scheduled.

Organise the governance for project that may continue beyond the programme closure

Closing the programme is likely to be a project in itself as there will be a lot of information reviewing and closing documentation. You may need a different skill set to the team that delivered the programme. It is important that a good quality Closure Plan is developed, as this will ensure gaps do not appear and critical tasks are undertaken. Finding suitable resources to support the reviews will normally require you to cast your net broadly and you will need the help of the SRO and BCM to find the contributors.

Release controls and realign any residual activities in projects to a new programme or other governance.

Ensure that all information is reviewed and handed over to corporate governance groups.

Ensure all programme issues are now closed or handed over to operations or other programmes or projects for management.

All programme documentation should now be archived and stored in accordance with Corporate and Legal requirements. All project documentation should be archived along with the programme documentation.

Ensure risks have a post programme action plan.

Both the Risk and Issue Logs should be reviewed and closed off.

It may be that some organisational risks have been owned by the programme during its lifecycle.

These now need to be handed over with ownership and mitigation plans put into place.

There are likely to be outstanding issues that may still exist when the programme closes. Not being able to resolve or transfer ownership may lead to delays. A review of project closure reports should be undertaken to ensure there are no outstanding follow on actions or legacy issues and problems that ownership has not been found for. A review of the effectiveness of the Risk Management, Issue Resolution Strategies and supporting processes should be part of the formal Programme Review.

Release resources and ensure compliance to governance requirements.

Release all staff from the programme.

Return all physical assets.

This step is straight forward - all programme resources, physical and human, should now be allocated to other programmes or work.

Programme information relating to resource management should now be archived in line with governance requirements.

Audit financial expenditure and close budgets.

This should be done at the end of the closure activities, as the work on reviewing benefits and capturing the full costs of the projects needs to be undertaken first. It is advisable that there is a formal review to check that financial controls have effectively been applied and lessons learned, particularly in the area of scheduling of funds and the challenges and opportunities that have come from this. The Business Case should be formally reviewed, accounting systems and budgets closed down.

Ensure programme assets are based to appropriate ownership.

You may well have your mind on your next challenge, but the quality of a well-managed programme can be judged by its legacy to the organisation and its stakeholders. As such, you need to apply maximum rigor to delivering a good closure, your reputation depends on it!

Finalise documentation and hand back to Portfolio Office

Ensure outstanding issues are passed to a new owner

Ensure no outstanding dependencies exist

Archive all information relating to the programme controls

Release controls team

Lessons learned should have been distributed to other programmes and projects. Programme information should now be secured and archived.

Formalise handover of existing risks to relevant authorities

Evaluate effectiveness of risk performance of the programme

Close the risk register and hand over to the portfolio office

Residual risks should now be actively managed within the organisation’s standard risk management processes.

No issues should remain - they should have been handed over to the operational groups, organisational governance or other programmes or projects to resolve.

Release programme staff from the budgets

Ensure HR policies are compiled with as a part of the staff release process

Close resource provision contracts with external suppliers and provide feedback on their performance

Formalise the evaluation of the business case

Close down programme relating budgets

Ensure residual budgets are dispersed or returned

Operational budgets should have been adjusted to reflect economic benefits (savings) and operational budget changes.

Close out documentation and place in archive

Assess whether outcome is sufficient in relation to the current strategic objectives.

Check for adjustments in benefits achievement. Feed changes into next strategic portfolio review.

The management controls associated with benefits delivery are often weak, which leads to change being avoided. It is critical that there is objective monitoring of controls across the portfolio to ensure that all projects and programmes are aligning their plan to deliver benefits.

Initiatives should have a clean, controlled finish. As part of demonstrating the value, ensure that reporting comes to a controlled end.

Project or initiative may have delivered in full, exceeded or fallen short in benefits delivery. Ensure the outcome feeds into the cyclical portfolio reviews to provide an accurate starting point.

Post Implementation Reviews are important to track benefits and learn lessons that can be applied to improve overall performance.

The risk appetite for the portfolio should be reviewed for impact on benefits achievement.

Confirm that the all benefits have the right risk rating associated with them.

Assess the impact of specific risks on benefits achievement.

Ensure the opportunity management activities are identifying new benefits.

The risk appetite will affect the ability to gain benefits. So if there isn’t an appetite to deal with big risks such as public opinion, then the ability to achieve risks will be reduced.  Consequently the risk appetite should be a driving factor in the level of ambition attached to benefits.

Each benefit in the programme and projects should have a risk calculation, this will be contributing to your benefit calculations, the application of the risk rating will be affecting the benefits valuation at the project.

There may be specific risks in the portfolio that may be causing a major problem in terms of benefits release, as such, these need to be re-evaluated and new mitigation plans put in place.

Ongoing benefits realisation and other post-project activities will contain a review of benefit related risks.

Analyse the resource consumption to ensure the optimal achievement of benefits.

Update resource plans to reflect lessons learned from change and operational team activities needed to release the benefits.

These should have been identified in the business case.

Some recurring benefits will not require further resources. Other benefits will require specific actions and effort, and the necessary resources must be planned and available.

It is possible that the cost of resourcing benefits has been underestimated, which is leaving benefits undelivered OR they are cost more than anticipated.

Check financial benefit forecasts for reliability.

Check that there is no double counting of financial benefits in the accounting processes.

Ensure that operating budgets are reflecting  changes to the cost base.

Ensure forecast benefits beyond the life of the programme or project are in line with the business case, and that the budget holders are clear on what is happening.

For cashable savings (eg reduced staffing levels) or increased revenue forecasts, adjust current and future budgets to reflect forecast benefits profile.

Where is identified that there are deficiencies in the accounting or calculation processes and guidance, then the business case procedures and documents will need to be amended.

In extreme cases, all business cases may need to be reviewed.

Inform corporate finance, so that future BAU budgets and strategic financial planning reflect portfolio benefits and avoid double counting or overlook benefits.

Place the vision under version control once agreed.

The Vision should be cross referenced against corporate objectives to ensure alignment, it may be appropriate to mention corporate objectives in the vision to help with context.

Ensure known risks linked to the vision are logged.

Vision Statement offers opportunities to head off resistance by including clarification, equally avoiding key issues may avoid early resistance but this may return to haunt the programme.  Acknowledging major risks in the vision will help the audience appreciate the reality of what is being aspired to.

Suitable skills to develop the vision into the operating model should be identified

The case for change should be evident in the vision.

The Vision Statement will be a key consideration when evaluating options, as the Business Case completes.

Ensure that the final version is formally signed off

You will need to facilitate the work to get everyone aligned and signed up to the Vision Statement, maintain version control and an audit trail of processed comments so if there is a need to re-visit this area there will be useful lessons and reference information.

The programme blueprint should now be put under version control.

Initial gap analysis on the alignment of any existing projects.

Confidentiality of the analysis and content of the blueprint content should be established.

Identify dependencies between the blueprint and existing projects.

Ensure audit trails of the blueprint development are maintained.

The management controls should ensure that the options in the blueprint stay within the boundaries and scope set for the programme and that there is a managed and controlled approach to reaching decisions.

The blueprint should be validated with the vision to ensure consistency and that it will meet the objectives that have been set.

Any issues that are identified during the blueprint work should be included in the programme issue register or allocated to projects.

In multi programme environments there should be a check for Blueprints overlapping and avoidance of duplication and conflict.

The Blueprint should now be under version control.

There may be issues that impact on the project which will need to be communicated and managed as a result of the definition of the blueprint.

Ensure risks associated with each option are clearly documented.

Analyse any new operational risks identified in the gap analysis.

Prepare mitigation plans for new risks.

This stage should remove some of the ambiguity about some of the risks but it may identify new ones as well.

Additional detail comes out of the evaluation and selection of the blueprint future state, meaning there should be a lot more information available to analyse and profile individual risks in the documentation, so overall, the level of risk should reduce as the understanding increases.

The output of this work may mitigate some risks; this should be factored into the development work.

There are likely to be high and low risk options that will need to be considered. Where information about current performance is missing then this will increase the risk for the programme.

Deploy specific resources with Blueprint and analysis experience.

As the analysis of the end and intermediate states are developed, each will have an impact on the volume and types of resources that will be required.

When thinking about resources, it is worth remembering that it isn’t just people, there may well be assets and technology that will be needed, including information.

There are two resource plans to be thinking about:

1) To reach the completion of ‘Define the Programme’ and ‘Design the Programme’, and

2) The resource management strategy for the entire programme, which is formally defined in the next stage but needs to be on the radar now.

High level cost estimates should be available.

The costs of achieving the various options should be estimated and considered as part of options appraisal.

Focus on co-ordinating the work of the various specialist and business groups.

You will need to facilitate this activity and organise any specialist input, e.g. IT or HR. You also need to do the work to pull that documentation together, but the responsibility for the content sits with the BCMs, your role in this is principally co-ordination and conflict resolution. There may also be key requirements developing which apply to all Blueprints.  These need to be captured and base-lined.

Define how each project will contribute to the operating model

The criteria for culling projects should be set, with systematic analysis and alignment being undertaken.  An independent check of each of the existing projects to assess their status and performance will help inform the decision making.

Re-assess the risk profile based on the changed dossier

Culling of projects without proper understanding of value and impact may have long term implications for the programme, positive or negative. As such, these should be recorded as risks.

Re profile the resource plan for the projects

Review project budgets to aggregate Business Case costs

Expenditure on projects avoided should be built into the Business Case and identified as an early benefit. Funds from closed projects can be used to resource priority initiatives.

Lead the reconfiguration and existing project and new requirement for the blueprint

You should lead this activity and undertake the systematic analysis of the ongoing need for the project. Closed projects will provide you with much needed resources. You will need to set out the criteria and weighting schemes for projects continuing and those that will be culled.  There will also be others that need to change direction. Establishing your credibility with Project Managers will be important, as they are likely to resist changes to their projects if they don't know what the future holds for them.

Define how each project contributes to the Blueprint.

Refine existing project plans to meet the Tranches and raise change requests for projects.

Tranche plan should be placed under version control.

Inter dependency network should be updated.

Impact assessment on assets.

The Tranche plan will define the programme controls points where stop go decisions can be made, so these must be optimised to enable control at the right points.

Different tranches will probably need different types of controls, so the Tranche plans should define how the control arrangements change.

Changes to projects should be managed as issues and delivered under change control and tracked by the programme.

Any existing physical assets that may be affected by the programme delivery will need an impact assessment to understand the implications on services and service contracts.

Projects may need to stopped, so the criteria for culling projects should be set, with systematic analysis and alignment being undertaken. 

An independent check of each of the existing projects to assess their status and performance will help inform the decision making. 

Tranches should be aligned to any external major events that the programme may contribute to and be aligned with work going on in other parts of the organisation.

Tranches should be used to reduce risk where possible.

Define how the tranche plans will affect the risk profile of the programme.

Review the impact on project risks.

This is the start of the formalisation of the programme plan, so the windows when the risks could occur will become clearer and the Tranche plan can be used to manage risk exposures or mitigate risks, so this is an opportunity to lower the programme risk profile.

The Tranche plan will clarify projects that will not be needed but may already be running.

Culling of projects without proper understanding of value and impact may have long term implications for the programme, positive or negative. As such, these should be recorded as risks.

Using step changes reduces big bang style risks and enables avoidance of time bound risks. Selection of the end game and the journey will significantly affect the risk profile of the programme.

Update the resource plan to show the realignment of projects resources.  Identify the initial programme level resource requirements for the programme.

The Tranches provide the starting point for developing the resource management strategy.  As the major changes are defined, an embryonic plan can begin to form.

The internal resourcing of the programme for this stage will be helped as you will know the types and quantity of resources required to develop the delivery strategy.

There may well now be opportunities to stop some projects that obviously do not fit.  This offers a big opportunity to release project resources from closing projects to help with resourcing the programme or early contender projects.

Review project budgets to aggregate Business Case costs and correlate funding plans to ensure tranches are achievable. 

Provide expenditure estimates against each of the tranches. 

Expenditure on projects avoided should be built into the Business Case and identified as an early benefit. Funds from closed projects can be used to resource priority initiatives. 

Existing financial commitment can be better controlled by scheduling funds based on the step changes. It may be that funding constraints will be a key element or constraint to what can be achieved and by when, which will affect the Tranches.

Create the high level schedule, identifying the critical dependencies and reconfigure the requirements for the Blueprint.

You should lead this activity and undertake the systematic analysis of the ongoing need for the projects. Closed projects will provide you with much needed resources. You will need to set out the criteria and weighting schemes for projects continuing and those that will be culled.  There will also be others that need to change direction. Establishing your credibility with Project Managers will be important, as they are likely to resist changes to their projects if they don't know what the future holds for them.

Refine the programme controls to reflect the preferred option.

How the preferred delivery strategy will integrate with framework controls should

Refine the programme controls to reflect the preferred option.

Maintain audit trails of how the strategy is selected.

Develop strategy selection decision criteria.

Identify options and undertake analysis.

Impact assessment of preferred strategy on future programme controls.

Impact assessment of delivery strategy on physical assets.

Impact assessment of delivery strategy on project delivery.

The focus should be defined and managing the control of the decision making process to select the strategy.

A decision making criteria should be established prior to the start of the evaluation process.

An audit trail of the decision and all input information should be held under Configuration management.

The selection of the strategy will be preferred at this point as there will be issues that may take time to resolve.

The delivery strategy should enable the optimisation of physical assets that may be impacted by the programme.

Each of the strategies will have different control requirements, this should be factored into the decision process and the assurance arrangements.

There will be issues that need to be tracked, many of which will include the impact of the strategy on existing projects.

The programme Risk Register can now be updated to reflect reduced ambiguity.

Supply chain and operational risks should be included based on preferred option.

The impact of each delivery strategy option should be assessed for the impact on the risk profile of the programme.

Normally each option will have its own strengths and weaknesses but the overall impact on the risk profile will be a key element of the selection of the preferred option.

One of the areas to be captured will be opportunities that are lost as a result of selecting a particular option, so the focus should not just be on negative risk.

If these are logged in the Risk Register then an opportunity may arise to capture the benefit later through some tactical change.

The programme Risk Register can now be updated to reflect reduced ambiguity.

Refine resource plans to reflect the programme strategy approach.

An Internal resource impact assessment should be conducted.

The preferred strategy for achieving the Blueprint should remove some of the ambiguity around resourcing that would have existed while there were a number of options for end state and delivery.

Now that the strategy has been defined, the resource plan for the ‘Design the Programme’ stage can have more detail and a schedule added to it.  This provides a gap analysis of the skills that are currently available and any new or additional resources that will be required to meet the end state.

The broader programme resource management strategy for the whole programme can now take shape.  You will know the types of resources needed to cover the wider delivery, through the various Tranches, so preparation work can now be undertaken for this.

Cost estimates can now be finalised for the preferred approach.

There should be a cost analysis of each of the options.

The analysis should form the Options Appraisal section of the Business Case. Do nothing should also be included as one of the options.

Ensure that there are tangible options presented to the programme board.

You should look to organise this work, make sure the right stakeholders are involved and ensure there is a systematic approach to drawing conclusions. You should be looking to bring structure to the process to ensure the right selection is made with good records being maintained for later reference.

Check that the proposed controls for the next stage are robust.

Maintain an audit trail of decisions.

Review effectiveness of project controls.

Gate review should be undertaken in line with the assurance plan.

The level of issues and the ability to resolve should be included in the decision process.

Identify lessons learned related to management controls.

For the gate review the controls should ensure that the approvals are auditable and any changes are recorded and actioned.

The gate should be undertaken in accordance with the assurance plan.

The gate should ensure that controls from the programme are being applied consistently to projects.

The approval should be auditable. The Authorisation must take into account the internal review.

The assurance plan will need to be reviewed and may need to be updated for the next stage.

The effectiveness of the programme in controlling the projects and their alignment with the framework should be part of the review.

There should be lessons learned that can be applied to this and other programmes and may require changes to the framework.

Review the individual major risks.

Scan for aggregating risks.

The overall risk profile should be a key element of the decision process. The Portfolio Board should have visibility of all the risk and the overall risk profile for the programme, and the plan to mitigate the level.

This is a good point to re-scan (to identify) any new risks or aggregating impacts that had not been identified before.

Viability of existing mitigation plans should be reviewed as well as the effectiveness of the risk management activities so far.

Depending on the nature of the programme, external independent assurance of the risk profile may be required.

Approve resources that will be required for the programme.

Approve the resource plan for ‘Design the Programme’ stage.

The gate review should test the viability of the resource plan and the outline resource management strategy.

It is very common for programmes to underestimate their resource requirements through over optimism about productivity and capability, particularly of in-house resources.

It is important to remember that this is not just people - there are physical resources.  Knowledge is also a resource and, the absence of which, leads to poor decisions.

The approval at this gate is validating the delivery strategy and the resource implications.

Review the funding strategy and anticipated costs.

Ensure there is commitment to the anticipated Business Case and funding for the Design phase. Significant effort should have gone into the options appraisal, which should be visible to the Portfolio Board. The budget for the next stage should also be established.

Lead the work to prepare for the decision gate with supporting evidence

If authorised, you will need to start to implement the Design Plan. You will need to ensure that all elements of the decision are auditable and maintained.

Develop the project mandates for each project needed to achieve the blueprint.

Ensure that the control standards for projects are incorporated into the design.

Update the dependency network between the programmes.

Update the dependency network between the projects within the programme.

Impact assessment on project controls.

Impact assessments on programme controls.

Impact assessment on physical assets.

Delivering the blueprint will need a range of projects to build the capability some may already exist and not require changes, there may be existing projects that will need to be changed to realign with the blueprint, and there will be new projects required.

Projects should have a clear line of sight to either benefits Blueprint or strategic requirements. If not, they should be considered for culling.

At this point the project dossier should be created, this will provide as much information about what each project will need to deliver. This will form the brief for the project when it launches, the links back to the blueprint and benefits for each project need to be defined.

The dossier should show how each project fits into the Tranche plan for context.

The key role of assurance during this stage is to check that the projects and the governance design will enable the achievement of the blueprint and benefits.

The size and shape of the project dossier will help to clarity the programme controls that will need to maintain control of the projects

Any short or long term impacts on physical assets and their management plans should now be clearer.

Focus on the cross project dependency risks to the programme.

Allocate programme risks mitigation actions to projects where possible.

At this point the project plans and Tranche plan are coming together so the overall map of risks and how they relate can be created, there will be better visibility of dependencies as well.

There may be external risks and inter programme risks that can be better defined and improved mitigation plans can be put into place.

Programme risks can be mitigated by project delivery. Market and organisational capability to deliver the projects should be considered as a risk. Any ambiguity about costs should be seen as a risk.

Analyse the resource requirements for the project delivery.

Identify key suppliers of resource of the projects.

The projects will be major consumers of resources.  As the project dossier has the core information about each project, it should be possible to make some estimates for resources.

The impact assessment on planned and existing projects should show what resources can be deployed or recycled.

If there is likely to be a heavy burden of resources, then this may be the right moment to undertake some market testing of supply routes for the provision of temporary resources at the project and programme level.

It is likely that there will be some early projects launching, particularly if there is procurement involved or urgent quick wins, so the resource management is formally starting at this point.

If project resources have not been formally inducted into the programme or are lacking programme management experience, this should be addressed now.

Financial estimates should be firmer and updated.

Initial costings for individual projects should be undertaken.

The cost of the project is a critical cost element of the programme and will represent a large proportion of the costs in the Business Case. At this point, there should be enough information to set a budget for each project.

Prepare the high level requirements for each project and how it links to the blueprint.

You should be able to develop the Dependency Network so that there is a clear understanding of how the projects fit together and the design is optimised. It is your responsibility to ensure that you have a clear understanding of what projects are required and who is developing them amongst the team. Some Project Managers may start to see the writing on the wall for their projects, so open dialogue is important.

Complete the programme Management and Control strategy.

Complete the programme Quality and Assurance Strategy.

Complete the Issue Management Strategy.

Place other theme strategies under version control.

Undertake assurance review of theme strategy alignment to the framework.

Impact assessment of the Monitoring and Control Strategy on project and programme controls.

Impact assessment of Quality and Assurance Strategy on existing arrangements.

Impact assessment of the Issue Management Strategy on existing arrangement.

Impact assessment of the information management strategy on existing arrangements.

The governance arrangements are now being assembled for the programme, so a key point is to establish them under version control and assure them for alignment to the framework.

The Issue Management Strategy should be based on the framework approach, so it should be straight forward and identify any specific variations that the programme may need to deploy.

Quality and Assurance strategy should cover how independence of the programme will work once it moves into delivery, and how the quality of programme management will be established, maintained and evaluated. As with other strategies a key component is alignment to the framework and explanation of deviations that are needed specifically for the programme.

The Monitoring and Control Strategy primarily sets out how the programme will monitor and control the projects in terms of setting controls, tolerance and evaluating performance for projects. This should provide quality and success criteria for projects within the programme.

The Information Management Strategy should include information on how the programme will align with the corporate information security policies as well as including details on any variations from the framework standards. This will be particularly an issue when external partners are involved in delivery strategy.

Complete the risk management strategy.

Consult corporate risk team on the programme approach.

Risk Management Strategy should be designed to define how risks will be managed during delivery, the needs and environment may be different to the design and define stages.

This could be quite a simple step, as the framework guidance should already be in place, the strategy should state this and explain any deviations specific to this programme.

The corporate risk management team should be consulted as part of the strategy development.

This may be integrated into one approach. A key area to focus on is how escalations will work, to ensure that risks are not buried too deeply, and also how risks from the programme will cascade risks down to projects. The other area should be to focus on how aggregation will be measured and monitored.

Complete the Resource Management Strategy

The development of the resource management strategy should have been going on for some time, as it begins to emerge once the Blueprint takes shape.

At this point, the formal strategy should be completed, as mentioned before.  It needs to take into account resources, other than people that are common across the programme.

One of the key decisions will be whether the programme manages a resource pool for the projects or whether projects take responsibility for their own.  The second approach reduces overheads but also reduces the programme control.

Performance metrics on how resource effectiveness will be measured should be defined in the strategy.

Complete the Monitoring and Control Strategy

Financial controls and approvals within which the programme will work and function should be included within the Monitoring and Control Strategy. These should define how budgets will be allocated and managed and the levels of authority for individuals within the programme and Project Managers.

Produce the governance model with the supporting processes and controls.

The Governance arrangements must give you adequate control and visibility of opportunities and potential threats from all directions. If the strategies are well defined and the processes work, your job will be a lot easier. You may be able to use the documentation that has been created by previous programmes and adapt it for your needs.

Ensure there are control gates for projects.

Set the tolerance allocation process for projects.

Establish the reporting processes for existing projects.

Establish version control for theme plans.

Create the Quality and Assurance Plan.

Create the information management plan.

Include the programme controls into the programme plan.

There should be plans to mobilise and manage the Quality and Assurance, Issue Management, Information Management and Monitoring and control strategies.

It is key that the plan includes critical review/break points at which the programme can be checked for business alignment, so that progress and performance can be reviewed.

Theme plans will now be put under change control with regular check points to cover effectiveness and reviews.

The full programme information set should now exist and be under version control.

The Tranche Plan and other plans will merge into the overarching programme plan, which may be a single or multiple documents.

The role of assurance at this point is to ensure that the plans will achieve the blueprint, benefits and meet the standards of the framework.

Risk management plan should be finalised.

Identify and assess any new risks.

Validate current risk profile.

There will be a lot of interaction with the development of the programme plans from other themes as these will be affecting the risk profile, so the risk mitigation plans are likely to be finalised after the other plans.

There should be a plan to fully mobilise and manage risk and issues for the programme.

Resource management plan should now be finalised.

Allocate resources to initiate specific projects.

This task specifically requires the output of the programme resource management plan.

This is a very important input to the business case, as it will provide the schedule of resource expenditure over the foreseeable lifetime of the programme.

If this is a long term programme, the level of detail around later Tranches is likely to be vague, however, a resource management plan for the first Tranche is essential.

The plan should be clear on where the resources are coming from and what their management arrangements will be.

A key area of planning should be the dependencies on key resources - physical or human.

The dependency network will illustrate how the project outputs fit together, this will provide the analysis to show where key resources will be required and highlight potential hotspots that will need to be managed.

Financial management plan should now be finalised.

There should be a financial plan that outlines how and when funds will be made available to the programme. Availability of funds could be a key constraint around which you have to work.

Pull the various plans together into the definitive document.

This is major piece of work for you, and you will need the support of the team around you. Ensure that dependencies are identified and factored into the schedule, risks and external dependencies must also be factored in. You will need to challenge the optimism of the planning to the projects and get a really clear understanding of dependencies, internal and external.

Maintain an audit trail of how the decisions to approve the business case were achieved.

Apply version controls to the business case and contributing information.

Include programme issues into the business case document.

Ensure that the review standards for programme business cases are followed.

This is critical point where controls are critical.

The business case will have contributions from a range of sources, all of these need to be under version and change control because in the future if any of these change then the viability of the business case will change also

Assurance should be used to validate the input information that is used to make the decisions, this information must be reliable otherwise the wrong direction may be taken.

It is likely that there will be many issues to resolve, these must use the issue management strategy with a full audit trail to ensure control is maintained.

The cost of assurance and controls must be identified and included in the business case as part of the programme management costs.

Refine the programme risk profile.

Update the financial risks and their potential value.

Review aggregated project risks and their financial impact.

Define the required risk budget.

The project should be complaint to the risk management standards in the framework and how the risk management cycle will be used by the project.

The risk profile of the project should be included in the business case, this should be a contributing factor to the management controls, the higher the risk the higher the level of control.

Approve resource management strategy.

Approve resource management plan.

Refine the resource plan based on any changes resulting from this review.

Confirm with internal and external suppliers the resource profile and plan in the business case.

At this point, the resource management plan is finalised and adopted within the business case as one of the key areas of financial expenditure.

The strategy and plan will come under a lot of scrutiny at this point as it is a key cost element, so expect plenty of challenge.

Resource management also includes the partners and supply chain anticipated in the delivery process.  It also thinks about where and when they will be required.  This resource plan should be linked to the milestones to show what resources you will need and when.

The projects should be compliant to the resource management standards in the framework and demonstrate how the resource management cycle will be used by the project.

Define the budget.

Undertake Independent assurance of cost estimates.

The project should be compliant to the finance management standards in the framework and how the resource management cycle will be used by the project.

The source of funds should be explained and where and when the expenditure is likely to occur, the Stages should be used as the basis for this.

Large elements of the costs will not be known yet however information on the current costs of services or operational delivery should be included for later comparison.

Check that the operating model is still valid after the assessment.

Some key checks are that the information in the Blueprint is current, the starting point is still the same or have the goal posts already moved?  Checking that funds are going to be available and that control points for the programme are clearly defined will also help assure delivery.

Check that the proposed controls for the next stage are robust.

Maintain an audit trail of decisions.

Review effectiveness of project controls.

Gate review should be undertaken in line with the assurance plan.

The level of issues and the ability to resolve should be included in the decision process.

For the gate review the controls should ensure that the approvals are auditable and any changes are recorded and actioned.

The gate should be undertaken in accordance with the assurance plan.

The gate should ensure that controls from the programme are being applied consistently to projects.

The approval should be auditable. The Authorisation must take into account the internal review.

The assurance plan will need to be reviewed and may need to be updated for the next stage.

The effectiveness of the programme in controlling the projects and their alignment with the framework should be part of the review.

Review the individual major risks.

Review the overall risk profile.

Scan for aggregating risks.

The overall risk profile should be a key element of the decision process. The Portfolio Board should have visibility of all the risk and the overall risk profile for the programme, and the plan to mitigate the level.

This is a good point to re-scan (to identify) any new risks or aggregating impacts that had not been identified before.

Viability of existing mitigation plans should be reviewed as well as the effective of the risk management activities so far.

Depending on the nature of the programme, external independent assurance of the risk profile may be required.

Approve the mobilisation of resources to launch the first Tranche.

Confirm resource budgets.

This gate review is the final approval before going into full delivery.  However, the reality may be that there are elements of delivery already under way to achieve quick wins or projects with a long lead time.

Once an independent review has been completed, the resource plan will need to be mobilised.  This may be part of the main resource plan, or it may be useful to provide this separately.

In the lead up to the gate review, it is wise to reconfirm internal and external commitments to making resources available.  Once the approval to proceed has been provided, they will need to be released in accordance with the schedule.

Check availability of funding to support first tranche.

Funds to mobilise the programme and put the infrastructure in place need to be ring fenced to ensure availability. The budget should be clearly defined and allocated.

Formalise the mobilisation arrangements to ensure momentum. 

The mobilisation will largely focus on activating Governance and launching early projects, some may already be in flight. It is worth seeing the launch and establishing of the programme as a project in itself, allocating a Project Manager to ensure it is well run.

Ensure that project definitions clearly align delivery to the programme standards.

Establish business performance reporting.

Re – baseline plans.

Update the programme issue register.

Establish the governance framework.

Mobilise theme plans and establish tracking and reporting.

Establish project reporting process.

Establish the dependency network and monitor effectiveness.

Establish the process for managing tolerances.

At this point the governance framework is being mobilised for the tranche, so the management of the themes should be in line with the framework with allowances for specific needs of the programme.

This milestone is confirming that the governance is in place and that the programme is established.

There will be a number of plans to mobilise and baseline, this may be under the generic programme plan heading, but the project plans should now be aligned and integrated to show major capability step changes.

Ensure the aggregating effect of project and programme risks are tracked.

Establish the risk management framework and monitor effectiveness.

Establish regular risk identification scans.

Undertake risk effectiveness reviews.

Ensure compliance of projects to risk process.

Programme risks can be cascaded down and owned by projects in some circumstances. For other programme risks, projects should be fully briefed to enable them to contribute mitigating actions where appropriate.

Undertake impact assessment of project resource requirements on programme resource plan.

Establish resource frameworks.

Establish resource reporting.

Implement performance metrics for individual teams and assets.

Implement supply chain monitoring and performance management in line with contracts.

This is where the resource management strategy and plan come to life.

It is possible that resources may be arriving at the programme and projects in numbers, so it is really important that there are appropriate controls in place to ensure they are being utilised as soon as possible.

It is important not to forget the induction and training programmes. An induction is applicable to everyone, to ensure everybody in the programme understands the context.  The training is about raising capability and performance.  Once the programme moves into full swing, it may be harder to find the time to do this, so covering training during mobilisation ensures it will get done.

Revise individual project budgets in line with revised projects.

Allocate funds to appropriate groups.

Establish expenditure tracking and monitor effectiveness.

Ensure compliance of projects to finance process.

Establish financial authorities.

The budgets for the projects will exist in the Business Case. The early development work for the projects will be to establish the viability of their objectives within that budget.

Appoint the Project Manager and approve the Project Plans.

You should be appointing the Project Managers and actively engaging with them to ensure that you establish rapport and control of the project. Make sure they understand not only what they have to deliver but also their obligations to the programme.

Initiate quality reviews of project outputs and performance.

Review and identify lessons from effect of the programme controls.

Manage project escalations.

Manage the dependency network to track the programme critical path.

Manage project escalations.

Track effectiveness of project controls and compliance to framework standards.

Track and control inter programme dependencies.

Undertake an assurance review of the testing plan to confirm all elements are in place.

Maintain configuration and change controls.

Monitor impact on physical assets performance.

The programme will need to satisfy itself that the quality of the output from the projects meets the quality criteria and that the performance of suppliers is to the required level.

The programme should be initiating Quality Reviews and health checks of the projects to ensure that the standards are being met and the delivery is optimised.

The programme processes should be monitored to ensure they are operating optimally. It is easy for programmes to start to drift towards autonomy as the drive to deliver takes over.

Reviews of all aspects of governance should be undertaken on a regular basis to ensure that the programme is using the latest tools and techniques, staff competencies are adequate and the processes provide adequate but efficient control.

 Information audits should be undertaken to ensure that the integrity and accuracy is being maintained to ensure the programme can make timely decisions.

Additionally, reviews should check the quality of the release processes for documents and that the stakeholders have the right versions.

The new capability should now be in place and working.   The management of defects should now be taken on by the corporate, specialist or operational teams for resolution with the supplier.

 Review issues to ensure all operational issues have been resolved.   Once transition is completed and outcome performance has been achieved, it is necessary to consider what will happen to outstanding issues.

 Ownership will need to be allocated to residual members of the project team, corporate contracts or the operations depending on how the capability will be managed.

Track programme level impacts of aggregating project risks.

Review risk management effectiveness and implement improvements.

Regular review of strategic risk for new or changing causes.

Review the effectiveness of project risk processes.

Update the programme risk profile at each programme board.

Close off risks relating to transitional service stability.

Most of the energy will be focused on project risks and issues. It is important that the programme focuses on aggregating risk and monitoring for similar risks developing across the projects or threats to interdependencies developing. For example, operational risks will be developing that threaten the need or timescales of the projects.

The monitoring of risk should be a continuous process which scans the environment from 4 perspectives - programme, project, operational and strategic (threats and opportunities). Fluctuations of individual risks should be monitored against aggregated threats to the programme. Issue and change control should use the same four perspectives and the focus on resolution must be maintained to stop the programme being overrun with issues.

The project related risks should now be closing down but there will still be those which affect working practices, operational stability and performance. These should be moved to the operational Risk Register.  

The corporate Risk Register may also be updated as the achievement of the new way of working may mitigate a corporate risk that was part of the Business Case justification.

Track and optimise the use of resources across the projects and programme.

Review effectiveness of resource management, productivity and optimise.

Monitor the quality and provision of in-house resources.

Monitor the performance of teams and assets against projections.

Intervene as needed on performance issues.

Conduct regular supply chain reviews and identify improvement opportunities.

Balance resources between projects to maintain momentum

This is a major delivery point for projects, so it may be a point where there is a reallocation of resources between projects.

The lead up to this point will involve the day to day management of resources within the programme, so there will now be information on productivity and effectiveness of teams and individuals. 

This information should be factored into the resource management review at this point to identify lessons and what the impact of those are likely to be on future Tranches.

Most of the lessons at this stage are likely to be related to project resources.  The focus will now shift to transition resources and the services change to achieve the outcomes.  Therefore carefully check transition plans to minimise potential performance risks.

Track and optimise the use of finances across the projects and programme.

Review effectiveness of financial forecasting and address causes of weakness.

Monitor and manage project financial performance.

Programme business progress should be reported to each programme board.

Monitor for opportunities to optimise financial performance.

Update budget information to reflect actual costs at this stage.

The tolerances for achieving the Projects will be set within the Business Case and these will need to be regularly managed and reviewed. In addition, there should be regular liaison with the financial functions to ensure that anticipated funds are going to be available in accordance with the plan, or to make adjustments if this is the case.

The budget for the programme will be defined within the Business Case. Tight controls of expenditure at the programme and project levels should be maintained and approvals for expenditure should be in line with organisational approval levels. The monitoring should be of the aggregated performance against expenditure as well as the individual projects. It is critical that expenditure is measured in line with achievements, under spends can be as serious as overspends.

Final transition costs should now be available and reflect the total cost of the projects.

Track the dependency network for cross project impacts.

Manage exceptions and ensure impact assessments are being managed.

It is important that you do not become the senior Project Manager and fixer, it is your job to stay above the detail and monitor the environment, the Dependency Network is your key tool for managing progress and the inter relationships between the projects which will enable you to maintain the direction of the programme in line with the plan.

The governance strategies should be underpinning much of what you do. There is a temptation to abandon the well thought out processes when the pressure comes, however, process prevents panic and you have a leadership role to play in keeping the team focused on using a structured approach to deliver the programme goals.

Initiate quality reviews of project outputs and performance.

Review and identify lessons from effect of the programme controls.

Ensure that there are acceptance sign offs for the project deliverables.

Ensure that there is business sign off of the outcomes being achieved.

Manage project escalations.

Manage the dependency network to track the programme critical path.

Manage project escalations.

Track effectiveness of project controls and compliance to framework standards.

Track and control inter programme dependencies.

Undertake an assurance review of the testing plan to confirm all elements are in place.

Review the Monitoring and Controls Strategy for effectiveness.

Review the Information Management Strategy for effectiveness.

Review the Quality and Assurance Strategy for effectiveness.

Impact assessment of lessons learned from controls and strategies and raise change requests.

Maintain configuration and change controls.

Monitor impact on physical assets performance.

At this point the transitions to achieve the outcomes should have been achieved, so the controls will focus on monitoring and tracking transition and project closures.

The achievement of the milestone should include the review of control effectiveness in preparation for the Gate review.

This review should look to establish whether the direction and route are correct.

 It should also look at whether the projects will build the capability that was defined for the Tranche and whether there is a justification for continuing the programme.

The Quality and Assurance Management Strategy should be reviewed and the effectiveness of audit and assurance be evaluated:

Have they happened enough to have had an impact?

Are the recommendations being adopted?

Is there adequate process to support this?

Information Management Strategy should have adequately secured and managed all programme information, including project and business information.

Check that the currency and integrity of information been maintained and associated information attributes been appropriate to the programme. Based on the review the strategy may require amendment.

The Monitoring and Control strategy will cover the interfaces with the projects and business operations, again, this one will require review and improvement.

Review and identify lessons from effect of the programme controls, these could come from the business, from project or any other sources.

Check that the proposed controls for the next Tranche are robust and are appropriate.

Undertake risk impact assessment of the changes.

Review risk management effectiveness and implement improvements.

Undertake risk identification review of any new programme threats or opportunities as a result of outcomes.

Update the risk management strategy from lessons learned if necessary.

Remove risks have now passed their proximity from the risk register.

At this point the level of change relating to this Tranche should be nearing completion so business stability risks should be reducing or should have passed, so this is a good moment.

The review of risk should look at the current aggregated exposure and the nature of the risks. In particular, the focus should be on the risks that affect the organisation's strategy, the ability to achieve the blueprint and realisation of the benefits.

The effectiveness of the Risk Management Strategy should be evaluated. Effectiveness of the escalation routes and the identification of both risks and issues, along with effectiveness of associated processes, including change control, mitigation plans and general levels of engagement will all enable improvements to be made to the approaches.

Review effectiveness of resource management, productivity and optimise.

Review the programme resource management plan for the remainder of the tranche.

Review the resource management strategy that will be required for the remainder of the programme.

The achievement of a major outcome means that a significant transition has now happened, so it is the opportunity to review the effectiveness of transition resources as well as delivery resources. Resources to support sustaining the business to achieve benefits may still be needed, the resource plan should be checked for this.

This is a good moment to analyse the effectiveness of business transition resources, the change team and pick up lessons for future transitions and tranches.

Based on the review here, there may be a need to revise the resource management strategy and/or resource management plan for the programme, as well as the impacts on the projects delivering the capability.

Refine finance plans to accommodate any changes.

Review effectiveness of financial forecasting and address causes of weakness.

Review the funding strategy and anticipated costs.

The review should principally focus on the ongoing financial viability of the programme and, in particular, the availability of funds to support it. The balance of benefits and costs should have been under review all the way along, this is the opportunity to stand back and re-think against the bigger picture of organisational context.

The review should assess the accuracy of the estimates being provided for costs and benefits. These should be re-forecast and a revised Business Case produced to justify the programme continuing.

Funds to mobilise the programme and put the infrastructure in place need to be ring fenced to ensure availability.

Ensure that options for changes of direction are analysed against the operating models and project dossier.

Provide recommended improvements in process effectiveness and decision making.

Formalise the mobilisation arrangements to ensure momentum.

You will have a key role in managing this review. This is mainly about the direction of the programme which is the domain of the SRO and the BCM. You should look to the SRO and BCM to re-affirm their commitment to the blueprint, Business Case and benefits as part of this review of direction.

This is a very important review for you. As you are responsible for the governance arrangements, this is a good opportunity to stand back and decide if you are using the right approach. What lessons can be learned and how can the governance be improved for the future?

The re-mobilisation will largely focus on activating Governance and launching early projects, some may already be in flight. It is worth seeing the launch and re-establishing of the programme as a project in itself, allocating a Project Manager to ensure it is well run.

Undertake additional testing to prove that there is no dependency on the legacy systems. 

This testing is to ensure that the systems have been fully removed and that no dependencies have been overlooked.  Issues with product stability or the decommissioning should be managed by the project.  There may be areas that are still dependent on or reluctant to give up the old ways of working, this will need to be regarded as an issue until it is resolved. 

A key risk is unexpected operational dependence on systems being removed.

There is a danger that groups who have not transferred or migrated, or a part of the service still depends on the old processes and systems - missing these could cause major embarrassment.

Specialist skills and resources should be deployed to deal with hazards.  

Specialist resources may need to be used to remove and dispose of legacy systems, especially if they carry specific risks (e.g. asbestos).

Costs of disposal and decommissioning should now be reflected in the budget.

Ensure that support costs associated with legacy systems are removed from the budget and payment to suppliers is stopped.

Check that the proposed controls for the next stage are robust and appropriate.

Maintain an audit trail of decisions.

Review effectiveness of project controls.

Gate review should be undertaken in line with the assurance plan.

The level of issues and the ability to resolve should be included in the decision process.

At this point the programme could be preparing to move into the next tranche or planned or premature closure, the actual review will depend on these.

For the gate review the controls should ensure that the approvals are auditable and any changes are recorded and actioned.

The gate should be undertaken in accordance with the assurance plan.

The gate should ensure that controls from the programme are being applied consistently to projects.

The approval should be auditable. The Authorisation must take into account the internal review.

The assurance plan will need to be reviewed and may need to be updated for the next stage.

The effectiveness of the programme in controlling the projects and their alignment with the framework should be part of the review.

Review the individual major risks.

Review the overall risk profile.

Scan for aggregating.

Review the effectiveness of risk management strategy.

The overall risk profile should be a key element of the decision process. The Portfolio Board should have visibility of all the risks and the overall risk profile for the programme, and the plan to mitigate the level.

The risk profile will be a key element of the decision to continue or close the programme

This is a good point to re-scan (to identify) any new risks or aggregating impacts that had not been identified before.

Viability of existing mitigation plans should be reviewed as well as the effective of the risk management activities so far.

Depending on the nature of the programme, external independent assurance of the risk profile may be required.

Mobilise the resources to launch the next tranche or closure.

This gate may well herald a change in the culture of the programme as it moves into a different Tranche, a completely new set of resources may be required to build the next capability.

There may even be a significant change in direction for the programme if external events have conspired to provide opportunities.

A key element of this is taking the lessons learned, identifying opportunities to improve and undertaking impact assessments on the benefits.

There may well be suppliers or resources leaving at this point as the team changes.

Those leaving the programme to return to an operational role should have debriefs through exit interviews to ensure knowledge is recorded and available to future tranches.

Updates may need to be made to HR records for full time staff.

If the programme is closing early, then an impact assessment on resource and contract commitments is essential - it could be very expensive.

Confirm availability of funding to support next tranche or closure.

Commitment to the anticipated Business Case and funding for the next Tranche should be put into place.

Lead the work to prepare for the decision gate with supporting evidence

If authorised, you will need to mobilise the next Tranche programme and deal with any issues that come out of the review.

Record any issues about the design that cannot be resolved and ensure that the design undergoes assurance for achievability.

Capture any issues that you have identified when doing the design and how they may be addressed. When developing the business design it is worth thinking about how it will be tested and interfaces with existing systems and working practices.

Record risks to the service that the new model or transition may cause.

When considering risks, the most desirable design might carry the most risks, this doesn’t mean that the easier route should be taken but the level of risk needs to be understood and transparent.

Identify and include appropriate resources to contribute to the business design.

The amount of expertise in the resources required will depend largely on the level of risk associated with the change. Ensuring that the right resources are involved early will enable early identification of problems and reduce wasted effort.

Costs of developing the design and procurement should be recorded in the budget.

The costs for this work, and in particular external expertise should have been identified in the budget for this phase of work. Cutting costs during these activities could end up with a much larger bill later.

Ensure that impact assessments of any changes are made to the Business Design documentation.

From the outset, there will be obstacles that the project will need to overcome to achieve its goals.

The sooner these are identified, documented, recognised and understood the better, as it will help to set expectations of what can be achieved at a reasonable level. How quality and testing will be managed needs to be considered.

If the solution is new or innovative there may not be a proven approach or experience of testing - this would increase the risk of selecting that option and it should be factored into the decision process.  

Appraisal should track opportunities and threats from each of the options.

Each option should have a risk assessment, looking separately at:

(a) Threats/opportunities to delivery.

(b) Threats/opportunities to benefits and requirements.

Ensure that the same resources are used to analyse each option.

Ensure that adequate and consistent resources are in place to undertake this work properly in terms of time, skills and experience. Decisions made at this point by the wrong people or in a rush could easily come back to haunt the project later.

Financial analysis of the implementation costs should be developed.

A key consideration is going to be cost. A budget will need to be set and if the achievement of the original idea is now looking more expensive, then it is better to stop the project at this stage.

Record issues that will need to be addressed by following this approach.

Produce the plan to assure the quality of the decision. No option will meet all the requirements perfectly so make sure that the issues associated with the preferred choice are fully understood and logged. For the selected option, there will need to be a plan to cover testing and acceptance; it is worth capturing that information now as a useful input to the Design stage.

Record any lost opportunities that should be tracked and any new threats identified from this option.

The preferred option may require compromise and the loss of some functionality or benefit that would have been useful. Log this as a risk so that it is tracked - an opportunity may arise to achieve this functionality in a different way later on.

Ensure appropriate resources are available to support the assurance review.

The recommended option must take into account the impact and requirement of resources to deliver and transition it into use. The availability and use of internal resources as part of the project is often overlooked, which in turn causes the project to run late or fail. Basic considerations should include:

• Who will be needed?

• Who will be available?

• Are the necessary skills and experience available in house?

If external support is required this will need to be factored into the Business Case.

Produce budget estimates for the delivery of the recommended options and cost of the Design stage work.

The option selected must be within the budgetary expectations that will have been set for the strategic Business Case or have a good justification for variation.

Ensure recommended actions relating to issues and quality testing are dealt with.

Resolving the issue may result in changes; these should now be managed under change control.  

Assurance may be required and the primary requirement – the Acceptance Criteria – is baselined, measurable and correctly attributed.

Ensure recommended actions relating to risk are dealt with.

There should be evidence that the major risks are being actively managed.

Ensure recommended actions relating to resources are dealt with.

The decision should seek detail on the scale of internal and external resources required, in general for the whole of the life cycle, and in particular for the next stage.

Ensure recommended actions relating to budget are dealt with.

Resolving actions on costs may affect the validity of the Business Case, if it goes beyond authorised tolerance that will require managing.

Identify issues associated with the options and put the final model under change control. 

The final Business Operating Model should be developed out of this activity; it should cover process, technology, organisation and information. The achievement of this full model should be the basis for assurance reviews going forward and the post implementation review.

The Business Operating Model, once base-lined, should be used as the basis for managing change to the scope of the project. Issues will arise associated with the requirement, Business Operating Model and the benefits. From this point onwards, changes will affect the stability and deliverability of the project, so must be controlled.

Record risks to the achievement of the Business Operating Model for the project and its transition. 

There will be opportunities and threats identified as part of this activity. There may be organisational or technical challenges that could arise in the future - it is important that these are being tracked and considered. The complexityof  risk will be a factor in assessing the Business Case.

Identify the resources that will be required to deliver the model.

The resources required to complete this activity will be drawn from a mix of the operational areas to be changed in addition to people with technical or previous experience of the assets and their capability.  

Refine the estimated costs of achieving the new model.

Ensure that the costs of all aspects of the change are being captured, not just the costs of the assets. There are financial implications to many aspects of the ways of working that will need to be estimated.

Procedures to cover how testing will be delivered should be included in the design.

The detailed technical design will provide the basis against which the quality of the products delivered will be tested. Therefore consideration of the testing plan should be undertaken at this stage - if requirements are being specified but can’t be tested then it may be that the requirements are not appropriate. The product descriptions should include reference to acceptance criteria which will provide the basis for the testing plan.

The final design should be under change control. The technical design should be captured in the product descriptions that have been developed from the Business Operating Model. 

The detailed analysis may well create issues with the original operating model that will require considerations of changes to the specification or the design. Any changes should be captured as issues and formal change control applied with an impact analysis.  

Ambiguities linked to the design should be recorded as a risk. 

During this activity there will be a number of areas of ambiguity arising, possibly from the knowledge of the team or how far the technology can be extended. The ability of the organisation to change to use the new capability is another area of risk, these should be captured as risks and recorded in the log.

Be careful to think about assumptions that are being made in the process, they may not have been recorded.

Ensure that resources with the right capability and knowledge are involved in this work.

It is important that the right resources are included in this piece of work. It is not just volume, but also expertise, which should include areas such as specific market knowledge, technical knowledge and understanding of how the products will be used when they are implemented.

Budget expectations should be updated to reflect the detail of the new design.

Make preparations to complete the Full Business Case.

There may well be a cost to undertaking this detailed design prior to the procurement being undertaken - these costs should have been included in the Outline Business Case.  

Build testing plans into the schedule and update issues register now the supply route is known.

Quality testing should be factored into the selection of the approach.  If the approach is unique the quality testing of the suppliers solution will be more difficult than if it is an off the shelf type of solution.  The product descriptions include acceptance criteria that will be used as the basis for the testing plan.  

Throughout the procurement process there will be issues associated with different supplier options that are either specific to one or to all of the options.  In a large or complex procurement, consider creating a separate log to control these to differentiate them from the project management issues.

Update the Risk Register to reflect the increased certainty and any new risks related to the outcome.

There will be a wide range of risks that will need to be addressed, ranging from availability of suppliers to the complexity of the products. Scenario planning of what the potential outcomes will be, their effect on the Business Case and final solution should be undertaken on complex projects.

Adjust resource plans in line with the selected approach.

The resources will need to be skilled in the subject matter and be able to advise on planning related to complying with national or European guidance.  When considering the suppliers, their potential to provide skills to support transition should be a factor.

Resourcing for testing can now be included in the plan.

The final pricing from the tender should be included in the Business Case.

Budgets should be set to cover the costs of the procurement and the resources required to undertake it. In particular, include the costs of additional specialist knowledge resources or tools that will be used to undertake the procurement.

Ensure that the quality and testing plan is adequate.

The results of the assessment could include questions about how testing and quality control will be achieved. Ensure that there are plans to resolve known issues. Major issues will be carefully considered in the assessment so expect queries and questions to be raised.

Assure that the risk profile is adequate and contingency plans are in place.

The assessment will consider the level of risk being managed. This may affect the level of control that is being applied in terms of contingency planning, which in turn should affect your plans for delivering the project and how it will be controlled.

Assure that the required resources will be available.

Resourcing will be high on the list of things that will be considered at the assessment, so challenges are likely.

Assure that the budgets are sufficiently accurate and available.

This will be the main area for consideration - a robust financial plan will be expected, not only showing total costs, but also the expenditure profile which will be built into the financial plans.

Acceptance criteria and processes for dealing with deliverables that do not meet the specification must be agreed.

The agreement of a testing regime and plan should be part of placing the contract.  

Unresolved or new issues resulting from the contract should be recorded.

As part of the negotiations there will be issues raised and changes requested. These must be captured and managed under change control to ensure there is no erosion to the functionality of the products or the performance commitments of the suppliers.

Record any new risks and review the overall risk profile prior to signature.

There will be risks associated with achieving this milestone, these will include failure to agree a contract, loss of expected functionality or cost differences. Each scenario should be tracked as a risk and a contingency plan kept in place, for example, having a preferred supplier should not preclude continuing dialogue with other potential suppliers.

Appropriate skills and resources should be dedicated to supporting the contract negotiation.

The placement of the contracts should include how the build and transition will be handled as well as any long term warranties.  This may require external input.

The testing regime should include operational testing which will consume resources.  The skills required and timetable need to be understood prior to contract signature.

Update financial forecasts and establish a change budget.

Payments to the supplier should be based on the achievements rather than simple time or input resource effort.  

The total costs resulting from the contract must be cross referenced back to the Business Case to ensure that they are within limits that have been set.

The detailed testing plan can now be developed to track the build and delivery.

The testing should extend beyond the functional testing of the deliverables. The Business Operating Model should be tested from end to end. Some of this will require a period trial that provides “proof of concept” that the performance improvements can be achieved.

Record or remove issues resulting from the review.  Once the contracts are in place, the full specification and operating procedures are developed, any changes or anticipated problems should be captured as issues to ensure an impact assessment on the effect can be undertaken.

Update Risk Register and refine risk profile relating to compatibility and adaptability of the components.

The completion of the Business Operating Model will present risks (they may be human or technical) which should be tracked.

Where the Business Operating Model requires organisational structure changes then the level of overall risk will be higher and must be actively managed.

The resource plans can now be finalised to move into deliver.

Resourcing in this context should extend beyond transition resources and consider the impact on the operational resource plans from the new operating model.

Financial forecasts for the project and operating costs can now be updated.

The financial implications of the new model should include the cost of any contracts, the implementation costs and of course and the ownership costs.  Any of these may have changed during the contract placement activities.

Activate the testing plan and ensure that progress testing is in place. Monitor new opportunities that arise from unexpected functionality that can be used positively.

There must be a process for managing testing issues that includes supplier and customer representatives.  Plans to resolve issues must be produced to avoid contract failure.

The process of building and testing prototypes and delivering the final build will raise issues linked to the ability of the operations to achieve the changes needed and the quality of the product – any concerns arising from the build of the components should be managed as issues.

The risk profile of the project should be under regular review.

The final build and testing should provide the opportunity to remove risks, reduce the likelihood and impact of risks as the service should now be tested.

Any problems that have arisen are no longer risks but should actively be managed as issues.

Testing resources should be scheduled.

There will need to be a mix of expert resources that understand any technical functionality offered and also from operational areas that will need to sign off that the project deliverables meet their expectations.

It is important to monitor the availability and performance of individuals to maintain effectiveness.

Costs for in-house and independent testing should be made available.

A budget to cover the testing programme should have been included within the full Business Case, any extension on time and resources should be cross referenced back to the Business Case budget.

Complete testing and review results to assure compliance.

Any specification issues that are now known about will need a rectification plan and work around in place. A recommendation to stop or go will come from testing results.

Ensure that any off specification issues are logged and that the capability is under change control. The Acceptance Criteria should have had ‘quality tolerances’ and the test plans should be objective. Any deviations beyond the tolerances should be treated as ‘off-specifications’. 

Update risks to reflect the successful completion of testing.

The completion of acceptance testing should enable the removal of risks around functionality and interoperability. The focus of risk should now be on transition activities and any threats to the ultimate hand over to operations.

Ensure all resources involved in the testing are consulted as part of completion.

The knowledge and experience gained from the testing should be documented and shared with areas that will be using the new capability. This should include operations and corporate teams.

Review budgets and adjust to meet any additional work that will be required.

Budgets should now be finalised and submitted as part of the gate review. This should include contingency for any risks that have been identified or issues that have not been resolved. 

Ensure that specification for assurance is correctly scoped.

Quality and testing should have been largely completed however as the capability moves into operations the knowledge of the testing regime and the monitoring of known problems must be clearly allocated. 

Update risk profile to reflect the business risks that could now become active.

Risk management will now focus on business and operational risk as the project moves into transition. Issue management should be clearly allocated with responsibility for issues relating to the contract and achievement of the specification that may continue post the project.

Ensure that there is agreement to provide internal resources for support where needed. 

The intensity and demand for support resources in terms of backfill and dual running will be needed.  

Responsibility for identifying and sourcing the resources should be allocated.

Ensure financial skills and budgets are available to fund the stage.

A budget to cover the costs of transition should be in place with responsibilities for expenditure allocated.

Adjustments to the transition plan should be undertaken under change control.

For a big project, it would be wise to have an independent assessment of performance to ensure that the level of risk is understood.

The risk profile of the project should be adjusted accordingly.

If the performance has deteriorated from the original baseline then the potential reputation risks will increase. Changes and schedules should be based on mitigation or removal of as much risk as possible.

If performance has improved since the baseline, the potential for a faster transition or acceptance of more risk may be acceptable.

Adjust resource plan to ensure adequate operating support is in place during transition.

The level of additional support for the operations provided by the project may need to be adjusted depending on the results of this activity.

Adjust transition budget to reflect new starting point.

If the level of operational support requirements change then the budget will be affected and should be updated.

The quality assurance plan should be tracking the performance of the new capability.

The monitoring of defects or issues, and the ability of the operational teams to use and operate the new way of working, will provide useful information for any future testing regimes.

Quality criteria should be managed to ensure that they remain within tolerance during transition.

If the capabilities have not been fully tested and signed off, information should be gathered to ensure that appropriate acceptance criteria has been met.

Ensure that operational risks are logged and managed.

As the solution is going into service the levels of risk should be under review with the increasing stability being reflected in the lower levels of risk exposure.

However, this is the period when the operational groups will be fully involved in the transition. This is likely to lead to an increase in the number of change requests so there will need to be a good process, not only for logging them, but processing them as well. 

Ensure that the resource utilisation is optimised and adjust as required.

During transition, additional support will be required by the operational areas as they work to recover to normal operating levels with the new ways of working in place.

Identifying suitable substitute or backfill resources should now be in place to minimise the impact and risk during transition.

Track costs against forecast and manage deviations.

There may be financial incentives and penalties built into the contract to help with quality management.

Monitoring of costs to ensure that they stay within tolerance is important.  

During this phase, costs could be running at maximum as the project and the operational transition support will be in place.

Undertake an assurance review of the testing plan to confirm all elements are in place.

The new capability should now be in place and working. The management of defects should now be taken on by the corporate, specialist or operational teams for resolution with the supplier.

Review issues to ensure all operational issues have been resolved. Once transition is completed and outcome performance has been achieved, it is necessary to consider what will happen to outstanding issues.

Ownership will need to be allocated to residual members of the project team, corporate contracts or the operations depending on how the capability will be managed.

Close off risks relating to transitional service stability.

The project related risks should now be closing down but there will still be those which affect working practices, operational stability and performance. These should move to the operational Risk Register.  

The corporate Risk Register may also be updated as the achievement of the new way of working may mitigate a corporate risk, that was part of the Business Case justification.

Release temporary resources from the project.

Once the systems and operating practices are stable, the additional resources should be released in a measured way that minimises risk or ability to react to an unexpected degradation in the systems.

Update budget information to reflect actual costs at this stage.

Final transition costs should now be available and reflect the total cost of the projects.

Ensure that the quality and testing plan has been completed.

Provide evidence of the completion of all tests. Ensure that there are plans to resolve known issues. There shouldn't be outstanding project issues which don't have an owner and any change requests should have a process to resolve them.

Ensure that operational risks are transferred into corporate registers.

Lessons learned about the way risks have been managed should be recorded and distributed.

Ensure that resources are released and their HR records updated.

Release project resources for other ventures or BAU.

Report final costs with commentary on any expectations.

Project financials are closed.

Review final testing and operational assurance reports.

Quality reviews and testing results should give the final trigger for acceptance of the product into operations. Outstanding issues should have a resolution plan or be cleared from the register. One of the risks that should be managed is the dependence of operations on the project resources in terms of skills and processes for managing the supplier.

Only risks relating to decommissioning should now be on the log.

One of the risks that should be managed is the dependence of operations on the project resources in terms of skills and processes for managing the supplier.

Ensure that responsibilities for resourcing are handed over to operational staff.

Care must be taken when reducing additional operational resources, particularly if expert knowledge is removed from the support environment.

Any additional costs associated with issues will require a budget.

Project finances should now be in the process of being closed off. The final obligations to support resources should be diminishing and final payments to suppliers should now be made.