January 20, 2000 CSE 7315 - SW Project Management / Chapter 7 - Detailed Planning - Sch. Est. & Negotiating Copyright © 1995-2000, Dennis J. Frailey, All

January 20, 2000

CSE 7315 - SW Project Management / Chapter 7 - Detailed Planning - Sch. Est. &

NegotiatingCopyright © 1995-2000, Dennis J. Frailey,

All Rights Reserved

Slide # 1

CHAPTER 7

DETAILED PLANNING -

Schedule Estimatingand NegotiatingNOTICE: This material is copyrighted and may be copied

or downloaded ONCE ONLY by students who are registered in this course at Southern Methodist University or National Technological University.

January 20, 2000



All Rights Reserved

Slide # 2

Detailed Planning Process

EstimateSize

EstimateEffort and

Cost

EstimateScheduleEvaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK

January 20, 2000



All Rights Reserved

Slide # 3

Three Levels of Schedule Detail

• Top Level Schedule– Generally produced during initial

planning, based on program master schedule, constraints, deadlines, etc.

• Generic Schedule– Generally produced during effort

estimation, based on the process and the information gained from estimating models

January 20, 2000



All Rights Reserved

Slide # 4

Three Levels of Schedule Detail (continued)

• Detailed Schedule– Generally produced when you are

about to execute the project or a phase of the project

January 20, 2000



All Rights Reserved

Slide # 5

Here We Will Cover Two Topics

• How to verify that the top level and generic schedule are realistic– Normally this is done as part of the effort

estimating process• How to develop a detailed schedule– This tends to be done when you are just

about to begin a particular phase of development

– But it can be done at a higher level for other purposes

January 20, 2000



All Rights Reserved

Slide # 6

Verifying that theSchedule is Reasonable

Two issues are of concern:• Total Time to Do the Job• Percent of Time and Effort in

Each Phase of the Job

How do you know whether the top level schedule is realistic?

How do you determine schedule details?

January 20, 2000



All Rights Reserved

Slide # 7

Total Time Needed• Total time needed to do the project

is a direct factor of– Size and nature of software developed– Organizational capability– Process and methods– Time constraints– Financial constraints

• This can vary significantly from one organization to the next

January 20, 2000



All Rights Reserved

Slide # 8

Estimating the Time Needed• Estimation models like Cocomo

can be used to predict the length of the schedule

• These models predict an ideal or optimal schedule

January 20, 2000



All Rights Reserved

Slide # 9

Estimating the Time Needed (continued)

• You can vary the actual schedule to fit your conditions– You have flexibility in matching

the schedule to other project constraints

– But you can drive up cost as you deviate from the optimal

January 20, 2000



All Rights Reserved

Slide # 10

The Optimal Schedule...... depends on people, process, nature

of task, environment, etc. …• Different models make different

assumptions about these factors, reflecting the experience of those who developed the models

• Until we have a better theoretical foundation, experience remains the best way of predicting your optimal schedule

January 20, 2000



All Rights Reserved

Slide # 11

Total Time to Do the JobCocomo Formula ...

e = .38 for organic .35 for semi-detached .32 for embeddedEffort is measured in staff months, as computed

by the Cocomo formula (basic, intermediate, or detailed)

Schedule is measured in calendar months

Schedule = 2.5 * Efforte

January 20, 2000



All Rights Reserved

Slide # 12

Notes on Cocomo Formula

• This formula assumes schedule compression adjustment factor = 1 (nominal)

• In other words, the schedule computed by Cocomo is an ideal schedule. – Yours is probably different.

Schedule = 2.5 * Efforte

January 20, 2000



All Rights Reserved

Slide # 13

The Cocomo Model ofTime vs Effort

staff-days

required to do

the work

Calendar Time Allocated for the Work

Optimal Schedul

e

January 20, 2000



All Rights Reserved

Slide # 14

Beware of Circular Relationship

• Schedule length is a function of effort in most models, including Cocomo

• If your schedule is different from the Cocomo ideal, then you must:– Change the “schedule compression” cost

adjustment factor– Recompute the effort (it should go up)– Do NOT recompute schedule as a function

of effort, because it is no longer valid

January 20, 2000



All Rights Reserved

