Planning

Contents:

1. Overview
2. Standards
3. Differences for Programmes
4. Governance Roles
5. Planning Management Cycle
   1. Identify
      • Business Requirements
   2. Analyse
      • Product Based Planning
   3. Plan
      • Stages and Decision gates
      • Product Descriptions
      • Estimation
   4. Deliver
      • Scheduling
   5. Review
6. How2Guides

Overview:

To achieve the objectives of the programme or project there must be a plan that forecasts where and how they will be achieved.

Project Planning is based around what will be produced (products). The plan should initially be based around these products rather than the activities that will be undertaken - this is referred to as product based planning.

Programme planning is at a higher level and joins together a number of plans, alignment to the business strategic plans, integration of dependencies with other programmes and the internal alignment of project, transition and benefit plans

There are a number of techniques that are associated with planning which overlap with other techniques, specifically:

• Change control is within Management Control
• Issue management is within Risk and Issue

The scope of the Planning technique is primarily

1. Business requirements
2. Product Based Planning
3. Stages and Decision Gates
4. Product Descriptions
5. Estimation
6. Scheduling

 

As a minimum, all initiatives will have:

A schedule based on the milestones in this framework An audit trail of how estimates are calculated Use a product breakdown structure showing what will be delivered Maintain product descriptions for main deliverables Maintain an audit trail of external dependencies in the risk register

Planning is different at the programme level because:

1. Programme Plans will need to aggregate the Project Plans (at a summary level)
2. There will be greater focus on inter-dependencies
3. They will have a longer lifespan
4. Plans include transition and benefits-related activities

Project Role/Activities	Programme Manager	Project Executive	Project Manager	Senior User	Head of portfolio	Business Analysis	Business Architect	Portfolio Office
Development of the project requirements to meet the programme blueprint	Authorises	Approves	Actions	Advises	Assures	Action	Assures	Advises
Identification of the products to be delivered by the project	Approves	Authorises	Actions	Approves	Assures	Advises	Advises	Advises
Analysis and development of specifications	Approves	Authorises	Actions	Approves	Assures	Advises	Advises	Advises
Development estimates and forecasts for the project plan	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Development of the plan	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Management of the plan	Approves	Authorises	Actions	Approves	Assures	None	None	Advises
Review of planning effectiveness	Approves	Authorises	Actions	Approves	Actions	None	None	Advises

 

Programme Role/Activities	Senior Responsible Owner	Business Change Manager	Programme Manager	Head of Portfolio	Business Architect	Portfolio Office
Alignment of programme plans to achieve the programme blueprint	Authorises	Approves	Action	Assures	Approves	Advises
Development of the programme plan	Authorises	Approves	Action	Assures	Approves	Advises
Development of the transition plans	Authorises	Actions	Approves	Assures	Approves	Advises
Managing dependencies between operation and programme led changes	Authorises	Actions	Approves	Approves	Advises	Advises
Planning and scheduling based on robust estimates	Authorises	Approves	Actions	Approves	None	Advises
Management of the plan and sequencing delivery	Authorises	Approves	Actions	Approves	None	Advises
Trend analysis of project planning effectiveness	Authorises	Approves	Actions	Approves	None	Advises
Review of programme planning effectiveness	Authorises	Approves	Actions	Approves	None	Advises

 

Role Key:

Accountabilities	"Authorises" - provides the Board endorsement that the activity has been undertaken
	"Approves" - provides business approval of the result of the activity
Responsibilities	"Actions" - responsible for ensuring the activity is undertaken effectively, can be delegated
	"Advises" - provides guidance and help where needed
	"Assurance" - formal independent review

Click the stages in the cycle diagram to go to the relevant page:

As with all the themes there is a cycle that operates between the stages and sometimes between the milestones. The intention is to ensure that there is continuous appraisal and improvement in the accuracy of the plans and that lessons can be learned.

 

Identify

Once the project is authorised to move forward, based on business and benefit analysis, the first stage is to formalise requirements, this work will endeavour to remove ambiguity and ensure the intention of the project is understood.

Requirements Management - is concerned with meeting the needs of end users through identifying and specifying what they need. Requirements may be focused on outcomes (e.g. describing what people should be able to do as a result of commissioning a new building) where the main concern is to describe what is wanted rather than how it should be delivered.

Requirements may need to be specified in precise terms (e.g. when ordering a technical component to fit with existing office machinery), alternatively, they may be described in any way between these two extremes.

The important issue is that those specifying the requirement have an adequate understanding of what the users need and how the market is likely to meet that need. They will also need to be able to keep any changes to the requirement to an appropriate minimum and to document the requirement in such a way that the market will be able to understand what is required.

It is very easy to start creating lists of things rather than focusing on what the results of the project need to be.  The root cause of project failure is often the lack of focus on the outputs/deliverables.

