Revision

Planning & scheduling Slide 1

Planning & Scheduling

1. Planning

2. Work breakdown

3. Scheduling

4. Activity networks and Gantt charts

5. PERT

6. Monte Carlo simulation

7. Schedule control


1. Planning

Why plan? To help you understand your project To provide direction by defining what work needs to

be done To work out the best approach

• To ensure that work flows in a logical manner between activities and to ensure that resources are available as and when needed

To communicate to your team – and other stakeholders – how the project is to be tackled

To help keep track of the project


Planning

Why plan?

To ensure that problems introduced upstream … are resolved upstream, e.g., • Upstream QA has ROI of 3:1 thru 10:1

• Fixing requirements errors after implementation can cost 100 times more than if it is done upstream

• The average project uses 80% of its effort on unplanned work: no wonder they are late!


Project-level plans

Vision, project objectives Deliverables/major products/desired outcomes

• Project level product-based planning documents: Product breakdowns, flow diagrams & descriptions

• how and when the project’s objectives are to be achieved • Project level charts, e.g., activity and Gantt

Scope: States what’s included … and what’s not (exclusions); scope creep is a big problem. WBS

Pre-requisites, assumptions, constraints, project interfaces Business Case Project team organisation Quality Plan; CM plan; change control plan; V&V plan; Communication

Plan; Risk management plan Tolerances, controls & control points Resources required (e.g., budget, effort, space, h/w and s/w resource

requirements (for development), materials, other services)


The vision

Studies have shown that a clear, common vision is essential for effective team functioning

• and that team cohesion is vital -- as important as individual capability

Helps streamline lower level decisions & establish trust, cooperation, ownership, …

Must be achievable … take note when your staff say it’s not … staff morale!


Publicizing plans

Plans need to be publicized & agreed by the project team

• they are most likely to be the ones who spot that the plan is infeasible

• if they are not, then plans may be abandoned, and the project then runs without control


Publicizing progress

Schedule control information

• Tasks completed; % of schedule used; % of resources used; … see Schedule Control, Section 7

Status reports to upper mgt

Risk list

Anonymous feedback channel

Defect stats (after baselining)

• New; open; fixed; average time to resolve

• Increases awareness that defect detection and removal is important !

• Useful when we move towards release


Defect statistics

fixed

open

time

defects


Defect tracking – after baselining

unit/module coding

unit test

QA review

code unit “done” – baselined - and now available to be incorporated into “the build”


“Done means done”

When a module is declared as “done” it should be unit tested, reviewed for quality, fixed if necessary, and then baselined • baselined: subject to the formal change control processes, and

available for incorporation into the build

Incorporating poor quality code (that the programmer promises themselves to tidy up later) into a system build leads to serious problems (and delays) • Trying to tidy up thousands of poor quality interacting code

modules can be v. difficult … if not impossible!

“25% of all software projects are cancelled - often because the quality problems were perceived to be insurmountable - at the time of failure, they are 100% over budget & caught in a (seemingly) never-ending test - fix - test cycle”


2. Work breakdown

Activities in a project should be organised to produce tangible outputs for management to assess progress

Milestones are used to track progress • do not necessarily involve delivery of a product to the

customer - may be purely for internal mgt purposes

• should be binary

• result in short report (e.g., outputs, achievements, deviations from plan)

Deliverables are project results delivered to customers • usually also a milestone

Each milestone/deliverable should have an owner – an individual responsible for making it happen


Top-level milestones

Feasibility complete • Go/no-go decision

• Launch

Requirements

Architecture

Stage n complete

Software release


Major project milestones

Start of project Key project decision maker(s) identified Vision statement created Business case established Initial plan established Change control plan created Initial risk list populated … Feasibility complete Project launch



QA lead on board Documentation lead on board Key users identified and interviewed UI prototype created, reviewed (until acceptable) and

baselined UI style guide created, reviewed and baselined Project plan created, reviewed and baselined Risk list updated … Preliminary requirements document complete



Stage milestones

Requirements updated and baselined

Detailed design created, reviewed and baselined

Detailed construction plan including mini-milestones created, reviewed and baselined

Test cases created

…

Stage “feature-complete” product delivered

Project estimates updated

Risk list updated



There are a lot of them – see reading list

Most projects do all these (eventually)

It will take less time to do them if we plan to do them • retrofitting them into the project when we

realise they are needed just leads to inefficiency and lack of coordination

• upstream activities done downstream are significantly more expensive!


Missing a milestone Persistent overtime is not the answer

• surgical overtime is fine

Working harder to catch up may yield poor quality code/poor decisions - which ultimately cause further delays

Projects that get behind, rarely catch up

“Adding more people to a late project makes it later” … Brooks Law

