Need for Structured R&D Roadmaps – Daimler Example

Source Daimler
It takes a long time to develop new technologies and integrate them into products. The wired article How Daimler Built the World’s First Self-Driving Semi has a great example:

Daimler, which owns Mercedes-Benz, has been working on autonomous driving for two decades.
…
As amazing as this thing is—it’s a fully autonomous 18-wheeler that works—company execs say it won’t can’t change lanes on its own, it won’t be market-ready for a decade, and could never replace human drivers.

Clearly, developing technologies takes a long time. So successful development needs intermediate productization of technologies.

Much of the technology in the Inspiration—the radars and cameras, the computing power and electrical architecture—has a long track record of commercial use in active safety features like lane departure warning and adaptive cruise control.

Rethinking knowledge management for R&D teams

As we know, R&D is focused on generating knowledge. Unlike manufacturing, where the outcome is products, R&D generates knowledge about how to build those products. Hence R&D workers are all by definition knowledge workers. The article Rethinking knowledge work: A strategic approach from McKinsey Quarterly has a very thorough discussion about IT tools needed to help improve the productivity of knowledge workers.

In the half-century since Peter Drucker coined the term “knowledge workers,” their share of the workforce has steadily grown—and so has the range of technology tools aimed at boosting their productivity. Yet there’s little evidence that massive spending on personal computing, productivity software, knowledge-management systems, and much else has moved the needle. What’s more, a wide variety of recent research has begun suggesting that always-on, multitasking work environments are so distracting that they are sapping productivity.

As we can all relate, what information is provided to R&D teams is far more important than how much. In fact, we need to reduce the information overload.

It’s time for companies to develop a strategy for knowledge work—one that not only provides a clearer view of the types of information that workers need to do their jobs but also recognizes that the application of technology across the organization must vary considerably, according to the tasks different knowledge workers perform.

The article defines two approaches for providing knowledge (information) to R&D teams: 1) Free access where team members have access to the entire knowledgebase and hopefully select the information they need and 2) Structured access where information is prefiltered for the team member.

Few executives realize that there are two divergent paths for improving access to the information that lies at the core of knowledge work. The most common approach, giving knowledge workers free access to a wide variety of tools and information resources, presumes that these employees will determine their own work processes and needs. The other, the structured provision of information and knowledge, involves delivering them to employees within a well-defined context of tasks and deliverables. Computers send batches of work to employees and provide the information needed to do it.

Free Access is the model employed by most R&D organizations because of their ease of implementation:

The information technology behind the free-access model is relatively easy to implement. The Internet and social media are readily accessible to anyone, and access to third-party databases is possible with any Web browser—although closed company cultures sometimes impede knowledge sharing.

Clearly, most R&D workers know are knowledgeable and know what information they want. However, the problem with free access is the volume of information that one obtains when one starts looking for knowledge.

The problems of free access are fairly obvious: while workers may know how to use technology tools, they may not be skilled at searching for, using, or sharing the knowledge. One survey revealed that over a quarter of a typical knowledge worker’s time is spent searching for information. Another found that only 16 percent of the content within typical businesses is posted to locations where other workers can access it. Most knowledge workers haven’t been trained in search or knowledge management and have an incomplete understanding of how to use data sources and analytical tools.

The problem of searching for relevant information is exasperated even more in the R&D environment. An employee searching for thermal cracking problems in an engine block will find all documents that have the words thermal and cracking. Even when narrowed down, thermal cracking may be related to very different mechanisms. The employee will likely give up the search and start working from scratch instead of digging through voluminous design documents. This was a common problem I faced when I was trying to investigate failure modes in past systems to generate more robust designs. A key answer would be to structure and filter the knowledge so that only the relevant information is displayed.

