The design-fabricate-assemble-test cycle of new product development is fundamentally a learning process.  Some even advocate that it’s best to fail frequently and quickly since each failure becomes the next stepping-stone to ultimate success.  Imbedded in this thinking is a crucial and often overlooked assumption:  You can’t correct a failure that you don’t know exists.  When an unknown error is resident in a project, others trust and build upon it.  The longer it goes undiscovered, the more disruptive, time-consuming and costly it is to fix. 

Fast cycle time experts differentiate the time-to-detect from the time-to-correct errors.  Most companies are far better at resolving problems than detecting them.  Ideally, we would detect problems in real-time just as today’s word processing programs highlight and often correct spelling errors. 

Real-time or zero latency measurement is all about driving learning by removing any delay from the time an error occurs or a condition changes to when we’re aware of it.  Imagine how frustrating it would be if your car’s gas gauge mimicked the lag in most corporate expense reporting systems and told you how much fuel you had thirty days ago!  In the best case, zero latency information is matched with zero-latency analysis and corrective action.  Anti-lock braking systems measure rotational speed hundreds of times a second and just as quickly adjust hydraulic pressure.  Chip layout programs provide designers with immediate signaling (and often correction) when design rules are violated.   In the far more complex world of software development, companies have increasingly paired developers with testers to reduce the time it takes to find errors.  They don’t often achieve zero-latency but the time-to-detect bugs has dropped significantly while software quality has increased.

Zero-latency is most important when synchronization is required between constantly shifting dependencies and priorities.  When surfaced, blockages and shifts in a project’s critical path can drive re-allocation of resources.  Test equipment constraints can be shifted when there is a real-time basis for priorities versus relying on last week’s schedule.  Requirements from critical stakeholders such as customer and suppliers change frequently during a development.  Any delay in communication and understanding here can easily derail the simplest project.  Besides, when is the last time you had a “simple” project!

What might have sounded like academic gobbledygook only a few years ago is increasingly possible using information technology.  Take the case of Microsoft’s recently introduced X-Box game console.  With minimal experience in a project of this magnitude and faced with the challenge of producing over a million consoles for the Christmas season, Microsoft could not afford delay in either detection or correction of design errors.  Early in the development process component specifications were not stable and the console design changed almost hourly[1]. 

Using collaboration tools designed for new product development by Agile Software, Microsoft, Flextronics (contract manufacturer) and component manufacturers such as Nvidia were able to swap information and reduce the time it took to respond to change orders by disseminating real-time information between the critical parties in the design-manufacturing pipeline.

“There was an average of 600 [engineering change orders] weekly across the supply chain in the early stages of the design,” said Lou Unkless, Agile's vice president of collaboration solutions. “Microsoft needed a tool that would help them reduce materials costs and get products out in time to meet their tight deadlines. They wanted to make sure data was available to their partners at the same time with zero latency.[2]”

Through the promises of information technology regularly outweigh actual experience; there is little question that progress is occurring quickly.  It used to be that simply communicating a discovered error to all parties could take just as long as finding it.  Now it’s possible to broadcast updates to all stakeholders instantaneously.  This goes a long way to reduce the amount of unraveling necessary when an error’s dependencies are broad.  It also eliminates destructive emotional outbursts and blaming.

It would, however, be a mistake to assume that zero-latency always requires huge information technology investments.   Many new product teams could do a much better job of collecting, analyzing and sharing information already at hand.  The greatest sources of detection delay are fear followed closely by poorly designed team dashboards[3].  Fear of public disclosure of failure is often heightened when time-to-market pressures rise.  Transparency is critical to learning.  Though we frequently cite sports teams as a virtuous example, we rarely are as direct as professional coaches and game films can be.  Leaders need to make it standard operating procedure to be public about failures and unsafe to shield problems.  If you want to chastise someone, focus on those who get it right behind closed doors and reward those who stumble in public.

 Properly designed team dashboards can support the zero-latency approach.  It’s not always easy to find quantitative measures that can be linked to real-time sources.  Push for it when the importance, instability and dependencies are all high.  At a minimum, try to increase the status sampling rate.  Alternatively, make sure your dashboard has a qualitative zone where critical path and those issues that keep you up at night can be highlighted, if only in words.  Better to have quick visibility and qualitative definition of important issues than high precision and quantification of unimportant issues. 

Zero-latency requires a different analytic approach.  Leaders and teams have to avoid over-reacting to a few data points that may be outliers relative to the central tendency.  Zero-latency measurement typically increases the sampling rate, which in turn makes trend data far more accessible and useful.  If weekly bug closer rates are dropping over time, don’t over-react to a day where several more are found.   At the same time, don’t mistake the currency of data with sound decision-making.  Cisco Systems took a multi-billion inventory write down last year yet they have one of the lowest latency information systems in the world.  They simply did not act on the data they had at hand. 

 Reducing the time-to-detect errors makes invisible failures visible.  People can’t be held responsible for fixing that which we do not know is wrong yet we are quick to jump on those problems which we see.  Zero-latency measurement removes the cataracts from your measurement systems and enables faster learning.

©2002 Christopher Meyer