Beyond Phase Gates – Agile R&D

Phased development with gate reviews has delivered many benefits to product development organizations. This process ensures business perspective is incorporated into product development. Gate reviews are generally led by senior managers. Their engagement drives organizational consensus and resource commitment. Gate reviews also guide the organization away from risky endeavors by focusing on predictability and return on investment.

However, stage gate process also introduces some challenges. This process is only applicable to large new product development efforts because of the additional overhead and required senior management time commitment. The gate review process is hard to implement on small sustaining engineering projects where the goal is fixing some issues or improving manufacturability. It is hard to apply this process to small technology development, advanced R&D or disruptive innovation projects. In many organization this means that small projects do not follow any consistent process. Hence managers loose visibility and control over the entire portfolio.

The stage gate process can be seen as waterfall model. This model assumes customer needs and functional requirements are completely known before development is started. For products with long development cycles or in rapidly changing markets, stage gates introduce many challenges:

  • Difficulty adapting to changing market needs
  • Limited business/marketing visibility into development
  • Late or uncoordinated requirements changes
  • Surprise issues and unexpected risks
  • Disconnected test plans and expensive testing

More importantly, this model reduces experimentation and prevents disruptive innovations from getting to market. As Clayton Christensen pointed out:

“The Stage-Gate system assumes that the proposed strategy is the right strategy; the problem is that except in the case of incremental innovations, the right strategy cannot be completely known in advance. The Stage-Gate system is not suited to the task of assessing innovations whose purpose is to build new growth businesses, but most companies continue to follow it simply because they see no alternative.”

So what is the solution? Implement Agile Development..,
Read More

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.

Read More

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.

Ideation Tools for Your Mobile

ZDNet has a list of ideation and idea management tools for different mobile tools. Some of them are even free.  I think it is great that we can capture ideas any where and queue them up for discussion.
The new clients all come as part of the innovation management platform provided by Spigit, Kindling, and just yesterday, Imaginatik, Each let’s you suggest and evaluate ideas, but in slightly different ways. 

Brightidea Mobile Back in February, BrightIdea announced it’s mobile client for the iPhone and iPad as well as Android devices. With BrightIdea Mobile, users can view, post, comment, vote, and share ideas. They can also  use Brightidea’s corporate micro-blogging feature  to post and follow activity within their innovation community.

I find interesting how Innovation has become a favorite buzz word.  The title of the article “4 Innovation Management Tools for Your Mobile.” I think there is a great deal of hard work between discussing ideas and developing innovative new products.  I guess in my book, innovation is 99% perspiration and 1% inspiration!

Pitfalls of Project Portfolio Management implementation

Computer World has an interesting IT Project Portfolio Management (PPM) article that is equally applicable to R&D management – just read R&D when they write IT :-).  They point out three dangerous myths of portfolio management:
  1. PPM is IT’s lookout
  2. Right tools drive PPM success
  3. The best starting place is PPM Best Practice
 In my experience, even the organizations that do PPM on R&D portfolios, often fall into some of these traps (I am not certain what fraction of companies have formalized PPM.  May be we will do a poll on this soon).  PPM is sometimes delegated to CTO or Engineering.  This has a negative impact on R&D team members because there is no clear customer for what they are developing.  
Another key problem is too much focus on tools and best practices.  I myself fell into this trap at one PPM implementation.  I was unaware of how little the organization new about their project portfolio (most were legacy R&D projects that had gone on for many years).  It was not wise to even attempt to implement PPM when there was no clear portfolio to begin with!

Great list of innovation management tools

Blogging Innovation blog has a great list of tools to manage innovation and ideas.  Tools to manage ideation are important and the author has put in quite a bit of work to generate a pretty comprehensive list.  Please also check out his word document on desired functionality.

In my experience, idea management tools are a subset of processes, tools and metrics needed to ensure that innovation pays off.  Managers need to find ways to quickly evaluate, develop and monitor innovative ideas.  There also needs to be an efficient approach to kill innovation projects that do not pan out.

One of the companies I worked at had a great innovation generation machine.  They gave out $20-50k for small projects that looked outlandish enough.  However, there existed no way to catch all this innovation and develop it further into delivered products.

What is your experience?  How is innovation management working in your organization.

Making Data Work For You

Here is an article from Forbes talking about how to make data work for you. The underlying presumption is that the data necessary to make management decisions is lying around in the company in different forms – the challenge is to mine it effectively and prepare the right kind of report.

The amount of data inside corporations is exploding. In fact, there has never been such a wealth of information available in the history of business, and there has never been the vast array of tools to dissect it.
CIOs are generating reports for business leaders that slice the data horizontally and vertically, project growth, calculate productivity and profitability, and compare all of this historically and competitively. They are even pulling out tidbits of data that may appear randomly and building models based upon recurrences that escaped notice by even the most astute teams of experts. But is all this stuff right?

The key challenge according to the article is to find the right kinds of skills that marry IT and business understanding to generate these reports. And that unfortunately, those skills are hard to come by.

You’re talking about creating a data model, but aren’t models inherently flawed? Look at what happened to Wall Street in 2007.
The problem with models is not so much that they’re difficult to create. It’s whether everyone involved agrees with the same semantics. If you want a revenue report or a profitability report, you need to figure out what should be included. Once you have clarity on that, the other steps are much easier.
Do these skills exist?
They’re not very common. We need a completely new skill set for the CIO and the IT department. They have to speak the language of requirements for the application as well as the business language of reports.

In my experience, getting hold of the right data to make effective R&D management decisions is a big challenge. The problem is not only that the data is fragmented across multiple tools and databases, but also the fact that the tools all use different jargon and structure. It is difficult, if not impossible to aggregate data across these fragments to generate meaningful reports.

For example, if one wants to generate project portfolio status reports automatically, one has to mine across project management, requirements management and financial management systems. Each one of these systems maintain their data at different, disconnected levels of abstraction. Even if it was possible to mine data from each one of them, effort needed to link them across each other would be cost prohibitive.

What do you think? Have you used automated data mining / report generation tools successfully? Are there any lessons learned that you can share?