Rework is on the mind of Project Managers globally. Witness the recent interview with Walt Lipke conducted by Yu Yanjuan for a Chinese PM journal (for full interview, click here).* The interview was part of an issue dedicated to rework (for that publication, click here).
The interviewer posed a series of three questions. I’ve excerpted key points from Walt’s response and added comments with links to previous posts.
“What is the present situation of rework in projects?”
“[M]y impression is rework is recognized as a problem, but there is little focus on doing something about it. p 2
Walt then went on to describe an encounter that illustrated his point.
"A few years ago, I proposed to a project manager (PM) that rework data should be captured. The PM’s response was, ‘no one wants that information.’ I was shocked. My response to him was, ‘How can you improve and minimize rework, if you have no understanding of your performance.’ He just shrugged, and indicated most project managers don’t care. Sadly, my guess is this attitude is pervasive and prevails today.” p 2
After 30+ years managing software development projects, I have seen many different attitudes toward rework. The attitudes vary with industry, geography, and culture (both corporate and societal). Even so, there is a growing awareness of rework, although it's dubbed with different labels.
Whether it’s called Refactor, Reiterate, or Recycle, rework is recognized as virtually inevitable in software development. Especially since the advent of the Agile framework, there’s widespread acknowledgement that development is a learning process.
So, allowance must be made to rework what’s been produced with incomplete knowledge. Such allowances are part of risk management. It’s a way to deal with epistemic uncertainty.
Still, there isn’t broad appreciation of metrics for gauging rework.
Does that suggest rework is not important? The interviewer’s next question yields an answer.
What are the impacts of rework in projects?
“[M]y estimate of the maximum impact of rework from out of sequence execution is approximately 18 to 20 percent of the planned project budget.” p 4
Walt goes on to say:
“Along with the cost of rework, there is also a schedule component. As you should expect, there is a corresponding duration increase. From my research, project duration increase appears to be linear with the rework rate. That is, project duration increases proportionally to an increase in rework rate.” p4
The impacts of rework can be crippling. As costs rocket and timeline stretches, customer patience frays. The negativity extends beyond the individual project and PM to the organizations they inhabit. It’s a vicious cycle. In Walt’s words:
“If unchecked, the project may be abandoned, a complete failure. Even when complete failure is avoided, most likely the product is delivered late at increased cost. … When this occurs, the customer is disappointed and most likely irritated. … The impact of irritating customers, in turn, creates a negative reputation. … It is apparent: paying attention to rework is worthwhile.” p 4 (italics added)
What are your suggested strategies to reduce rework rate?
The key point is to catch the problem early. But,
“…how should we ‘pay attention’, so that small problems don’t propagate and become much larger and more difficult to resolve?” p 5
The answer deserves close attention as it might be misunderstood. Walt’s reply starts by focusing on the word “strategy”. This aligns with comments he made earlier in the interview. There, he supplemented his personal research with that done by SEI.
SEI statistics tie the impact of rework to process maturity. With mature processes, rework amounts to less than 5% of the total effort. At the other end of the scale, with immature processes, rework exceeds 50% of the total effort!
In that context, the best strategy relates to maturity:
“My suggested strategy for reducing rework is to improve your company’s process maturity level.” p 5
Note that to bring rework under control, an organization also needs a common, shared definition of rework. Such solutions are long-term:
“The downside of this strategy is there is no easy path to improving maturity level of your operation.” p 5 [Or, I might add, to a shared definition.]
Individual PMs are rarely in a position to implement strategies across an organization. But, there are tactics that PMs can adopt to bring rework under control on their own projects. Doing so increases their probability of project success.
Walt addresses such tactics when he says:
“Fundamental to making improvement is having measures of performance. Without data there is no basis for improvement. Therefore, one of the measures you must have for the objective of reducing rework is the rework generated.” p 5
For those following my posts over the past months, you'll recognize this is a reference to Schedule Adherence (SA) metrics such as R, R-tasks, SAI, and R$tot.
In short, SA metrics offer PMs the means to better manage rework on their projects. Understanding and using those metrics is something that PMs can do without waiting for broader initiatives.
There are plenty of resources that explain SA and its metrics. There are even tools for producing the metrics on a project. Taking action is up to you, the individual PM.
Link to article: https://pmworldlibrary.net/wp-content/uploads/2020/12/pmwj100-Dec2020-Yanjuan-Interview-with-Walt-Lipke.pdf
References:
PMR (2020). Rework on Projects is more serious than most people realize: Interview with Walt Lipke; Project Management Review; republished in the PM World Journal, Vol. IX, Issue XII, December. |