“Structured-provision technologies first appeared in the early 1990s and have improved considerably of late. They often have a range of functions. The most important is workflow technology that controls how knowledge workers get information and job tasks. These workers may encounter supporting technologies that include information portals, business rules or algorithms to automate decisions, document- or content-management systems, business process management-and-monitoring systems, and collaboration tools. Increasingly modular component designs make these technologies easier to deploy.”

Structured access has had some success in simple knowledge work like mortgage application processing or insurance claims processing:

Productivity is the major benefit: as measured by the completion of key tasks per unit of work time, it often rises by 50 percent when organizations implement these technologies. One automobile-leasing company, for example, achieved such gains after it implemented a new system for lease processing and end-of-lease sale offers. The reason for the improvement was that workers had few distractions and spent no time searching for information.

The key disadvantage of structured access is that by definition it reduces direct interaction between workers. Furthermore, it requires a well defined process that can be automated to structure the knowledge.

In structured information environments, computer systems rather than knowledge workers integrate the work, so extensive system and process design is required up front for implementation. While these systems can be tailored to fit complex business processes, that kind of tight fit can become a problem if business environments or processes change.

This is easy to do in simple tasks but very difficult to do for complex R&D. Some work has been done in structuring interactions for systems engineering requirements management. However, I am not sure of any tool that can structure access for R&D environment (beyond those developed by my firm InspiRD.) The article provides a useful framework to analyze what type of access would be beneficial in which environment.

R&D clearly falls under the top right corner of this 2×2,. I would contend that even under that scenario, some amount of structure is absolutely critical to effectiveness. In fact, we need a hybrid approach where the IT systems filters and narrows the search results for the team member. It then provides free access only to the relevant information so that the R&D team member can reuse past development.

Another way of smoothing the path to structure is letting knowledge workers use familiar, typically free-access tools when they interact with a structured system. To alert them when it’s time to use a structured application, for example, have it send them an e-mail. If a structured task requires, say, passing financial information to and from the system, let workers use a spreadsheet. Always remember: high-end knowledge workers don’t want to spend all their working hours interacting with automated tools.

Limiting choices in a hybrid approach, if implemented correctly can actually enhance collaboration and interaction. If team members are overwhelmed by the amount of information and start redeveloping technologies, free access will reduce interactions – not enhance collaboration. By limiting choices, we might be able to encourage R&D teams to engage in productive purpose driven communication and build networks.

We live in a world where knowledge-based work is expanding rapidly. So is the application of technology to almost every business process and job. But to date, high-end knowledge workers have largely remained free to use only the technology they personally find useful. It’s time to think about how to make them more productive by imposing a bit more structure. This combination of technology and structure, along with a bit of managerial discretion in applying them to knowledge work, may well produce a revolution in the jobs that cost and matter the most to contemporary organizations.

Why Open Innovation is hard to implement

We have often discussed how innovation has become a buzzword with many myths surrounding what drives innovation. I was recently discussing Open Innovation with an R&D executive. He made a pretty significant remark: There are lots of positive articles around open innovation, but there do not seem to be many balanced evaluations of the approach. Fortuitously, Knowledge@Wharton has an interesting note about The ‘Flip Side’ of Open Innovation that addresses some of the concerns.

A lot of people have been writing about open innovation,” says Wharton management professor Felipe Monteiro. A typical example, he adds, is Procter & Gamble’s Connect + Develop strategy, which encourages collaboration with outside organizations as a way to bring new products to market faster and more efficiently.

While the P&G approach “has gained a lot of traction,” Monteiro notes, it also raises questions about whether, and when, companies should be concerned about protecting their own knowledge. Monteiro’s research into this issue has led to a paper titled, “Does Strategic Protection of Knowledge Undermine the Effectiveness of External Knowledge Sourcing?” co-authored with professor Michael Mol from the Warwick Business School, and professor Julian Birkinshaw from the London Business School.

I am going to use the article as backdrop to summarize four key concerns about Open Innovation and why it appears that many companies are not really recouping their open innovation investments (much less earn a return on them). We should all think carefully about these before investing in open innovation:

