Every business leader wants to improve time-to-market for new products, but very few can translate that desire into tangible action.

Luckily for these leaders, a solution exists, and today I’m speaking with just the man to tell us about it. Drew Locher is a faculty member of the Lean Enterprise Institute, a global educational organization dedicated to improving organizational inefficiencies, including bringing products to market. As part of his work in developing and delivering innovative business improvement programs, in 2008 Drew authored Value Stream Mapping for Lean Development: A How-To Guide for Streamlining Time to Market, a very practical framework for leaders looking to reduce cycle time. Today he continues his work to create organizational efficiencies as the President of Change Management Associates, a management consulting firm based in the Philadelphia area.

Given the importance of time to market (TTM) in driving growth—as well as my own experience in driving improvements through the application of lean methodologies—I am very pleased to be catching up with Drew today as part of Invetech’s Executive Series on Growth.

Colin: Drew, good afternoon, thank you for your time.

Drew: Good afternoon Colin, and thank you for having me.

Colin: It is our pleasure. Drew, by way of background, could you please give an overview of Change Management Associates: its mission, types of client work, and operational approach?

Drew: Change Management Associates has been my business name since 1990. This year, we’re celebrating our 25th year anniversary.

Colin: Congratulations!

Drew: During your introduction, you used the term “management consulting.” I think of us more as educators: our mission is to spread the word on all concepts under the umbrella of enterprise excellence. That would include the application of enterprise excellence concepts to product development. We do this through onsite workshops—which we prefer to be application based, “learning by doing,” another common theme of ours—and we try to pique interest through institutions like Lean Enterprise Institute. I am also part of the University of Michigan, so we do public workshops there too.

Colin: Terrific. From the perspective of product development, improving TTM is one of those holy grails that most organizations pursue, but very few succeed in achieving. Why do most organizations struggle to be more efficient in this area?

Drew: I do believe that it is a lack of willingness as it’s not easy to do, and it takes a serious commitment of management. I learned this back in the 1980s at GE: one of our strategic initiatives in the second half of the 1980s was to reduce TTM. This was a corporate-wide effort, and we had access to all of the businesses. When we first did it in major appliances around 1986, it didn’t work! However, we learned from it, applied our learning to aircraft engines, and were successful in reducing time to market by 50 percent in 1990. GE did it again in aircraft engines and had reduced another 50 percent by the mid-90s. It all comes down to willingness and commitment.

For several reasons, people have difficulties in getting their heads around very complex systems. They don’t know where to start, or how to go about doing it. It also seems that people who work in project-based environments struggle to recognize bigger issues around process. Those are two of the biggest challenges, because if you don’t think about processes, you’re not thinking about process improvement.

Colin: Yes, I think what you’re saying reflects well with my own experience, and the exciting thing is that it is in our hands. There have been many different kinds of management paradigms to improve TTM: the stage gate movement of the last 20 years, or the rise in outsourcing as a way of tapping into skills more efficient than internal resources, just to name a couple. You have focused your work around value stream mapping as the underlying approach to reducing TTM. Could you share what led you in that direction?

Drew: Value stream mapping is a very powerful tool: it gives visibility to complex systems. You start with the current state, so that people can get a common understanding (“This is how we flow projects”) and then getting them on a same page of the future stage (“This is how it can work”). It’s a tremendous social tool, bringing together different functions, and most development processes encompass about as many different functions as you have in an organization. For those reasons, it is very applicable. Not all of my colleagues believe this—that is, my colleagues who work in product development—but I am a strong, strong believer for these social reasons, and also just for getting visibility. Once people have gotten visibility into their own systems—and the inefficiencies therein— they can grasp what is going on, then they are off and running to redesign them.

Colin: You mentioned from your experience with GE that you saw 50 percent improvement, which is terrific. Is that typical? Are there any other benefits of using a value stream mapping approach?