Slide # 15

Other Models Give Different Formulas for Time

SLIM formula for TOTAL effort (lifetime):

SLIM equation for development effort vs development time is slightly different:

Size = Ck*Effort1/3*t4/3

So t4/3 = Size / Ck*Effort1/3)So t = (Size / Ck*Effort1/3))3/4

DE = Constant / Time4

January 20, 2000



All Rights Reserved

Slide # 16

024

68

1012

1416

18

0.5 0.6 0.7 0.8 0.9 1 1.1 1.2

RELATIVE TIME

RELATIVEEFFORT

• EFFORT = CONSTANT / TIME4

Putnam’s “SLIM”Time vs. Size Equation

January 20, 2000



All Rights Reserved

Slide # 17

Why Do Models Vary on Schedule?

Grady and Caswell compare five different sources (p34, 35) (see references)

• Differences stem from:– Type of software being developed– Schedule compression– Organizational differences– Process and methods

January 20, 2000



All Rights Reserved

Slide # 18

What to Do about Variation• Hewlett-Packard recommendations:– Measure actual data & keep for the

future– Count everything (overtime, etc.)

• Once you know YOUR organizational behavior, you can better calibrate the models to fit your experience

January 20, 2000



All Rights Reserved

Slide # 19

For Small Projects ...• General formulas tend to fit large

projects better than small ones• And you may not have a good data

base of historical schedule information

...• So it may be better to estimate the

time in a more detailed manner, as will be shown in the next section

January 20, 2000



All Rights Reserved

Slide # 20

Time may require Adjustment

• Actual project may require a different amount of time than the “ideal” computed by the models

• Project constraints may also affect the schedule

• You have a lot more flexibility with schedule than you do with size or cost

January 20, 2000



All Rights Reserved

Slide # 21

When Will Each Specific Task be

Performed?• This requires developing a more

detailed schedule• Which can also be used to give a

more accurate estimate of the total time

January 20, 2000



All Rights Reserved

Slide # 22

When Will Each Specific Task be

Performed? (continued)• Generally you start with the top

level schedule from initial planning, or the generic schedule developed during the effort estimate, and develop a more detailed schedule

• Very finely detailed schedules are best done just prior to performing the actual work

January 20, 2000



All Rights Reserved

Slide # 23

Developing theDetailed Schedule

I Needa Detailed Schedule!

Tell me How Long it

will Take and When Each Task will be Complete.

What do Ido now?

Yes, Sir!Right Away,

Sir.

January 20, 2000



All Rights Reserved

Slide # 24

What are the Details

of the Schedule?

January 20, 2000



All Rights Reserved

Slide # 25

Techniques for Developing & Documenting a Detailed

SchedulePERT Charts (PDM)– Show dependencies– Can expand to show resources, timing,

and critical pathGANTT Charts– Show timing and parallelism

Network Charts – Combine the benefits of PERT and GANTT– But you need a tool to manage them

January 20, 2000



All Rights Reserved

Slide # 26

Steps of Detailed Scheduling1) Task Dependency and Flow– Shows dependencies, but not timing

2) Task Duration– Shows minimum schedule length– Identifies the critical path

3) Critical Path Analysis– Determines what must change if the

schedule is to be reduced

January 20, 2000



All Rights Reserved

Slide # 27

Steps of Detailed Scheduling4) Resource Requirements – Shows manpower loading, cash flow,

etc.5) GANTT Chart – Shows relative timing– But not the dependencies

6) Network Chart – Combines GANTT and PERT

January 20, 2000



All Rights Reserved

Slide # 28

PERT Charts &

Critical Path Analysis

January 20, 2000



All Rights Reserved

Slide # 29

PERT“PERT” stands for

“Program Evaluation and Review Technique”

or“Performance Estimating & Reporting

Tool” (depending on which author you

read)

January 20, 2000



All Rights Reserved

Slide # 30

PERT Origins• PERT was developed in the 1940’s

as a management tool for complex projects

• In its fullest form, PERT involves complex statistical analysis of project schedules and plans

January 20, 2000



All Rights Reserved

Slide # 31

PERT Charts• The basic tool of the PERT

technique is the PERT Chart, which represents the schedule and resource needs of a project

