Shift happens: how to manage changing projects

One of the most important decisions in research and development is defining the scope of the project. Some problems involve making a simple refinement. Others require inventing a whole new technology. Managers thus assign projects to different “buckets” – allowing them to tailor their project management approaches.

Despite all their efforts, however, the chances are good that the R&D project’s senior supervisors will assign the project to what may later turn out to be the wrong project bucket. Often, what might look like an incremental product that involves a “near search” for straightforward solutions and looks towards resources readily available within your company starts to look instead like a “distant search” project that requires going farther afield for answers.

What now? Should you stick to your original strategy, or should you change?

To find out the best way to manage these kinds of mid-course corrections – for a recently published study on managing R&D project shifts in high-tech companies – we interviewed 142 managers of 12 corporate R&D teams at two leading global technology companies who had faced the challenge of just such a shift. By questioning these managers closely about their experience, they found three managerial practices that seemed to make it much easier for the R&D team and the overarching R&D organisation to make that decision and act on it.

Near versus far

Deciding whether a project requires a near search or a distant search is a key choice because these two kinds of projects are often structured and run in very different ways. A simple refinement requires focused research that generally draws on resources and solutions that are near at hand. (Think of a facelift project for a mature car series.) A more complex project often involves searching for answers from farther away, and the chances of success are usually much lower. (Think of developing a driverless car.)

The need to reclassify a project from a near-search to a distant-search effort arises for a number of reasons. Sometimes, the researcher or developer uncovers something unexpected. Chemists, for example, have often accidentally discovered significant compounds while trying to solve a completely different problem: Viagra started as a heart-disease drug but evolved into a potency-increasing global blockbuster.

At other times, the competitive landscape may change: a team may have started working, only to learn that a competitor has come up with something truly innovative, or found a way to develop a product that can match your product’s features at half the price.

When such a new opportunity occurs, the team needs to move quickly from being near-search to distant-search focused. Less frequently, the opposite can also happen – a light bulb goes on unexpectedly and a solution starts to seem much nearer at hand than forecast.

“…a team may have started working, only to learn that a competitor has come up with something truly innovative, or found a way to develop a product that can match your product’s features at half the price.”

In either case, teams are at risk of missing the short time-window they have to switch because their managers are unable to realign their resources quickly enough to take advantage of the opportunity.

Such an adjustment can be a brutal challenge for a manager. It’s as if you were carrying the right maps and equipment for one kind of treasure hunt but then realised you were actually facing a completely different challenge: Sorry, it’s not buried on top of Kilimanjaro after all; it’s scattered all over the Dolomites.

Through our interviews with the managers of these teams as well as their companies' division managers and CEOs, we found that teams belonging to the company we called MicroSystem, which allowed for course corrections, succeeded more often than the teams that belonged to the company we called CommCorp, which did not.

Three easy steps

Several structural factors enabled the teams at MicroSystem to make a successful transition from a near to a distant focus, unlike CommCorp. MicroSystem’s solution was not simply to let the project’s chief scientist “wing it”. What worked for them is a method we call “responsive search”, which makes it easier to shift between the two modes. Three mechanisms facilitated their mid-course corrections:

     

  • A universal risk metric. Instead of evaluating the risks of local and distant search projects on a separate scale, MicroSystem reviewed all projects on one risk scale. Being able to compare the risks directly made it much easier for senior R&D managers to assess the nature of the risks ahead and weigh the risks versus rewards of their entire portfolio of opportunities.
  •  

     

  • A regular meeting that reaches across multiple levels of the hierarchy. Some kind of regular exchange, either weekly or monthly, kept managers in the loop about the progress of a given line of research and development.
  •  

     

  • Continuous, not annual, planning. Annual plans don’t make much sense in a fast-moving industry. Weekly or monthly updates on the progress of the work and on external events (in the market or in other labs) helped managers ensure their team received the kind of resources it needed.  
  •  

Although each of these mechanisms may seem obvious in isolation, it is combining them that enables the team to make a shift between near and distant searching without much disruption.

“…teams are at risk of missing the short time-window they have to switch because their managers are unable to realign their resources quickly enough to take advantage of the opportunity.”

The good news is that these measures aren’t all that difficult. As the president of MicroSystem told us: ‘The biggest challenge is laying the foundation for all these processes. Once established, it was like clockwork and everybody in the organisation knew what to look out for.’ 

Interestingly, my co-authors at first faced a somewhat analogous problem at an early stage of this research project. Readers of a precursor draft told them that the case-based results were too anecdotal to draw any reliable conclusions. How, readers asked, do we know that this experience can be generalised? They needed to look beyond the traditional case method (a near search) to find a quantitative way to test whether these measures would always be useful. That’s when they reached out to me (a truly distant search, as they all work in the USA), and asked me to help check the validity of their findings quantitatively.

Using Kaufmann’s NK model (1993), we modelled the projects’ search in a way that allowed us to portray the challenges as a hilly landscape. The NK model uses two parameters: first, the number of specifications (N) that define the project’s current technological scope. For instance, one of CommNet’s projects, a computer tablet, is configured with specifications for the processor, screen size, and other features. The second parameter  (K) is the number of (other) decisions that affect each of the N decisions.

We designed a program that emulated this strategic challenge, simulating what would happen over the course of 10,000 projects. The program modelled four different strategies to represent a project’s R&D search:

1) Local search: the team only searches locally to improve existing technology.

2) Distant search: the team makes “long jumps” every period, looking for new technological possibilities.

3) Responsive search: the team reacts in response to landscape shifts, depending on whether the environment seems to favour a local or a distant search.

4) Ambidextrous search: teams pursue both possibilities at once, ignoring shifts in landscape. Scholars write about this possibility often but we did not observe it in any of our actual cases. 

What we found supported the case observations: on average, teams faced with this kind of challenge are better off if they stay responsive, particularly in an environment of high technological turbulence and high time-to-market pressures, but that such responsiveness mattered less if technical and market turbulence were low (or when time-to-market pressure is not as high).

Lessons for individuals

Beyond offering insights for managers, these results may give individual professionals some food for thought as well. This project, for example, ran into a wall until my co-authors decided to shift their strategy and reinforce their case study work with analytical simulations. People facing similar challenges should keep in mind two lessons that we learned in the course of this research:

     

  • Don’t assume that you know the true complexity of your problem. It’s easy to misjudge the scale of a challenge.
  •  

     

  • If it’s not working, rethink your strategy. Patience is a virtue, but not if you’re trying to pound a square peg into a round hole.
  •  

Traditional thinking about innovation has it that “if at first you don’t succeed, try, try again.” Our research suggests that on the contrary, under certain circumstances, a better motto might be, if at first you don’t succeed – switch!

This article draws its inspiration from the paper Managing R&D Project Shifts in High-Tech Organizations: A Multi-Method Study written by Aravind Chandrasekaran, Kevin Linderman, Fabian Sting and Mary J. Benner. It is forthcoming in the journal, Production and Operations Management

Fabian Sting is Associate Professor of Operations Management, Department of Technology and Operations Management, Rotterdam School of Management, Erasmus University. (Email)

Share this article: