Bottleneck Busters Blog

One of the most fascinating processes that I had a chance to study at one of the companies I worked for was their design process for new products.  I had a chance to look at it from the “design factory” perspective, and I was working with a few experts that have a strong background in critical chain implementation.  Although we did not have a chance to finish the project, the study itself was very worthwhile.  I could go through all the undesirable effects, and put up a very crowded current reality tree, but I think the root cause issue came down to how each task was being measured. 

The major metric, so to speak, was having your task deliverable done on-time.  It was also clear, as we looked at the process, that there was really no way to validate from the outside that a task had been completed satisfactorily.  It only became apparent that there was a problem when the next engineer tried to use the deliverable to complete the next task. 

And, as with many projects, the product was constantly changing.  At this company, we saw that if an engineer completed their task early, they generally did not deliver the task until the due date.  They used the time between completion and due date as a buffer - in case a change occurred to the product while they had the task. The bottom line is that the system could not take advantage of any positive variation. The task was completed on-time, at best.

Of course, if something went wrong, and you could not complete a task on-time, most engineers still reported that their task as completed on-time.  With so much pressure from management to complete a task on-time, and no method to validate the quality of the completed task, reporting it as complete seemed to be a small risk.  If it was only slightly late, chances are that you could complete the task before the next engineer realized that there was a problem.  Savvy engineers already had their excuses in place in case the issue became apparent to management:

"Well, the previous engineer did not deliver their task to me on-time, and they reported it to me as complete, so that's what I did."

"I thought it was more important to deliver what I had completed to the next engineer so that they could get started, while I finished up the details of the task."

And many others. The managers that had the task of monitoring the flow of work through the design pipeline started to see a common pattern.  Early on, all programs reported that everything was "green," and that all of the tasks had been completed on-time.  At some point, one of the engineers finds themselves at the due date of his task, with no inputs.  They usually have no choice but to report a problem, and thus the project goes from on-time to six months late.

Top management looks at all the people and investment involved in the design process and can't believe it.  They decide to take one of the projects they have a lot of passion for and make sure it gets through the design factory on-time.  Suddenly, the priority is clear, and engineers will drop other projects (which may be more profitable in the company) to make sure they don't get their ass in a sling over this task.  If they get done early, they send the deliverable to the next engineer, to get the “hot potato” out of their hands. The design gets done on-time, and senior management concludes that it must be due to a lack of a sense of urgency on the part of middle management.  Combined with poor financial performance and the need to cut costs and eliminate non-productive resources, the inevitable reorg follows.  In this company, the mean time between reorgs (MTBR?) is about two years.

And so it goes on, beginning to look like the downward spiral discussed in Malcolm Gladwell’s The Tipping Point.  The key lesson, I think, is to understand the pros and cons of the major metrics you are using to evaluate your people and processes.  Tie the metrics into Net Profit, ROI or Cash Flow, if possible.  Overall, it always appears to be that is the easy metrics (efficiency, on-time delivery, etc.) are the ones that seem to give us the most trouble.  Also, the ability to accurately validate that measure (with an outside party, if necessary) seems important as well.  As Eli has often said, “Tell me how you are going to measure me, and I will tell you how I will react.”

And why did we not have a chance to finish the project?  Well, there was this reorg right in the middle of it…