Planning Tasks

Create outline high level plan and identify impacts on other projects and overall portfolio plan.

The high-level plan should be an outline at this stage – with enough information to enable the idea to be evaluated.

A key test for the idea, based on the plan, will be the fit with the rest of the portfolio – whether it can be accommodated or whether this or other elements of the portfolio would need to be rescheduled in the light of available finance, resources, etc.

To create this plan, assess how long the idea will take to deliver, how much preparation is required, when it would start and finish.

Establish whether the idea is time-bound – e.g. whether there is a window of opportunity, a constraint or deadline that must be achieved.

Identify the key dependencies, to enable the idea to be located within the overall plan. Identify whether other projects or ideas are dependent on this new idea – the idea might have been identified by an existing project as something required to enable that project to deliver.

Establish the options for the approach to be taken to delivery. This is particularly important when organisations are involved as they may have different approaches to such things as procurement that will need to be taken into account in the approach and plan.

Create outline high level plan and identify impacts on other projects and overall portfolio plan.

The high-level plan should be an outline at this stage – with enough information to enable the idea to be evaluated.

A key test for the idea, based on the plan, will be the fit with the rest of the portfolio – whether it can be accommodated or whether this or other elements of the portfolio would need to be rescheduled in the light of available finance, resources, etc.

To create this plan, assess how long the idea will take to deliver, how much preparation is required, when it would start and finish.

Establish whether the idea is time-bound – e.g. whether there is  a window of opportunity, a constraint or deadline that must be achieved.

Identify the key dependencies, to enable the idea to be located within the overall plan. Identify whether other projects or ideas are dependent on this new idea – the idea might have been identified by an existing project as something required to enable that project to deliver.

Establish the options for the approach to be taken to delivery. 

Draw up a high level plan to present to a Senior Responsible Owner (SRO).

The planning will depend on what delivery route is selected. At this stage a high level view of what the timescale constraints are likely to be will inform the next milestone.

Any major milestones should be included in the planning process.

The programme and/or project milestones should provide high level estimate of timetable.

Undertake an impact assessment on existing projects and programme plans

The plan should cover major time based events or constraints could be referenced and used as an input to the planning process.

The brief should reflect the projects that are known about and will be included within the programme so that there is no doubt about their involvement, this may well have an impact on their current board or governance arrangements.

This is the point where projects that are live but will no longer be required also need to be highlighted and how their objectives will now be met, if at all.

New projects joining a programme when it is in delivery should be tested for alignment to the vision and potential positive or negative impacts it will have.

Ensure there is a plan in place to cover the next stage with realistic estimates.

The activities to move between your organisations milestones should be clearly defined. There should be a schedule to cover the above that is realistic and achievable. The outputs from the next stage should be clearly defined.

Confirm that the portfolio plan, the financial plan and the benefits and resource plans are aligned.

The medium  and longer term financial plans should be reflecting the BAU and portfolio investment plans and sources of funds need to be clearly defined.

Confirm that the portfolio plan, the financial plan and the benefits plans are aligned.

Benefits planning is a key element of portfolio management.

A baseline should be established for each benefit.

There should be a benefits realisation plan for the portfolio, built up from project and programme level benefits profiles.

Ensure transition plans are designed to maintain compliance or identify compliance related risks.

Compliance projects are often time-dependent – there is a specific implementation date that has to be met.

If possible, identify interim milestones that can be monitored to provide early warning and assurance that delivery of the overall compliance project is on track.

Ensure that change plans are viable.

Adjust the portfolio plan based on rate of change being achieved.

Revise change plans based on lessons learned to date.

Ensure that the dependencies between programme and project delivery and business change have the right balance.

Identify and manage dependencies. These can be “logical” (e.g. A cannot be started until B is finished) or “logistical” (e.g. A needs the IT testing facility at the same time as B).

Involving operational managers in planning change helps ensure the right balance between the rate of change and the stability of service delivery.

Operational managers should take key roles such as Business Change Manager at Programme level and Senior User at project level. 

Develop the closure plan for programme and projects.

Projects should be closed or re-aligned.

Resourcing contracts will need to be formally closed, with appropriate notifications given to suppliers that services will no longer be required. This should be in line with the Resource Management Strategy and Plan Review of existing projects - consider whether alternative governance arrangements need to be found for projects that extend past the end of the programme. This is most likely to be the case where a programme is terminating early, but some projects are still required to deliver. Procedures for early termination of projects should also be invoked in line with the Monitoring and Control strategy where appropriate.

If there are projects that will last beyond the end of the programme then the governance arrangements will need to put into placed, this is quite a likely scenario. Alternative arrangements could be moving them into another programme or setting them up in standalone mode under the control of the Portfolio Office.

