Upload
julian-garrett
View
219
Download
0
Embed Size (px)
DESCRIPTION
Copyright © , Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 3 5/1/2003 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
Citation preview
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 25/1/2003
The Overall Planning Cycle
AnalyzeJob
Manage Risks
Execute
GenerateDetailed Plans
GenerateInitial Plans
Measure, Manage Productivity and Quality
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 35/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 45/1/2003
Process Simplification
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 55/1/2003
Many Processes are Too Complex
How to Change a LightbulbVolume 1
Volume 2
Volume 3
Volume 4
Volume 5
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 65/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 75/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 85/1/2003
Reducing Rework
Copyright © 1995-2003, Dennis J. Frailey, All Rights Reserved Day 5, Part 2, Page 95/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 115/1/2003
The Longer It Takes To Detect, The Higher The Cost
COST
PHASE WHERE DETECTED
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 125/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 135/1/2003
Rework = Inefficiency• Total rework is a measure of
process efficiency• You probably have a lot more
rework than you think
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 145/1/2003
Making Processes More Consistent
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 155/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 165/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 175/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 185/1/2003
Flow Analysis
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 195/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 205/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 215/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 225/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 235/1/2003
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?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 245/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 255/1/2003
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!!
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 265/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 275/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 285/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 295/1/2003
Typical Results
• First time - 22 seconds• After coordination of handoffs -
13 seconds
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 305/1/2003
Re-engineering the Process
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 315/1/2003
• 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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 325/1/2003
• After time, the organization no longer fits the customer and/or the available technology
But Things Change
OrganizationCustomer, Environment,
Technology
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 335/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 345/1/2003
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.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 355/1/2003
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.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 365/1/2003
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.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 375/1/2003
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?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 385/1/2003
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!
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 395/1/2003
• 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!
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 405/1/2003
Analysis• Changed the process• Changed the organization structure
– Responsibilities– Authority
• Changed the culture– What is important is serving the
customer
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 415/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 425/1/2003
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
Motive for this
approach: even
workloads
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 435/1/2003
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
Bad samples are common on the first attempt due to the nature of the work.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 445/1/2003
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
More defects are generated on the second cycle!
Sample
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 455/1/2003
Re-engineered Process forGraphic Artist Group
Improved Process:
Need
AssignmentDept
G1G2
G3G4
G5
Design
P1P2
P3P4
P5
InspectionGood Products
Defective Products
Sample
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 465/1/2003
Re-engineered Process forGraphic Artist Group
Improved Process:
Need
AssignmentDept
G1G2
G3G4
G5
Design
P1P2
P3P4
P5
InspectionGood Products
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 475/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 485/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 495/1/2003
• 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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 505/1/2003
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!
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 515/1/2003
What Assumptions were Invalid?
Why did we make them?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 525/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 535/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 545/1/2003
Managing the White Space
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 555/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 565/1/2003
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.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 575/1/2003
The Classic“White Space” Situation
21 43 65 87
Orga
niza
tiona
l Hie
rarc
hy
8-step Process for Serving the Customer
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 585/1/2003
The Classic“White Space” Problem
21 43 65 87
Who is responsible for this handoff?
Orga
niza
tiona
l Hie
rarc
hy
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 595/1/2003
The Classic“White Space” Problem
21 43 65 87
Orga
niza
tion
al H
iera
rchy
Who is responsible for this handoff?
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 605/1/2003
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.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 615/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 625/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 635/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 645/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 655/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 665/1/2003
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.
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 675/1/2003
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
Copyright © 1995-2003, Dennis J. Frailey, All Rights ReservedDay 5, Part 2, Page 685/1/2003
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