INFO 638Lecture #41 Software Project Management Resource availability and critical chain INFO 638 Glenn Booker

INFO 638 Lecture #4 1

Software Project Management

Resource availability and critical chain

INFO 638Glenn Booker


Resource Availability

To make a project schedule complete, resources need to be assigned to each task

Need to identify the number of resources, and their roles 3 senior programmers 0.1 program manager 1 database analyst, etc.


Resource Availability

Now we need to determine if the project can be completed with the resources available

The key is to balance the resources with the tasks they need to accomplish – some refinement of the tasks and activities in the project is often needed


Leveling Resources

Resource assignments are generally done task-by-task at first

Then need to add up the planned resources and look for potential problems Over committing people Resources inconsistent with project

priorities


Leveling Resources Lack of management to monitor the

project resources Lack of accounting for employee

turnover Leveling should result in no resource

being planned to work more than 100% of the time And we want a logical flow of resources

needed – no wild fluctuations


Leveling Resources

No schedule is typically perfect – we want to get reasonably close however

Strategies to level resources include Use available schedule slack Shift the project finish date Smoothing


Use available schedule slack

Slack is the amount of time a task’s start or completion could be changed without affecting project completion

Hence we can slide tasks left & right on the schedule within the limits of their slack time to smooth out resource needs


Shift the project finish date If the completion date isn’t critical,

consider moving it to the right (later) in order to avoid resource conflicts (multiple tasks needing the same resource at once)

Otherwise might need to reduce the project scope to eliminate conflicting tasks, or defer feature completion to later releases


Smoothing

Here, smoothing refers to deliberately planning people to work overtime to accomplish certain tasks

Done by scheduling >8 hours of work per day, or using weekends and/or holidays as work days


More Approaches Other ways to help smooth the

resource needs include Decompose activities into smaller tasks,

and spread out when those tasks are done

Stretch the duration of tasks, thereby reducing the number of resources needed

Use less skilled resources, and extend the schedule for the task accordingly


Cost of Resource Leveling

Often leveling or smoothing resources can lead to a longer project schedule This may increase the cost of the project,

particularly if fixed project costs are affected (e.g. facility rent)

More direct costs could include failure to earn early completion incentives, or penalties for late project completion


Micro-level Planning

It’s possible to plan subtasks to a very fine amount of detail (day or two subtask task durations)

This can be a good strategy for understanding serious estimation problems

In general, however, the added cost of planning and tracking isn’t worth it


Work Packages

Earlier we defined a project as having activities, which are broken into tasks

A way to describe and manage the tasks within an activity are work packages

The work package describes the tasks to be accomplished, relevant dates, and who will do the work


Work Packages

Sometimes a work package is also a contractual mechanism to describe a chunk of work to be accomplished The manager of a work package is

responsible for managing the tasks needed to get the work done, and report the time and effort needed, and the work package’s status


Work Packages = Insurance

The work package can also be seen as insurance to describe the work in enough detail to help recover if turnover is a problem During the peak of the dot-com boom,

this would have been a very wise strategy to follow


Work package assignment (p. 155)

WP #

WP Name

Early Start

Late Finish

WP Manager

Contact info

A Design 3/4/05

4/1/05

F Smith 345-5678

B Product eval

Etc.

C Place locate

D Product forecast


Work Packages The list of all work packages are

summarized, like shown on the previous slide Then each work package (A, B, etc.) is

described in task-level detail using the form on page 156 of the text

Notice that several fields in the top of the form come from the main schedule – predecessors, successors, critical path, etc.


WP Implications on schedule Whether you use work packages has

strong implications on the level of detail that appears in your master schedule If using work packages, you could plan to

the activity level, and leave the details of each activity to the work package managers to define

If not using work packages, the main schedule needs to plan to the task level


Complete Project Plan

With the project defined to the task level you have enough detail to estimate the labor costs, and are able to provide a complete project proposal to upper management for approval to proceed


Critical Chain Project Management

Critical Chain Project Management (CCPM) is another approach to managing resource conflicts Key additional reference is “Critical