Valley of Death: A key concern in innovation is getting it transitioned into delivered products. Many companies I have worked with fail pretty frequently at this stage. We have discussed the valley of death extensively. The more disruptive (and hence the most valuable) the innovation, the more difficult it is to get it to market because it disrupts company culture and bureaucracy. When accessing innovation from the outside, this becomes even more difficult because of “Not Invented Here” mentality. Unless one can find an internal technologist or champion, open innovation just withers on the vine. This is very hard to overcome and needs active management involvement.
Trade Secrets Protection: We have often discussed how innovation is not about an aha moment or one brilliant idea. Innovation happens at the interface of multiple disciplines and technologies. (For example, iPhone could be seen as combining a capacitive touch screen with low power processing and an intuitive user interface. Each was available in the market, but the integration generated value). To access innovation from the outside, companies will need to share their problems in enough detail that potential suppliers can describe solutions. However, this description will also be available to all competitors – which defeats the whole purpose.
Evaluation / Management costs: As discussed earlier, managers need to consider many potential issues before deciding on accessing any innovation from the outside. A key issue that is forgotten is the time involved in evaluating innovation ideas. Because of trade secrets related problems described above, most companies use open innovation to access ALL innovation. Broad ideas need to be filtered before they can be sent to the technical teams – a task that requires management involvement. Companies quickly realize that this is VERY expensive. Even when ideas sound interesting, the value is difficult to estimate. Innovation needs to be accessed when needed – we can not just let innovative ideas sit on a shelf and get to them when the need arises. Innovative ideas require maturation and many cospecialized assets to get them to market. This is not cheap to evaluate.
Liability: When suppliers submit their ideas to companies, how should they be protected? Any implied protection exposes the company to potential litigation liability. Disregarding inadvertent public release, consider the possibility of independent discovery. The company may have independently developed ideas similar to those accessed through open innovation. If they decide to use internal ideas, they might still be exposed to IP litigation. Hence, most companies ask suppliers to submit ideas with all rights released! Most people are not willing to do so…

I welcome comments…

Collaboration for New Service versus New Product Development

Another quick note: This one about differences between collaboration in new product development vs new service development in the Journal of Product Innovation Management (A Comparison of New Service versus New Product Development: Configurations of Collaborative Intensity as Predictors of Performance):

Collaboration among firms for innovation has received considerable attention. However, little is known about how firm-to-firm collaboration is configured in new service development (NSD) versus new product development (NPD).

The article measure the impact of 1) Good processes / communication vs 2) Good relationship / trust. They find that collaboration on products is more effective with good processes while collaboration on services is more effective with trust. Probably makes sense: Services are inherently unprotectatble and trust is needed to ensure the partner plays well.

2011 Global R&D Funding Forecast

Here is link to the 2011 Global R&D Funding Forecast: from the R&D Magazine: “

Global Spending Following cuts in total R&D spending by most advanced economies during the global recession in 2008 to 2009, R&D spending growth resumed, albeit at reduced levels, in 2010 and is again forecast for 2011. Rapid growth in R&D spending in emerging Asian nations only slowed slightly during the recession and is forecast to continue growth that is several times that of the advanced economies.

US has a third of the global R&D spending, even though others are growing much faster. Here are some takeaways:

In addition to outsourcing R&D, many organizations are building new R&D facilities in offshore locations.
R&D Collaboration is increasing between developed and developing nations, with all parties gaining from it.
R&D gap between developed and developing countries are narrowing as measured by patent filings. Even though developed nations continue to file for new patents, developing nations are fast accelerating their rate of patenting.
And some good news – academic innovation and R&D is accelerating. May be because many strong students went back to academia when they could not find jobs in the great recession…

A lot of interesting data.

Social networks helpful in improving R&D efficiency?

