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.
The next blog in this series, Checking The Terrain, explains how to read your terrain to navigate it safely and create an innovation strategy.