R&D Myopia: Looking at R&D Processes Through a New Lens

Research & Development can be a challenging process. It operates with a view across multiple areas of the enterprise. It looks at competitors, at the marketplace, at strategy and brand, and it must come to grips with an inherently hazy future.

John Lamy of Lamy Consulting

General managers tend to think about their R&D operations in terms of the projects, the technology, and the deep expertise it houses. I’d suggest also thinking about the R&D process itself. New ways are emerging to ameliorate the false starts and delays, the perennial understaffing, and the all-too-frequent mis-targeting that so often afflicts R&D.

Let’s take a look at a typical scenario, a composite of three real companies. Does any of this sound familiar?

Acme-Tech makes smoke detectors for the residential construction industry. Dave started Acme-Tech in 1997, just after finishing his Ph.D. in chemical engineering. He now has 59 employees and does $13 million annual revenue. Acme-Tech sees itself as an industry leader, but Dave is about to get smacked by a perfect storm.

Acme-Tech’s R&D consists of Dave and six other engineers, and over the years they have added a CO₂ detector, a CO detector, and three other similar products ... all fairly high-tech, with interesting features and leading-edge performance. Their focus has been on technology and products, but the R&D process itself has remained hidden in Dave’s blind spot.

They had planned to introduce their new CO detector at the Chicago Home Show in March, but unfortunately the project was delayed and they’ll have only a spec sheet to present ... no hardware. But across the aisle at the show, their main competitor Syner-Tech is introducing a new smoke detector that outperforms theirs. And an Oregon-based startup showed a new product that under-performs theirs but is priced 70% below theirs, a classic disruption play¹. Dave is hammered by the perfect storm. Didn’t see it coming. Red flag, bad days ahead for Acme-Tech.

The Framing Problem

Given the heavy lifting involved, most of us tend to sweeten R&D by seeing it as Opportunity (think SWOT Analysis). That’s exactly what Dave does, implicitly and unconsciously. After all, we are engineers exploring and creating new products for the future.

In this scenario, I’d suggest something a little different: at the top level, R&D should be viewed as mitigation against Threats. In the trenches, day to day, R&D is fun and teeming with opportunity; but strategically we need to look more broadly and remember the words of Intel CEO Andy Grove²: ^“Only the paranoid survive.” If we don’t do it, a competitor will. And there are many more possibilities than we can address given reasonable resources, so we have to be effective as well as wide-angle in our R&D project selection and execution. R&D is our offense, but it’s also our most important defense. And we need to see not only what’s ahead of us, but also what’s coming at us from every angle.

R&D Process Innovations

The last few decades have witnessed the arrival of the Lean philosophy from Toyota and other organizations. Lean is about eliminating waste, reducing big batches of work (WIP in manufacturing), moving smoothly and quickly, and, most importantly for R&D, harnessing the creativity and initiative of the people who operate the processes. While the Lean philosophy has found a comfortable fit in manufacturing, its application to R&D is more of a subtle and slower integration.

If you haven’t taken a good hard look at your R&D process for a few years, you may have unseen problems about to catch up with you; and your competitors who are already implementing Lean principles may be passing you by.

You don’t want to find yourself in Dave’s position, so where do you start? The good news is you don’t have to completely retool everything you know in order to incorporate Lean principles. Rather, you can begin looking at tried-and-true R&D processes through a new lens.

Portfolio management and set-based design are two critical processes that support world-class R&D, and both have been enriched by the incorporation of Lean principles.

Portfolio Management

In my experience, I’ve never seen an R&D project that wasn’t understaffed. In a sincere effort to contain expenses, the management team unwittingly stretches out the project duration and actually drives costs upward. This happens innocently: a project idea pops up and generates excitement, and the team devotes resources to it, more or less unconscious of the impact on all the other projects. You rarely put all the projects in the context of each other and think about the total effect of that constellation on your development effort or even your future business trajectory. The take-away: you need a robust methodology to decide which projects to execute now, and which to put on your future Project Roadmap.

