Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 1 5/1/2003 Day 5, Part 2 Applying the Principles and Techniques of Productivity,

Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 15/1/2003

Day 5, Part 2Applying the Principles and

Techniquesof Productivity, Quality and Cycle

Time Management

Software Project Planning and Management

Dr. Dennis J. FraileyPrincipal Fellow

Raytheon Company


The Overall Planning Cycle

AnalyzeJob

Manage Risks

Execute

GenerateDetailed Plans

GenerateInitial Plans

Measure, Manage Productivity and Quality


Summary of This Module• Simplifying the process

– Reduce rework– Make processes more consistent– Analyze value-added (see part 1)– Analyze and optimize process flow– Periodically re-engineer the process

– but not so often as to be disruptive– Manage the white space

• Exercise to apply and demonstrate the power of these techniques


Process Simplification


Many Processes are Too Complex

How to Change a LightbulbVolume 1

Volume 2

Volume 3

Volume 4

Volume 5


Process Complexity Means Low Productivity and Long Cycle

Time •Typical software development processes are much more complex than they need to be

•This often results from trying to be too comprehensive or too rigid– Processes are important– But they must be designed for efficiency

We need to focus on eliminating steps that do not add value to the product


Ways of Analyzing Processesto Simplify Them

• Reducing rework• Making processes more

consistent• Value-added analysis• Flow analysis• Re-engineering the process• Managing the white space


Reducing Rework


Reducing Rework - The Impact

of Defects on Cycle Time

ProcessStep

Undetected Defect

Several Steps

ProcessStep

Defect Detected

Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 105/1/2003

Doing It Over Again

ProcessStep

Undetected Defect

Several Steps

ProcessStep

Defect Detected

Rework costs money and time


The Longer It Takes To Detect, The Higher The Cost

COST

PHASE WHERE DETECTED


Look for Rework• Rework is anything you do because

you didn’t do it right the first time.– debugging– correcting documentation– correcting designs– correcting requirements– re-testing– responding to customer complaints

• Some rework is hard to avoid but most can be reduced significantly


Rework = Inefficiency• Total rework is a measure of

process efficiency• You probably have a lot more

rework than you think


Making Processes More Consistent


Impact ofInconsistent 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

SystemEngineer

Story


Example of InconsistentProcesses and Procedures

On one project, we found that roughly 50% of the cycle time was spent in the following activities:

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


Making Processes More Consistent

• Use standards, especially for interfaces and data formats

• Use compatible tools and procedures (even if they are not optimal for individual tasks!)

• Develop a culture that resists “ownership” of processes

and methods EmailStory


Flow Analysis


Flow Analysis IdentifiesProcess Bottlenecks

• Determine what people actually do throughout the entire software development cycle– what is their actual, day-to-day process?

• Diagram the actual process flow– (not what you think it does - what it

really does!)• Draw a flow chart or other diagram


Sample Process Flow DiagramSTART

CHECK STATUS

CORRECTERROR COUNT?

GO TO DEBUG STEP

DEBUG ERRORS

LOGOUT

INSPECTMODULE

OK?

LOGOUT

IS ERRORCORRECTIONCORRECT?

APPROVE

LOGOUT

FINISH

DETERMINE WHY?REPEAT INSPECTION

CORRECT ERROR CNT

CORRECT THE ERROR

NO

YES

NO

NO

YES

YES

FIND SW MODULE


Show Everything• Include all inputs, outputs,

inspections, rework, temporary storage, set ups, etc.– everything that happens

• Determine which components do not add value

• Identify opportunities to eliminate waste and flow problems

• Focus on non-essentials


Areas to Focus On• Procedures and methods

– Are they working effectively?– Are they interfacing well with each other?

• People– Are they using their time efficiently?– Are they spending too much time waiting

between tasks?• Coordination - or lack of it

… continued


More Areas to Focus On• Computers and Software

– Are they available and effective?– Is too much time spent getting them to

work?• Requirements/specifications/other

inputs– Are they available when needed?

• Queues and waits– Where is the excess WIP?


Identifying Queues and Waits

Think of yourself as the software product being developed.

Take yourself through the process. At what points are you just waiting, with no

useful work being performed? These are bottlenecks, waits or queues that

should be removed


Example -Eliminating Queues and

WaitsProblem: you take a long time to complete unit test because everyone

needs the test system at the same time

Analysis: the test system is a constraintSolution: optimize the constraint! I must have

the test system today!

But I must

have it too!!


Some Options for Solution• Stagger development schedules to

even out use of test system– costs more up-front planning– requires people to be flexible in their

schedules• Obtain more test systems

– costs more money– but may be worth it


Exercise - The Passing Game• Input: Six coins piled on the end of a long

table, with six people lined up on one side of the table

