Project Launch Process L120

Blog: Biz-Performance, David Brown

L120 – Detail the Segment Plan

DEFINITION

Prepare and agree a detailed plan for the segment. This may include tasks, milestones, timescales, dependencies and responsibilities.

SUMMARY

The Path Plan (defined in L090) will have defined the project’s processes and resourcing at a high level. Each part of the Path Plan is expanded to provide a much greater level of detail in a work plan for the segment – known as the “Segment Plan”. Detailing of phases is ideally done some three to four months before work is due to begin on that phase. A phase may relate to one segment or may be a logical or functional subset of a segment.

A detailed work plan provides a measurable schedule for accomplishing a specific goals defined in the Project Constitution and Path Plan. It needs to be constantly maintained until all tasks in the plan are complete.

A well defined work plan will enable the project manager to:

identify the tasks, effort, timings and resources necessary to meet the specified objectives in the minimum time span and with an efficient use of resources,
identify areas of risk and take remedial action before they become critical to the project,
establish a benchmark against which to measure progress, and
communicate project objectives and assignments to project team members.

The key activities in developing a work plan are to:

split segments, phases, processes and activities into logical and manageable tasks,
define each task according to an agreed proforma,
produce a logical order in which tasks must be performed,
estimate the effort required for each task,
allocate resources to each task, considering skills and availability, and,
produce and agree a baseline work plan.

Planning requires significant effort from the project manager and team leaders. Sufficient time must be allocated to the development of comprehensive detailed work plans. The project manager should develop a schedule for producing the plans.

PATH PLANNING GUIDANCE

This process is normal practice.

DEPENDENCIES

Prerequisites (Finish-Start):

Define and agree project management techniques (L040)

Prerequisites (Finish-Finish):

Produce Path Plan (L090)

Dependent procedures (Finish-Finish):

Detail / revise staffing, team structure and organisation (L130)
Mobilise resources (L160)
Present project/segment approach to user community/team (L200)
Confirm or renegotiate KPMG’s contractual relationship (L150)
Begin work on following segment

RECEIVABLES

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

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

Path Plan (L090)
Project Organigramme, job descriptions and charters (L100)
Organisation structure of the client organisation
Available resources details / skill sets
Details of resource availability

DELIVERABLES

Segment Plan typically showing:

Task profiles
Gantt chart
Network diagram
Estimated hours for each task
Resource utilisation report
Resource allocations
Baseline plan

TOOLS

Example plans
Project planning software

DETAILED DESCRIPTION OF TASKS

Develop Task List

The project or team leader should identify the tasks required to complete each activity. In an Application Software Implemetation Project (ASIP), it would be normal to organise the project plans by segment, process and task. Typically these would be identified using the process’s identifier (eg “L120”) and a task number.

Tasks should be action oriented and descriptive. The task list should be comprehensive and include necessary checkpoints, reviews or sign-offs as appropriate. The overall approach to review and quality control may have been described and agreed in the Quality Plan.

A deliverable for each task should be described wherever possible. The team leader should describe the process and procedures to review and verify the quality of each deliverable. Additionally, the team leader should identify and document the individuals responsible for reviewing the deliverable for consistency, completeness and accuracy.

Each task should be described in detail to ensure team members will understand all the work required to complete the task. The individual responsible for verifying the task is complete should be designated.

Substantial administrative effort is required during a project to ensure the smooth execution of the plan. This effort must be incorporated into the detail work plan to ensure a realistic schedule is produced. This effort is generally grouped into support tasks, overhead tasks and contingency tasks.

Support tasks facilitate the production of deliverables through better communication, appropriate training and management. Examples of project support effort include project-related training, project management, issue resolution and change control.

Overhead tasks are non-productive work efforts. However, including these tasks is important in developing a realistic plan. Some examples of overhead tasks are non-project training, annual holidays, bank holidays, and illness.

Contingency tasks add additional hours and a duration buffer to the detail work plan to address weaknesses, unknowns and vulnerabilities. The project manager and team leaders should determine the guidelines for adding contingency tasks to detail work plans.

Define Task Dependencies

Dependencies are the logical relationships between tasks and should not be constrained by resource availability. The result of the dependency identification process is a network diagram graphically depicting the order in which the tasks are to be completed. SIIPS Dependences.PNG

