I had just completed a year-long project with nine employees to learn about the lifecycle of an innovation project, the tools involved in each phase, and most importantly: how and when to involve diverse perspectives at every phase. We applied the theory and tools to a real-world problem for our city and were excited and energized by the result! As this was the first cohort of students, I was overjoyed when one of them contacted me to receive coaching - she wanted to lead an innovation project of her own!
In our first meeting to define the project scope, I asked a question that she was all too familiar hearing me say: "What is the problem we are trying to solve?" She described how her department had researched and adopted a new document management system that would standardize many of their processes and make it infinitely easier to respond to resident requests for where their request was in the process. The problem, however, was that even though everyone had agreed that the software would be beneficial, and even though they had purchased the software and had been trained on it, less than half of the team was actually using it.
My student was confused and a little disheartened when I told her, "This isn't an innovation project."
This newly minted student of innovation fell into the trap that many of us do: after receiving innovation training, we assume that the tools could and should be used in every project. But not every project needs exploration to frame the problem, diverse perspectives to check and potentially re-frame the problem, and prototyping and piloting before implementation. While the solution to her problem - why people aren't using the system that was agreed to - isn't known, the situation called more for root cause analysis and change management than for innovation.
Here are some attributes that can help you make the decision about whether innovation tools would be beneficial.
Does It Need Innovation?
YES | NO |
The end state and/or solution is not known. | There may be one or more strategies for getting there, but the details of the end state and/or the solution is known. |
The "old way" is no longer viable. | The "old way" is inefficient but still viable. |
The problem has never been encountered before; the question has never been asked before. | The problem has existed before and the conditions in which it exists are similar. There is no need to recreate the wheel. |
There is uncertainty about what the REAL problem actually is. Understanding the problem to be solved would benefit from involving a diversity of perspectives. | The problem is fully known and would not change or benefit from involving other perspectives. |
Just like the example with my student, you may find that the solution is known, but how to get there is not. In these instances, root cause analysis tools can help understand what is getting in the way; standard operating procedures can help define how to do the work consistently; project management can help everyone understand who is responsible for what and by when; and proper change management can ensure that everyone is on the same page and is receiving the appropriate level of support for where they are in the process.
I SO appreciate folks considering innovation tools and processes more and more in their efforts - they definitely have a place, but as the saying goes - just because you have a hammer doesn't mean that everything is a nail.
Comments