This is the second blog in a five-part series about innovation centers. The first blog described the functions of a center. This article looks at how to establish business objectives and how best to orient the center to them.
Standing up an innovation center is like orienteering–navigating to a destination across unmarked terrain using just a map and compass. Your destination is a productive innovation center, stood up and ready to operate. The terrain you navigate is the environment in which the center is stood up and will operate. Your trek is the set of activities you manage and perform to stand up the center. Your map contains phases and disciplines required to stand the center up. And your compass is a set of tools which you use to take readings, adjust direction, and proceed.
Standing up a center ready to productively operate begs the question of what productive means. Simply put, it’s the right center for the right need at this time. That begs questions about what’s right and how one would know, and that’s where the requirements hierarchy helps. I like the one below because it smoothly links business requirements to design and technical requirements. Influence flows in two directions:
Here’s an example for standing up a fictitious U.S. Coast Guard innovation center:
Insight by Recorded Future: Federal technology experts examine data strategies for cybersecurity in this exclusive executive briefing.
|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 culture of innovation which produces cutting-edge solutions for operators|
|Capability Requirement||Make a statement of capability required to satisfy the mission need or close the capability gap. Will read like a solution statement.||Stand up a center where staff, customers, and stakeholders continuously collaborate to develop cutting-edge solutions for operators|
|Functional Requirements||Make specific statements of what a solution should do to satisfy the performance requirement. Requires multiple statements.||Foster collaboration; foster innovation or inventive thinking; manage a pipeline; develop, design, and test solutions for deployment; etc.|
|Design Requirements||Make specific statements of how the solution should be designed to meet functional requirements. Requires multiple statements.||Create processes to solicit user needs, generate candidate solutions, manage the pipeline, determine ROI; define resources and core competencies required to operate; 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 testing equipment to…; 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 later to get agreement on actions — and more costly.
How the mission need/capability gap and capability requirement are worded is critical. There are many ways to describe a need and a capability to meet it, and small wording changes can have big design and operation impacts.
Compare the mission need/capability gap above with a slightly altered alternative:
Statement 1s broader framing opens up more possibilities. Statement 2 narrows the focus to R&D. Neither is or more “right” unless one is better at helping the organization solve the right problem the right way, at a certain time. Because each lower level disaggregates the requirement above into specific conversations, decisions, and actions, small degrees of difference at one level multiply at lower levels.
One challenge is that people frequently mingle problems and solutions. People say, “We need to …” and what follows is really a solution in search of a problem — be more innovative, improve accountability, write better requirements, etc. The words “need to” indicate a fix to some problem (or problems) which might not be clear in the conversation.
To help everyone get on the same page ask why, what if, and how questions about the statement. Why do we need to innovate? What would that accomplish? What if it doesn’t happen? What if it happens in different ways? How might we innovate?
As you lead discussions, think about the solution statements you hear and help the group shape the right one for its purposes using the types, below. The right pair of problem and solution statements will fit in the requirements hierarchy, above.
|Standard||Verb-Object-Qualifier||Innovate IT acquisition|
|Conjunctive||Verb-Object-(Qualifier) and Verb-Object-(Qualifier)||Innovate It acquisition and better align acquisitions to business objectives|
|Hierarchical||Verb-Object-(Qualifier) to/by/so that Verb-Object-(Qualifier)||Innovate IT acquisition and better align acquisitions to business objectives to meet FITARA requirements|
The next blog in this series, The Terrain, looks at the organizational, customer and market environments in which you’ll stand up the center.