• The PERT chart uses the Precedence Diagramming Method (PDM), which is similar to a flow chart, to represent the dependencies among activities

January 20, 2000



All Rights Reserved

Slide # 32

A Minimal PERT Chart ...• Lists activities to be performed

(from WBS)• Indicates dependencies – Activity X must precede activity Y,

etc.– This information comes in part from

initial planning (life cycle analysis, process definition)

January 20, 2000



All Rights Reserved

Slide # 33

Sample PERT Chart from Organizational Planning(in Early Planning Steps)

Prototype Final Design BuildDesignKeyboard

CodeDesignKeyboardSoftware

Test

BuildKeyboardEmulation

DeliverySubcontracted SW for Numeric Key Pad

Contract

This can be produced by

hand or with a project

management or scheduling tool.

January 20, 2000



All Rights Reserved

Slide # 34



Test

BuildKeyboardEmulation DeliverySubcontracted SW for Numeric Key Pad

Contract

An Alternative PERT Notation• Touching boxes implies

dependency• Used to reduce space • Used later in this course

January 20, 2000



All Rights Reserved

Slide # 35

• List each task on a “post-it note” or index card

• Lay out the tasks on a board• Indicate task dependencies with

lines (arcs)

Developing a PERT ChartStep 1 - Task Dependencies

Task 1 Task 3 Task 6 Task 7

Task 8Task 2 Task 5

Task 4

Task 9

January 20, 2000



All Rights Reserved

Slide # 36

Design Test Code

Design Spec

Integrate

Develop Hardware

Code VerifyTest

Evaluating Dependencies

January 20, 2000



All Rights Reserved

Slide # 37

“Test” Task

depends on

“Code” and “Test

Code”Design Test Code

Design Spec

Integrate

Develop Hardware

Code VerifyTest

Identifying Dependencies• What depends on what?

January 20, 2000



All Rights Reserved

Slide # 38

Identifying Dependencies• What dependencies are unknown?

Design Test Code

Design Spec

Integrate

Develop Hardware

Code VerifyTest

Who needs this? (no

successor)

January 20, 2000



All Rights Reserved

Slide # 39

Identifying Dependencies• What depends on what?

Design Test Code

Design Spec

Integrate

Develop Hardware

Code VerifyTest

External task that

we depend on

January 20, 2000



All Rights Reserved

Slide # 40

Finish to Start First task must finish before the second starts

Start to Start Second task must start x months after first starts

Finish to Finish Second task must finish y months after first finishes

Types of PERT Dependencies

x

y

Task 5Task 23

7

6Task 1 Task 3 Task 6 Task 7

Task 8

Task 4

Task 9

January 20, 2000



All Rights Reserved

Slide # 41

With most PERTtools, you can

specify a priority amongparallel tasks

Task 1 Task 3 Task 5Task 2 Task 4

Task 5Task 1 Task 3

Task 2

Task 4

Verifying Dependencies• Do not overconstrain -- use only

the the essential dependencies

• The following PERT chart represents a much more flexible plan

January 20, 2000



All Rights Reserved

Slide # 42

What to Learn from a Task Dependency PERT Chart• Identify dependencies you did not

know existed• Identify missing dependencies

where you do not know the successor or the predecessor

• Identify critical dependencies, such as a hardware activity that will hold you up if it is late

January 20, 2000



All Rights Reserved

Slide # 43

NOTEPERT Charts are a good method for developing a detailed process description as well as developing a project schedule



Test

BuildKeyboardEmulation DeliverySubcontracted SW for Numeric Key Pad

Contract

January 20, 2000



All Rights Reserved

Slide # 44

Developing a PERT ChartStep 2 - Task Duration

• Lay out a Time Line at the bottom of the board

• For each task, estimate its duration and write that information on the post-it note. – Can be minimum feasible duration or

expected duration based on availability of resources

• Place each task in its appropriate position relative to the time line

January 20, 2000



All Rights Reserved

Slide # 45

Developing a PERT Chart Step 2 - Task Duration

(continued)• Proper placement shows earliest

start and end date for each task

20 weeks8 weeks

Minimum total time for whole activity is 26 weeksJ F M A M J J A S O N D

6weeks

8weeks

