Why is innovation different

Before considering the metrics, we should think about why it makes sense to have innovation separated from implementation and operational groups.

​

This can be an innovation process that the existing teams use, or groups established specifically to explore innovation: an R&D centre to develop products, a market development team looking at new opportunities, or an M&A team or incubator looking to grow business capabilities.

​

But why? What is it that you hope to gain from this separation

​

Most business tasks are made more effective through strict process control to give stability to performance and forecasts. You know what each product costs, what the margin and volumes are in your markets, and when new products will be introduced. You are aware of the risks and are managing them.

In other words, you are eliminating uncertainty.

​

Innovation, however, emerges from exploring uncertainty so a different approach is needed. Innovation processes do still require controls to ensure that projects do not lose focus or become irrelevant, but the aim of these controls is to explore and manage uncertainty instead of eliminating it.

​

Innovation projects require the freedom to discover and experiment with new products, processes, or markets. This also means that the projects are more likely to fail. Unlike operational or implementation functions, project failure in innovation is a healthy indicator and signifies that the teams are trying new approaches.

​

So, it makes sense to have a different approach for innovation than is used for implementation and operational teams. The elimination of uncertainty that comes with strict process control will suppress innovation, and the freedom that innovation needs will undermine the stability of day-to-day business processes.

​

If a different approach is needed, it follows that there should be a different method of measuring performance.

​

Innovation metrics to drive performance

We know that metrics drive performance, so what is the performance you are looking to reinforce?

We have described the two approaches, innovation and implementation, and the advantages of each. The next step is to understand how the two can exist in the same business and how they should interact.

The ideal situation is that an idea is initially developed into a project within the innovation processes, where the flexible approach will support and nurture its growth. This project should then be handed over to the implementation processes for efficient and effective implementation.

​

The key to having the two approaches co-exist in the same business is to understand when the hand-off should be between the two. This can be an innovative product being passed to an implementation team to productionise, a market development being handed to a business unit to fold into their day-to-day business, or an M&A or incubator development becoming an integrated business unit.

​

There is no universal answer to finding this handover point, it depends on the experience and structure of the business. For example, if your company already has a well-established new product introduction process, the innovation teams can hand over relatively early. If your business is mainly operational, the projects may need to be developed to productionisation before handover. The main consideration to finding this handoff is to look at how the relative processes manage uncertainty in comparison to the maturity of the project.

​

Understanding when this handover should occur gives clarity of what the performance indicators for the innovation project should be. The receiving team will be ultimately responsible for delivering business performance and will be measured on traditional metrics such as revenue. Their key performance criteria for receiving an innovation project are to understand the project’s potential for delivering this goal.

The innovation project should therefore be measured on this potential performance: for example, quantifying projected revenue instead of measuring project revenue directly. There will clearly be a degree of uncertainty with any projection, which should be captured in a further metric.

​

Measuring innovation revenue – a word of warning

The reason for avoiding business metrics such as actual revenue is that they apply pressure on the transition between the innovation team and the implementation team.

​

An innovation team will only be able to realise revenue if they hold onto a project through to implementation. This fails to take advantage of the efficiency of the implementation teams, and also dilutes the resource of the innovation team.

​

It can also be a cause for unhealthy competition between units. An innovation project will often be a competitor for those being delivered by other business units. A lack of co-ordinated transition is costly and can be damaging.

​

In the case that we were consulting on, this resulted in the innovation team restricting engagement with the rest of the business, actively keeping their best projects concealed from their peers. This is clearly damaging to inter-team relationships, but crucially, it meant that a major project was not able to make use of the knowledge and experience of the teams that were already working in the target application. And had lost relevance by the time it was implemented.

​

How to make innovation metrics constructive

The innovation team must see the implementation team as their customer. It is clearly in the interests of the implementation team to receive a project that will add value and can be delivered with minimal uncertainty, so they should be supportive of establishing a good handover.

​

The handover point and conditions must be established at the start of the innovation project to ensure that the project has a clear set of guidelines to prevent it from drifting away from business objectives.

