Managing the Rework Cycle

8/12/2019 Managing the Rework Cycle

1/11


2/11

ACLN - Issue 55The Critical Path Method CPM ) has longdominated among techniques for project planning. This

method provides a framework in which the duration of,and linkages between, individual tasks can be planned.From this, the sequence of tasks maybe identified. If oneelement on the path were to be delayed, it would create adelay in the entireproject. It is anaccepted, often required,technique for planning projects and for testing impactson schedules. It is the basis for virtually every piece ofpopular project management software offered. Properlyconstructed andupdated, it is anextremelyuseful planningtool, and yet CPM is an inadequate model for managingcomplex development projects.

The typical means for monitoring project progressandongoing cost and schedule performance are variationsof earned value systems. These provide for setting workand budget standards for individual tasks. Progress onthe tasks, and cost and schedule variations are assessedby comparing actual effort and cost with the task budgets.The earned value system for project monitoring is, likeCPM, an accepted, and often contractually required,project management technique. Truthfully and faithfullyemployed, it is a highly disciplined monitoring methodand, like CPM, is an inadequate model for managingcomplex development projects.

What is missing, as any experienced project orprogrammemanager knows, is rework For all their utility,conventional methods treat a project as being composedof a set of individual, discrete tasks. Each taskis portrayedas having a definable beginning and end, with the workcontent either to be done or in process or done Noaccountis taken of the quality of the workdone, the releaseof incomplete or imperfect products, or the amount ofrework that will be required. This is particularlyinappropriate for development projects, in which there isa naturally iterative process of design/engineering.Indeed, our analyses have shown that rework canaccount for the majority of work content (and cost) oncomplex development projects. While this var iessignificantly among projects and project types, it is hardlyever a matter of a single revisiting of a particular task.Instead, several iterations are typical, often far removedin time from the scheduled and actual conduct of the firstround of work on the task. This is readily seen, forexample, in the release of initial engineering drawings,A revisions, B revisions, C revisions and so on (forthose companies that actually monitor such information).

Companies experienced in complex projects knowto expect this, and have developedrules of thumb to counton two (or three or four) revisions per engineering product.Even so, this expectation is rarely incorporated explicitlyin work planning and management systems, because thetechniques do not allow it. Worse are the cases wherethis rework cycle is not explicitly anticipated ormonitored.Here, they are not only working with halfa tape measure;they are reading it with their eyes closed. These are notunintelligent people nor project-naive companies; on thecontrary, they include the most technically sophisticatedpeople conducting andmanaging complex developments

37

in firms whose very existence depends on successfulproject performance.THE DDITION OFTHE REWORKCYCLETOTHETR DITION L VIEW OF PROJE T WORKPROVIDES POWERFUL M N GEMENTC P ILITY

What we need, then, is a different view ofdevelopment projects - one that recognises the reworkcycle, plans for it, monitors it, and helps managers reduceits magnitude andduration. We need amethod that reflectsa more strategic view of projects - one that accounts forthe quality of work done and the causes of productivityand rework variations. We need to be able to see moreclearly than is allowed by tradit ional methods howchanging external conditions and our own managementactions alter staff productivity and the rework cycle, andhow the consequences spread through an entire project.We need a new framework, applicable across a range ofprojects, reflecting that which is common and that whichis unique among projects. Only in this way may wemoreconsistently and rigorously extract, learn andapply lessonsth at will yield su sta ined improvement in projectmanagement and performance.