There are different types of dependencies describing the various manners in which tasks can be related. These are “finish to start” (a task can start once the predecessor tasks have been completed), “start to start” (a task can start once the predecessor tasks have started) and “finish to finish” (a task can only be complete once the predecessor tasks have been completed).

The relationship between tasks should be carefully analysed. A series of sequential tasks can create an unnecessary bottleneck if some of the tasks could actually be performed concurrently. On the other hand, many concurrent tasks may imply a greater management overhead.

In a ASIP , substantial work is normally performed in parallel to exploit the benefits of a package-focused solution. This leads to many “finish to finish” dependencies where most of a task can be conducted without waiting for others to finish, but it is not certain that it is complete and correct until certain other tasks have been finalised. This is particularly the case during Integrated Design Development and Implementation (IDDI) where parallel work on the logically severable topics within the overall business solution is fundamental to exploiting the package-focused approach. These principles are discussed in greater detail in Process D100 – “Prepare / review / agree IP / Topic descriptions and sign-offs” and in some of the general “Methodology” sections of an ASIP

The dependencies within IDDI will normally be at the detailed task level. The intention should be to recognise dependencies between different aspects of the work, but to try to overlap tasks where it is valid to do so. For any one topic, normally represented by the coverage of an Implementation Paper (IP), there may be tasks to:

prototype, design and document the topic in an Implementation Paper
develop or parameterise and unit test the topic
prepare procedures and user documentation for the topic
prepare a formal system test for the topic
prepare user training for the topic.

Once the design has been agreed in the Implementation Paper it would be possible to make progress with the other tasks, except note that the approach to documentation, testing, and training is likely to be defined in earlier “environmental” Implementation Papers which need to have been agreed before work in those areas can safely progress.

Before the system can become live, the training must be conducted and data must be loaded onto the system. Note how the definition and preparation of the data conversion routines may itself also lead to dependencies in the overall plan. Also, the overall approach to the handover of the system for live usage will have been defined and agreed in another “environmental” Implementation Paper.

This example only deals with a single topic within the project. Normally, many logically severable topics are identified (see Process D100). These will be run in parallel to the extent that is most efficient. There will inevitably be dependencies between the topics. In the following diagram, three topics are shown. The outcome of the first is necessary to define the second and third. For example, the first topic might be “define accounting policy”, and the other dependent topics might be “define coding structure” and “define reports required”. Note in this hypothetical example, the assumption is made that reports can be defined without having to wait for the detailed coding structure to be defined – this is typical of the advantages which can only be achieved in a package-based solution.

In a real ASIP project there will be dozens of topics and a complex web of dependencies. It is important that these principles are understood and applied properly if the package-focused approach is to be exploited to the full.

Estimate Work For Each Task

Initial broad estimates will have been established in the Path Plan. These may be expanded top-down to give initial estimates for the tasks identified. Tasks should also, however, be estimated on their own merits, and the results consolidated bottom-up and matched with the top-down versions. This process may be repeated to identify any problem areas in either the initial estimates or the detailed figures. If overall estimates or timescales need to be changed, changes may be necessary to the overall Path Plan and the Benefit Model for the project.

Estimating is always a difficult task. The productivity of some staff in understanding complex requirements then designing and developing solutions can be phenomenally above average, whereas some inexperienced staff may not be able to make progress at all in the alien environment of the project team. Quantified mathematical approaches to estimation used for custom development programmes are not normally appropriate to a package-based implementation where huge amounts of functionality can often be “developed”, ie configured in, by entering a “Y” in a parameter screen for the package.

In many ways, elapsed time and effort may be driven more by the complexity of the situation than by the amount of functionality to be generated. The difficulty can be illustrated in the formula:

Effort is proportional to:

Scope

times

Flexibility

times

Organisational Complexity

Ask yourself the following questions to understand the logic of this:

How many things do I have to do?
How many choices do I have for each?
With how many people do I need to agree each choice?

It is also important to note that complexity is not proportional to scope. The more components there are in a solution, or issues there are to be handled, disproportionately more complex is the solution. The nature of this relationship can be seen in the mathematical model shown below. Where there is a single component, there is a single entity to be addressed. Where there are two components, there are the two entities themselves plus the additional aspect in the way they intersect and affect each other. With three components there are the three intersects between pairs plus the way all the entities relate to each other. As can be seen in the diagram, this very rapidly leads to an explosion in the complexity of the problem.

