Project Launch Process L090

Blog: Biz-Performance, David Brown

L090 – Produce Path Plan

DEFINITION

Produce and agree a high-level management “Path Plan” showing the overall plan for the project. This may include the list of the software implementation processes with high-level timescales, sequencing, dependencies, deliverables, resource requirements and responsibilities.

SUMMARY

This process develops the initial estimates for the project covering:

effort in hours per segment, process and activity;
overall duration and duration by segment;
resource staffing levels by segment, process and/or activity.

It establishes the sequencing and dependencies of the processes identified in Process L030 – Select Paths, and identifies the deliverables to be produced.

It establishes organisational and structural needs for the project which are dealt with in Process L100 – Define organisation, people and support requirements.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):

Select Paths (L030)

Prerequisites (Finish-Finish):

Do Quality Plan (L080)

Dependent procedures (Finish-Finish):

Define organisation, people and support requirements (L100)

Dependent procedures (Finish-Start):

Segment Launch

RECEIVABLES

Project Constitution showing terms of reference, scope and objectives
Definition of business needs and anticipated benefits
Quality Plan showing approach to:

project management,
change management,
use of other methods and techniques,
quality review and sign off.

Organisation structure of the client organisation
Available resources details / skill sets

DELIVERABLES

A high-level management Path Plan showing high-level timescales, sequencing, dependencies, deliverables, and resources requirements.

TOOLS

ITPM Core Guide
Example plans
Project planning software
Estimating Model software (spreadsheets)

DETAILED DESCRIPTION OF TASKS

The desired approach to the project will have been established in Process L030 – Select Paths. This will have identified which processes should be included in the project. The planned path and processes may be quantified using details of the project’s scope and intended benefits in preparing an initial Path Plan, showing broad estimates of dependencies, timing and resourcing. Detailed plans and estimates will be established during the subsequent segment launches in the Segment Plans.

Facts, views and information

To develop a good Path Plan will require information and discussion. The project’s sponsor and project manager should identify a core planning group to consider the project approach and detail. Team members should be knowledgeable about the subject matter and collectively should be able to cover all aspects of functionality and technicality. They will be expected to be able to identify resources and resource requirements relating to their area of knowledge, whether business or technical.

The core planning team is generally a small number of people. The scope of the project will dictate the team size. Additional resources may be called upon to provide input as needed. For a large project, developing the Path Plan may take considerable time and commitment.

The core planning team should enhance the list of additional or missing information about the project and then determine the best method to obtain the information. The objective for gathering additional or missing information is to refine or define objectives and scope of the project, assumptions, constraints, risks and expectations such that a full Path Plan can be constructed. Facilitated workshops are often the easiest and fastest method to gather necessary information and to agree the findings.

Organise the plan

In a Software Implementation Project, it would be normal to organise the project plans by segment, process, and, optionally, task. The Path Plan will not normally show tasks, although it may be necessary to sub-divide processes where they have different components at different stages of the project – for example, testing and training processes have elements of concept, approach, preparation, conduct and follow up which may need to be shown separately in the Path Plan.

The Path Plan shows the segments of a project and the processes within each segment, optionally divided into lower levels of activity where appropriate. It shows these against a time line, so that at a glance an overview of the entire project may be seen. Individual resources need not be applied to each activity. The activities should not be too detailed so that the activity plan becomes unwieldy to maintain.

Establish the dependencies and sequencing

One of the unique advantages of the Software Implementation Project approach is the way it allows tasks to be scheduled in a more efficient manner than conventional approaches. It is important, therefore, that the Software Implementation Project principles are fully considered and allowed for in calculating the high-level sequencing and dependencies. These principles can be found in the core information for Software Implementation Project and detailed discussions are included where relevant in the process descriptions. Practitioners unfamiliar with the principles should either read through the full descriptions of all relevant processes or seek assistance.

Many of the detailed dependencies cannot be shown at this level of detail, as they exist between individual tasks in the various processes. These will be established later during the Segment Plan.

List the deliverables expected

The specific deliverables that will be produced should be identified. These will normally be found in the Software Implementation Project process descriptions.

Develop Initial Estimates

This is frequently handled in four stages :

decompose the project into logical work components
decompose the project into logical functional (or technical) components
populate the estimating model
develop an estimate range.

The core planning team should review any existing project estimates (for example, from the proposal or from and initial project evaluation) and the initial cost / benefit analysis. This information should help the team to understand the information presented to the sponsor and senior management and the initial expectations for project cost and duration.

The project manager should focus on providing senior management and the sponsor with an estimate range, rather than specific cost figures and durations. The initial estimate range should include:

effort in hours per phase and activity,
overall duration and duration by phase, and
resource staffing levels by phase and/or activity.

The estimate range should contain enough contingency to reflect the provisional nature of the project boundaries. It should be conservative and reflect both “best case” and “worst case” scenarios.

To develop the initial estimate, the project manager and team must develop initial assumptions about the resource staffing levels for the project. The project manager must avoid the impulse to adjust estimates without identifying real reductions in work or redefining the project boundaries. The core team should review any adjustments to the estimate range together. They should identify the points during the project execution when more accurate estimates will be available. Senior management is more likely to accept initial estimates if they understand that more accurate estimates will become available during project execution.

Match resource availability to plan

Resource levels will clearly have an impact upon the estimated elapsed time for the plan. To some extent, resources may be either:

fixed – ie there is a defined set of people with defined time available, or
variable – ie the project can obtain the staffing that it needs on demand.

In practice, project resources are normally a mixture of the two types. Some resources will be restricted in number, some may be available but their availability is limited by cost or priority issues, whereas some types of resource could be allocated with little difficulty. The balance between speed and cost/effectiveness should be assessed to optimise the overall benefit to the client organisation.

SIIPS Total Effort over Elapsed Time.PNG

Note: The two theories illustrated in the figure which concern the relationship between elapsed time and effort. In “Putman’s theory” it is asserted that the more effort you put in, the shorter the elapsed time – but you progressively approach a limit of possibility. As you approach that limit it takes increasingly more effort to obtain relatively small advantages. A more plausible theory was presented in “Boehm’s theory” which agrees that a limit is approached, but suggests that after a given stage adding resources makes the entire process less efficient and take longer. In either case, it is clear that a “normal” project should be operating with a sensible balance between effort and time.

Resource availability will need to be discussed and agreed between the relevant parties concerned.

Project organisation and structure

The project’s basic structural and organisational needs should be considered in producing the Path Plan. These needs may be identified during this process. Typically, they will be addressed in Process L100 – “Define organisation, people and support requirements” which will usually be conducted in parallel to the path planning.

It is normal, however, for the Path Plan to identify high-level responsibilities, particularly where other parties are involved, for example, consultants, external contractors, the organisation’s IT department. Other resources will normally be estimated in terms of type and quantity, eg 40 days of purchasing clerk time, 100 days of business analyst time.

Discuss, agree and publish the plan

The overall project Path Plan should be discussed and agreed with the project’s sponsor and any other key decision makers within the client organisation. It may also be appropriate to agree the details with representatives of any other parties involved, eg consultants, package vendor, contractors.

It should be clear that the Path Plan only contains broad initial estimates of timing, resourcing and cost, and that the approach will be subject to review and amendment at stages throughout the project.