The team was rightly proud of the work they had done in creating an obeya space to manage their project, and their excitement was obvious in their faces as we gathered around their schedule wall. But just as obvious were the unpleasant “surprises” that awaited them during the course of their project. I could see those nasty surprises lurking in the long gaps that appeared intermittently in the swim lanes of their schedule and in their “plans” to deliver critical product attributes.
I could see it because it was an error I have seen before and in fact had committed myself in the past. It happens when teams insert long periods of “standard” or “block” timing that often consists only of a starting point and an ending date with little understanding of what happens in between. Development examples include drawing release, tool creation and test completion, but there are many others.
The obeya will typically have a sticky placed for drawing start and then a single sticky placed 10 weeks later indicating the date when 200 drawings must be completed and released into the system. Or worse, there is a sticky placed when tool start will be authorized and not much else until 20 weeks later, when all the suppliers should have shipped their tools.
These huge gaps in information can allow a team to get into serious trouble before they are even aware that there is an issue. My old boss, John Fleming (former EVP Global Manufacturing at Ford) used to call this “traveling hopefully,” and it was never a pleasant journey.
It’s a bit like sailing in a race from Boston to Miami, knowing only your final destination and that the average time is around two weeks. Then calling your sponsors from a bar in Norfolk a couple weeks later to tell them you are working on a recovery plan. At that point, who cares?
While it’s true the best sailors know they can’t control the ocean, neither are they willing to trust their fate to the winds and waves. They continually sharpen their navigation skills, work to deeply understand their route and where they are to that plan at any given time, and they employ the best tools possible to increase their chances for success.
In the same way, lean development is less about creating highly detailed plans based on things you can’t possibly know in the beginning of a development, and more about developing a deeper and shared understanding of the work to be done and increasing fidelity as you close knowledge gaps over time.
Milestones and Early Indicators
That means that to build a better development plan, you should start with the actual work to be done. This includes the tasks, the sequence of tasks, and the interdependencies across functions so that the team can recognize looming issues and act in time to stay on course. In lean terms, the team can see an abnormal condition, pull the andon to signal for help and employ effective countermeasures in a timely manner.
Foundational to this capability are effective milestones with clear purpose statements and quality of event criteria to measure against and guide the team on their journey. In fact, teams often require more than milestones. Because milestones often serve as key integration points, early indicators should be placed in between milestones to protect the integrity of those points and not affect other “swim lanes.”
These indicators should be reliable predictors of milestone success. Even if you meet in daily stand-ups, if you don’t recognize an abnormal condition, you may overreact to minor things and not even see a major storm on the horizon. Too many stand-up discussions are vague and conversational and will do little to head off problems without these fundamentals.
Creating a Glide Path
Another example of hopeful traveling can be seen in the way some program teams approach the delivery of critical product attributes. Teams often set attribute objectives and then act as if attributes like weight, speed, cost or others will just evolve “naturally” out of the development work only to find out at the end of the project that they have come up short.
Achieving such attribute goals require closing knowledge gaps during the course of the project. Creating a simple glide path will outline expected progress from the starting point to the ultimate objective, based on specific activities designed to close those gaps over the course of the program. This gives a visual tool that can help determine abnormal conditions when the team is off glide path. Setting up a percent of objective expectations tied to these activities is one effective way to create such a glide path.
So the next time you see schedule voids where monsters might be lurking, ask the team about the work that is being done there. Filling in these black holes can be challenging. After all, you are creating new value and much of what you are doing has not been done before. There are so many unknowns. That’s okay. Challenge your team. What do they know? Do they understand the tasks in their order or which task might be dependent on others? In other words, do they truly understand the work to be done. If they don’t, you may have a much bigger problem than creating good schedules.
Jim Morgan, a former director in operations at Ford, is senior advisor and founder of the Lean Product and Process Development initiative of the Lean Enterprise Institute.
This article was originally published in the Lean Post, the blog of the Lean Enterprise Institute.
