Justifying Research Teams (or not)

Have you ever been on a project that was significantly delayed because the new technology or gameplay took longer than expected?  Many of us have, and it should come as no surprise that new tech, mechanics or complex, exploratory asset creation schedules are hard to predict.  Yet they are part of projects with tight delivery dates.

These elements are often seen as the "critical path" of a project, which means that if they are delayed, the whole project is delayed.  Competent management of projects includes identifying such critical paths and prioritizing the work on them.

However, if there are many possible solutions and therefore a lot of uncertainty along a critical path, or if a number of projects share the same solution, the risk is often very high.

A common way to address this is to have a separate research team explore a solution well ahead of the start of a project or at least the point where the path becomes critical.  There are some advantages of this.  The first is that these research teams can have the time or resources to fully explore solutions and pick one that is best for the product and is not rushed into production due to schedule pressures.

My favorite example of this is the Toyota Prius' development.  Toyota's goal was to create a car that would appeal to the "green" consumers.  However, the choice of engine technology was not certain. 

Either a hyper-efficient gas engine, an electric engine or a hybrid were all candidates.  Delivering the car to market in half the time that a typical car was developed was the challenging goal.  It was their critical path.

Toyota could have chosen an engine technology up front and focused their efforts on making it work.  Most companies, faced with this tight schedule, would have done so.  Instead what Toyota did was inaugurate three research teams to study each engine technology.

Months later, the all-gas engine team found that although they could improve the efficiency of the engine, they couldn't deliver enough efficiency to attract the green market.  The electric engine team found that  they could achieve the efficiency, but they couldn't deliver a car with a low enough price to entice buyers.  Although people want to be green, there is a limit to how much they will spend.

The hybrid engine team were able to build an engine within the mileage and cost targets, and it was chosen and refined for production. When hearing this story, many managers are unmoved. "We can't afford to have multiple teams researching multiple solutions!" they say.  In response, we might ask "how much does it cost to delay the entire project by months because the critical path was stretched out?"  You can easily spend 10 times the cost on a delay for a 80+ person team than you would have been researching up front with a much smaller one.

The concern about cost is not the only barrier to such teams.  There are at least three others:

Each problem has a solution that is unique to a company, but often the best solution to the last problem is to have the researchers join the project until the new solution is in place and the project team can take it over. Research teams are not always the answer.  There are pros and cons to having them.   If uncertainty is low, it's often better to have research be part of the project.   You have to judge how much uncertainty you have on your critical path and therefore how much you are willing to gamble on a delivery date.