Replan! If this estimate is wrong, others may well be too – recalibrate your schedule. Abandoning planning is a serious mistake!

Avoid helping out with the coding yourself!


3. Project scheduling

Why is scheduling hard? Estimating the difficulty of problems and hence the cost

of a solution is hard Human estimates are notoriously optimistic – use GAP Productivity is not proportional to the number of people

working on an activity, e.g: • “Adding more people to a late project makes it

later” The unexpected always happens

• so much for “managing for success” Rolling wave planning


Rolling wave planning

Impossible to produce detailed plans and estimates for work that is more than 2 or 3 months away

Produce detailed plans for the next stage

Accepted that plans and estimates beyond that are going to be high-level (and not precise)


Scheduling Identifying deliverables/milestones, activities, tasks The WBS is used to define the project scope

• May focus on deliverables/products and/or activities/tasks Identify inter-dependencies

• Inherent vs resource dependencies Estimating time required to complete each activity/task Creating project charts (activity, Gantt, …)

• Activity networks show task dependencies and critical path(s) • Gantt charts show schedule against calendar time

Allocating resource (most obviously staff) Re-organizing tasks to

• ensure optimal use of workforce • e.g., smoothing

• reduce project duration A complex iterative process


Identifying activities/tasks

The activity based approach

Project

Analysis Design Build

Data design Modular design

Physical design

a WBS


Identifying activities/tasks

The product-based approach (e.g., PRINCE2) identifies:

• The products to be developed; their sub-products

• External products needed

• The order in which products can be developed

• i.e., their inter-dependencies

• Product descriptions

… and then activities/tasks

To be revisited when we look at PRINCE2


The IBM WBS

Project

Component 7

Deliverable 1

WP 4

Deliverable 2 Deliverable 3

Component 14 Component 25

WP 45

Task 34 Task 35


The IBM WBS

Deliverables: software sub-systems; training materials; specification; …

Components: key work items needed to construct a deliverable, e.g., module; test plan; test reports; …

Work-package: collection of related tasks needed in the construction of a component

Task: allocated to one person

• task estimate produced by/agreed with that person


Tasks & mini-milestones

When only long term (major) milestones are used, the project team can lose a day/week without control or lose track of what is really important

Lowest level activity is often referred to as a task --- the completion of a task is a mini-milestone

The 8/80 rule (guideline)

Allocated to one person

• And estimated by that person!

Beware of confusion between estimates and deadlines

The mini-milestone list must be complete

Mini-milestones should (again) be binary

• “done means done”


Elapsed time

The calendar-time duration of an activity/task is sometimes referred to as its elapsed time

The elapsed time will depend upon

• The effort required, and

• The resources deployed

E.g., if PM = 0.6 person-months, and we allocate one person, then we might expect elapsed time = 0.6 months, but …


Elapsed time

This assumes that the person will spend all their time on the task (and our estimate is right!)

In reality we never spend all of our time on a task • Day-to-day stuff (email; regular meetings); training

courses; task switching overhead; etc. • Staff who are seconded to your project still have an

existence in the company that will take up some of their time

70% might be a typical assumption So the elapsed time might be 0.6/0.7 ≈ 0.86

months

70% of 0.86 = 0.6


Adding contingency

Stuff happens … both to be expected (sickness, holidays, …) and unexpected

We need to add contingency to our plans

• But not at the task level

• Parkinson’s law dictates that the contingency would be used up unnecessarily

• Add contingency at the stage or work-package level


4. Activity networks

Nodes represent activities (“Activity-on-node” network)

(By convention) weeks refer to “end of the week” • first activity could start week 0 – i.e., end of week 0/beginning of week 1

• employs a single activity duration (rather than multiple estimates)

Various notational conventions:

Label Duration

Earliest start

Activity description

Earliest finish

Latest start

Latest

finish

Activity span Slack/float

We’ll ignore the label


Activity network notation

Label Duration

ES T1 EF

LS LF

Span Slack

EF – ES = LF – LS = Duration LF – ES = Span LS – ES = LF – EF = Slack

useful sanity checks


Activity durations & dependencies

Activity Duration Dependencies

(weeks)

T1 5

T2 4 T1

T3 2

T4 6 T3


Activity network & critical path A critical path is one that is greater than or equal to any other

path in duration

Here critical path is T1,T2 (length = 9) If T3 slips slightly it will not extend the whole project - there is some

“slack” along the lower path – but none on the critical path

finish start

5

ES T1 EF

LS LF

Sp Sl

4

ES T2 EF

LS LF

Sp Sl

6

ES T4 EF

LS LF

Sp Sl

2

ES T3 EF

LS LF

Sp Sl

Dur.