12weeks

26 weeks

January 20, 2000



All Rights Reserved

Slide # 46

What to Learn After Durations are Added

• The first task to focus on is the very last task – Will it complete by the project

deadline?• If not, how can you make the whole

schedule shorter?• The answer starts with determining

the Critical Path

January 20, 2000



All Rights Reserved

Slide # 47

The Critical Path is ...… the longest calendar path through

the schedule from the first to the last activity

Task A

Task CTask B

Task D

Task E

The Critical Path in the above example is A,C,D

January 20, 2000



All Rights Reserved

Slide # 48

The Critical Path is ...… the path that must be shortened in order

to shorten the whole schedule… the path that drives schedule slips– If a critical path task slips, the whole schedule

slips… the riskiest part of the schedule

Be especially wary when the critical path involves dependency on external tasks that you do not

control!

January 20, 2000



All Rights Reserved

Slide # 49

• If the schedule is small, “eyeball” and determine which path is the longest.

• Otherwise a tool can be used

• Critical Path => min possible schedule

Critical PathTasks

Non-CriticalPath Tasks

Developing a PERT Chart Step 3 - Determining the

Critical Path

6 weeks3 weeks

5 weeks

January 20, 2000



All Rights Reserved

Slide # 50

What if the MinimumSchedule is Too Long?

• You must find a way to cut the schedule

• Begin with tasks on the critical path– Try to divide them into smaller tasks

that can be done simultaneously– Assign more resources so you can do

them faster• Note that when you do this you

might create a different critical path

January 20, 2000



All Rights Reserved

Slide # 51

Developing a PERT ChartStep 4 - Resource

Requirements• Determine the resource requirements

of each task:– Equipment, Facilities, etc.– Key personnel– Total labor effort (staff days, etc)– May also show minimum and maximum

reasonable allocations, i.e., 8 staff weeks: • minimum 2 weeks (4 people)• maximum 8 weeks (1 person)

January 20, 2000



All Rights Reserved

Slide # 52

Resources• Write this information on the index card or post-

it-note• Vary labor totals or types of personnel assigned

to different tasks in order to meet schedule needs

8 staff weeks:2 weeks, 4 people

8 staff weeks:4 weeks, 2 people

8 staff weeks:2 weeks, 3 senior people

These options mayreduce the critical

path or even removethis task from the

critical path

January 20, 2000



All Rights Reserved

Slide # 53

Scheduling Tools can ...… find critical path/shortest

schedule… find minimum and total effort

levels… do simulation of schedule to

determine likely outcomes when exact duration are indefinite

January 20, 2000



All Rights Reserved

Slide # 54

Scheduling Tools can … (continued)

… assist in “what if” analysis of possible alternatives

… revise schedules with minimal effort

Sample tools: Microsoft Project®, Primavera®

January 20, 2000



All Rights Reserved

Slide # 55

“Schedule from the Back” conceptMinimal execution times for each task

Assuming adequate staff, task E must be started at least 7 weeks before final integration, whereas task A must be started at least 11 weeks before!

Using PERT Charts to Decide on Development Sequence

Final Integration4 weeks

C1 week

D3 weeks

F4 weeks

E2 weeks

B6 weeks

A2 weeks

January 20, 2000



All Rights Reserved

Slide # 56

Suggested Notationfor Post-it Notes

Yellow– Normal Tasks

Pink or Red – External Tasks that You

Depend OnBlue – External Tasks that Depend

on You

January 20, 2000



All Rights Reserved

Slide # 57

Schedule for Project P(sample)

J F M A M J J A S O N D

January 20, 2000



All Rights Reserved

Slide # 58

• Gizmo hardware must arrive by June 1– We must watch their schedule

• Joe and Mary must be available 100% for this project

• Integration must wait until Sept 15• Programmers must be available on March 1• At least three test sets must be available

during the month of August

Critical Dependencies, Issues, Assumptions, and Lessons

Learned (sample)

January 20, 2000



All Rights Reserved

Slide # 59

Gantt Charts

January 20, 2000



All Rights Reserved

Slide # 60

GANTT Charts• These are devised from some of the

same data used in a PERT chart, but show the relative time phasing of the tasks instead of the dependencies