If all the projects close at the same time as the programme, then each should follow the project closure process with the supporting formal closure processes and documentation being in place.

The project documentation should be handed over to the Portfolio Office.

Finalise plans and close.

Remove controls from continuing projects.

The close down of contracts and resources that were part of the Resource Management Strategy and Plan should be undertaken. A review of the effectiveness of suppliers should be undertaken and that information shared with other programmes. It is a good idea to include the suppliers in this review! The projects should now all be closed down (unless they are continuing under a different governance) and project closure formalities followed. There should be a formal review of the effectiveness of the project controls and planning processes deployed as part of the Monitoring and Control Strategy.  The Programme Plan will have evolved as will the Project Register. These should have happened under control and there should be a solid audit trail. If estimates were not accurate, then the lessons that can be learned from this should be documented. Resource and Monitoring Control strategies should be reviewed for effectiveness along with the lessons learned from their plans and the effectiveness of the overall Programme Plan.

Project control arrangements for continuing projects should be removed as they are handed into new governance.

Any specific lessons about project controls should be included into the programme lessons learned and closure reports.

Set up the post implementation review schedule to monitor ongoing impact

There should be a date in the diary for post programme review, As a rule of thumb 12 months may be appropriate, but may need to be sooner if benefits have not been established.

Adjust medium term plans to reflect the changing capability of the organisation.

Confirm that strategic planning is supporting the change plans and adjusting their strategy.

Feed back into regular portfolio planning and review cycle to include any new opportunities.

Activities necessary to realise benefits and evaluate the portfolio programmes and projects should be planned and managed.

Ensure that work on benefits realisation that extends beyond the remit of the portfolio is picked up by corporate planning and not overlooked. 

Portfolio planning is cyclical – so “scan” at the beginning of the cycle should be informed by the current status of benefits, risks, etc.  The output of this activity will be an input to the Scan process if an idea is identified.

Any major milestones should be included in the planning process.

The plan should not be part of the Vision Statement, but major time based events or constraints could be referenced and used as an input to the planning process. Vision Statement should be under change control and, ideally, this should be the final version.

For each option develop an outline plan to compare timescales.

Undertake an impact assessment on each project scope and outputs.

For each option, there should be clear step changes visible, it should not be seen in one leap. There should be enough detail to enable early planning to begin.  Each Tranche should end with the delivery of step change in capability, described by an intermediate blueprint. External dependencies relating to each of the Blueprint options will need to be identified. There should be clarity about what the key project outputs (deliverables) will be to achieve the Blueprints.

The programme blueprint will provide the requirements for the projects, so this is a key step in the process.

For existing projects, their scope and outputs need to be tested for contribution with and alignment to the future state or any of the intermediate states, if they don’t, there may need to be changes to the scope.

New projects joining the programme when it is in delivery should have an impact assessment of their scope on the programme blueprint and requirements developed accordingly.

Re-align Project Plans and integrate into Programme Plan

Projects that remain should be included in the plan and their dependencies identified. Projects will need to be categorised to show their contribution to the Blueprint and Benefits. At this moment, you only have headline information so some decisions may need to be deferred until the work on the Blueprint starts to bear fruit.

Re-align Project Plans and integrate into Programme Plan with focus on early tranches.

Provide estimates of the timing for each of the tranches.

Refine project schedules to align with the programme tranches.

Projects that remain should be included in the plan and their dependencies identified. Projects will need to be categorised to show their contribution to the Blueprint and Benefits.  At this moment, you only have headline information so some decisions may need to be deferred until the work on the Blueprint starts to bear fruit.

The tranches should reflect two dimensions, namely the business time constraints for the achievement of the new capability and the ability of projects to achieve them.

The results of this work will almost certainly require changes to existing project plans.

For new projects joining the programme, their requirements and timetable should be built into existing tranches.

Tranches and plans should be refined to reflect the preferred option.

The assessment of length and resilience of the delivery timetable for each option should be auditable.

Undertake an impact assessment on the projects of the preferred delivery strategy.

An outline plan with Tranches should be available for each option that is being considered. The speed of delivery may be a key element in the decision making process.

The delivery strategy may impact the way some projects are being run or who runs them, as the strategy may well have an impact on governance and the use of the supply chain.

As such, there should be an impact assessment on each project to determine the best way forward in terms of delivery and governance.

Formalise plan for the programme tranches and review.

Stop decisions on existing projects.

Go decision on projects to initiate during Design.

There should be a coherent plan that recognises project delivery, business change capability and constraints in the delivery of the programme. There should be a plan in place to transition the new team that will deliver Programme Design.