ES Tn EF

LS LF

Sp Sl


The importance of the critical path

Identifies

Critical sub-tasks - a delay in these will extend the whole project

• Risk mgt!!

The minimum project length – could be longer if there is slippage

Sub-tasks on the critical path are ones that the project manager might attempt to

• shorten - by using more experienced staff/tools/re-use/…

• start earlier - by reconsidering the precedence requirements

Both may shorten the overall project

Of course in theory we could have 2 or more critical paths - but it is unlikely


Slack T3: available time = 3; Slack = available time - estimated time = 1

T3: ES = 0; LS = 1; T3’s slack = LS - ES = 1

finish start

5

ES T1 EF

LS LF

Sp Sl

4

ES T2 EF

LS LF

Sp Sl

6

ES T4 EF

LS LF

Sp Sl

2

0 T3 EF

1 LF

Sp 1

Dur.

ES Tn EF

LS LF

Sp Sl


Slack on the critical path T1: available time = 5; Slack = available time - estimated time = 0

Slack on the critical path is zero

finish start

5

0 T1 EF

0 LF

Sp 0

4

ES T2 EF

LS LF

Sp Sl

6

ES T4 EF

LS LF

Sp Sl

2

0 T3 EF

1 LF

Sp 1

Dur.

ES Tn EF

LS LF

Sp Sl


Computing earliest starts

start

5

0 T1 5

LS LF

Sp Sl

4

ES T5 EF

LS LF

Sp Sl

6

ES T4 EF

LS LF

Sp Sl

2

0 T3 2

LS LF

Sp Sl

Work from left to right: If T1, T3 are not dependent upon any other tasks – then clearly earliest start (ES) = 0 (beginning of week 1). Then compute the earliest finish: EF = ES + duration

finish

A slightly more complex example (to add a bit of interest)

Dur.

ES Tn EF

LS LF

Sp Sl


Computing earliest starts

start

5

0 T1 5

LS LF

Sp Sl

4

5 T5 9

LS LF

Sp Sl

6

2 T4 8

LS LF

Sp Sl

2

0 T3 2

LS LF

Sp Sl

The earliest starts (ES) for T5, T4 are now available from the earliest finishes (EF) of their predecessors. Then compute the earliest finishes (EF) of T5/T4: EF = ES + duration. Project finishes week 9. Therefore critical path has length 9.

finish

T5 ES = max{T1 EF, T3 EF} = max{5, 2} = 5

Dur.

ES Tn EF

LS LF

Sp Sl


Computing latest starts

start

5

0 T1 5

LS LF

Sp Sl

4

5 T5 9

LS 9

4 0

6

2 T4 8

LS 9

7 1

2

0 T3 2

LS LF

Sp Sl

Span = LF – ES Slack = LF - EF The “final” tasks must finish by 9 so as not to delay the overall project

finish

Work from right to left

Dur.

ES Tn EF

LS LF

Sp Sl



start

5

0 T1 5

LS LF

Sp Sl

4

5 T5 9

5 9

4 0

6

2 T4 8

3 9

7 1

2

0 T3 2

LS LF

Sp Sl

LS = LF - duration

finish

Dur.

ES Tn EF

LS LF

Sp Sl



start

5

0 T1 5

0 5

5 0

4

5 T5 9

5 9

4 0

6

2 T4 8

3 9

7 1

2

0 T3 2

1 3

3 1

T1 and T3 must finish at latest by the latest start times of the tasks that are dependent upon them

finish

T3 LF = min{T5 LS, T4 LS} = min{5, 3}

… continuing right to left

Dur.

ES Tn EF

LS LF

Sp Sl

LS = LF - duration


Gantt chart 4/7 1 1/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1

T2

M1

T7 T3

M5

T8

M3

M2

T6

T5

M4

T9

M7

T10

M6

T1 1 M8

T12

Start

Finish


Staff allocation 4 / 7 1 1 / 7 1 8 / 7 2 5 / 1 / 8 8 / 8 1 5 / 8 2 2 / 8 2 9 / 8 5 / 9 1 2 / 9 1 9 / 9

T 4

T 8 T 1 1

T 1 2

T 1

T 3

T 9

T 2

T 6 T 1 0

T 7

T 5

F r ed

J ane

Anne

Mary

Jim


Smoothing

T1

T2

T3

T4

Staff: 2 4 3 2 1 0 slack


Smoothing

T1

T3

Staff: 2 3 3 1 0

T1’s slack has been reduced

T2

T4


Smoothing

T1

T2

T3

Staff: 1 2 2 2 1

T4


Allocating resources to activities

Allocating resource (staff) to one task makes it temporarily unavailable to others

• This may cause other tasks to have to start later than they (theoretically) could have

