Initial steps for agencies to stand up an innovation center
Lou Kerestesy, founder and CEO of GovInnovators, offers several considerations for agencies as they begin the process of deciding business objectives and how be...
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.
Choosing a destination
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:
Requirements disaggregate in the downward direction where the relationship is one of “includes” or “bounds.” A department mission includes and constrains a component mission. A performance requirement includes and constrains 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 center:
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:
Create a culture of innovation which produces cutting-edge solutions for operators.
Create a culture of innovation that accelerates the transition of technologies from research and development (R&D) to operators.
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.
Type
Structure
Solution
Simple
Object
Innovation
Unqualified
Verb-Object
Innovate acquisition
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
What next?
The next blog in this series, The Terrain, looks at the organizational, customer and market environments in which you’ll stand up the center.
Lou Kerestesy is the founder and CEO of Gov Innovators. Read for all of Lou’s innovation blogs, including his complete paper on “Standing Up An Innovation Center.”
Initial steps for agencies to stand up an innovation center
Lou Kerestesy, founder and CEO of GovInnovators, offers several considerations for agencies as they begin the process of deciding business objectives and how be...
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.
Choosing a destination
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:
Learn how federal agencies are preparing to help agencies gear up for AI in our latest Executive Briefing, sponsored by ThunderCat Technology.
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.
What next?
The next blog in this series, The Terrain, looks at the organizational, customer and market environments in which you’ll stand up the center.
Read more: Commentary
Lou Kerestesy is the founder and CEO of Gov Innovators. Read for all of Lou’s innovation blogs, including his complete paper on “Standing Up An Innovation Center.”
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Related Stories
Creating a place to turn ideas into innovations
Innovation in government doesn’t have to be overwhelming