• Each “activity” box is sized to be proportional to the length of time it takes

• The boxes are lined up, usually in the order of execution, to show what is happening at what time

January 20, 2000



All Rights Reserved

Slide # 61

Sample Gantt ChartVertical line

represents current date

Task 2

Task 3

Task 6

Task 5

Task 1

Task 7

Task 4

January 20, 2000



All Rights Reserved

Slide # 62

A More Advanced Form of Gantt Chart

• Height of box indicates number of people working on the activity

• Width of box indicates length of activity

Task 2

Task 1

Task 3

January 20, 2000



All Rights Reserved

Slide # 63

Task 6

Task 5

Task 7Does Task 6 depend on Task 5? Can Task 5 finish on

time?

Gantt Chart does NOT tell you ...… task dependencies

… significance or impact of schedule slips… whether it is realistic to expect you to meet the

schedule… critical path

January 20, 2000



All Rights Reserved

Slide # 64

Network Charts

January 20, 2000



All Rights Reserved

Slide # 65Jan Feb Mar Apr May Jun Jul Aug

Network Chart --Combining the Pert and

Gantt• Horizontal width indicates schedule length • Arcs indicate dependencies• Horizontal position indicates scheduled

time and task parallelism

Task A

Task CTask B

Task D

Task E

January 20, 2000



All Rights Reserved

Slide # 66

Network Chart Summary• Tells you the duration of tasks and

their interdependencies. • Shows Critical Path• Can be color coded to show

different parts of the project– Software in blue, mechanical in red,

etc.• But it still cannot tell you if the

schedule is realistic

January 20, 2000



All Rights Reserved

Slide # 67

Possible Exam Questions Explain the Advantages and

Drawbacks of PERT charts and GANTTcharts

Discuss how a Network Chart combines the advantages of PERT and GANTTcharts

January 20, 2000



All Rights Reserved

Slide # 68

Possible Exam Questions (continued)

Discuss what information is NOT shown by a PERT chart

Discuss what information is NOT shown by a GANTTchart

Discuss what information is NOT shown by a Network chart

January 20, 2000



All Rights Reserved

Slide # 69

Project Management and Scheduling Tools

• Most such tools can show a PERT or GANTT chart

• More capable tools will show a network chart, which is hard to do by hand

But tools take a lot of work to enter data and the data changes a lot in

the early steps of detailed scheduling

January 20, 2000



All Rights Reserved

Slide # 70

Recommendations Regarding Management/Scheduling

Tools• Do a PERT chart by hand and work through the fundamental relationships

• Then use a tool after things have settled down

• Select a tool carefully– Some cannot handle the complexity of a

very large project– But the most capable tools are harder to

use

January 20, 2000



All Rights Reserved

Slide # 71

Using Network or Pert Charts to Establish a Schedule

Earliest Completion Date– Tells you how soon you can

complete– Tells you the earliest you can start

each taskLatest Start Date– Tells you how late you can start

and still meet the deadline– Tells you the latest you can start

each task

January 20, 2000



All Rights Reserved

Slide # 72

Using Network or Pert Charts to Establish a Schedule

(continued)Critical Chain Analysis– Adds analysis of critical resource

needs– Can help you manage to meet

short cycle time

January 20, 2000



All Rights Reserved

Slide # 73

Earliest Completion Date

A, C, E, F can slip without hurting schedule

E4 weeks


G3 weeks

D6 weeks

A3 weeks

B4 weeks

C2 weeks

F2 wks

17 weeks min.

Earliest Start DateLater Start Date

January 20, 2000



All Rights Reserved

Slide # 74

Latest Start Date

• A, C, E, F can start late without hurting schedule• B, D, G, Final must start as shown, since on

critical path


G3 weeks

D6 weeks

A2 weeks

B4 weeks

C2 weeks

F2 wk

E4 weeks

17 weeks min.

Earlier Start DateLatest Start Date

January 20, 2000



All Rights Reserved

Slide # 75

Critical Chain Analysis&

Slack Management

January 20, 2000



All Rights Reserved

Slide # 76

• A Critical Resource is a resource that is required 100% on each of two or more tasks– A piece of equipment– An individual with

unique skills• A critical resource can