Chain Project Management” by L. Leach, ISBN 1580539033


Critical chain vs. critical path

The critical path is the longest duration through the project Doesn’t consider the resources needed

for tasks along the critical path Critical chain is the longest path

through the project, considering both task dependencies and resource constraints


How is CCPM different?

CCPM is based partly on some statistical concepts

The duration of any task will vary, depending on various reasons Those reasons could be due to common

causes (normal random fluctuations) or special causes (specific causes which could be identified)


Common & Special Causes

Common causes are accounted for in the contingency planning for each task – the amount of time needed to ensure it’s completed on time

Special causes are dealt with as part of risk management


Plan for 50% Completion Time

Normally we plan each task so that 90% of the time we’d finish on time This includes a lot of time for each task

compared to the 50% completion time (the task time we’d finish in 50% of the time)

CCPM plans for the 50% completion time, and adds the additional time as contingency time


Figure 12.1, page 254

This is what the cited figure means – the white part of each task is the time needed to finish it 50% of the time The grey part is the difference between

90% and 50% completion times In CCPM we lump the 50% times

together, and lump the grey parts into a contingency time period


Notice the assumption

The text assumes that the difference between 90% and 50% completion times is very large – typically half of the planned duration So tasks with a 90% duration of 6

days, have a 50% duration of 3 days Is this realistic?


To create a critical chain path

1. Start with the early schedule from traditional project management (TPM); figure 12.2, the critical path is tasks C1-C2-C3

2. Replace the 90% completion times with 50% completion times for every task


To create a critical chain path

3. Convert the early schedule to the late schedule, and show resources; the late schedule is shown in Fig 12.3

4. Look for resource conflicts, and adjust the start time for each task(here it’s assumed each person can work one task at a time)

5. Add time buffers


Time Buffers

Buffers are time intervals added to the end of a series of tasks to allow for contingencies

Buffers can be used for many reasons Project buffers Feeding buffers Resource buffers


Project buffers

Project buffers are at the end of a critical chain, to protect the overall project schedule (allow for general contingencies) If T50i is the 50% completion time for

task i on the critical chain, T90i is the 90% completion time for task i, then

project buffer = sqrt{ (T90i – T50i)2 }i


Feeding buffers

A feeding buffer is a buffer at the end of a series of tasks which feed into the critical chain (like a stream which feeds a river)

It is calculated the same as a project buffer


Resource buffers

A resource buffer isn’t a time buffer at all; it’s a flag to warn that a particular resource will be needed soon So it’s an alarm clock!

A resource buffer is established some time interval before the resource is needed (1 week, a month, etc.)


Return to CCPM example

Resume the example from slide 28 Add feeding buffers onto the end of tasks

A1-A2 and B1-B2 (since they feed the critical chain C)

Add project buffer onto the end of tasks C1-C2-C3 (since it is the critical chain)

Notice that resource conflicts aren’t considered for buffer time periods


Return to CCPM example

The project which was 16 days originally (under TPM) is 13.7 days using CCPM A schedule reduction of 14%


Managing a project using CCPM Since the nominal task duration is

only met 50% of the time, there have to be careful rules for managing the buffers

Three levels of warning are established When the first, second, and final thirds of

the buffer are entered None for when the buffer is exceeded?


Managing a project using CCPM

How seriously each of these warnings is treated depends on how far into the series of tasks you are when the buffer is used Again using a scale of first, second, and

final third of the tasks accomplished This produces the chart on page 261


Managing a project using CCPM

So if a series of tasks is 15 days long, and has a 10 day buffer If you are 8 days into the buffer after

completing 7 days of the tasks’ work The tasks are 7/15 into the work, which is

the second third of the tasks The buffer used is 8/10, which is the final

third of the buffer Hence the diagnosis is “Serious problem;

implement the solution”


CCPM Summary

So CCPM uses a little statistics, and a little risk management theory to reduce the planned schedule for completing a project

Several examples of success using CCPM are cited

Documents

INFO 638Lecture #41 Software Project Management Resource availability and critical chain INFO 638 Glenn Booker