Drew: Well, value stream mapping should seek radical change: at least 50 percent improvement. We’re not nipping around the edges when we’re talking about fundamentally changing the way development projects are going to flow. When a company calls me up and asks for help, I ask them what their goals are. If they say “Ah, maybe 20 percent reduction in lead time,” I say, “No, we are going to do more.” Now, ideally the goals should be market-driven—if a given market needs a certain period of time, we should be designing for less than that—but I’m looking for 50 percent improvement (or more) in every future stage.

There are some other things that we’re looking for as well, based on business needs. It might not just be speed-to-market, it could be more projects, e.g., the volume of projects going through the system. We might focus on process time of development, not just lead time; or it could be that the business need is market acceptance; or you might just be designing the wrong things. It could be all the above. Any major improvement initiative in which value stream mapping is undertaken requires an important conversation up-front: what is the market, what is happening in your market, what are the business needs. Then we very specifically define those goals and targets, which then become the design parameters for the future stages.

Colin: We’ve been talking back and forth about value stream mapping. Could you briefly give a thumbnail sketch of what a value-stream map is? How would you go about developing one in the context of R&D and development projects?

Drew: It’s a big picture view. We often use the expression “10,000-foot view” of any system or process. We do a work-up of the system on a wall. We then do a virtual walk-through, where team members describe what they do at each major step, show the tools they use, etc. What distinguishes value steam mapping from most approaches to traditional mapping is that we put data on the map to enhance the value of the story it’s conveying. We input lead time, the different steps of the development process, process time, actual work content, the level of effort required, quality matrix, etc.

One very important input is percent C&A (Complete and Accurate), a measurement of the information quality. We will put in the number of iterations that we might go through at a particular stage of a process, or even a specific step. The data highlights waste and issues of flow. We will often say that value stream mapping creates an eye for flow and for waste. Ultimately, the people in this process are the ones mapping it, and we just facilitate it. They start to develop eyes for flow and waste, and it gets them thinking about systems, so it’s a very valuable tool in teaching systems thinking.

Colin: I agree. I am always trying to enhance my own skills in value stream mapping because I find it one of the most useful business tools one could have.

To summarize what you’re saying: the goal is to look at the map in terms of flow and waste, and then try to re-engineer it to remove waste. From your experience in being involved in many value-stream-mapping exercises, what are the typical wastes that you would see in a development processes? Are there any examples of how organizations have re-engineered the process to take those wastes out?

Drew: One point that I would make is that you are not trying to take all the waste out. What often will happen with value stream mapping is that people will do a current state and then brainstorm all the waste. I do not recommend that. You’ve got very specific targets that you are shooting for, and you know the point at which you are, so we want to focus on those wastes that are most impeding you from meeting your targets.

If we start these projects and don’t have an adequate understanding of the voice of the customer, we are setting ourselves up for failure, and we might not know it for two years until we go to market. That input is measured by our C&A’s, our first pass yield (a summary matrix of the whole value steam from an information quality standpoint), and ultimately by market acceptance. You cannot flow with poor information and it creates a lot of re-work, iteration and dries up your process time.

When we map, we use a project or two as the context for the map, but we have to remember that those are just examples, and that there are a lot of other projects. One of the pieces of data that will go in a map is the number of projects and where they are in that system. More often than not, we are trying to do too many projects at the same time, and that’s analogous in manufacturing to too much WIP. Sometimes we need to reduce the amount of WIP, the amount of projects, which allows the engineers to focus more and be more productive on single projects. That’s another waste that sometimes we have to address.

For TTM, we are looking at lead times—why would lead times extend for a segment of the value stream? Perhaps if I’m trying to do too many projects at once, as an engineer or as a system; or perhaps it could be quality issues, things are sitting around too long because I’m waiting to get information that I didn’t receive up front. Or it could be other things. It could be imbalances in the work load, an imbalance in the systems, or in resources-versus-demand. It could be that some of our processes take a long time. Maybe we need to upgrade our tools to do things quicker. Insight into all of the above can come out of a value stream map.

