Building Trust in Innovation Practices
• What is the problem being solved or opportunity pursued? 1
• What metrics will be tracked and how do they rank in importance?
• What is the timeframe for the pilot and what are the major milestones?
• What is the desired business outcome and how does this compare against alternatives, including doing nothing?
• Who are the key affected stakeholders, what are their care-abouts, and how can their buy-in be secured?
• How does the pilot scale into production, including interoperability between pilot environment and deployed environments?
During the pilot effort:
• Does the data support the identified target use cases, are there potential different use cases to consider? 2
• Are any challenges to making progress the result of potential assumptions?
• If the effort is ongoing without progress, is the pilot stuck in a sunk cost fallacy? Is the effort continuing solely because of a perception that so much time, money, or effort has already been spent, that the effort must continue? Or is there something blocking progress that remains unidentified?
After the pilot completes:
• Did the pilot solve the target problem completely or in-part?
• Were there areas where too much time and energy were spent?
• Were there assumptions, opportunities, or risks that proved inaccurate?
• What might have been done differently and why?
As agile development methods have shown, there is merit in taking scheduled pauses to ask questions and assess the answers. Refining key use cases, success metrics, and mile markers are the base requirements to not get stuck in pilot purgatory. Knowing the path forward and being able to measure progress is important, as is determining when the final goal has been reached.
In pilot projects, these pauses can also be used to question perceived risks and opportunities, whether they continue to hold true as the project progresses. These pauses and the answers to the questions asked may also determine if a pilot needs to be paused or stopped.
1
Separate the target from the technology to ensure it isn’ t a solution in need of a problem.
2
Capture new use cases but avoid scope creep. Journal of Innovation 113