This Focused Performance Weblog is a "business management blog" containing links and commentary related primarily to organizational effectiveness with a "Theory of Constraints" perspective. TOC is noted for its applications in Project Management and Multi-Project Management (Critical Chain) and Operations Management (Drum-Buffer-Rope), as well as in Marketing, Strategic Planning and Change Management (TOC Thinking Processes). If you are on an archive page, current postings are found here.
Tuesday, February 17, 2004
Promises and Prescriptions Part 2 - The Added Work of Rework -- "There's never time to do it right, but there's always time to do it over." If you've ever uttered that time-worn sentiment, stated with an air of exasperation (or muttered under your breath), then you're probably familiar with rework. The need to re-do something is rooted in one of two possibilities. Either it was not done right the first time, or something has changed to make the original attempt less than fully useful. While there could be a number of reasons for either (Murphy's Law has not yet been repealed, after all), there are several common practices of project management that can actually contribute to rework.
One source of self-inflicted wounds is the misuse of estimates used to build schedules and make promises. Too often, estimates are single numbers (or are transformed into single numbers by some sort of "best-case-worst-case-most-likely" PERT calculation), that reflect the best guess as to how long a task is expected to take, given available information. Estimates are asked for long before many of the details of the project are really understood. This is the nature of planning and promising in many organizations.
Unfortunately, the foot shooting continues: estimates get translated to commitments, and are published as schedules that link the string of estimated tasks to the calendar. Now there's a due date for every task that, if exceeded, means the project promise is in jeopardy. Pressure to meet that due date--to keep the project on track--can overwhelm even the strongest desire to handoff a quality deliverable to successor tasks. The rush job comes back to haunt you as you do the rework, which takes more time than estimated, plus the additional re-setup; or users do the rework, adding to their effort and the chance of handing off their output late.
A second source of rework is created when work is started too soon. Too soon sometimes means before somebody else's handoffs are ready. If you start without a full set of required inputs, you will find yourself making assumptions. Those assumptions could be wrong.
Too soon can also mean before it's needed. Just because you have all the inputs that were identified in the initial planning doesn't mean you should jump on it immediately. Often, that is the appropriate action, but there are also situations in which you could invest effort prematurely, only to find that some other part of the project has changed circumstances. Your good planned work is now either less than what is needed or something the project doesn't need at all. While that last possibility doesn't directly relate to rework, it is just as wasteful if you had other, more valuable things to do with your time.
(Prescriptions for dealing with rework will be found in the next installment.)
View Frank Patrick's profile