Such a new framework has emerged from theapplication of SystemDynamics simulation methods to awide range of development projects. In a manner quitedissimilar to CPM/PERT models, it treats a project notmerely as a sum or a sequence of discrete tasks, but asflows of work in which there are multiple rework cycles.Because of the significant rework content of developmentprojects, this framework is able to reconcile a project sman-hours spent, tasks/items performed, elapsedtime, andmuch more. Not only can the Rework Cycle modelaccurately simulate the actual recorded history of projects,but it can provide powerful forecasting and what imanagerial capabilities.First built for a ship design project at Littonl theRework Cycle model has since been applied accuratelyand successfully to over 60 projects - software systemdevelopments at AT T defence electronics systems atHughes Aircraft, the cross-Channel tunnel, electricutilities power plant engineering and construction, anddozens of other programmes and projects. Repeatedapplications of this more realistic model have proven itto be logically correct and, when codified as a workingsimulation model, numerically accurate. Its uses havebrought enormous benefits to the businesses that haveadopted it.


3/11

ACLN - Issue 55 38The traditional view a project as stages work to be done work process and work done may be seen

as a more continuous stream work in which the pool tasks in work to be done is depleted over the course time,such that at the end the project, nothing is left there, and all the tasks fill the pool work done Figure 1 .

Figure A project may be seen as a flow of work

Work to be Work Workdone being done doneSince it is people working at some varying level productivity who cause the work to get done, changing the

number people along the way, or somehow influencing their productivity, alters the pace work getting done seeFigure 2 .

Figure 2 Productivity affects the pace of work flow

ProductivityeopleWork to be Work Workdone being done done

Under this traditional view, key measures project performance - work to be done, project stage staff, andpercentage complete - as computed by a simulation model, might look like those illustrated in Figure These mayshow the way we plan the effort to go; this may be the way we hope things will go. It is rarely, however, that even aremotely ambitious development project actually performs this way.

Figure 3 There are idealised shapes to some of the key performance measures

Work to do Staff Percentage done

Time Time Time


4/11

ACLN - Issue 55 39

fwe view the process as physical pools in which work resides and pipes through which work flows, it is easy to seethat a quality measure, acting as a valve and varying over time in the range of ato 1.0, diverts more or less of thework being done into the rework cycle see Figure 4 . So long as this measure of quality is less than 1.0, some workbeing done - even rework itself - will continue to move into and through the rework cycle.

Figure A quality measure diverts work into the rework cycle

orktobe done

People Productivity Quality ~ork reallydone

Rework

Thedistinction between productivity andquality is important. Staffmay exhibithighproductivity, butbe producingwork of low quality that requires later reworking. In such a case, the net throughput to the pool ofwork really done islow2 The pool of rework requires staff to expend effort to execute it - to alter/correct/complete the work items needingrevision. With this addition to the model, project performance would be different. As shown in Figure 5, somewhatmore familiar and realistic patterns are simulated when rework is generated and executed. Recognising the allocationof additional staff effort to execute rework, and the resulting slowdown in the pace of final completion, provides amore accurate description of work on a project.

Figure More realistic patterns of performance measures are simulated when rework is generatedand executed

orkto do

Time

Staff

Time

Percentage done

Time


5/11

LN - Issue 55 40

In fact, however, there is a critical way station in which elements of rework linger until identified as needingrework. We have termed this way station undiscovered rework see Figure 6 . Undiscovered rework consists ofthose tasks or workproducts that containas-yet-undetected errors of commissionor omission, andare therefore perceived,and reported by all traditional systems, as being done.Figure With undiscovered rework taken into account the rework cycle complete

People Productivity Qualityt Work reallybeing done doneWork tobe doneKnownrework Undiscoveredrework

The completed model of the rework cycle yields simulation-generated behaviour that is characteristic of alldevelopl 1entprojects. Theprecise quantities and timing obviously differ among projects, but the behaviour is common:as the initial round ofwork nears conclusion, previously undiscovered errors become apparent, requiring more staff fora longer time; the perceived and reported progress significantly slows down as the magnitude of recognised reworkgrows, and an extended completion effort ensues as the last elements of undiscovered rework emerge see Figure 7 .

Figure 7 With the full rework cycle acknowledged simulated performance characteristic of alldevelopment projects

Work to do Staff Percentage done

Time Time Undiscovered rework