SIIPS Complexity grows faster than scope.PNG

The best form of estimation is by analogy. Look for analogous situations and examples from other ASIP projects where the same levels of complexity were involved. A database of previous projects and an estimating framework may have been kept and developed by the Implementation Team.

The effort necessary to complete each task should normally be estimated in hours. The estimate should be based on all the work to be accomplished using the prescribed processes, tools, techniques, and standards. Task estimates should range between 7 and 70 hours. If a task estimate is larger than 70 hours it should generally be divided into two tasks. Tasks with estimates smaller than 7 hours should generally be combined with another task. The estimate should included the total hours for all resources required to complete the task.

Assign Resources

The project manager and team leaders should develop a list of resources available to work on the project. From this list, specific resources can be assigned to each detail work plan. The team leader can then assign specific individuals to the tasks using the network diagram and task profiles. Appropriate resources should be assigned to each task. An appropriate resource is not necessarily the most experienced one because the most experienced resource cannot be assigned to all the tasks. Resource experience and skills should correspond to the specific requirements of a task.

The project manager and team leaders should determine the average resource availability per day for the project. The resource availability factor is expressed in hours per day. Experience has shown that a team member assigned full time to a project rarely works more than 75% of the day on direct task work.

Finally, a detail work plan calendar and individual resource calendars should be developed. The detail work plan calendar reflects non-working days, such as weekends, bank holidays, and designated company shutdown periods. Resource calendars typically reflect annual holidays, previous commitments such as training, seminars and the resource’s hours available per day.

Further consideration is given to resource allocation in the parallel process L130 – “Detail / revise staffing, team structure and organisation”.

Scheduling

Scheduling is an iterative process. Typically it is performed in conjunction with acquiring and assigning the project team members as described in Process L130.

Factors affecting the scheduling process are task dependencies, resource assignments, resource availability and task estimates. The project management tool should be used to produce the schedule and level resource utilisation simultaneously. Automated project management tools utilise various algorithms for scheduling. The team leader should understand the basics of the scheduling algorithm.

Schedules may be influenced by defining a fixed elapsed time for completing a task, regardless of the hours estimated. They may also be influenced by locking tasks to a firm start and/or end date. Fixing and locking tasks should be used sparingly because their use can produce an unrealistic or inefficient schedule.

The objective of the scheduling should be to achieve the most efficient usage of resources to deliver the best solution in the shortest time. Note, however, that the most efficient solution is rarely the fastest and rarely the one that delivers maximum benefit. These issues should be judged to give the best overall benefit to the client organisation.

In an ASIP, the “parallel approach” is a key feature of the way in which we exploit a package-focused approach. Design, development and implementation tasks are overlapped by topic, subject to the dependencies established above, to give the best mix of tasks, leading to:

less complex components which take less time to complete,
more genuine involvement of users during sign-off activities,
efficient use of staff,
lower peak staffing requirement,
shorter elapsed time,
better overall solutions.

The ideal resourcing profile for the Delivery Segment of a ASIP project would build rapidly to a steady staffing level, fitting the various tasks together to minimise wasted time as aspects of the work start up and tail off. Typically, each topic within the project would still pass through prototype/design, parameterise/development, test, implement stages, but these would not need to be dependent upon each other. This is an essential element of the ASIP approach. Further details may be found in the “Methodology” materials.

The detail work plan may need to be rescheduled several times to achieve a realistic plan, each time amending resource allocations and dependencies to refine the plan. When a satisfactory plan has been achieved, the project manager, project sponsor and any other key members of the client organisation should review and agree the detail.

If necessary, steps should be taken to confirm that the resources identified in the plan will be made available as required. The plan should be communicated to the participants and to other interested parties such as user management and the steering committee.

Baseline the Detail Work Plan

Once scheduling is complete the detail work plan should be baselined – ie a frozen version of the details will be kept for comparison against the actual plan which will normally change and evolve during the project. The baseline is the benchmark against which to measure progress and control the project. A baseline generally contains the start date, end date and hours by resource for each task.