How innovation and change connect

Innovation and organizational change overlap, but they direct attention to different questions. Innovation work asks what new or improved product, service or process is worth developing and putting into use. Change work asks what that proposed difference means for the people, routines and responsibilities involved, and how the transition will be supported.

The distinction is useful when it helps people coordinate. It becomes unhelpful when it creates a handover in which one group produces an idea and another is left to make it workable. Operational constraints can change the idea itself; early experimentation can change what people are being asked to adopt.

You do not need two large programs for every small improvement. You do need to notice both the uncertainty in the proposal and the work required to use it.

Innovation includes implementation

A common shorthand treats innovation as coming up with ideas and change management as everything that happens afterwards. That misses an important part of innovation.

For business measurement, the OECD/Eurostat Oslo Manual requires a product or process to differ significantly from the firm’s previous ones and to have been introduced to the market or put into use. An interesting proposal is not enough. The manual also distinguishes innovation activities, which may be ongoing or abandoned, from an implemented innovation.

That definition has a particular statistical purpose. It does not settle every use of the word in design, public services or everyday conversation. It does, however, prevent a project from treating the existence of a prototype as the whole achievement.

If the distinction between creating something and introducing it is still unclear, begin with innovation versus invention.

Not every change needs to be called innovation

A change can matter greatly without being novel. Replacing equipment with an identical model, moving a familiar process to another team, or restoring a previously agreed routine can require careful coordination. Calling it innovation may add little to the task.

The Oslo Manual excludes routine changes and simple replacement from its business-innovation definition. Conversely, something already used elsewhere can still represent a significant change for the firm adopting it. Novelty is not always a claim to be first in the world.

For practical planning, ask what is uncertain and what will be different locally. A familiar tool may present little technical uncertainty but substantial work around access, responsibilities and training. An unfamiliar service concept may need further investigation before anyone can sensibly plan a broad rollout.

The amount of support should follow those conditions, not the prestige of the label.

Two conversations to keep connected

Imagine discussing the same proposal with two different lenses.

Through the innovation lens, you might ask which problem deserves attention, what alternatives exist, and what evidence would justify further investment. Through the change lens, you might ask whose work is affected, which routines need to change, and what conditions will make those routines possible.

These are organizing questions, not rival definitions or strict job descriptions. A designer can investigate a handover; a service manager can challenge an untested assumption about user needs.

A CLOSER LOOK

One proposal. Two connected sets of questions.

1. 01
   Explore the proposalWhich problem matters? What alternatives exist? What would justify the next investment?
2. 02
   Make the work possibleWhose routine changes? Who handles exceptions? What support and ownership are needed?

An answer in either conversation can change the other.

The Design Council’s Double Diamond already includes understanding a problem, developing alternatives and testing solutions on a small scale. Its explanation also makes room for revisiting earlier questions. Reading it as “creative work before delivery starts” loses that connection.

Equally, change management should not begin with a communications campaign for a solution nobody has examined. An early conversation with affected people may reveal that the proposed solution addresses the wrong difficulty, or transfers the burden to a group missing from the project room.

Hypothetical example: from a repair portal to a workable service

Consider an invented repair service where employees report broken equipment through a mixture of email, telephone calls and informal messages. A project team proposes a new portal to reduce the confusion.

There are at least three different problems it might be trying to solve: requests arrive without enough information, nobody knows which team owns them, or employees cannot see whether anything is happening. A single interface could help with some of those problems while leaving others untouched.

The innovation work starts by finding out which difficulties matter and considering alternatives. A better request template, a clearer ownership rule or a shared queue might be more useful than a completely new portal. Assumption mapping can help identify which belief deserves a test before the team invests further.

The change work starts at the same time. Who will monitor incoming requests? Who can change an assignment? How are urgent cases handled? What should an employee do when the normal channel is unavailable? These are not details to defer until the interface is finished; they shape what the service has to support.

Suppose a prototype makes ownership visible, but a rehearsal shows that two teams use different definitions of an urgent repair. The response is not automatically more training or another notification. The teams may first need to agree a decision rule and who has authority to apply it.