Most rework is discovered by downstream efforts or testing, but months or even years may pass before thisdiscovery occurs. During this time, dependent work will have incorporated these errors, or technical derivationsthereof, and enter its own rework cycle. The more tightly-scheduled and simultaneous the project tasks, the more of amultiplier effect there will be on subsequent rework cycles.This final element of the rework cycle, undiscovered rework, plays a pivotal role in the propagation of problemsthrough a project. Lurking undetected - as a software bug , or a design miscalculation, or a wrongly-placed bulkhead- it causes productivity loss, delays, and more rework on dependent tasks. Undiscovered rework is the single mostimportant source project cost and schedule crises. It is the great killer of projects and of new products and ofcareers , and no traditional systems even acknowledge its existence. Even more important, most projects seem to beplanned and managed as though it does not exist.The specific technical content of undiscovered rework is, by definition, unknown at any point in the programme,but it is crucial to programme management success that it be:acknowledged and plans and schedules set accordingly so to reduce the disruption of the surprise ;actively sought out while earlier discovery may feel unpleasant at the time, it is important not to kill themessenger but rather, to encourage early identification of technical problems;

prevented as much as possible - that is, improving quality as defined here easier said than done, sincemanagers cannot mandate by edict the achievement of higher quality .


6/11

ACLN - Issue 55

THERE ARE BENCHMARKS FOR THOSE WHO SEEKTO MANAGE THE REWORK CYCLEAcross the variety o projects that we have examined3, andwithin certain groups o projects, patterns o behaviourhave emerged that can be useful as managerial rules o thumb. While each project is, indeed, different, the empiricalobservations and measurements reported here are valid benchmarks for all those who undertake to manage the rework

cycle in their own projects. These relate to quality and to the timing o the discovery o rework. With these measures,it is possible for a project manager to assess the true status o a project.Moderate improvements quality have a dramatic effect on performance

To underscore the magnitude o the issue and the appropriate degree o managerial concern, consider the rangeo values exhibited for qu lity - the fraction o work being executed that will not require subsequent rework.As indicated in Figure 8 the effective values range from 0.90 to below 0.10. The figure shows the range oquality values for each type o project4 and the resulting number o rework iterations.

the projects examined, commercial software development prolects exhibited the lowest amount o rework(i.e. the highest quality), ranging from little rework in some stages to 1 /2 full rework cycles in others. Many suchprojects are actually adaptations o prior developments.At the other extreme are aerospace developmentprogrammes - all o which are advanced military developments,usually with substantial research efforts - which typically have at least four (and usually more) rework cycles in thedesign effort. Between these two extremes are electronic systems development projects (typically designing andintegrating systems o new hardware and new software) which exhibit between one and nine full rework cycles, andthe design o large-construction projects (with a range o about - to 21/2 rework cycles6Figure 8 There is a wide range of values for quality the fraction of work being executed thatwill not require rework

e r o ~ p c e

7

9

8

65

2

o

43

Software

Largeconstruction

9

876Number o 5rework cycles432

0

0 1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0Typical values o qualityin development projects

This figure shows the empirically derived value o quality for dozens o real development projects in differentarenas. Along with the range o quality for each industry segment are shown the rework cycles implied by that range.As lower quality causes more cycles o rework, more effort and cost must be expended to complete the work - theequivalent o doing it once, and then doing it all over again and again. A quality o 0.20 will require five cycles o workand cost (four rework cycles) to get it right. Development projects here are those that are dominated by designengineering activity to develop a new product or system, and do not include the building o units to a stable design.Clearly, the larger the technological leap being attempted by the overall project, the lower this measure o qualitywill be and consequently the more rounds o rework required. However, even within the range o each project type,there is considerable variability in work quality, and therefore in the cost and time required in a development project.Consider the project performance improvement achievable with even moderate improvements in quality. In an erawhen 30 to 40 per cent performance improvements are set forth as ambitious targets for organisations undergoingchange programmes andprocess re-engineering, the highly-leveraged impact o this kind o quality improvementmustnot be overlooked.


7/11

ACLN - Issue 55 42

Discovering rework early has a significant impact on development timeRegardless o the effort and impact o the quality improvement, undetected errors and rework cycles are

unavoidable in complex development projects. Whatever rework is generated, it has its most destructive effect on thewhole project when it is in the state o undiscovered rework . Discovering the rework earlier and faster removesmuch o the programme-wide disruption, especially the impacts on development time.To illustrate this, we used ourmodel o the rework cycle to simulate the development time required for a projectunder varying levels o quality and the speed o rework discovery. Figure 9 summarises the results in terms o themultiple o the original work schedule. For convenience, think o a development effort planned to achieve initial workcompletion in one year - the results shown in Figure 9 would then be number years . The figure shows four lines- for rework discovery times equal to one-quartero the original design plan time one-quarter year in our example), aswell as discovery times o half, three-quarters, and one.

