FOLLOW

FOLLOW

SHARE

Creating An Innovation Strategy 2

Getting oriented is vital before you start in earnest

4Jan

This is the second blog in a five-part series about innovation strategy. The  previous blog defined innovation strategy. This blog looks at how to establish strategy objectives and align activities to which your organization can orient.

Creating an innovation strategy is like orienteering – navigating to a destination across unmarked terrain using just a map and compass. Here’s how:

Navigation Component Navigation Activity
Your destination is an effective innovation strategy, documented and ready for use Determine the destination and define effective using a requirements hierarchy; document using the hierarchy and additional formats, as needed
Your terrain is the environment in which the strategy is developed and deployed Observe and clarify using graphics and descriptions of your organizational environment, the customer’s, stakeholders’ and relevant business and technology markets
Your trek is the set of activities you to create and implement the strategy Identify and manage with strategic planning practices modified for innovation requirements, and continuous monitoring and modification
Your map depicts phases and disciplines required to create and implement the strategy Fill in using the requirements hierarchy, strategic planning inputs, and innovation requirements
Your compass is a set of tools which you use to take readings, adjust direction, and proceed Use by facilitating conversations to decisions, then implementing decisions

Choosing A Destination

Creating an effective innovation strategy begs the question of what effective means. Simply put, it’s the right strategy for the right need at a particular time. That begs questions about what’s right and how one would know, and that’s where the requirements hierarchy helps.

Requirements hierarchies are often used to trace requirements in software development. You can find and use any framework, but I recommend the one below because it smoothly links business and technical requirements. Influence flows in two directions:

Requirements disaggregate in the downward direction where the relationship is one of 'includes' or 'bounds.' A department mission includes or bounds a component mission. A performance requirement includes or bounds functional requirements.

Requirements consolidate in the upward direction where the relationship is one of 'is necessary for' or 'supports the accomplishment of…' Meeting functional requirements is necessary to meeting performance requirements (but perhaps not sufficient). Meeting the component mission supports the accomplishment of the department mission.

Here’s an example for standing up a fictitious U.S. Coast Guard innovation strategy:

Level What To Fill In Requirements
Department Mission DHS mission statement Lead a unified national effort to ensure a homeland that is safe, secure, and resilient against terrorism and other hazards
Component Mission (add rows as required) Coast Guard mission statement Protect the public, the environment, and U.S. economic interests in the nation’s ports, waterways, coasts, international waters, or any maritime region as required to support national security
Mission Need/ Capability Gap Make a statement about a capability missing or lacking but which is required to satisfy the component mission. Can read like a strategic goal or objective, or problem statement. Create a strategy to enhance operator capabilities in order to improve performance
Capability Requirement Make a statement of capability required to satisfy the mission need or close the capability gap. Should read like a solution statement. Create a knowledge network of staff, customers, stakeholders, suppliers and others who know operations well enough to inform the strategy
Performance Requirement Make a statement of outputs or outcomes which satisfy the capability requirement. May be multiple statements, but must be complementary. Collect initial input on capabilities and performance by [date]; develop the strategy by [date]; effect continuous monitoring by [date]
Functional Requirements Make specific statements of what a solution should do to satisfy the performance requirement. Requires multiple statements. Collect information about…; analyze information about…; articulate a vision; establish communication channels and mechanisms to support collaboration; foster innovation or inventive thinking; continuously monitor impacts; create effective means for revision and re-commitment; etc.
Design Requirements Make specific statements of how the solution should be designed to meet functional requirements. Requires multiple statements. Create processes to solicit capability and performance information; create processes to analyze, synthesize, and prioritize capability and performance improvements; create strategy document as WIKI; etc.
Material Requirements Make specific statements of people, processes, tools, materials, etc. required to satisfy design requirements. Requires multiple statements. Provide physical space to work at…; provide virtual space to work at…; determine protocols for; acquire equipment for…; store data in…; etc.

Requirements hierarchies aren’t easy to fill out but they’re worth investing the time and effort, early. No matter how challenging it might be to get agreement on words, it’s more challenging to get agreement on actions later – and more costly.

What Next?

The next blog in this series, Checking The Terrain, explains how to read your terrain to navigate it safely and create an innovation strategy.

Comments

comments powered byDisqus
Butterflies small

Read next:

Insuring the success of your transformation, launch or innovation initiative earning buy-in. 4 steps, 5 minutes.

i