That agreement may then change the design. The interface might need to explain an exception, request different information or show a different status. Learning has moved in both directions.

The scenario is hypothetical. It illustrates decisions to investigate, not a successful project or an observed reduction in repair time.

Make the next commitment explicit

A useful way to connect the work is to organize it around the next decision rather than around a complete sequence of departmental handovers.

For a small experiment, the decision could be: can the team responsibly rehearse this process with a limited set of cases? For a wider introduction, it could be: have the important questions about benefit, operation and support been answered sufficiently for this scope?

Keep a short shared brief with four parts:

• The proposed difference. State what changes for a particular user or role, and what problem it addresses.
• The evidence and uncertainty. Record what has been learned and which important question remains open.
• The operating arrangement. Name who will perform, support and maintain the work, including exceptions.
• The decision boundary. Specify the commitment being considered, the conditions attached to it, and who can revise or stop it.

This is an original coordination aid, not a replacement for the approvals a particular organization requires. Its purpose is to stop assumptions disappearing between a learning discussion and an implementation decision.

For the repair service, a brief might permit a limited daytime trial while leaving out urgent requests until the exception rule is settled. That is different from declaring the entire service ready. The readiness playbook explores how to make that boundary concrete.

Separate delivery, use and benefit

A system can be delivered without becoming part of ordinary work. A new routine can be used without producing the intended benefit. If all three are compressed into a single success label, it becomes harder to understand what needs attention.

Proctor and colleagues’ implementation-outcomes paper distinguishes implementation outcomes from service and clinical outcomes. The paper proposes concepts including adoption, feasibility and sustainability. It comes from health-related implementation research; applying the distinction to another workplace requires choosing appropriate definitions and measures.

A CLOSER LOOK

Delivered does not automatically mean useful.

1. 01
   DeliveredThe queue and agreed access arrangements are available.
2. 02
   UsedEligible requests are handled through the intended working process.
3. 03
   HelpfulThe experience and outcomes improve without concealing extra burden elsewhere.

For the repair-service example, delivery might mean the queue and access arrangements are available. Use might mean that eligible requests are handled through the agreed process. Benefit might concern whether employees can obtain a repair without repeated chasing, and whether the organization can manage the work fairly.

Those questions need different observations. Counting accounts created would not establish that technicians can manage exceptions. Counting requests would not tell you whether the right requests are included. A faster response might also conceal extra work being pushed onto the person reporting the problem.

The GOV.UK guide to measuring service success recommends drawing on performance information and other evidence, rather than digital analytics alone. In this example, a useful review could combine a defined set of process records with conversations about the experience of reporting and handling a repair.

Compare like with like where possible. State the scope, time period, eligible cases and missing data. If workload or staffing changed during a pilot, an improvement afterwards cannot automatically be attributed to the new service.

Where the connection breaks down

One warning sign is a pilot supported by exceptional effort that disappears at rollout. The prototype may have an enthusiastic project team resolving every problem, while the eventual service has no funded owner. Before extending it, ask which parts of the pilot depended on that temporary support.

Another is treating every objection as resistance. An objection can be wrong, but it can also expose an unexamined cost or a missing dependency. Investigate the substance before choosing a response.

A third is keeping an experiment alive because so much has already been built. Preserve the option to revise or stop. The point of learning is to affect a decision, not to supply a story for continuing unchanged.

There is also a limit in the other direction: a very small, reversible change does not automatically need a large readiness program. Use a proportionate conversation with the affected people, a clear owner and a review point. Add more structure when the consequences, dependencies or uncertainty justify it.

A practical place to begin

Bring the people exploring the idea together with the people expected to operate it. Ask each group to name one uncertainty the other needs to understand. Then agree the next decision they can inform together.

If the main gap is understanding the opportunity, continue with innovation management. If the idea is reasonably clear but the conditions for using it are not, work through change readiness. Neither conversation has to wait until the other is declared finished.