Management Control Tasks

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.

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.

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.

Establish the level of controls needed based on the RPA

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

The Risk Profile Assessment is a critical factor at this point, it will be defining how complex the initiative will be and the overall impact on the organisation - it doesn't have to be big to cause chaos!

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 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. 

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.

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.

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.  

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.

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.

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.

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.  

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.

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.

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.

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.

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.

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’. 

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. 

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 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.

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.

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.

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.