Lean Design - Lean product development article by Ron Mascitelli

Published by the Product Development Business Process Roundtable, August 2002:

Taking a Lean Approach to Product Development:
An Interview with Ronald Mascitelli, PMP

Ronald Mascitelli has served as both Senior Scientist and Director of R&D for Hughes Electronics and the Santa Barbara Research Center. His experience in industry includes managing advanced R&D programs for the Department of Defense, NASA and the Department of Energy, among others. He is the Founder and President of Technology Perspectives and has taught his proprietary workshops in product design and development at such firms as Boeing, Rockwell Automation, and Raytheon. Ron is the author of the book Building a Project-Driven Enterprise: How to Slash Waste and Boost Profits Through Lean Project Management.

PDBPR: You have been somewhat critical of Phases and Gates processes. What do you perceive as some of the limitations of these types of processes?

Mascitelli: I don’t condemn Phases and Gates processes. However, I recognize that if they are put in place in an overly rigorous or, pardon the word, anal kind of way, they can be an obstacle to efficiency. I like to talk about having a permeable gate process or a process that has fewer gates that are used for freezing the requirements as opposed to being an arbitrary command and control process. Phases and Gates tend to force you into a serial progression in development – which I have found to be fallacious in almost every case. I have worked with a telecom company that put themselves out of a major market because they used Phases and Gates in such a way that they were saying: “We’re done with Concept Design now; we can’t go back and do that unless we reopen Gate 1,” or “we signed off on Gate 2 so we can’t think about it anymore.” This isn’t the way product development should work. A better way to think about it would be to ask, “At what point do critical decisions have to be made to maintain fidelity to the schedule?” The answer could be, for example, that there’s a need to freeze all system level requirements at such-and-such a point because, if they’re not, the detailed design work might need to be redone. So we might agree on a freeze point and have a gate review where we review everything: the project plan, costs, Net Present Value, etc. Then we can move forward with some frozen requirements that we can use as a foundation on which to build the project. I tend to substitute, rather than arbitrary Phases and Gates, more of a continuously narrowing funnel, with critical decision junctures used as control gates. Those companies that already have Gates can begin to align them with critical decision points in order to have a somewhat more efficient process.

PDBPR: And this is what you are calling a continuous flow product development process. Can you clarify the basic difference between Phases and Gates and Continuous Flow?

Mascitelli: Phases and Gates is a system that’s imposed from the top downward, onto the design effort – it’s a form of policing the process. It doesn’t inherently add any value. The Phase/Gate process has checklists associated with each phase so that the deliverables on the checklist are value-added, but the Gate process itself doesn’t actually transform anything. It doesn’t even necessarily require that you make any design commitments. Continuous Flow starts with the nature of the design you’re trying to achieve and then asks, “What would be the optimal critical path that would enable a multi-functional team to achieve this?” And then we work outward by asking, “What are the critical decision points that will tend to drive our schedule and drive our risk, and where do we need to put reviews in order to make sure that we can maintain our schedule and our target?” Continuous Flow tends to build from the bottom up – from the nature of the project itself, upward. You only put in as much control as you need for the nature of that project, inserting, perhaps three critical freeze reviews, in a typical duration project, where some companies have five, six or eight gates. [A process with larger numbers of gates] represents a lower risk approach. If you have a project where you’re betting the company and you feel that you have too many outsiders working on it, and it’s too complex, then using the formal Gate Reviews can be a good way of pulling things together. In an internal project where you have a half-dozen people working for one year, it’s kind of ridiculous to make them go through all that formalism to get a project out the door. It comes down to fitting the tool to the application. Phases and Gates work very well for developing the Polaris Missile system or to put a man on the moon, but is it really necessary to make a minor modification to a product that you already have in production?

PDBPR: You say that it’s vital to have a cross-functional team with a “heavyweight” team leader – what is your definition of a heavyweight team leader and why is this important?