Welcome to Portfolio Management. There are four distinct steps. The first two steps represent homework, prior to a big, one-day, intensive meeting where we execute the third step. And after the meeting, maintenance is essential.

Capacity Estimation

How many projects can your R&D operation successfully execute? I’m always amazed at how little attention goes to this critical question. Let’s start with the basics: just estimate how many person-hours of effort per year you can commit to R&D. Include your R&D team, plus other folks who contribute to the effort from other functions. Come up with a single number. This number is your ticket to the future.

This number translates back to the percent of revenue that your company invests in R&D. Ask yourself, is it consistent with your stated strategy? And does it mesh properly with your industry’s norms?

Candidate Projects

Next, create a list of products you’d like to see in your future line-up; each one could become an R&D project. This kind of dreaming is fun and creative. It also requires a penetrating look at the future, what the competition is doing, where the technology is heading, and how your market is developing. This was one of Steve Jobs’ many strategies, and it’s something you can implement as well.

Ensure each project on the list is backed up with a one-pager that spells out the key specs, the possible sales volume and profit level, the strategic role (e.g., enhancement or breakthrough), a ballpark estimate of required staffing, and total project effort (person-hours), duration, and cost. It also lists the key risk elements and quantifies them on a simple 0-10 scale (10 means high risk). Similarly, assign the strategic importance a 0-10 score.

Now for some calculations. Compute a financial figure of merit for each project. Net Present Value (NPV) is the obvious candidate, and we’ll use it here; but you may have some other financial metric you like better.

The risk-adjusted NPV: First convert the risk into a percentage of certainty: certainty % = (10 – risk) * 10, so a totally certain project gets 100%. Then multiply NPV * certainty % to get risk-adjusted NPV.

Finally, calculate the R&D efficiency: the benefit of the project relative to your capacity to execute it. Begin by calculating the total effort required, which roughly equals duration * staffing level, expressed in person-hours. The R&D efficiency = risk-adjusted NPV/effort.

So on the eve of the one-day, intensive Portfolio Management meeting, you have a list of candidate projects, a one-pager for each, and six key parameters for each:

• NPV ($)

• Risk (0-10)

• Risk-adjusted NPV ($)

• Development effort (person-hours)

• R&D efficiency ($/person-hour)

• Strategic importance (0-10).

Portfolio Management Intensive Meeting

I can’t stress enough the importance of this meeting. Today you will map out the future of your company.

Consider who should attend this meeting. Include top-level managers and key people from R&D, marketing, and manufacturing. Keep it as small as possible, but include the genuine players. I suggest bringing in an experienced facilitator, both to keep the meeting moving forward efficiently and also to allow the CEO to be an active participant

The meeting is essentially an exercise in decision-making. The key question to be answered is, “Which projects shall we launch?” As such, it embodies the two fundamental aspects of making decisions: the rational, and the intuitive. I have a respect for both and believe there is no cookie-cutter structure for this meeting. Ideally, the meeting will build on a base of classical decision-making while also encouraging the intuitive, history-based mind to speak up as well. For tie-breakers, the CEO has the last word. This helps everyone to feel heard, and the process will be as transparent as possible.

First on the agenda is a brief pitch from an advocate for each project: why it’s a good idea, where the parameters came from, etc. Allow approximately ten minutes for each project, depending on how many you have.

Then move on to the serious decision-making. Let’s look at two approaches:

You could simply arrange the list in descending order of R&D efficiency, and draw a line when you reach your capacity. This approach captures the highest NPVs, and tempers meeting members with the effort spent by your R&D machine. The problem is, it’s a little too robotic and doesn’t capture the intuitive, heuristic wisdom of the group.

I prefer the classical decision-making matrix, where key parameters, with assigned weights, are listed down the left and the individual projects are listed across the top. The assembled team then scores each project on each parameter, the computer does the multiplication and addition. The top scorers are included in the “keeper” set, until capacity is reached.