At this point, the programme blueprint, benefits and delivery strategy will be signed off, which will provide the direction needed to make decisions about the destiny of some of the projects.

This is the point where they should be stopped or re-scoped, take care to ensure that the project closure process is followed and that continuing work relating to projects is included within other projects or delivery mechanisms.

There will probably be a need to initiate early projects that have longer lead times but the need is certain.

Project schedules should be linked to the programme tranches.

Create summary mandates for each anticipated project.

Initiate the closure of projects that will not be required.

Draft project mandates.

Map dependencies between existing and proposed projects should be mapped.

More detailed work on specifying the requirements for the projects will take place as the programme moves into delivery.  At this stage, the Tranches should be defined along with the projects that were built into them. It should be possible to provide a more detailed analysis of the requirements from the early tranches.

For new projects, the scope, objectives and other parameters should be developed and included in the Project Dossier, these should be based on the blueprint and the associated inputs from benefit profiles.

Interdependencies between projects should be identified at this stage, this should be between existing projects and projects that are initiated in the future.

Existing projects may need to be formally aligned or changed to reflect their new direction, this should be included within the Project Dossier documentation.

If a new project is allocated to the programme whilst in delivery there should be an impact assessment on the project dossier and appropriate changes made to enable scope and dependencies to remain optimal.

Complete the project control strategy.

The project controls and reporting arrangements should be included for all areas of governance.

Migrate existing projects into governance framework.

There will be a number of key strategies to be developed around planning. The Monitoring and Control Strategy will define how the programme will maintain internal control of itself and the standards that it will adhere to.  Equally important is that it will be setting the standards which the projects will work to, and how they will be monitoring and controlled. Standards for planning will also need to be defined, to ensure that there is consistency particular for projects. Without a consistent approach you cannot have a reliable Dependency Network. The other area of governance is around Resources, where are they going to come from and what you will need.

For each of the Governance Strategies (e.g. risk management) there should be specific guidance on how the programme level controls interface with the projects, this is a very important element of the governance model. So each strategy should include procedures for managing escalations and allocations and how the tolerance will be set and managed.

All the strategies will be based on this framework, so much of the common standards that programmes will use should already be in place, but there might be specific differences for individual programmes. The criteria for measuring the success of projects for each theme should be defined.

The projects should be migrated into the specific control mechanisms for individual programmes and formally signed off.

Finalise overarching Programme Plan.

Create the programme Dependency Network.

Align the project plans to the requirements from the programme plans.

The Programme Plan could encapsulate the other plans, but must include details of the Project Dossier delivery. It is essential that a Dependency Network is defined to provide a tool that can be used to track the relationships between projects going forward, without this, it will be very difficult to maintain an overarching picture.

The programme plan will be the dominant factor, it isn’t an assembly of project plans. The programme plan will include the information for the tranches and other contributing information, so the project plans will be developed around the tranches, only the projects in the first tranche will be need to have detailed plans at this stage.

The benefits realisation plan will be a key factor in setting milestones and deadlines for specific project outputs that will enable benefits.

The project plans should be based on the project lifecycle milestones and wherever possible, the project stages should be tied to the end of a programme tranches, as this enables the alignment of controls between the programme and the projects, so if the programme changes direction there are stage control points for the constituents projects.

Define the milestone plan.

Confirm the viability of the proposal timescales and that they are not over optimistic.

Project budgets should be formalised for inclusion in the programme business case.

The project should outline how it will achieve the planning standards and use the planning cycle.

The PID should include the estimated time to achieve each of the milestones in the lifecycle, with a commentary as appropriate.

This is the point where the project budgets will be set as their contribution to the overarching programme budget.

The business case will be reviewed at the end of each tranche and updated, there may be ambiguity about the projects in later tranches, but the budgets around current live projects and those that are about to be initiated after Decision Gate 4 should have as much certainty as possible.

Revise the plan to reflect the key delivery dates in the first tranche.

Stop decisions on existing projects.

Go decision on projects to initiate.

The plan should set the pace for the programme and ensure that there are adequate controls in place to enable delivery. There should be focus on the Intermediate Blueprint, but later Tranches may need feasibility work to be undertaken. Any residual projects remaining under the control of the programme should now be terminated. Recruitment or procurement of resources to enable the mobilisation as described in the Resource Plan. The guidance and controls that will be needed to control the projects will also need to be put into place, along with any technology to support them. It may well be that some are already in place if there are early projects running.

After this gate review the programme will move into full delivery of the first tranche.