Mascitelli: There’s a continuum of organizational designs that can execute a non-recurring project. They range from a fully functional organization, with a liaison person who borrows resources and moves material around, to a fully ‘projectized’ organization, where each team is dedicated, there’s a team leader, and they are almost autonomous. In the middle is the ‘matrix’ organization, where you have functional managers and you’ve got project team leaders and they work in orthogonal ways, pulling resources from the functional groups. A ‘heavyweight’ team leader is someone who, once the project team has been constituted, and once the resources have been identified within the functional groups, may not hold them as a dedicated resource, but they control the time they have been promised. The heavyweight team leader is the manager of those individuals for that time. The team leader makes decisions in conjunction with cross-functional teams, and the team leader has a certain amount of clout in terms of getting an individual’s time when it’s needed. The team leader can negotiate with functional managers to alter schedules, if necessary, and to have some flexibility in executing the process. The team leader is also the person who makes the critical decisions on the project that affect the business case, and that affect the overall success of the project. If you don’t have this [level of autonomy], then you immediately fall sway to the sustaining engineering interruptions, and the customer-call fire drills, and the management whim fire drills, and the changing priorities, and all those things that will limit the likelihood of the project being a success.

PDBPR: What are some methods you would recommend for gathering that all-important customer feedback at the “fuzzy front end” of product development?

Mascitelli: There are two ways of thinking about this. One of them is the idea of indwelling. The concept of indwelling is that, as much as you can, you become your customer or you find individuals who are, as close as possible, surrogates for your customer, and you use them as a sounding board for, for example, formative prototypes, conceptual focus groups, etc. You can find such proxies internally, within your own company. In my opinion, marketing tends not to be a particularly good choice for this because they can become like the fox in charge of the henhouse. If you ask marketing what the product should look like, the product would have every feature that any customer had ever mentioned. Instead, what you need to do is find someone internal, for example an applications engineer, installation engineers, or service and repair people, who are actually in the field working with the customers who are using the product. If you don’t have that, then the next best thing is to find someone who is a lead user or a lead customer with whom you have close relationship, and either send some of your people to them so that they become part of their product teams, or you can bring them in as part of your design team and make them partners in the design.

Another tool is called probe and learn. If you’re not sure who your customer is or what they’re looking for, then come up with some low cost prototypes or simulations that you can test. You cast a big net and let the market pull on the ones they are most interested in, you can then refine what is in your ‘net,’ and then go back to the market and say, “you said you liked this, now how about this version…or this one…or this one.” This approach lets the market pull the concept from you, instead of saying, “We think this is what the answer should be and we’re going to convince you that we’re right.”

PDBPR: You explain the apparent oxymoron “mass customization” by saying that it’s really “the postponement of customization” until relatively late in the process. What are some approaches teams can use to this “postponement of customization?”

Mascitelli: I believe that the best company in the world is one whose products look different to every customer and yet the factory can’t tell the difference between them. You get the full price advantage of full customization and you get the full advantages of mass production. There’re many ways to achieve this. One of them is to work on platforms. When people speak of a product platform they think of a chassis or an enclosure. My concept of a platform is any multi-use component that spans multiple products or even multiple product lines. You could have a valve platform, and a connector platform, and a circuit board platform, and each one of those, because they span multiple products within a line or even multiple lines, looks the same in every product. The factory can’t tell the difference between them. A better approach would be to postpone assigning a unique product part number until very late in the production process. Build a number of these sub-assemblies or platforms and [toward the end of the process] assemble them into whatever unique configuration you need.

A good example of this is a product where the primary control and functional features are embedded in software instead of hardware. You produce the same hardware for everybody but in the end you just load in the appropriate software and you sell it as “Product A” as opposed to “Product B.” Even more effective is selling the ability [for end users] to customize [the product]. A good example is “the select comfort mattresses,” the ones that have the inflatable valve on them. To me this is a perfect product because the fact that one can choose one’s own comfort level is a selling point; but the benefit to the company is obvious: they do not have to carry mattresses with different levels of firmness. From their perspective it’s one product, but the market sees it as an infinitely customizable product.

PDBPR: There’s been a lot of talk over the years about the benefits of co-located teams, but you suggest that in some ways they can even hamper communications. Why is this and how can it be remedied?