Often, we will see prototyping show up in value stream mapping. Everyone wants to do prototyping, and in the exercise, you can see how long it takes to create prototypes and test them. Too often we’re making these prototypes look market-ready, yet we’re not there yet in the development process. We start talking about rapid learning cycles and simple prototyping, and all of a sudden, that lead-time collapses. Trying to do too much, poor information quality, imbalance of demand and capacity within the system, and not using the right tools to do rapid learning cycles: those are the most common problems for the extended lead time.

Colin: What you say resonates strongly with me. I particularly like your insight around the completeness of information; that is, the documentation set required to progress the development process, particularly in regulated industries. Documentation and completion of documentation is critical to releasing a product to market. If you don’t have agreement on what that document map looks like and what maturity is required at different stages, it only slows you down and creates a lot of churn.

You mentioned earlier the experience of GE, that in the appliance area you didn’t perhaps make as much progress as you wanted, but in the jet engine area you made profound progress and then made even further progress, which is terrific. Again, do you have any comment, any reflection on why organizations struggle? What the keys to success are in using value stream mapping as an approach to improve time to market?

Drew: As I mentioned earlier, they struggle when they don’t properly use the tool. In the future state, they go after 100 things, so the future state becomes unrealizable and then people become frustrated and don’t follow through. We just wanted to focus on some key things. Recognizing that this is the first future state, and there could be a second, a third and a forth. Back in my days with GE, we didn’t use value stream mapping, we did mapping of the process, which we called “level zero maps.” They were high-level maps, and we did one improvement cycle; several years later, after I left, they did another one, so it’s about continuous improvement.

But probably one of the big things that I see is that people try to tackle 100 things—and it just doesn’t work. That’s probably the most common misuse of the tool. Additionally, they don’t get all the right people involved. If you’re not getting that collaboration of the future stage of design, people might sub-optimize. They might help one area at the expense of another. You really have to get everyone together to dedicate the time. With development processes, it takes a little longer, it might take you three days just to map the current state. It’s very complex. I’ve mapped out development processes that are a month long and fifteen years long. You are going to need more time if it is fifteen years, as well as anything in between. 

Colin: You mentioned something about ambition, that is, if people say “I want to improve it by 20 percent,” then it is not necessarily helpful to go into a value stream mapping exercise. But when you are looking to significantly drive a breakthrough, it’s a terrific approach. I know in your book that, as well as describing a lot of the mechanics of mapping, you dedicate many pages to the idea of leadership and culture. What is the sort of culture that helps get the right kind of breakthrough and mindset?

Drew: When I reflect on the times when it has really worked well, it was just strong leadership. What does that mean? Open-minded leaders who aren’t so attached to the current system. I remember a company (that I will have to leave nameless) in the Chicago area, and we set a goal to go from three years to one year with their products. When I talk about these numbers, I recognize that these projects vary, so we use averages for the most part. It could have been three years, plus or minus six months, based on complexity, down to one year plus or minus maybe two months.

So, for the company in Chicago, we set 12 months as a goal, and there would always be a competition for time. Engineers wanted so much time; the purchasing people had to source, so they wanted their time; the manufacturing people had to prepare, so they wanted their time; there was always a competition going on. But instead of this being a nasty confrontational competition, every time we hit a barrier, it was not “We can’t do this,” it was “How can we do this?” And they just kept at that process and I never heard anyone say “We can’t do it.”

I’m working with a company in Jersey, and development means a lot of things to a lot of people.

They are ready to move on to another future stage because they are fearless. I will throw up ideas of things I’ve seen at other companies and they never once say “Well, we can’t do that here,” they are always “How could we do that here?” No matter what it was.

The open-mindedness of what can be—and not letting preconceived notions and past experiences determine that something can’t be done—is driven by leaders. If the leaders in then room are flinching—”We won’t go with the 50 percent4, we will just go with the 20 percent”—everyone just falls in line with that and the whole creative process of creating a future stage just comes to a screeching halt.