usually be used by only one task at a time

• If shared, each task gets only part time use

?

Youare

essentialto myproject

Myproject willfail without

you

Critical Resources

January 20, 2000



All Rights Reserved

Slide # 77

• If two tasks need a resource, one must give it up or both must run slower

• But it is tempting to fantasize that you can share resources without such high waste

Sharing a Resource MeansLess Efficiency

Percent Use AvailabilityWaste

100% 85% 15%50%+50% 40%+40% 20%33%+33%+33% 25%+25%+25% 25%25%+.... 17.5%+.... 30%

January 20, 2000



All Rights Reserved

Slide # 78

Using Critical Resources• If the resource is critical, it is also

known as a constraint• The fundamental rule of constraint

management is that you should maximize the efficiency of the constraint

• Which means you should avoid overusing constraints and wasting time on inefficient sharing

January 20, 2000



All Rights Reserved

Slide # 79

If Task B needs a resource that is also needed by Task A then Task B is on the

Critical Chain

The Critical Chain• The critical chain consists of all

tasks using resources that are needed on the critical path

Task A

Task CTask B

Task D

Task E

January 20, 2000



All Rights Reserved

Slide # 80

Critical Chain Analysis• Start with Latest Start Date

schedule • Mark critical path tasks as “on

the critical chain” & identify resources needed for these tasks

January 20, 2000



All Rights Reserved

Slide # 81

Critical Chain Analysis (continued)

• If also needed elsewhere in parallel tasks, mark those tasks as “critical chain” tasks

• Reschedule those tasks earlier, so there is no conflict of resources

• This may change the critical path!

January 20, 2000



All Rights Reserved

Slide # 82

Conventions for Critical Chain Analysis

ConflictEarlier Start Date

Latest possible

Start Date

NormalTasks

Critical Pathand

Critical Chain

Critical Chainbut Not

Critical Path

CriticalPath Tasks

January 20, 2000



All Rights Reserved

Slide # 83

Example of Critical Chain Analysis

G and F need the same critical resourceSo F and its predecessors (E, C) must be started

sooner

A3 weeks


G3 weeks

D6 weeks

B4 weeks

E4 weeks

C2 weeks

F2 wk

17 weeks min.

January 20, 2000



All Rights Reserved

Slide # 84

A Further Example

• A and C cannot proceed in parallel• This changes the critical path and lengthens

the schedule!

H4 wks

G3 wksA

3 wks

E4 wks

C2 wks

F2 wks

B4 wks

D6 wks 18 weeks

minimum

Suppose A and C need the Same Critical Resource

January 20, 2000



All Rights Reserved

Slide # 85

Other Schedule Management Techniques

• Do more careful monitoring of critical path and critical chain tasks

• Start critical chain tasks as soon as you can - to provide maximum risk control

• DO NOT allow people to include slack time in their task schedules. All slack should be held in reserve by a higher level manager

January 20, 2000



All Rights Reserved

Slide # 86

Example of Slack Management Problem


G3 weeks

E4 weeks

C2 weeks


G3 weeks

E4 weeks

C2 weeks

Plan: C and E allow slack to reduce risk

Actual: C and E wait until last possible minute to start

January 20, 2000



All Rights Reserved

Slide # 87

What Might Really Happen


G5 weeks

E4 weeks

C2.5 weeks

Reality: C and G slip a little bit …

C’s slip is absorbed by E’s slackBut G’s slip causes the whole project to slip 2

weeks

January 20, 2000



All Rights Reserved

Slide # 88

Slack Management


G5 weeks

E4 weeks

C2.5 weeks

Actual - Slack can be applied to any task that slips, so the project stays on schedule

Plan: C and E have no slack


G3 weeks

E4 weeks

C2 weeks Slack - 4 wks

January 20, 2000



All Rights Reserved

Slide # 89

Negotiating

January 20, 2000



All Rights Reserved

Slide # 90

Detailed Planning Process

EstimateSize

EstimateEffort and

Cost

EstimateScheduleEvaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK

January 20, 2000



All Rights Reserved

Slide # 91

If the Plan is Not Feasible• DO examine assumptions and data– initial cost estimates are often very

conservative• Do examine risk/cost tradeoffs to