This is the more rational approach, but keep in mind there is no bulletproof way to manage your portfolio.

Portfolio Management Decision Matrix

Next, with a bit of quick arithmetic you lay out a Product Roadmap reflecting just the keeper set: when will each one hit the market? How do external constraints (trade shows, important customer requirements, etc.) fit into the Roadmap?

Then, cover the intuitive side “Why did we weight this parameter a 10? I think it should be a 6, and look what that does to the list.” “If we don’t do the xx product, Syner-Tech will and we’ll be toast.” “Dave, I think you are unrealistic about the yy product.” On and on. This is when the realistic goals get voiced.

And, you’re seeking balance across several important dimensions. Breakthrough projects are typically riskier and return less NPV per unit of R&D effort. Improvement projects are quick and easy and pay nicely. You need all that, so it’s important that the conversation include these subjective aspects as well.

If the process is working well, a consensus emerges; if not, the CEO has the opportunity to weigh in.

Last step: continue the Product Roadmap with projects that didn’t make the cut in this round. On your Roadmap, show all the new products deployed across time. This serves a couple of purposes: it gives you a good starting point for the next Portfolio Management Meeting, and it helps stop feature-creep in existing projects, e.g. “We don’t need to shoehorn this feature in, we’ll put it in the B-version next spring.”

Product Roadmap

Maintenance

How often should you go through this exercise? It depends on your situation, but twice a year is suggested. Remember, this is the management of your future.

Good visual management of your R&D projects will enable the management team to keep an eye on things on a week-to-week basis. If bad news erupts from within R&D or from outside the company, be very responsive — don’t hesitate to hold another Portfolio Management Meeting on short notice.

Set-Based Design

Under the Lean R&D model, there are about a half-dozen similar intensive meetings where an enormous amount of work gets done in a single day. Plus, the benefits of buy-in and coordination are huge. Let’s take a look at another one of those meetings, the review of Set-Based Design.

Serial Development

Chances are that Portfolio Management seemed to you reasonable and culturally appropriate. By the same token, Set-Based Design may seem a little strange and counter-cultural. Back in the day, the design team would typically get an idea in its creative head and “just do it.” It’s the culture where we value action, results and speed. In my younger engineering days, that’s exactly what we did.

But there are problems with this approach. First, fairly often we’d hit a snag downstream and have to reset. Could we have foreseen the snag? Sometimes no, but fairly often, yes. And the reset is a serious do-over that takes almost as long as the original dead end.

But the deeper problem is more subtle: the kind of knowledge that the team gradually accretes has a breathless, frenzied feeling to it. It’s shallow and solution-specific. It’s not the kind of expertise and insight that we truly want to cultivate in our R&D organizations.

Overall: doing development this way, one idea at a time, actually takes longer than set-based design. Not good.

Parallel Development

Toyota designs differently by using a parallel development approach. First they isolate the highest risk aspects of the design, the parts with the most unknowns, and then focus on them. They choose to figure out the low risk stuff later. Then they gather the most promising approaches to each high-risk problem into a list. Here’s what’s different about this process: they study all different solutions, as a set; they don’t zoom in on one immediately. They get to know the territory and run many quick-and-dirty experiments to begin the winnowing. By quick, I mean hours and days, not months. I vividly remember doing this as an engineer when I began to catch on to set-based design. Gradually, they rule out various options. The design begins to come together.

But here’s the key: the knowledge Toyota is building up is deep. It’s genuine expertise. It’s robust, deliberate and comfortable. Then, if there are resets because they’ve missed something, the response is much faster.

And the big prize: set-based design actually goes faster.

Putting It Into Practice

Again, you’ll want to hold another meeting. But this time, no top-level managers. This is strictly tactical and technical. So the attendees are the key technical and project management folks.

And it’s actually a series of meetings spread over a few weeks or maybe a month or two. Here are the steps:

1. List the risky elements on a flipchart.

2. Assign an owner to each risky element.

3. Quantify the risk (0-10) and do a little brainstorming.

4. Commit to specific actions, research, and tests before the next meeting.

5. Post the situation on a visual management whiteboard in the meeting room, so the management team can walk by and know within a minute how things are going.

Visual Management Whiteboard for Set-Based Design

Adjourn until the next agreed-upon meeting. When the second meeting starts, highlight progress, knowledge acquisition and risk reduction that has been achieved to date. Brainstorm, cross-fertilize, help each other out. Remember, since no managers are in the room, focus on getting problems solved.

Exception: Strategic Outsourcing

There is one important area where the management team needs to be involved in this discussion: the make/buy decision. Sometimes this is a complicated and strategic decision. Ask IBM in the 80s about outsourcing the processor to Intel and the OS to Microsoft, and what that did downstream to the PC’s profitability and IBM’s survival in the PC business.

Outsourcing is quicker and cheaper, so sometimes it’s great. But sometimes it enables suppliers reap your benefits later. The right answer depends on the situation in your industry relative to prevailing customer satisfaction levels. (See the discussion in Christensen³.)

When the Risk is Low Enough

At some point in this process, we reach a tipping point: the risk is low enough that we can shift gears. The litmus test is that we have enough knowledge to create a top-level or system-level block diagram of the product, with an understanding of the approach for each block and how we’ll verify that each block is working correctly.

Only now do we enter the formal Project Management paradigm. We convene the team to create a Gantt Chart, and we manage the project as we execute it. Our goal becomes a string of prototypes, along with the concurrently developed capacity to build the product in production.

Myopia versus Lean

In this article I’ve presented a glimpse into some of the limitations of R&D as it is currently practiced, and a couple of examples of lean practices that typify the emerging Lean R&D paradigm⁴.

If your R&D focus is entirely on technology and product — and you are neglecting process, strategic fit, roadmap, core competency, and similar big picture aspects of running the business — at best, your R&D efficiency will suffer. At worst, you will end up like Dave at Acme-Tech: with blind spots and vulnerabilities and a bleak competitive future for your company.

If you begin now to incorporate Lean principles through the methodologies discussed above, you will begin to reap benefits almost immediately. Why go Lean?

1. It’s more efficient. You spend less money for the same (or better) eventual outcome.

2. It’s quicker. Yes, you go slower in the early stages. You think more deeply about what products to develop and how they fit your competencies and your roadmap. And you follow alternative solutions longer. But, when the chips are down, you don’t go running back to square one without a clue. This means you can begin to reap revenue sooner. And, as sometimes happens, you get there before your competition and stake a claim in the space.

3. It’s better. You get products that are more competitive and that populate a more intelligent roadmap into the future.

I’d suggest that you occasionally sit back and take a long look at your R&D function. Sure, think about the projects and the deep expertise — but also think about the R&D process itself. Like everything around us, it too, is evolving. Are you truly up to date? Do you think of R&D as a bulwark against threats, as well as a great exploiter of great opportunities?

The two processes I presented here are examples from a generous handful of similar ideas. Of course they’re not totally new, but the Lean approach has contextualized them and enhanced them. They’re fairly straightforward to implement, and they can yield exceptional returns to the efficacy of your R&D program. Give them a try.

John Lamy worked in Silicon Valley for 25 years as an R&D manager and consultant. He has a BSEE from MIT and an MBA from Cornell. Contact him at [email protected].

References

1. Christensen, Clayton M. & Raynor, Michael E., The Innovator’s Solution, 2003, Harvard Business Review Press. Pages 31-71.

2. Grove, Andrew S. Only the Paranoid Survive, 1996, Doubleday Currency.

3. Christensen, ibid, Page 125-148.

4. Mascitelli, Ronald, Mastering Lean Product Development, 2011, Technology Perspectives.