The starting point of planning is developing clear requirements that then enable you to build a list of outputs that will be required, you can then start thinking about the things that will need to be built.

 

Business requirements

'Business requirements or drivers' is the term used to describe what the business wants to get out of the investment, originating from the problem that is being addressed, they are the foundation for the justification of the change.

In a programme, the requirements are more often referred to as the drivers.  A programme will develop a blueprint to describe the end game that will be created to meet the driver.

A project within a programme will normally have the requirements provided from the blueprint.  More work will be required to define them at the next level of detail, but there should be sufficient detail to provide the scope for the project.

The requirements may take a variety of forms, from a specific (objective) technical requirement through to a vague (subjective) expectation. The key thing is to capture them - these expectations will shape what stakeholders are expecting and will need to be included or excluded from the scope of the project in the next stage.

There is also a danger that requirements are driven by the features of a supplier's products, so care needs to be taken to differentiate (as constraints) when such requirements arise, as these will affect the options for delivering the solution.

 

Analyse

At the outset a detailed set of requirements may be handed over to the project manager by the business analyst. The extent and complexity of these requirements will be a key consideration in designing the plan.

Projects are, to some degree, unique. Therefore the approach to analysing and designing the plans may need to vary. There are a variety of techniques that can be used and this stage will look at the business options, previous experience (i.e. learning lessons from the past) and other techniques to gather together the information that will be used to develop the plan using a chosen approach.

This step should produce details on the outputs (products) to be produced and detailed understanding of how the products will be sourced along with the resources that are required to achieve this.

The analysis will highlight different options for achieving the requirements which will then be developed into the preferred plan.

At the end of the analysis, product descriptions should be completed which will provide the basis for the scheduling and estimating.

 

Product based planning

Developing the products

In the early days of the project, there will be inadequate information to formalise the plan. There is also a danger that the project team moves too quickly to producing plans, which focus too much on details rather than the high level 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.

Tip – don’t be surprised if this step highlights areas relating to scope.  It may well be things need to happen that were not spotted earlier.

Technique

The sequence/product flow/activity models are simple diagrammatic illustrations of what needs to be achieved and an overview of how the requirements fit into the bigger scheme of things and how the objectives will be met by the project.

As we develop our plans, we will become more specific about whether it is a product, activity, output or outcome that is being mapped, however at this stage we just want to illustrate at a very high level what has to happen.

Tip - Post it notes and a wall are a great way to do this – create all the things you need to achieve and try to put them in some sort of order.

Example

In this example, it is the relationship map that shows what needs to be done to organise a workshop. There is three key elements to the plan.

The objectives need to be set before anything can happen.  This is followed by finding a room, inviting the stakeholders and organising a presenter. As you can see, some activities enable multiple events whereas others are self-sustaining.

This kind of relationship diagram can be very helpful for explaining the project to people less familiar with project management, and you can see from this illustration that some activities are more critical than others.

 

 

Plan

Now the information has been gathered and analysed to identify what has to be delivered, the plan can be created.  There may different levels and views of plans which may be considered depending on complexity.

The project will have stages that align with the lifecycle, with each stage having its own specific Stage Plan, and a number of the views may be associated with a particular stage.

The planning step involves the development of estimates for the cost and resources required to deliver the products to the necessary acceptance criteria.

From these estimates the schedule will be built. This will normally be illustrated in some sort of graphical representation such as a Gantt chart.

There are a range of other techniques that can be used such as critical path analysis and dependency.

 

Stages and Decision gates

Management stages are the major board-level control points within the programme or project. Their principal purpose is to stop the project running out of control. Within the lifecycle there are a number of control gates that the project will pass through.

At the end of each management stage the project should be reviewed for viability before proceeding forward. This review is normally under the remit of the project board, with advice from the CoE.

The decision gates are an essential part of the control mechanism to ensure that projects and programmes maintain momentum but do not run out of control.

By the time the programme or project reaches the end of a stage, it should have achieved all the milestones within the stage, be able to provide evidence that this has been done and ensure that there is justification to continue.

The basis for the decision to continue will be based upon the following factors:

• Funds are available
• The strategic direction is still relevant
• The benefits are still achievable
• The risks are being managed and are acceptable
• Past progress is satisfactory
• Future plans are agreed

The approach to how the programme or project will take to the gates and the level of risk should be reflected in the Assurance Plan.

 

Product descriptions

Product descriptions are absolutely essential for all projects.  Bear in mind that the level of detail and the size of the product are variable.

The product descriptions will be key elements in developing the plan, so not only do we need to specify what we know, we also need to think about what we don't know, which may cause us issues later.