see if you can accept a higher risk• Do make a list of barriers that

must be removed in order to make the estimate fit the constraints

January 20, 2000



All Rights Reserved

Slide # 92

“The quickest way to make a project uneconomical is by

doubling the resources needed and using the cover story that you need

to prevent failures.” Adams, The Dilbert Principle

If the Plan is Not Feasible• DO NOT “cave in” & lower

everything to meet a target cost or schedule

January 20, 2000



All Rights Reserved

Slide # 93

The Negotiation ProcessWe MUST have

the lowest bid!!!We will, boss!!!

Management will try to trim the budget by sending an army of low-ranking, clueless budget

analysts to interview you and ask “insightful” questions. Adams, The

Dilbert Principle

January 20, 2000



All Rights Reserved

Slide # 94

Re-think key factors

Spreadsheet for estimating

This will never satisfy the cost

goal!???!

January 20, 2000



All Rights Reserved

Slide # 95

Identify Opportunities and Barriers

Barriers

Opportunities to Cut

January 20, 2000



All Rights Reserved

Slide # 96

Negotiate

If they will cut back on the reviews

and ...

Well, I’ll think about

it

January 20, 2000



All Rights Reserved

Slide # 97

Beware ... Estimates are Never

Perfect

January 20, 2000



All Rights Reserved

Slide # 98

Estimating Accuracy vs. Phase

0

0.51

1.52

2.53

3.54

4.5

Feasibility Plans Design DetailedDesign

CodeandTest

Release

Upper LimitActual

Lower Limit

• Typical Estimates

• • • • • • •

•

January 20, 2000



All Rights Reserved

Slide # 99

Some Opportunities to Offer• Plan to re-estimate after

important milestones• Prioritize requirements and

promise to deliver the top ones by the deadline – Incremental deliveries

January 20, 2000



All Rights Reserved

Slide # 100

Some Opportunities to Offer (continued)

• Put a high cost on requirements changes

• Look at each “adjustment factor” in Cocomo as an opportunity

• Get training for everyone

January 20, 2000



All Rights Reserved

Slide # 101

Some Typical Barriers to Faster Schedule or Lower Cost• Lack of adequate resources– Software, tools, people, etc.

• Slow approval cycles for required resources

• Poor coordination with other disciplines, other companies, etc.

• Customers, peers in other disciplines, and managers who don’t understand software development very well

January 20, 2000



All Rights Reserved

Slide # 102

Some Difficult Barriers to Faster Schedule or Lower Cost• Irascible and irrational

customers & managers• Intentional barriers– Competitors, etc– Political constraints

January 20, 2000



All Rights Reserved

Slide # 103

Negotiating Tip . . .• The more facts you have, the

better off you are during negotiation

• Get them to review your estimate

– Sometimes they don’t bother• Be well prepared to explain it

January 20, 2000



All Rights Reserved

Slide # 104

Several Iterations are Likely

• Identify the factors that affect the cost and schedule– Experience levels, stability levels, etc.

• Examine sensitivity of the results to various factors

• Examine historical data to make a better picture of probable events

• Don’t put too much faith in the accuracy of models

That’s why you should use a spreadsheet!

January 20, 2000



All Rights Reserved

Slide # 105

Summary - I• Optimal schedule depends on many

factors unique to the project• “Bottom up” scheduling uses PERT,

GANTT, and Network charts.• Basic PERT chart shows dependency

& flow only• Adding task duration shows critical

path and shortest possible schedule length - but not relative timing

January 20, 2000



All Rights Reserved

Slide # 106

Summary - II• Critical path analysis identifies what tasks

must be shortened to shorten the overall schedule

• Adding resource requirements enables you to decide on sequencing and when to schedule tasks and resources

• GANTT shows relative timing but not dependencies, flow

• Network chart shows both, but requires a more capable tool

January 20, 2000



All Rights Reserved

Slide # 107

Summary - III• Critical Chain shows resource conflicts

between critical path tasks and other tasks

• Critical Resources must be managed to avoid impact on critical path

• Critical Chain Analysis shows which tasks must be started earlier in order to avoid resource conflicts

• Slack Management gives maximum risk control and shortest cycle time

January 20, 2000



All Rights Reserved