Figure For most levels of work quality improving rework discovery time yields significantimprovements development schedules

7 7

5 5Development timemultiple o time plannedfor original work) 3 3

2 21 10 0

1 0.3 0.5 0.7 0.9Quality

As is now obvious, improvement either in quality or rework discovery yields much better schedule performance.It is noteworthy from the results charted that lowering the rework discovery time in an organisation or project is mostleveraged in improving schedule performance when quality is not at extremely low or extremely high levels. Atextremely high quality levels, there simply is not as much room for improvement o schedule performance, and in thestages o a developmentwhen extremely low quality prevails, rapid reworkdiscovery ends up subjecting the executiono the discovered rework to the same low-quality conditions that caused it to cycle in the first place. In such conditions,it is best to workfirst on quality enhancement practices and systems, then to accelerate the benefit with rework discoveryenhancements, such as earlier or improved reviews or testing.

The prevailing rework discovery time on design development efforts is typically in the range o one-quarter tothree-quarters the scheduled length o the original design effort. In order to derive a good approximation o reworkdiscovery times, construct a graph o the issues and re-issues o work product in the stage o development beingexamined historically, available; otherwise, monitor an ongoing effort). Plot, over time, each subsequent round orevision as a line. Simplified, your chart should look like Figure 10. By measuring the typical horizontal distancetime) between each adjacentpair o curves, good estimates o the rework discovery time and how it changes over theproject/stage) may be obtained.


8/11

ACLN - Issue 55

Figure 1 A critical addition to the set of closely monitored performance measures should be themagnitude and timing of work revisions

Original revisions

Crevisions

Time< Approximate rework discovery time

Now, you can also compute a good approximation of the time-varying quality of a project stage's work product.Calculate the ratio of (a) the number of revisions to (b) the number of releases/revisions in the prior round; thensubtract each computed ratio from 1.0. For example, if there were 350 B revisions on 500 A revisions5, theprevailing quality during the work on A revisions was 1 - (350/500) =1- 0.70 =0.30With measures available it is possible to assess the true status of a projectArmed with this new information, you will be able to assess where your project stands relative to other developmentprojects. Further, you will be able to determine much more accurately where your project really stands as it proceeds.

eused our simulation model of the rework cycle to construct Figures and 12, which are necessary for morecorrect mid-project assessments of progress and the magnitude of remaining effort. Using your estimates of projectquality and rework discovery time to select the appropriate chart, you may look up the true (range of) re l progress.In fact, with the benefit of data on a completed project, one may construct one's own progress r mp chart byplotting, for the completed project, (1) the historically reported percent ge complete versus (2) a retrospectivecomputation of the percentage really complete. (You should compute the percentage really complete based on hoursspent up to that point, relative to the total hours eventually spent.) Perfectly accurate project progress monitoringwould yield a straight 45-degree diagonal (hence the triangular ramp shape): at a perceived/reported condition of 20per cent complete, the ctu l percentage complete would be 20 per cent, and so on. Instead, real progress is typicallyless than reported progress. Further, a given level of reported progress might mean any of a range of values for realprogress.