There may be projects that are already completing or will undergo significant governance or structural changes, in this situation they should follow the project closure steps to ensure that lessons learned and handovers are formalised.

The decision to go into Tranche delivery will trigger the initiation of a number of projects, preparations should be made for this and the other alternative is that the programme will close.

Update Programme Plan to reflect more accurate Project Plans.

Establish the programme plan and ensure that the projects understand their contribution to the blueprint is tracked.

Initiate new projects.

Migrate all projects on to the programme control framework for the Tranche.

The Programme Plan and schedule will define which projects are being launched and how they will be resourced. The projects contribution to the Dependency Network should be fully defined and dates agreed between projects. The project control framework should be applied to each project and tolerances defined for the Project Manager. Projects should be launched and configured in line with the Monitoring and Control Strategy. Project filing, naming conventions and configuration standards need to be deployed to ensure the security and compliance to information management standards. Assurance arrangements to review individual project progress should be defined as part of the project initiation.

The establishment of the tranche control framework may require changes within the projects, these could include scope, quality, governance, process or just reporting regularity.

Each project should be aligned to the framework and new projects configured to work consistently, a key area of focus is dependency management, between projects and their impact on other programmes and benefits.

Projects being initiated should join the project lifecycle at the appropriate point with appropriate milestone plans being created, which will provide the basis for tracking project performance.

Monitor and optimise delivery schedules and manage dependencies.

Review accuracy of planning and project tolerances. Adjust if necessary. 

Monitor the effectiveness of the planning standards for project.

Identify opportunities for project delivery optimisation.

Ensure risks relating to the schedule are being mitigated.

Develop transition plans.

Confirm acceptance of relevant project outputs.

Review schedule and product descriptions to ensure the full capability has been delivered.

Ensure progress reporting into the programme against key milestones and, in particular, against the delivery of the outputs on which other projects are dependent. The programme should be part of the project gate reviews; these should be linked to the major outputs required by the programme if possible. Escalations and decisions from the projects should only occur when they are going out of tolerance or impact the Dependency Network and overall schedule.

The programme controls should be in place and generating progress reports which enable the programme to be steered in the right direction. Monitoring of projects to ensure they are remaining within tolerance should be part of the regular routine of the programme. Ensure internal specialist roles are providing the added value anticipated. Resources should be procured in line with the Resource Management Strategy and the activities being undertaken to manage the supply chain should be in line with the Resources Management Plan.

This is the point where the project delivery is coming to an end, so the Project Plan should now be completed as the capability moves into usage. Lessons learned should be documented and submitted to the Portfolio/Programme Office.

Realign plans to achieve any new requirements.

Review accuracy of planning and project tolerance and adjust accordingly.

Formalise plan for the programme tranches and review.

Project transitions completed.

The reviews should focus on the direction of the programme and the strategy for getting there. Lessons learned on planning, customer performance and rate of change capability should be reflected in a revised plan and the plan for the next Tranche.

Assess the effectiveness of the project controls and internal programme management controls as defined in the Monitoring and Control Strategy to ensure that adequate governance of the projects is being achieved. It may be necessary to tighten or vary the levels of controls based on early experiences. The Dependency Network and planning tools should be reviewed and assessed for effectiveness and ensure the next Tranche has the appropriate toolkit in place. The Resource Management Strategy, the effectiveness of supply chain installation and also development of internal talent may require the plan or strategy to be changed.

The plan should set the pace for the programme and ensure that there are adequate controls in place to enable delivery. There should be focus on the Intermediate Blueprint, but later Tranches may need feasibility work to be undertaken. Any residual projects remaining under the control of the programme should now be terminated.

The main projects should be at Project Stage Gate 7 as their individual outputs will have been implemented and accepted into operations by the business.

Evidence of sign off will be required by the programme and where the projects have not met their quality expectations then plans to remediate should be included in actions that follow this programme milestone.

There may be projects that have not been at Project Stage Gate 7 for a variety of reasons, one may be that they have further stages.

The schedule should cover the removal of all assets from operations and disposal from the organisation.

A schedule to remove and dispose of legacy assets is required and their removal will need to be accounted for to ensure that no legacy assets remain within the organisation.

Revise the plan to reflect the key delivery dates in the next tranche or closure.

Stop decisions on existing projects.

Go decision on projects to initiate for next tranche.

After this gate review the programme will move into full delivery of the next tranche or into Close the Programme activities.

There may be projects that are already completing or will undergo significant governance or structural changes, in this situation they should follow the project closure steps to ensure that lessons learned and handovers are formalised.

The decision to go into the next Tranche delivery will trigger the initiation of a number of projects, preparations should be made for this. If the programme moves into closure plans will need to be put into place to re-allocate governance arrangements.

Identify any dependencies with other changes.

Dependencies can be a significant issue if the change is complex so ensure they are identified at this early stage. If the project is part of a programme they may be better managed at that level.

The outline Project Plan for each of the viable options should be created for comparison.

One of the key considerations for the options appraisal should be the ease of implementation. The Business Plans should be created for each to enable this analysis. The products that will be required should be becoming visible so the use of product based planning should be feasible.

Produce a plan for the Design stage and update the business milestone plan.

The selection of the preferred option needs to consider the planning implications.  

There is a danger that the project team moves too quickly in producing plans, which focus too much on detail rather than the business view of the journey. By using a graphical representation, it will make communications with non-technical stakeholders easier and provide a valuable input into identifying the milestones and control points for the project. It is important to focus on what the end game is for your project. By focusing too much on delivering assets the overall effect of what the project needs to achieve can be lost. 

Ensure recommended actions relating to planning are dealt with.

The decision gate may seek assurance on realism of the high-level plans and the detailed plans for the next stage.

Identify the products that the project will be required to deliver within the scope.

The Business Operating Model will provide the basis for the ultimate scope of the project. Delivering the new operating model will be the basis of the objectives for the final project definition. These will form the basis of the work packages in the schedule.

The plan should be updated to reflect the delivery of the final design.

Product based planning can now be fully developed. This in turn will evolve into work packages when the project moves into delivery. The extent of planning needs to cover (1) a high-level Project Plan, plus (2) the lower level stage or team plans (including quality control, specific plans for communications and consultation as well as quality assurance e.g. audits, health checks). The products within the plan should have objective criteria against which they can be tested and by the resources that are defined.

Adjust the plans to reflect the selected approach.

There are a number of factors to be considered for planning. Procurements can be long and complex - they are regularly underestimated when planning is being undertaken. Failure to allow appropriate time will confuse the supply chain. The second consideration is the ability of the supplier to deliver to any non-moveable deadlines that are being defined for the project; this could include legislative compliance, for example. One of the key aspects of supplier selection will be the ability to achieve the transition schedule.

Assure the robustness of the plans.

Stakeholders will be expected to contribute to the review and commit to the changes. Before the assessment, they should have been fully briefed and there should be no unexpected challenges. Confirm there are viable (and reviewed) plans to take the design forward to delivery.

A stage plan for Develop should be created.

A realistic schedule to cover the negotiations phase should be included. 

Planning adequate time for this should be allowed; it may be short or protracted and is a significant dependency within your plan. Work packages should now be finalised. Dependencies should be included within the plan. 

Detailed planning for the delivery can now be completed and controls designed.

If there are changes to the Business Operating Model this may well have an effect on products and the delivery timetable, which will have knock on effect on resources.  Therefore, a review and update to the baseline plan should be undertaken along with changes to work packages.

Ensure there is a clear schedule with break points for reviews and decisions.

Ample time must be allowed for all the testing and assurance to be undertaken - there could be issues with resource availability therefore time will be needed to resolve any issues that arise.  Time spent here will pay back dividends later as it will ensure transition and operational issues are identified and managed.

Revise schedule to include the delivery of any outstanding functionality.

Create transition plans.

Any lessons learned from the acceptance testing should now be built into the transition plans.

Ensure there are resources with appropriate planning skills and that responsibilities for assurance have been allocated.

Update the project plan with the 'Deliver' stage plan.

Responsibilities for planning the implementation and the achievement of outcomes need to be clear. The operations team must have clear responsibilities for operational changes.

Adjust schedule to optimise performance during transition.

If the baseline performance is better than predicted this may mean that a more aggressive transition can be delivered or, if performance is lower, the rate of change may need to be reduced.

There should be a transition schedule and the progress should be controlled against these milestones.

Reasonable timescales should be allowed for.

Transition of the capability into service will be followed by a bedding in period.

The transition plan should reflect the level of risk that operations are able to carry with, either, parallel systems or no systems in place.

Close monitoring of time should be undertaken to ensure that transition is delivered within tolerance.

Review schedule and product descriptions to ensure the full capability has been delivered.

This is the point where the project delivery is coming to an end, so the Project Plan should now be completed as the capability moves into usage. Lessons learned should be documented and submitted to the Portfolio/Programme Office.

Ensure all planned activities have been completed.

Provide evidence that the plans have been completed.

The plan for post implementation review and final closure should be in place.

The plan for this should take into account the scale and breadth of the rollout and the allocation of responsibilities. If it is a site by site sign off, then this will take a lot longer. Pragmatic approaches should reduce the time for sign off.