Slide # 108

Summary - IV• When the plans show that there is

not enough time or money to do the job,

NEGOTIATE - don’t CAPITULATE

• Having the facts will help you in the negotiation process

• Expect several iterations

January 20, 2000



All Rights Reserved

References1) Brassard, Michael, The Memory Jogger Plus+,

Goal/QPC, Methuen MA, 1989.2) Goldratt, Eliyahu M. & Jeff Cox, The Goal,

(North River Press, 1984.) Also Theory of Constraints and It’s Not Luck.

3) Thayer, Richard H., ed., Software Engineering Project Management, IEEE Computer Society Press, 1994.

4) U. of West Florida, PERT Home page, http://www.uwf.edu/~coehelp/studentaccounts/rnew/perthome.html

January 20, 2000



All Rights Reserved

Slide # 110

End of Chapter 7

January 20, 2000



All Rights Reserved

Slide # 111

Addendum

How to Develop a More Detailed PERT

January 20, 2000



All Rights Reserved

Slide # 112

Developing a Detailed PERTTop Down Approaches

• Start with top level process for each major activity -- draw PERT based on known dependencies

• An activity with more complex dependencies

Prototype Final Design BuildDesign

CustomerAssessment

MarketingReview

• A simple activity with linear dependencies


January 20, 2000



All Rights Reserved

Slide # 113

Developing a PERT from the Top Down (continued)

• Then, for each process step, decompose into sub-activities


. . . .

.

SelectComponents

DesignInterfaces . . . .

.

• At each level, determine dependencies between the subactivities at that level

January 20, 2000



All Rights Reserved

Slide # 114

At Lower Levels there areTwo Options

1) Limit dependencies at each level to those within that level

. .

.

January 20, 2000



All Rights Reserved

Slide # 115

A More Powerful Option2) Flow dependencies down from higher level

and determine dependencies between tasks at the same level from different higher level activities. I.e., determine all dependencies with other tasks, regardless of whether they are part of your activity or someone else’s.

. . . . .

January 20, 2000



All Rights Reserved

Slide # 116

Developing a PERT from the Bottom Up

• At the bottom level, determine all dependencies with other tasks, regardless of whether they are part of your activity or someone else’s

Note that you are only determining dependencies related to your specific activity

. . . .

.

January 20, 2000



All Rights Reserved

Slide # 117

Developing a PERT from the Bottom Up (continued)

• Do the same for other activities (or the people in charge of them should do this)

. . . . .

January 20, 2000



All Rights Reserved

Slide # 118


• Then move up a level and coalesce dependencies from lower level tasks

. . . . .

January 20, 2000



All Rights Reserved

Slide # 119


• Continue this until you get to the top

• Then you will have a complete list of task dependencies

January 20, 2000



All Rights Reserved

Slide # 120


NOTE: Many PERT tools do not support dependencies at the lower levels except within a given higher level activity. For these cases you must determine the higher level dependencies between activities by hand - (and could miss some of them as a result)

January 20, 2000



All Rights Reserved

Slide # 121

Alternative Bottom-up Approach

• Start with bottom level tasks• Determine all dependencies• Decide which ones to group together

based on logical dependency flows, strong dependencies

• Move up a level and repeat• Continue until you get a comfortable

“top level” map

January 20, 2000



All Rights Reserved

Slide # 122

Alternative Bottom-up Approach

NOTE: this approach may produce surprising results - combining things that did not seem appropriate to combine -- it is sometimes a good way to define teams on the project as well

January 20, 2000



All Rights Reserved

Slide # 123

Sample Result

January 20, 2000



All Rights Reserved

Slide # 124

Iterate the Process• Whether you go bottom up or top down, your initial

results may identify problems, inconsistencies, impossibilities, and unknowns that need to be resolved

• Resolution will result in redoing the PERT• For that reason, a good tool is recommended to

automate the process

NOTE: normally you will not iterate the basic PERT, but will iterate a more complete PERT after

developing the more advanced forms of PERT described in the next several slides

Documents

January 20, 2000 CSE 7315 - SW Project Management / Chapter 7 - Detailed Planning - Sch. Est. & Negotiating Copyright © 1995-2000, Dennis J. Frailey, All