9/11

ACLN - Issue 55 44

Figure Progress ramps help to i ntify the true state of progress on a project or a project phase

Perceivedprogress

eal progressis consistentlyless thanperceivedprogress tPerceived progress

e l progresscould have arange of possiblevalues foranyone reportedlevel of perceivedprogress

Figure 2 shows for each of three typical combinations of quality and rework discovery time the relationsbetween per eived percentage complete as reported by traditional systems and the re l percentage complete whenundiscovered rework is taken into account.

Figure 12 Lower quality and longer rework discovery times disguise low real progress, and increasethe range of uncertainty in estimating progr ss

Quality =0.4 Quality =0.3 Quality =0.2Rework discovery Rework discovery Rework discoverytime =0.25 . time =0.5 . time = 0 7 ~ ~ o 8 8 8Percentage Percentage Percentage60 of work 60 of work 60 of work really really0 ~ ~ c ; 40 40 really20 complete 20 complete > ~ c ; complete200 0 00 20 40 60 8 100 0 20 40 60 8 0 20 40 60 8 100Percentage of work Percentage of work Percentage of workperceived complete perceived complete perceived completeIn every case there is a gap between real progress and that which is perceived. Looking across the three chartsit becomes clear that the lower the quality and the longer the rework discovery times:

the larger the gap between real progress and that which is perceived and the longer-lasting the gap;the later in the project/stage that a significant gap persists;the greater and longer-lasting the uncertainty in the size of the gap;the later the point of maximum uncertainty abut real progress.


10/11

ACLN - Issue 55Uncertainty real progress is responsible forseveral troublesome project phenomena

The demonstrated uncertainty in real progress isresponsible for several well known troublesome projectphenomena - the 90 per cent syndrome, the lost year, andthe delayed introduction of the product.The p r cent syndrome

The 90 r cent syndrome occurs when, for aprolonged time, project managers report to executives orthe customer that their effort is 90 r cent done.Examine the middle progress ramp for anexample of this.In these conditions, anearnest, responsible managermightwell report 90 per cent progress achieved when, in fact,the real progress level is as low as 70 per cent. Somemoreworkgets done, some rework is discovered, andlater,the manager still perceives and reports that about 90 percent of the work is done, when 7 or 80 per cent is reallydone. And so it goes on, until, after much distress anddisappointment (and time and cost), 90 per cent is reallyachieved and the project moves on to completion. Quiteapart from any lily-gilding inclinationsof engineers, thereis a systemic cause for the 90 per cent syndrome.The lost year

One of our clients, managing a large new systemdevelopment project, describeda related phenomenon, andrequested a diagnosis. The 1,000-person developmenteffort had progressed to what seemed about two-thirds tothree-quarters completion. One year later, af ter anadditional 1,000 staff-years of effort, it seemed that theyhad made no progress, or had even lost ground, followedby a slow pace of progress towards completion. He calledit the lost year . His question: What happened? Theabbreviated answer is clear, once again, from the middleprogress ramp. In these conditions, 70 per cent progresscould be reported as early as at 30percent real progress.Quite some time later (specifically, one year), havingmade to 30 per cent more real progress, the system canstill be reporting 70 per cent progress, or even less.

A lot of progress was made. A lot of rework wasfound and corrected (work that had been viewedas done).The lost year was not lost; it obviously felt like onestep forward and one step back, but it was just a largeexample of the rework cycle thwarting conventionalmonitoring systems. Even after the lostyear the project,still being reported at about 70 per cent complete, was infact just 60 per cent complete, so what was seen as theremaining 30per cent felt as if it took a long time to finish.The delayed introduction o the product

Not so very uncommon was the dilemma faced byanother client firm. They wanted to introduce their newsystem product at the earliest responsible time in atechnologically competitivemarket, but they had a historyof undependable announcements on product releaseschedules, followed by dashed expectations. When couldthey really promise the market that this new systemproduct would be available?

