What do the numbers 1/16, 4/04, 5/03, 5/30, 8/22, 10/23 and 12/20 have in common? They are the dates (day/month) that I sent out my e-letters in 2007.
What does this series lack? A smooth cadence! So, let me share my New Year's resolution for 2008. I will send out one e-letter per month. And, I will send it on the first Thursday of each month. (Well, actually, the second Thursday in July, to avoid the July 4 holiday in the
Why my concern about cadence? Because a steady cadence in any value creating activity helps both the consumer and the producer. Let me explain why:
I hope that every lean thinker by now understands takt time. This is the available production time per day divided by the number of items the customer is demanding each day. For example, if the single-shift production process operates eight hours a day (480 minutes) and customers demand 240 widgets a day, the takt time is two minutes.
This is a critical concept for synchronizing production to customer demand and for giving the production system immediate feedback on whether it is meeting demand. But takt time is difficult to apply in a product development activity like e-letters. What is the rate of customer "demand" for a new product no one has ordered? And, what is the available production time, particularly when developers are working on several products at once?
Which brings me to the concept of 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 vs. 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.
Let me make this concrete by applying it to e-letter writing. I have decided that an e-letter a month is about right. Too frequent and I may bother readers. Too infrequent and I can't share enough of the knowledge I think is important. (But I will be delighted to hear from you whether I am right.) So, that is my rate of demand for 2008. But I also have lots of other projects – too many, in fact – competing for my time, which can disrupt my pace. (That’s what happened this past year.) So to have any hope of maintaining a cadence, I have to decide what's really important. The answer for 2008: E-letters come first and at a steady, monthly pace.
However, even with a steady pace, I will still face several problems:
* Not every e-letter takes the same amount of time to write. Some almost write themselves in a few hours because I already know what I want to talk about and how to say it. Others take much longer because I need to do research. And e-letters may take different amounts of time for LEI's busy staff and advisors to review.
* The amount of time to write an e-letter is never precisely known when I start. Some topics just don't pan out as I put pixels on the screen. And others require unanticipated research as I realize (or am informed!) that I don't actually know what I'm talking about. And, still others turn out to need an extra review from someone in the lean community with special knowledge, predictably someone with more urgent tasks.
There are two ways around this. I can start every e-letter far enough in advance to complete the worst-case letter on time, the one that really doesn't want to get written. Or, I can start each letter just far enough ahead of the deadline to complete all of the development steps on the planned schedule for that letter and prepare one "safety stock" e-letter in advance to use if I can't make my deadline. (If this happens, I'll need to immediately prepare another "safety" letter. And if I frequently dip into the safety stock, I will need to ask some hard questions about my letter-writing process.)
So, let's see how I do in 2008 with my first-Thursday-of-every-month cadence. Visual controls will be firmly in place in the Archives section of the LEI Web site (www.lean.org) – where all of my e-letters are available and listed by their send date – and everyone will be able to keep score!
But, wait. My e-letters aren't the point here. It's how your organization goes about determining the rate of customer demand for new products. And how it selects the short list of important projects which can actually be done. And how it sets a strong cadence so these projects are always started and completed on time with the right content and highest quality, without twisting you and your people into pretzels to get the work done.
May I suggest that creating a steady cadence would make a great 2008 New Year's resolution for every one and every organization in the lean community?
With best wishes for the New Year,
Jim
Jim Womack
Founder and chairman
Lean Enterprise Institute
P.S. Improvement projects to transform organizations are very similar to product development projects. Only so many can be done at a time. They take different amounts of time to complete. They utilize scarce resources. And a steady cadence for starting and completing these activities is extremely helpful to the whole organization. I'll be discussing this topic and many others at LEI's annual Lean Transformation Summit in
Feel free to forward this message to suppliers, customers or colleagues who are implementing lean – or should be.
To learn more, visit LEI (www.lean.org).
Copyright, Lean Enterprise Institute (LEI),