• Output: Six coins piled on the other end of the table

• Goal: Shortest time / highest productivity Finish

Start


Rules for The Passing Game• Each coin must be picked up before

it is moved.• Each person must hold each coin for

a minimum of 1 second -- if they do not, you get a penalty - the coin moves back to the starting pointSee how fast you can move the coins by

coordinating and synchronizing your handoffs


Typical Results

• First time - 22 seconds• After coordination of handoffs -

13 seconds


Re-engineering the Process


• Organizations usually begin by designing themselves to fit the needs of the customer, the business environment and the available technology

Organizations Optimize toFit the Customer

OrganizationCustomer, Environment,

Technology


• After time, the organization no longer fits the customer and/or the available technology

But Things Change

OrganizationCustomer, Environment,

Technology


Process Re-engineering• Basic Idea: from time to time, it is

necessary to reinvent the process• Motivation can come from:

– intense competition– new technologies– new customers– new laws– other changes in the environment– realization that competition does it better– realization that you have not rethought the

issues in a long time and may be stagnating


Changes Make Organizations and Processes Obsolete

You define your

organization to mirror or support a

given environment.

But environments change and changes can

make organizations less effective.


Organizations Need Periodic Redesign or Re-engineering

“We’ve always done it this way and it works just fine”

• Assess the environment• Rethink the processes• Reinstate the direct connections to

– customers– suppliers– employees– etc.


Example 1Credit Approval Process

Before:

• Credit approval must go through six departments

• Each department takes 2-3 business days• So credit approval typically takes 3 weeks

Meanwhile, the competition is approving credit in 1 week!

And we are losing sales because of this.


SolutionCredit Approval Process

• Each department must increase productivity and reduce cycle time to 1 day per approval step

• Each department does this through incentives (bonuses, rewards, etc.)

Will this work?>If so, why?>If not, why not?


Wrong Solution!Credit Approval Process

• It is accomplished by – Rejecting faulty input (even slightly faulty)– Producing output that is often defective

Result: Average credit approval takes 6 weeks!

Greatly increased rework!


• One individual handles all six steps of each transaction

• The six former departments become consultants, available to handle special cases but not involved in routine cases

Re-engineered SolutionCredit Approval Process

Credit approvals reduced to 1 week!


Analysis• Changed the process• Changed the organization structure

– Responsibilities– Authority

• Changed the culture– What is important is serving the

customer


Example 2Graphic Artist Group

Original Process:

Need

Graphic Artist Design

Group:Assignment

Dept

G1G2

G3G4

G5

Design

Graphic Artist Printing

Group:Assignment

Dept

P1P2

P3P4

P5

InspectionGood Products

Defective Products

Sample



Original Process:

Need


Group:Assignment

Dept

G1G2

G3G4

G5

Design


Group:Assignment

Dept

P1P2

P3P4

P5


Defective Products

Sample

Motive for this

approach: even

workloads



Original Process:

Need


Group:Assignment

Dept

G1G2

G3G4

G5

Design


Group:Assignment

Dept

P1P2

P3P4

P5


Defective Products

Sample

Bad samples are common on the first attempt due to the nature of the work.



Original Process:

Need


Group:Assignment

Dept

G1G2

G3G4

G5

Design


Group:Assignment

Dept

P1P2

P3P4

P5


Defective Products

More defects are generated on the second cycle!

Sample


Re-engineered Process forGraphic Artist Group

Improved Process:

Need

AssignmentDept

G1G2

G3G4

G5

Design

P1P2

P3P4

P5


Defective Products

Sample


Re-engineered Process forGraphic Artist Group

Improved Process:

Need

AssignmentDept

G1G2

G3G4

G5

Design

P1P2

P3P4

P5


Defective Products

By tying a graphic designer to a printer for the whole job, defects were repaired quickly and

good products had greatly reduced cycle time.

Sample


Problem: there are many delays during software test because of requirements errors and changes– Rework to fix code to match new

requirements Analysis: we didn’t have time to examine

and rework the requirements earlier

Example 3 SW Process Takes Too Long


Process changes: – ADD a requirements inspection – ADD time in the requirements phase

to correct defective requirements– MODIFY the reward system to foster

discovery of requirements defects during the requirements phase

Improving the SW Process


• Reduced total development time– Modest increment to requirements analysis

schedule– Large reduction in debugging time

• Reduced cost – The number of staff during requirements was

smaller than the number during test– The amount of rework during the test phase was

smaller so they saves money

Results of Re-Engineering to Reduce Rework


Rethinking The Passing Game

• Re-engineer the process• You must follow the rules• But examine the assumptions

Hint:it can be done in under 2

seconds!


What Assumptions were Invalid?

Why did we make them?


How Often do you Need toRe-engineer?

