cadence

Think of cadence as takt time adapted to activities beyond routine production. In the product development world -- as brilliantly illuminated by our late colleague, Allen Ward -- it is very helpful for a development organization to have a clear sense how many new products are needed per unit of calendar time and to develop a steady pace for initiating and finishing these projects. The demand might be one per year or one per quarter or one per month, depending on the perceived desires of customers. But in every case the demand needs to be determined in advance and projects need to be completed at a steady rate.

When there is no steady cadence for starting and completing projects, work starts to bunch up and the resources of the highly trained and integrated development team can't keep up. As a result, projects are delayed or delivered with some functionality missing. Or they are completed with less than the full attention they require for consistently high quality. And in either case development costs are often much higher.

So what to do? The answer is simple. But it is hard at first. The senior management must decide how many new products customers might like (usually a very large number) then de-select attractive projects down to a number that the available development resource can actually support. And management must make a conscious decision to start and complete these projects on a steady cadence, without constantly dropping new projects into the system and cancelling others.

(Note that completing projects of differing complexity by a given date - for example, ones using a totally new technology or product concept versus those involving only routine applications - will usually require starting them different lengths of time before the completion date. So care must be taken to think through the whole portfolio of projects to start each at the right time.)

Another way to think of cadence is heijunka (production leveling) for product development, in which the needs of the customer for new products - which may appear to vary and to bunch up, particularly in highly competitive markets - are set against the capabilities of the development organization. While it might be nice to continually vary the output of the development organization to meet changing customer desires, this is usually impossible if many of the resources are specialized and scarce.

The practical alternatives are (a) unrealistic goals and continuous gyrations in scheduling, causing muda, mura, and muri, or (b) an acknowledgement that a development organization can only do so much in a given period of time and that it can actually get more useful work done if everyone is working at a steady pace. In my experience, the organization and the customer are better off with the latter approach, when a clear cadence is established for project completions and the cadence is maintained.

Source: Jim Womack [[email protected]]