The calculation method for projecting business targets back to the handover point must be agreed between groups; you may have anything from a fully detailed statistical model to a group consensus discussion. Whichever method you use, the calculation itself and the assumptions that support it must be clear and documented.

​

As important as setting the goal, is to understand the level of uncertainty around the goal, so this calculation must be approached in the same manner.

​

The assumptions for projected targets and uncertainty may change as the innovation project evolves, or as the target application changes over time. The process for re-evaluation and agreeing new targets must also be defined: who should be involved, how do you change the assumptions or the calculation, and how does this change project health.

​

Once the projected goals have been defined, the method for the team to demonstrate that they have met these goals should be agreed. For example, a product innovation may have a performance goal that can be established with a specific prototype test, a market development may have a defined process for demonstrating price, volumes, and sensitivity.

​

Having clear goals is important for keeping the project on track but will be much more effective if the expected change over time can be captured as the project evolves. You might be able to show a glide path for performance, or the agreed uncertainty may converge to an amount that an implementation team can manage in their processes. For example:

• The path to a product meeting its test requirements may be established through a design review, then a simulation before the handover test.

• A market development may be demonstrated through a series of focus groups, defined analysis steps, and competitor research.

• An M&A project may have a clear demonstration of alignment between progressively deeper aspects of the current business activities.

​

This process of projecting targets back to a series of metrics that apply across the maturity of a project provides an effective guide for progress. As the team discusses the targets, the assumptions behind them, and the areas for uncertainty, they will be able to draw inspiration for their idea generation sessions.

​

The added benefit from this approach is that it aligns the incentives between the innovation teams and the implementation teams. This will form the basis of collaborative work where the experience and knowledge of the implementation teams can be brought to the innovation environment in a constructive way.

​

One of the biggest challenges to setting metrics is that there is no one common approach that can be applied to all projects, or that can be carried over from the existing business. This means that performance goal setting for innovation projects requires effort and flexibility from the management team.

​

To summarise the performance metrics

• Handover point between innovation and implementation teams to be defined

• Calculation method for projecting end project performance to handover point agreed

• Targets agreed between innovation and implementation teams

• Uncertainty – causes and impact – to be agreed and quantified

• Test Method for demonstrating targets have been achieved defined and scheduled

• Review cadence to be scheduled

• Change control for metrics to be defined

 

Measuring innovation failure

A healthy innovation environment is one where new approaches are explored and existing limits are stretched. This limits have been in place for a reason, and while you may be able to break new ground with a new way of thinking or a new technology, there will also be times when you will not be able to break through and the project fails.

​

Failure is a natural part of innovation, to the extent that if an innovation group does not suffer any failures you should review whether they are actually pushing the limits of what’s possible. The point here is that failure is an important part of development, each failure that results in learning brings you closer to the solution.

​

So how do you measure whether the difference between a valid failure and a poorly executed project?

Poor execution may be to blame, but how should you react if a product or application failed because a stretch technology didn’t work as expected. Market conditions may have changed in an unexpected way, or a newly developed business unit did not deliver the results or provide the synergies expected.

The key indication is whether the team can explain why the project failed not just the final result: what should have been changed in the journey toward the result. Were the underlying assumptions wrong, and why. Was there a flawed execution, and why.

​

A factor that is often overlooked is the review of when a project failed. The next best situation to a project success is for it to fail as quickly as possible. The team should be able to describe when the project failed and if this could have been brought about sooner: was enough stress applied to assumptions or were the right triggers in place to end the project.

​

The explanation of when and why a project failed is only half of the exercise. The team should be able to demonstrate controls that have been put in place to ensure that there are no repeats of these failures.

Project success metrics therefore fall into three categories:

• Projects that were successfully handed over

• Projects that were not successfully handed over, but we understand why and have captured the learning

• Projects that were unsuccessful

​

You have a choice at this point: you may measure number of projects, number of hours expended on projects, or budget allocated across the three categories. This will depend on what the performance is that you are looking to improve and who the innovation process stakeholders are. If you are presenting to investors, they may be looking for budget allocation that can be paired with he hand-over metrics discussed above to provide an indication of Return On Investment. You may be present the number of hours allocated to innovation and success rates as a message to employees that the company is serious about innovation