45The diagnosis revealed a somewhat higher quality

than in the prior charts, butwith a longer reworkdiscoverytime, as characterised by the third progress ramp (shownin Figure 12). In this condition, the true status of adevelopment project remains highly uncertain until thevery end. Combined with consistent over-estimating ofprogress are wide (vertical) bands of uncertainty withinwhich perceived progress may become unexpectedlystuck . While real progress is being made, the late andprolonged appearance of previously undiscovered reworkresul ts in ever sl iding undependable estimates ofcompletion time - particularly at the later stages, whencompanies are making announcements of new productintroduction schedules.This client s organisation and practices hadbeen setso as to encourage high levels of completion beforesubjecting to testing the integratedprototype. The analysisled the client to implement a new structure and set ofprocedures that includedmuchmore earlier testing. Whilethis increased testing costs, total project time and costswere reduced significantly. Although the resulting earlierrework discovery was a bit scary to the managers atfirst, much more dependable introduction schedules wereattained.SUCCESSFUL PROJECT M N GERS WILL EOTH DVOC TES N INSTRUMENTS OFCH NGE

Even with a better model there will remain amanagerial inertia forged from years, even decades, ofmisunderstanding. It wil l not be enough for projectmanagers to internalise the associated lessons of therework cycle. They must also learn the importantdifferences between:the substantial influence that the manager has

over productivity quality and reworkdiscovery and hence project cos ts andschedules;the relative lack of control that the managerhas over these same conditions.

The very best of project managers know thisintuitively, butjust as important theymust ensure that theirformulated action plans and associated logic are effectivelyandpersuasively communicated to (and implementedwiththe aid of) many other players - senior company managersand colleagues, the project staff, partners and suppliers,and customers themselves. The passive manager (orworse, those who encourage obfuscating or ostrich-likebehaviour) will not make waves - nor will they make anycontribution. Their projects will continue to fail.Successful project managers will take on the roles ofthought leader and action leader - the advocate andinstrument of change - in the systems and practices thatsurround them. The alternative - the unmitigatedmachination of the rework cycle - will mean continuingthe familiar pattern of development projects - unforeseencosts, unexpected delays, and unfulfilled promises.


11/11

ACLN - Issue 55

ot s1 Naval ship production: a claim settled and a

framework built. Cooper, KG. Interfaces apublication of the Institute of Management Sciences.December, 1980.2 The distinction between productivity, quality, andrework has the added benefit of making all of thesefactors measurable and monitorable Totalthroughput of work items in a project stage (lines ofcode, tons of steel, drawings, numbers of units, testsconducted, and so on) can be measured over timemuch as in traditional systems, and compared withthe number of hours spent in the same timeframes,so as tomonitora legitimatemeasure of productivity.Numbers of revisions and rounds of revisions, canbe monitored over time so as to derive a tangiblemeasure of quality.

3 These project models were built using the dynamiccontinuous simulation language, DYNAMO. SeeDYN M0 usersmanual Pugh-RobertsAssociates,and Introduction to systems dynamics modelling withDYN MO Richardson, George P and Pugh III,Alexander L. Pugh-Roberts Associates is a USsubsiduary of PA Consulting Group

4 We acknowledge the bias in the data caused by thefact that easy, smoothly running projects rarelycommand the attention of consultants brought in bymanagement. Therefore, the true range of qualityvalues is likely to be broader to the right for eachclass if one includes less difficult projects.

5 Takeheart, home builders. Theconstructionprojectsin the sample reported here - power plantscombatant ships - all significantly exceed 1 billion.

6 Technical content and organisational practice inexecuting and reporting revisions vary widely.Account should be taken of the fact that the amountof effort on successive rounds of revisions willchange (usually decrease). All measuresof qualityreported herein have been normalised to representrevision effort that is equal to original releases on aper unit basis.

Managing the Rework Cycle

Documents

Transcript of Managing the Rework Cycle