Strong, open-minded leadership is critical in designing future stages. You need persistent leadership to make sure that future stages get implemented, because after the mapping and everyone gets back to their real job, you’ve got to make sure that you stay the course and bring that team back together as necessary. That’s why I love the group that I am working with right now in New Jersey—they just knock stuff out and get it done. Keep in mind it’s a finite number, I’m not asking them to do 50 things, I’m asking eight things maybe or six things. Let’s knock those out in the next three to six months and then move on.

Colin: I often find that those leaders who are a bit more open-minded tend to be outside-in in their thinking, so they take the time to go to other organizations to understand the best practice and look at the impact, and they try to learn and observe from that.

Drew: That’s exactly the company that I was referring to in Chicago. Most of the leadership team of development were at that company less than two years. They bought in outsiders for the reasons that you are hitting on: somebody at the top realized they needed fresh blood. Different, though, is the company in New Jersey that I was referring to. They were young people that grew up in that business, but they are just fearless. So it really gets to a personal level – are you open-minded? I can show you example of what other companies have done and I can show them certain tools that might help them. If they are willing to be open to those, then they are willing to accept them and try them, and then they go and do the research. I might introduce them to some other companies that have applied those tools. That gives them confidence that it can be done.

Colin: Sometimes the hardest thing when trying to do new things is to make a start. In the modern world everybody is very busy, and people want to have impact. For those wanting to start their journey of improving time-to-market through value stream mapping, how would you recommend that they begin? Where should they put their focus?

Drew: It depends on your current state and your targets, where you are going. Maybe I would frame the question a little differently: we have a future state, how do we get there? Part of that future state design is maybe eight major initiatives. We are firm believers in doing a few things, doing them right, then moving on. Generally speaking, let’s get the information quality first, we will get benefits of flow, we will reduce process time, and now I’ve got time to do some of the other things. Like, maybe some new tools that we are going to put in place. It takes time to put those tools in, and learn those tools.

I always look at the key ideas they come up with, and I say “Ok, you know what is coming in the pipeline, right?” What project coming in that pipeline can we experiment with?” It could be an idea that is later in the system, maybe some design for manufacturability concepts we want to apply. “What projects do you have that are close to where we can apply that?” and then we identify those. That is part of the implementation plan. Why this is important: you look at the future state and think, “It’s so big! How will we affect these changes?” I say, “You do it piece by piece.”

What I find very often is people think we have to have all these pieces in place before we can start. No, No, No. You have this moving train of projects going through to implement as quickly as possible and to learn from it, because it is just an experiment, we’ve got to figure out how to make this work. You haven’t thought that through at value stream mapping, you went to the 10,000-foot view. For every idea, it’s asking “What’s the first project that I can experiment with?” and then we can learn from that. If it worked, maybe it didn’t, so we can tweak it a bit. Maybe it didn’t work at all and we throw out that idea. We usually shoot for a year to have the future state implemented, though there are exceptions to that—a nuclear aircraft carrier was the exception when I worked with them for 15 years.

Generally speaking, the future state we want to be able to implement in a year. Now, the new projects that are coming in are going to reap the benefits of all the changes. The ones that were already in process may not have reaped any benefit because they were too far a long, or perhaps they received a bit of benefit because we were able to use them for the experiment. You have to be patient, which is not a common characteristic in leaders. And if I am dealing with a two-year lead-time, I have to be patient to start seeing measureable benefits. Maybe not two years, maybe a year.

Colin: But it’s the commitment to the journey to get there in two years that builds the organizational muscle to continuously improve.

Drew: And that’s where you need that steady leadership to keep it going. It’s not like in manufacturing where you can tweak something and measure it in a minute or tomorrow. This takes a while. When we were working on the design for the nuclear aircraft for 15 years, you know, after five years we’re asking “Is this better?”, no one knew, we had to figure it out. They are smart people.

Colin: Drew, it has been terrific to host you here at Invetech today, and thank you for taking time out of your busy schedule and to talk to me here. I am sure that the folks we send this to will really enjoy your insights and the wisdom that you have built up about how to reduce TTM by exploiting value steam mapping. You have been very generous with your time, so thank you very much.

Drew: Thank you Colin, I hope that it helps your cause in some small way.

Colin: Thank you!