I Put 100% Into Our Projects and Get Less Than 100% Out — Where Does the Time Go?

Introduction

In 1984 I had a summer job creating spreadsheets to track the throughput and waste in a chip manufacturing company. The boss of the group knew he was purchasing X amount of material and getting 0.6X of that out at the end of the cycle, but he did not know where the problems were.

The spreadsheet tracked the number of rejected wafers at key points in the flow. With this simple information he knew where to focus improvement efforts.

In the product and IT development world, a rejected wafer is similar to work that has to be done over because of errors. This could be measured as hours expended in rework or defects found.

The picture shows a simple representation of a work flow. The methodology you use within the flow is not important for this discussion, only what you put in and what comes out. The project starts at the left and a major release is produced at the right.

Here are some some simple assumptions for which you can substitute numbers you might have.

• There will always be leakages throughout; the goal is not perfection.
• The minimum amount of waste is 15-20% (e.g., 1 day per week) due to unforeseeable issues, communication, learning curve and the difficulty of the work.
• The team members are hard workers — no one is slacking off.
• Your numbers will be different from my examples.

An Example Work Flow

Input: 100% resources are fed into the pipe (project start).

• Some user requirements are created, and they feed into iteration 1 and subsequent iterations:
  • 5% is lost due to clarifying ambiguities and incorrect or missing requirements.
  • 5% is lost due to test cases not being generated at a time when it is cheap to clarify and fix ambiguous requirements so ambiguities flow downstream.

• Design is mostly informal (or skipped); the team jumps from requirements to code.
  • 5% is lost due to numerous clarifications, performance issues and re-designs later.

• Demos are performed for each iteration and the early feedback plugs a potential leak (this is a good thing).

• No code reviews are performed so potentially buggy code (along with ambiguous requirements) are passed off to the testers.
  • 5% is lost due to the time spent in cycles of test and re-test, along with discussions regarding requirements and defects.

• Final test is performed, but it takes 5 cycles of test to work through the bugs:
  • 10% is lost due to the time spent in the test cycles and meetings needed to clarify defects.

• Requirements changes come in that are coded but not charged for:
  • 5% loss due giving away too much free work. (Expect to give away something because that keeps customers happy; just don’t give away everything).

Output: 65%, or your number X%

You will probably never get a number higher than 80-85%, so don’t feel bad about your number!

Three questions

• Are there any obvious leaks in your system?
• Where are they?
• What can you do to reduce the leaks?

Some practices that might help

• Elicit requirements to clarify the target.
• Develop test cases to clarify requirements very early.
• Manage requirements changes to gain revenue.
• Conduct peer reviews to catch defects and reduce undetected problems flowing downstream
• … There are 10 other things I thought of — you probably know 10 also.

Why change what you are doing now?

It does take effort (and cost) to change, so you will have to be selective. However, the changes you make and maintain can improve productivity forever, thereby covering the cost.

Typical reasons to change are:

• Keep customers happier with better work delivered faster.
• To regain most of your X% loss (a benefit you can keep forever).
• Make money and cut costs.
• Use the time saved to to build new products.

If you have questions or comments about this article, or would like to discuss any leaks or permanent patches, please contact us for a complimentary 45-minute chat or just send an email.

[Forward this email to your boss! Subject: Here’s a cool tip for you] Quick Link