CSE 7315 - SW Project Management / Module 23 - Cycle Time Management and Negotiation Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M23

CSE 7315 - SW Project Management / Module 23 - Cycle Time Management and NegotiationCopyright © 1995-2004, Dennis J. Frailey, All Rights Reserved Slide 1

CSE7315M23

January 8, 2004

SMU CSE 7315 / NTU SE 584-NPlanning and Managing a

Software Project

Module 23Cycle Time Management and

Negotiation

Slide # 2 January 8, 2004

CSE 7315 - SW Project Management / Module 23 - Cycle Time Management and

NegotiationCopyright © 1995-2004, Dennis J. Frailey,

All Rights ReservedCSE7315M23

Objectives of This Module• To introduce basic concepts of

cycle time management• To discuss negotiation of estimates





Introduction toCycle Time Management

• Cycle time is addressed in more detail in the course CSE8314 (NTU SE 762-N).

• Here we present some simple tips for cycle time management.





Detailed Planning Process

EstimateSize

EstimateEffort and

Cost

EstimateScheduleEvaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK





What Is Cycle Time?• The amount of time it takes from the

beginning of your project to the end• You must count everything,

including delays, waits, etc.

Looking at cycle time helps you see causes for schedule slips that you might miss using other methods





What Makes Cycle Time High?

• Excessive inventory or work in process (WIP)– Work waiting around but not being done– Higher overhead, longer delays

• Process flow variability– Excessive waiting and long queues

• Complexity and inefficiency of processes– Redundant and unnecessary steps





3 Steps to Cycle Time Reduction

1. Reduce variability2. Simplify the process3. Reduce WIP

N

A VY


CSE7315M23

January 8, 2004

Reducing Variability

Too often, we create variability -- mistakenly thinking we are

improving performanceFor example, expediting some

parts of the work due to “priorities”





0 5 10 15 20 25 30 35 40 45 50 55 60 65 700

10

20

30

PERCENT EXPEDITED

• When we expedite a task, other tasks are delayed

• In some cases, each task waits until it is expedited before it moves at all

Cycle

Tim

e M

ultip

lier

for U

nexp

edite

d Ta

sks

Expediting is Bad for Cycle Time





BAU

7 14 21 28CYCLE TIME (DAYS)

NumberOf

Tasks

ExpeditedTasks Delinquent

Tasks

7 14 21 28

NumberOf

Tasks

CYCLE TIME (DAYS)

With managed priorities, you

improve the normal case and reduce the

need for “priority tasks”

Managed Expediting


CSE7315M23

January 8, 2004

Inefficient Processes

Often our processes are inefficient because of factors

that we have not paid attention to





Examples of Inefficient Processes and Procedures

• Tools do not share data• Individuals do not understand each others’

work• Excessive time and effort spent on interfaces

between different individuals and organizations





Waste Due to Inefficient Processes and Procedures

Cycle time is wasted on such activities as:

Real WorkConversionCorrectingLanguages

– Converting documents and software from one tool/format to another

– Correcting problems due to different programming styles

– Handling interfaces between programs written in different languages


CSE7315M23

January 8, 2004

Reducing Work In Process (WIP)

The Key is Smooth Flow





Smooth Flow

• The ideal process flows smoothly, like a train running on tracks.

• Note: tracks are empty most of the time





Uneven Flow• The typical process runs unevenly,

like vehicles on a city street– Lots of entrances and

exits– Vehicles of different sizes and speeds– Some drivers are uncertain of what they

want to do– Lots of stoplights to “control” the flow

(mainly to prevent collisions)• Streets are usually crowded (with WIP!)





Webster’s definitions:•Utilize: to make use of•Busy: constantly active or in motion•Productive: yielding or furnishing

results, benefits or profitsWe tend to measure utilization by how

busy we are, but utilization tells us little about how productive we are

We should work to increase productivity•This may require decreasing

utilization!

Utilization vs Productivity





EFFECTIVE UTILIZATION

CYCL

E TI

ME

Running assets at a high effective utilization

requires a costly cycle time trade off

For details of theory,

see Gross and

Harris in reference

list.

100%

Why Reduce Utilization of Critical Resources?





Other Cycle Time Hints





• Practitioners generally focus on their work and on what they think is happening rather than on what is happening– They tend not to see all of the waits, queues,

etc. that they cause themselves– Their perception of how they spend their

time is generally incorrect

Practitioners May Not See Problems and Opportunities





Just as athletes rely on coaches, software

engineers need to learn to trust in

others to observe and help them do

betterEgoless

Programming

Independent Observers See Problems and Opportunities

• They are not so busy getting the job done to see how they might improve it





Software Developers Are Accustomed to Improving

Cycle Time • Think of your software development process as a large computer program that runs too slow. How would you make it run faster?

• Imagine how you would speed up a computer program . . . . . . . .

• Then draw analogies to the software development process -- and improve the process the way you would improve a program





Examples of Software Cycle Time Techniques

• “Just-in-time” training• Plan testing / test equipment in advance• Rethink the detailed design process

– Do you need to maintain detailed design documentation?– Do you need to do detailed design at all?

• Use on-line requirements and design models instead of paper documents and specifications





Examples of Commonly Found Cycle Time Obstacles

• Poor communication /cooperation between software development and the rest of the organization

• Poor management of unstable requirements, algorithms & interfaces

• Contention for test assets -- need better planning, assets allocated to software test

• Poorly qualified subcontractors





More Cycle Time Obstacles• Excessive paperwork, signatures,

and reporting– Negotiate reductions with

management and customer• Reuse of software not designed for

reuse• Attempts to use the latest tools

and methods -- without adequate support and integration





Negotiating





Detailed Planning Process

EstimateSize

EstimateEffort and

Cost

EstimateScheduleEvaluate

Source InformationStatement of Work

RequirementsConstraintsStandardsProcesses

Historyetc.

WBS Size

Effort &

Cost

Schedule

OKCompleteDetailedPlanning

Revise &Negotiate

Not OK





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





“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





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





Re-think key factors

Spreadsheet for estimating

This will never satisfy the cost

goal!???!





Identify Opportunities and Barriers

Barriers

Opportunities to Cut





Negotiate

If they will cut back on the reviews

and ...

Well, I’ll think about

it





Beware ... Estimates are Never

Perfect





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

• • • • • • •

•





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





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





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





Some Difficult Barriers to Faster Schedule or Lower Cost

• Irascible and irrational customers & managers

• Intentional barriers– Competitors, etc– Political constraints





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





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!





Module Summary - I• Cycle time problems are usually

traced to three factors:– Variability in processes– Inefficient processes– Excessive work in process (WIP)

• Many cycle time improvements require looking at the whole process instead of just individual steps of the process





Module Summary - II• 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





END OFMODULE 23





References• Goldratt, Eliyahu M. & Jeff Cox, The

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

• Gross and Harris, Fundamentals of Queueing Theory, Wiley, pp 10-11, 101-102

• Swartz, James B., The Hunters and the Hunted, (Portland, Oregon, Productivity Press, 1994) ISBN 1-56327-043-9

Documents

CSE 7315 - SW Project Management / Module 23 - Cycle Time Management and Negotiation Copyright © 1995-2004, Dennis J. Frailey, All Rights Reserved CSE7315M23