Mascitelli: Co-location is like a lubricant. It makes it easier to do everything, provided that you have the right communication and controls in place. The drawback of it is that people are so close together that wasteful conversations and needless interruptions can be rampant. You can even get situations where people make decisions on the fly; one group is over in a corner, they get together in someone’s office, and they agree to do something that isn’t communicated to the rest of the co-located team. In such a case, in principle, people are disenfranchised instead of being brought together for the purpose of making a decision. Having an army co-located on a battlefield without tactics or strategy or control is useless. What you need is control in the form of some kind of coordination (and I recommend the stand-up meeting format) and also synchronization of effort. Everyone needs to know what decisions have been made and they need to know where everyone else stands. If you can get that kind of communication, and that kind of control over decisions, then you can have a co-located team and benefit from it. If not, then I think that, if anything, the chaos and the turbulence in co-located teams can be a negative. I’ve seen teams that can’t get anything done. They are so impressed with their own intelligence that they don’t produce any real work. But the real point here is not to disparage co-location but to recognize the need to run the team once you’ve got them together and not assume that co-location is a panacea that’s going to solve all of the communication problems such that we don’t have to manage it. In fact, it’s just the opposite!

PDBPR: You make an interesting distinction between calendar time, work time and value-added time. What’s the difference between these three classifications of time?

Mascitelli: Calendar time is, obviously, the actual duration of time on the calendar that it takes to complete an activity. It’s the market clock, if you will. The work time is the amount of time one has applied to attempting to do the task. This tends to reflect the resource allocation. For example, if I am expecting a full time person and I only get a half time person, then the work time will equal only half of the calendar time. Of the time that someone is actually working, how much of that work really needs to be done to achieve the deliverable that’s needed at the end of the task? If they’re working on something that is incorrect, if they’re doing more work than is needed by the customer, if that deliverable is not what is needed by someone further down the line, then there’s waste. If you really want to optimize you’re process, then you need to look at the ratio of calendar time to work time. If someone spends a week on a task, but there’s only about a day’s worth of useful information coming out of it, then you need to go back and look at what it is that is being created. There are two different improvement opportunities in any product development process. One is to get people doing the work when needed, and the other is to try to make sure that they only perform tasks that genuinely add value.

PDBPR: And what about value-added time? What is your definition of a value-added activity?

Mascitelli: Any activity or task in a product development effort is value-added if it transforms the deliverables of the process in such a way that the external customer would be willing to pay for it and would be aware of that transformation. Transforming the deliverable means working on something that will go directly into the launch package for that product – the essential pieces needed by the factory, or in the marketing domain, or in the sales domain, that will make that product a viable business. If I’m creating a drawing that’s going out to the factory – that’s value-added. If I’m creating a brochure that’s going to go out with the sales force – that’s value-added. However, if I’m going to do some research work that may benefit some future products, that’s not, strictly speaking, value-added – it’s a strategic investment. This is a somewhat mercenary definition because when I say “pay for it,” I do mean, dollars out of pocket.

PDBPR: You point to approval cycles, regularly scheduled meetings, planning cycles and first-in-first-out queues as areas that can attract waste. Can you pick one of those, maybe a particular pet peeve, and say how it can be made leaner?

Mascitelli: One of my pet peeves is the “first-in-first-out” queue. It is the worst way there is to allocate company resources. It makes the assumption that everything is the same priority. By homogenizing and democratizing priorities you have inherently put something that’s lower priority ahead of something that’s higher priority. The only time when that is an acceptable approach is when you have excess capacity, which is another way of saying that the work time and the calendar time are equal. If you have people sitting around waiting to do drawings and they don’t have any other work, and, as soon as a drawing needs to be done, someone is immediately assigned to it, and they do the work as fast as they possibly can, then you can use first-in-first-out. But in such a case you don’t really even have a queue. As soon as you have a queue, then, just like in the factory, you have a ‘buffer against the machine.’ In this situation, if you don’t put the priority jobs first, the opportunity costs to the company will kill you! Any bottleneck or constraint in the process needs to be addressed with a priority system, so that the high priority work always goes through the bottleneck first.

PDBPR: What are some of the characteristics of what you term “customer defined deliverables” and why do you believe that this is a particularly powerful concept in the domain of lean thinking?