• Who gets priority?

Slack priority --- give priority to those tasks with the smallest slack

Could also consider task risk


5. PERT

Programme Evaluation and Review Technique Having a single figure for task duration ignores the inherent

uncertainty PERT demands 3 estimates for duration

• most Optimistic (a) • most Likely (b) • most Pessimistic (c) and then specifies that the • Task Duration Estimate = (a + 4*b + c)/6

• can again be used in activity network/critical path calculations • Task Duration Standard Deviation = (c – a)/6

• can be used to estimate probability of deadline adherence


Activity duration variability

% of activities

weeks late ….. -3 -2 -1 0 1 2 3 4 5 6 …..

van Genuchten’s study found: • the most common reason for activities being late was time spent on non-project work • evidence of Parkinson’s law --- the jump from 9% to 30%

9%

30%

17%


6. Monte Carlo simulation

a b c

Probability of completion

For each activity/task, we can construct

the risk diagram (using the PERT estimates and (say) van Genuchten’s risk profile)


Monte Carlo simulation

Using a simulation tool:

repeat (a large number of times) 1. for each task: pick – in accordance with its risk profile - a

duration for the task

2. using these chosen task durations: calculate the duration of the project (or stage) using the normal forward pass through the activity network

end (repeat);

Plot a histogram of the resultant project durations to obtain a risk diagram/profile for the project


Project durations

count

duration (weeks)

20 38

99

70

40 18

40 41 42 43 44 45 46 47

e.g., Probability of finishing within 43 weeks 14 + 20 + 38 + 99 14+20+38+99+70+40+18+11 = 171/310 = 0.55

=

Typically we’d run the simulation far more times than 310

You’ll very probably see a project risk profile similar to the van Genuchten profile

11 14


52

7. Schedule control

7.1 Gantt charts


7.2 Slip charts


7.3 Ball charts

10/10/09 10/10/09

21/10/09 23/10/09

Activity A

Start of A Completion of A

Currently predicted start date (will change as estimates of start change)

Originally scheduled start date (fixed)


Ball charts

10/10/09 10/10/09

21/10/09 23/10/09

Activity A

When the task actually starts the predicted start is changed to the actual start – indicated here via bold italics underline. The colour is changed to green (on, or ahead of, time) – or red (late)


Prominent display of the “Balls-on-the-Wall” chart gives a constant reminder to the team & provides staff

“motivation”

10/10/09 10/10/09

21/10/09 22/10/09

15/10/09 25/10/09

10/10/09 12/10/09

19/11/09 29/11/09

25/11/09 29/11/09

Current Date = 23/10/09

Activity A

Activity B

Activity C


7.4 Timeline charts


7.5 Earned value management

Each activity within the project/stage has a value

• Equal to the original planned number of work-days (person days) required

When the activity is complete the project is credited with (having earned) the value of that activity

So at any given time, the earned value is the sum of the original work-days planned to achieve the currently completed activities


The baseline budget

34

40

days

work-days

Estimated project budget

The project has 3 activities: the first is due to take 40 work-days and is due to be completed by day 34

PV

PV = planned value


Earned value (EV) & actual cost (AC)

34 37

40

days

work-days

But in reality the first activity takes 37 days (where-upon the value of 40 is credited to the EV of the project) and requires 45 work-days of actual effort.

PV

EV

* 45

AC


PV, EV and AC

PV

EV AC

days

work-days


Schedule indicators

These compare current achievement

What have we achieved (now) vs. what did we plan to have achieved (by now)

• EV vs. PV

SV = EV – PV (schedule variance)

• SV > 0 is good (i.e., EV > PV)

SPI = EV/PV (schedule performance indicator)

• SPI > 1 is good (i.e., EV > PV)


Schedule variance (SV)

PV

EV

SV … in this case is < 0

work-days

days


Cost indicators

These compare costs. In order to achieve what we have now achieved:

• what did we plan to spend vs. what have we spent?

• i.e., EV vs. AC

• CV = EV – AC (cost variance)

•CV > 0 is good (i.e., EV > AC)

• CPI = EV/AC (cost performance indicator)

•CPI > 1 is good (i.e., EV > AC)


CPI

CPI = EV/AC

Suppose that CPI = 0.8

This means that AC = EV/0.8 = EV * 1.25

The actual cost (to-date) is 25% more than we planned (in order to achieve what we have)

We might also then tentatively predict that the whole project will be 25% over budget


Slippage

PV

EV

slippage

now

How much longer has it taken (to achieve what we have) than was planned

work-days

days


Slippage

PV

EV

slippage

50

e.g., Slippage = 10 days 25% overrun

40

work-days

days

Documents

Revision