MIT Sloan Review article The “Unstructured Information” Most Businesses Miss Out On has some interesting benchmark information on the role of social networks in driving knowledge collaboration (and hence efficiency) in R&D environments. The article details an interview with, K. Ananth Krishnan, the CTO of Tata Consultancy Services. As you might remember, I have not been very impressed with the role of social networks in complex R&D. TCS seems to have great success using social networks to share knowledge between geographically disconnected employees:

Well, let’s talk about the use of social webs inside the enterprise. Here at TCS, we are having a lot of success in saying that if you’re dealing with a particular problem and you need help, you go into our social platform and you just ask. You type in a question saying, “This is a problem I’m having. Has anybody solved this before?” And you might get five responses in 30 seconds from people who have done exactly what you tried to do, and they have their solutions.

That is great. Can we replicate this trend in any R&D environment? What are some of the challenges involved in using social networks effectively in an R&D environment? Mr. Krishnan points out one:

Of course, three responses might say one thing and two might say something totally different. So you still have to use the intuition and the judgment.

So, one key problem with social networks is not knowing the veracity or accuracy of solution provided. The other key problem is ability to describe the problem in sufficient detail that someone could suggest a meaningful solution. Let us dig in:
Mr. Krishnan is in the IT business where a more or less common language / jargon is shared between all employees. Most physical system require multiple disciplines (mechanical, electrical, etc) that all speak different jargons. Furthermore, most problems occur at the intersection of different disciplines. It is extremely hard to describe such multidisciplinary problems in sufficient detail in a social network. Even more importantly, there are only a handful of people who could understand the problem and provide a realistic solution. Social media would probably not be the most effective means to reach those people. We should probably consider project networks?
That said, clearly, homogeneous environments such as software development or ASIC design can benefit from social networks. TCS seems to be very enthusiastic about it:

We are today probably one of the largest users of the social web inside the enterprise, and we have improved our ability to look at the structured and the unstructured opportunity. In the last three years we have really launched into the exploitation of the social web as a means for ideation, as a means of finding the expert, as a means of learning. We use the web to form groups to look at specific problems and tapping into a collective intelligence.

TCS seems to have a key innovation in the use of social networks here: They use unstructured information from the social network to supplement structured information and to drive discussion. I think that is a key requirement for the success of social networks in the R&D environment.

All those things supplement the way we look at our structured information, and they get some of these subjective insights into what we should be doing as a business.
For example, I have a blog inside the company, and I just finished writing a blog post which will go live tomorrow morning on the ideation process. There are a lot of things that I as the CTO of India’s largest software company should be looking at. Obviously, I don’t have the bandwidth to look at all of them. So I’m asking my readers to help me find out what am I missing. What are the three things they feel I should be paying attention to? Hopefully I will get a few hundred responses, and then I and my staff will go through and make sure that we pick the top three from there.
I do this quite often to supplement what I’m reading from all the other sources of information. The kind of insights that our business leaders might need for creating a new service offering or going after a new market or whatever, many of those get validated by this softer data.

So, I seem to be coming to the obvious conclusion that all tools can be helpful or harmful. It depends on how one uses them. Hence, if R&D managers want to use social networks, they have to get involved, show the team how to use the social network by example, structure the interactions on the social network AND give it adequate priority (probably by using it themselves).

How to Succeed in Distributed Product Development

MIT Sloan Management Review had a somewhat interesting article Putting It Together: How to Succeed in Distributed Product Development. The idea is pretty straight forward: as products get increasingly complex and competitive pressures require companies to work ever faster, more companies are forced to distribute product development across multiple organizations.

COMPANIES HAVE TRADITIONALLY been protective of the innovation activities they use in product and process development, seeing the activities as part of their crown jewels. That thinking, however, is starting to change. The increase in outsourcing, offshoring and alliance building has resulted in innovation efforts that often require the orchestration of multiple organizations separated by cultural, geographic and legal boundaries.

As the article points out, distributed nature of R&D varies:

At one extreme are centralized arrangements, with a clear lead organization and subsidiary “supplier” organizations. At the other are innovation efforts performed by decentralized “open-source” networks. In between is the realm of outsourcing and offshoring — the key building blocks in a trend called distributed product development or DPD, whose success factors are still not widely understood.

We have discussed the impact of distributed R&D on innovation. We have also seen that the impact of distributed teams on learning. We have also seen how virtual teams multiple times in the past. This article points out that distributed development adds significantly to the uncertainty in team performance:

Outsourcing complex product development work subjects companies to significant uncertainty. Companies can make perfectly reasonable decisions and still find themselves needing to make expensive changes, ranging into the millions or even billions of dollars. Our contention is that, by anticipating some of these changes, managers can reduce risk and, ultimately, cost.

So how does the article suggest we manage distributed product development:

The flippant answer — “very carefully” — is also the right one.
1. Communication must be perfectly clear, especially if the project involves people from different cultures.
2. Incentives must be carefully aligned.
3. Despite upfront planning, you still should be ready to adapt and realign as the inevitable snags occur.

We have covered incentives in the past. I guess the key to cross-cultural, cross-organizational and multi-location distributed R&D is communication. May I suggest you take a look at InspiRD?

Why Project Networks Beat Project Teams

MIT Sloan Management Review has a great article on a new concept for R&D execution organization in Why Project Networks Beat Project Teams. The focus is on R&D of complex systems and driving collaboration and knowledge sharing. As frequent readers may recall, this is an area of great interest for me. We have often discussed how increase in complexity of systems under development has been the driving challenge in R&D management. We have also talked about knowledge workers in virtual teams and what drives collaboration and knowledge sharing in large multi-disciplinary teams.

The overall message of the article is straight forward: R&D managers should encourage at least some of the team members to bring information/knowledge from experts in their personal networks into the R&D activity. Involvement of these non-core members (experts) was shown to increase R&D success. Detailed learnings from the article are below:

To research the factors that affect the success of teams working on knowledge-intensive projects, we studied an established companywide recognition program for project teams at a large multinational food company. As part of that study, we surveyed 1,304 members of project teams in the company to identify key characteristics that promote success in knowledge-intensive work. We then compared responses from the project teams regarding how they went about their work with the company’s assessment — through the judging of the team recognition program — on the significance of the projects’ outcome.”

The idea they have come up with is that of Project Networks:

Typically, project networks consist of a core set of team members who bring in noncore contributors (such as other company employees, suppliers, consultants or customers) from their personal networks who can provide knowledge, information and feedback regarding the team’s task. The project network thus takes advantage of both the project team as a whole and the personal networks of the members.

The researchers studied 177 teams with 1,304 members in ONE food company (I have never worked with food companies, but I am sure their development can be quite complex). They found that team success – as measured by the same recognition measures across all teams – improved with the involvement of non-core members. Here is why they think the addition of non-core members is beneficial:

Project networks take advantage of the benefits noted by team-focused researchers — such as the commitment and dedication of members — but can overcome the risks associated with a small group’s limited perspective by crossing team boundaries for project feedback.
Project networks can also take advantage of the benefits associated with members who cross organizational boundaries for new ideas and broadened access to knowledge, yet the team structure provides accountability that can be lacking in informal personal networks.
…
Managers are often not given the luxury of hand-picking exactly the members they would like on a project team; they may have to go with who is available at the time. Encouraging project networks allows managers to look beyond the core project team and to take advantage of what noncore contributors outside of the project team have to offer.
emphasis added

According to the authors, project networks are beneficial in all kinds of situations (innovation, customer service or operational improvement). They only had two innovation teams – one with non-core members and one without. The team with non-core members was able to come up with a fundamentally new product, while the one without just had incremental improvements. The team involved non-core members by:

The Innovation Project A team involved a number of functions — sales, marketing, R&D and process development — and was located across six U.S. states in nine different facilities. Through its project network, the Innovation Project A team acquired relevant food formulation knowledge that customers had about their specific applications for this type of ingredient. In addition, the core members of the project team augmented their own knowledge by accessing food production expertise both from other colleagues in the company and outside vendors. While not core members of the team, these contacts were all part of the project network.

So, how and when should one involve non-core members? The figure from the article (replicated below) provides details. My suggestion is to do it carefully. Only involve non-core members when the project is complex. Even then, clearly define boundaries and ground rules. There is clearly a possibility of proprietary information leakage if the process is not managed carefully.

Meetings are a waste of time

Here is some data that would make your day First a survey that suggests Businesses Waste 4.8 Hours Per Week Scheduling Meetings:

By the time the year ends, many have spent the cumulative equivalent of six weeks scheduling meetings, and that doesn’t include time spent attending them.

That sounds excessive and not realistic. But what do I know… On the same note, here are some suggestions from HBR to improve reduce waste with my 2 cents added:

Meetings always shorter than 90 minutes
Meeting materials delivered at least day before and everyone comes prepared
One page executive summary for the briefing package that everyone must read
Clearly defined roles and responsibilities for each participant in the meeting (no one attends the meeting unless they have a stake)
Predefined agenda for the meeting (no meeting requests without agenda)
Clear conclusion at the end of the meeting (As per HBR: Where are we going to go from here? What are the to-dos and who is going to do them? When will they be delivered?)

I remember reading and article about how P&G’s strategic reviews took place. The business unit sent out the briefing package at least a week before the review. All obvious questions were discussed over email. The meeting was for making decisions and having real debates. I really like that idea.

Learning in Cross-organizational New Product Development Teams

Another interesting article from the Journal of Product Innovation Management: Increasing Learning and Time Efficiency in Interorganizational New Product Development Teams. The thesis is clear – cross organizational product development is on the rise. However, it is unclear that processes exist to learn and improve performance from these projects:

Despite the growing popularity of new product development across organizational boundaries, the processes, mechanisms, or dynamics that leverage performance in interorganizational (I-O) product development teams are not well understood. Such teams are staffed with individuals drawn from the partnering firms and are relied on to develop successful new products while at the same time enhancing mutual learning and reducing development time. However, these collaborations can encounter difficulties when partners from different corporate cultures and thought worlds must coordinate and depend on one another and often lead to disappointing performance

Some interesting learnings about what drives success: Caring, Safety and Shared Problem Solving (team building?)

To facilitate collaboration, the creation of a safe, supportive, challenging, and engaging environment is particularly important for enabling productive collaborative I-O teamwork and is essential for learning and time efficient product development. This research develops and tests a model of proposed factors to increase both learning and time efficiency on I-O new product teams. It is argued that specific behaviors (caring), beliefs (psychological safety), task-related processes (shared problem solving), and governance mechanisms (clear management direction) create a positive climate that increases learning and time efficiency on I-O teams.

The results seem to have been validated empirically:

Results of an empirical study of 50 collaborative new product development projects indicate that (1) shared problem solving and caring behavior support both learning and time efficiency on I-O teams, (2) team psychological safety is positively related to learning, (3) management direction is positively associated with time efficiency, and (4) shared problem solving is more strongly related to both performance dimensions than are the other factors. The factors supporting time efficiency are slightly different from those that foster learning. The relative importance of these factors also differs considerably for both performance aspects.

Here is the take home message (lets add it to the other learnings from the past – including virtual team performance):

Overall, this study contributes to a better understanding of the factors that facilitate a favorable environment for productive collaboration on I-O teams, which go beyond contracts or top-management supervision. Establishing such an environment can help to balance management concerns and promote the success of I-O teams. The significance of the results is elevated by the fragility of collaborative ventures and their potential for failure, when firms with different organizational cultures, thought worlds, objectives, and intentions increasingly decide to work across organizational boundaries for the development of new products.