Mascitelli: In my many years of experience as a practitioner, I saw too many internal deliverables created in an ‘over-the wall’ fashion. For example, there’s a need for a quality plan. Well who defines what the quality plan looks like? Each engineer defines it, separately, based on some older example that they picked out of their filing cabinet and then marked up. They do a great deal of work, in a vacuum, and then they throw it ‘over the wall’ to the Quality person, who throws it back, with a couple of change recommendations, and they go back and forth. An alternative would be to have the Engineer sit down with the Quality person, up front, and ask: ‘What are the requirements? Give me a template and then let’s mark it up and use it as a straw-man to define exactly what it is I’m going to create for you.’ This method is almost like getting the document pre-approved. You get a clear, up front understanding of all the pieces and all of the steps. Perhaps you do a feed-forward three-quarters of the way through the process to make sure you’re on the right track. By the time your deadline arrives, it is almost pro-forma. The internal customer is already familiar with the document and has approved the format and the content. I site a counter-example in my book where a telecom company created a 120 page test plan for their test department to use in the production and testing of some equipment, and only five pages of the document were actually used. They threw the rest of it away. No one had ever talked to the internal customer about what was actually required. It was all done ‘over-the-wall.’

PDBPR: In your book you highlight the idea of “exception management.” What is exception management and how does it work?

Mascitelli: Exception management turns on its head the sort of command and control approach that’s been used ever since the days of Frederick Taylor in the 1920s and 30s. In Taylor’s world, there were white collars and blue collars; white collars control and the blue collars do the work. That same idea – that managers control – has been the pervasive view until the past ten years. Over the past decade, there’s been a lot of discussion about empowerment. However, perhaps one percent of the companies I have worked with have something that resembles real empowerment. The reason for this is that empowerment only works if you define an envelope of performance, which the employee can operate, and then you give them full autonomy within that envelope. For example, you could give a designer a weight limit, a target cost, a target date for completion, and key performance parameters. And then you turn the designer loose to design as he or she thinks best… with the admonition that if the designer cannot hit any one of those targets the team leader must immediately be notified of that exception.

If I’ve defined my envelope properly, then your piece of the puzzle will fit if you successfully hit your targets. Then, as a team leader, the exceptions are the only things you have to manage. The biggest issue here is maturity – both organizational and individual. People need to be encouraged to be honest about their schedule. But it’s also incumbent upon the team leader not to shoot the messenger. If someone comes with bad news you don’t yell and scream, but say “thank God you came to me.” That’s empowerment…and it enables exception management. The two go hand in hand.

PDBPR: “Economies of scope” is another concept you discuss in your book. What are economies of scope and how can teams benefit from them?

Mascitelli: Product development is a recurring process to perform a non-recurring activity. Embedded in that is the assumption that some things are common in every product development process. Although it does not have the benefits associated with classic economies of scale, it is possible to identify elements that are common to most product development processes. For example, if you’re always going to use a product specification then you should use a standard template for it. That way you hit the ground running and save some time while ensuring a healthy level of uniformity. You can also have a standard Design Review process that is tailorable and flexible. There’s always room to standardize, even on the design side of things, by having, for example, common components or common fasteners. The aim is to standardize as much as possible without compromising innovation and creativity. That’s a key point – never let a standard conflict with creativity.

The limit at which we can factor out these economies of scope is the limit at which the process can be made to look the same, without sacrificing innovation. Phases and Gates is a good example of what I mean by economies of scope because the same process is used by everyone, but every project is a little different and every project can tailor that process to the needs of the challenge at hand. If you’re company has phases and gates, I would recommend making them very flexible. Some projects need only one or two gates; some need all five. Keep the checklists flexible and the gates, permeable, so that you can delay final approval of some items.

Some people have thrown up their hands at product development and said, “well, it’s always different.” Well, it is not always different. There’s a great deal, in fact, that is the same from one project to another. You could put numerous tools on a common website within the company and let each team leader access templates or standards. You can even have a template for a whole project plan. One company has five or six project plan templates – one for a line extension, one for a brand new project, one for an OEM project, etc. This provides a good starting point and it helps you make sure you haven’t missed something – because it’s a proven process and a proven plan.