A project that is creating products that are similar to those produced elsewhere, should re-use their product descriptions or refer to that product to avoid having to provide a full description. The other value of this is having a track record (good or bad) that you can learn from when developing you Project Plan.

It is harder to describe softer products in detail as there may be a lack of clarity about what the results of the change will be. However, the more detail that can be captured the less ambiguity there will be, helping the project board focus on the key decisions that will enable clarity and direction.

Detailed product descriptions enable accurate estimating of resources, costs and timescales.  The lack of clearly defined product descriptions is a clear indicator that a project is not focusing sufficiently on what it will need to produce.

There is another key role for the product description, it will also contain the quality criteria for the product, so it is a key contributor to a quality plan and associated testing regime for the project.

 

Estimation

Plans tend to suffer from an optimism bias, which is the demonstrated tendency for people to be over-optimistic about the outcome of planned actions. This includes over-estimating the likelihood of positive events and under-estimating the likelihood of negative events. It is also reflected in overestimation of benefits.

There are a number of reasons for this, which include:

• Lack of experience in the type of change
• Leadership that enforces the ethos of "just do it"
• Lack of willingness to face up to the reality of how long it will take or how much it will cost
• Lack of capability and capacity of the organisation to deliver the change
• Lack of commitment of the users to deliver the outcomes
• No basis for estimation -consequently there is no basis on which to improve

When making estimates, it is a common failing to think in terms of how long it will take to get the job done rather than the amount of effort it will take to do the job.  These are completely different concepts yet they are often used within projects without that recognition. 

To have effective estimates it is necessary to understand what tasks are required and what activities need to be undertaken to deliver a product.

Each task will take an amount of resource effort, consume capital costs and there will be a timeframe within which resource effort will be dedicated to the activity. There are a number of ways to estimate both the effort to do the task and the period (or duration) over which it is likely that the task will take place. 

There is no substitute for experience when developing estimates, which can be gained from investigating:

• Previous projects
• Other organisations and reference sites that have done this type of project before
• Subject matter expertise on the topic area.

All three of these sources are valuable inputs into the techniques.

There are areas where the project may assume that the stakeholder resources will be available, which may be off the estimates radar, but will have a big impact on the operational performance including:

Meetings to assist with specifications or estimates	Training	Workshops for risk or stakeholder analysis
Testing	Calls and emails	Commenting on documents

 

3 point estimating should be used as a way of establishing a realistic likelihood of events.

 

 

Deliver

If a plan isn't monitored and controlled it cannot, realistically, result in delivery of the tested, approved and accepted products. That doesn't mean that a plan cannot change, but this should happen based on careful consideration of the implications.  Projects will face a number of pitfalls, many can be forecasted, and as such the control of the plan will include the navigation of these obstacles.

There is a basic cycle that will now be managed through to the end of the project's life.

- Implement the plan and establish the controls

- Monitor the progress of the project against the baseline in the plan -with particular reference to effectiveness of the estimates and the performance of resources against those plans

- React to changes or evidence that the project will not stay within agreed tolerance levels and re-planning accordingly

- Improve by identifying and implementing approved improvement opportunities.

 

Scheduling

The schedule is the element of the plan which includes the timeline.  There are many techniques and tools that can be used. To develop the schedule, it is necessary to arrange a sequence of outputs (products) and work out the activities that will be required to achieve them.

There are a number of dependencies that will need to be considered when constructing the schedule:

• The relationship between outputs
• Dependencies on external products or events
• What resources are being used (they can't do two tasks at once)
• The availability of resources/particular specialists (e.g. legal)
• What assets or services will need to be used to support the tasks? (E.g. hardware for prototyping or test lab facilities)
• Governance constraints -EU procurement regulations or HR agreement
• Non-negotiable deadlines, for example legal compliance

The word 'milestone' is used extensively but invariably means different things to different people, so in this context a milestone is a task of zero duration that shows an important achievement in a project (it may be an event for celebration).

The lifecycle has a number of pre-defined milestones which are the way the project or programme progress will be tracked.  

The schedule should include planning time, estimate each milestone's completion date, this can be used as the baseline to compare it with the actual completion date at the end.

Milestones should be the minimal points of control in the project for those that are not familiar with it, such as high-level sponsors and executives of the organisation.  It is likely projects will create their own technical milestones to show the progress between the lifecycle.

 

Review

Once the stage has completed, the plan should be reviewed for effectiveness and the lessons documented and learned. If this isn't done then the same mistakes will be made again and again, which happens in reality, so this is a key part of the process.

Areas where valuable lessons from other projects area learnt would include:

Accuracy of estimates	Resource productivity
Effectiveness of the project board	Reliability of suppliers, in-house and external
Risk and issue identification and impact assessments	Unforeseen events that should have been predicted
Project management support	Realism and engagement of stakeholders