• Re-engineering is disruptive, so you should not do it too often

• Conditions that call for re-engineering:– Changed customer environment– Significant new technology– Significant new competitive circumstances– Need to make the process more efficient from the

customer’s perspective– Significant new but different business opportunity


Examples ofSuccessful Re-engineering

• Federal express vs post office– Who would’ve thought that flying a package to

Tennessee and back is faster than trucking it for 200 miles?

• 10 minute oil change vs car dealer– Someone realized that

• Service stations seldom provide this service anymore• Car dealers are too slow to satisfy customers


Managing the White Space


White SpaceA Fundamental Problem of Of

Hierarchical Organizations

Too many handoffs between departments, where there is no responsibility at the point of need,

only much higher in the organization


Managing the White Space• The “white space” represents all

of the parts of your process that nobody is responsible for

• Or where the responsibility is too far from the day to day process– handoffs between organizations or

activities– changes in responsibility– etc.


The Classic“White Space” Situation

21 43 65 87

Orga

niza

tiona

l Hie

rarc

hy

8-step Process for Serving the Customer


The Classic“White Space” Problem

21 43 65 87

Who is responsible for this handoff?

Orga

niza

tiona

l Hie

rarc

hy


The Classic“White Space” Problem

21 43 65 87

Orga

niza

tion

al H

iera

rchy

Who is responsible for this handoff?


How Do You Reduce theWhite Space?

• Re-design the process to provide optimal flow to the customer– (minimize white space)

• Re-design the organization to align responsibility directly with the process– (minimize mismatches)

Consider the credit approval and graphic artist examples.


How Do You Manage theWhite Space?

• Assign responsibility for interfaces– With authority equal to or greater than that of product

development steps– This concept requires rethinking how we assign responsibility

and authority• Assign overall responsibility for the entire process flow

– At a level where day-to-day activity is visible


White Space Management Software Development

ExampleMicrosoft “integrate every day” strategy• Interfaces are defined early in the

process and placed under change control

• Mock-ups of the complete system are defined at the start of the project

• Integration team has control over all interface changes

• An integration test is run every day


Effect on Software Developer• Your module or function is not

complete until it integrates with the rest of the system without introducing any problems

• If your module fails this test, you must take it back and fix it


Effect on Software Process• Integration and test errors are

minimized at the end of the process• The product can be “shipped” at any

time after the major features are successfully integrated– Additional time, if any, allows for less

important features– Features that don’t get done in time

wait for the next release


Summary• Simplify the process

– Reduce rework– Make processes more consistent– Analyze value-added– Analyze and optimize process flow– Periodically re-engineer the process

– but not so often as to be disruptive– Manage the white space


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).

• Hammer, Michael & James Champy, Reengineering the Corporation, - A Manifesto for Business Revolution (Harper Collins, 1993.)

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


Additional References1. Bartlett, Christopher A. and Sumantra Ghoshal, "Changing the

Role of Top Management: Beyond Strategy to Purpose" Harvard Business Review, Nov-Dec 1994 (and Jan-Feb 95, May-Jun 95)

2. Beatty, Richard W. and David O. Ulrich, "Re-Energizing the Mature Organization" Organizational Dynamics, date unknown, sometime in 1991 or 1992

3. Belasco, James A., Teaching the Elephant to Dance - Empowering Change in Your Organization, Crown Publishers, 1990

4. Boynton, Andy and Bart Victor "Organizations and Change: A Consultant's View", from a presentation, date unknown, probably Oct 1992

5. Duck, Jeanie Daniel: “Managing Change: The Art of Balancing” Harvard Business Review, Nov-Dec 1993

6. Deming, W. Edwards, Out of the Crisis, MIT, 19827. Fiman, Byron: “Accelerating Change” by Implementation

Management Associates, Inc, presented by Byron Fiman


Additional References8. Frey, Robert, "Empowerment or Else" Harvard Business Review,

Sep-Oct 19939. Hall, Gene, Jim Rosenthal, and Judy Wade, “How to Make

Reengineering Really Work” Harvard Business Review, Nov-Dec 1993

10. Kotter, John P., “Leading Change: Why Transformation Efforts Fail” Harvard Business Review, Mar-Apr 1995 (reprint # 95204)

11. Peters, Tom, “The Tom Peters Seminar - Crazy Times Call for Crazy Organizations” 1994

12. Stevenson, Wayne, President and CEO of Control Systems International, from a lecture in Jan 1995

13. Tichy, Noel M. and David O. Ulrich, "The Leadership Challenge - A Call for the Transformational Leader" Sloan Management Review, Massachusetts Institute of Technology, Fall 1984, Volume 26, Number 1

Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 1 5/1/2003 Day 5, Part 2 Applying the Principles and Techniques of Productivity,

Documents