28 Jul Innovate, Automate, or Improve? You Don't Have to Choose.
There’s an old saw around business computing that you should improve processes before you automate them. It is seductive to think that if the business side could just get its act together and tell us clearly what it wants, everything would be fine. And if your only objective is to automate what you’re already doing, it might (underline the “might”) work. But that leaves a lot of technology value on the table and presumes the luxury of time for a nice, neat, business-then-technology kind of sequence.
The biggest problem with this kind of thinking is that it leads to the conviction that somebody else has the right answer. You see this all the time in elaborate requirements-collection methodologies. Peel away all the surveys and focus groups, benchmarks and best practices, the endless narratives, user stories, use cases and general deforestation by documentation and what you’ve got is the belief that somebody or some other organization knows the answer. Guess what? Innovation, especially with technology, is a group effort. Expecting that you can discover a neatly packaged right answer in some other organization or in someone else’s head is a dead end.
In the prevalent us-and-them climate of IT, the requirements-gathering process is often our only gesture toward working together, and too frequently it’s just that, a gesture. You tell us what you want and we’ll tell you what you can have. But the right answer for an organization is going to emerge from the interaction of its parts. Even the best pre-packaged “solutions” are going to require some adaptation in business processes, employee training and culture. In fact, the more pre-packaged a solution, the more adaptation will be required in the non-technical parts of the overall system. Every one of these adaptations will impact the understanding of the situation and fitness of a particular approach. At the beginning of this learning process, we simply can’t ask enough questions to map out the full course to completion. And even if we could, we wouldn’t know enough to understand the answers.
Rather than trying to discover the right answer through a front-loaded organizational interrogation process, consider an approach of description and dialogue. I’m not suggesting a return to the glass-house days of “this is what you’ll get and you’ll like it.” I am suggesting that technologists get better at describing whole systems that include more than just technology and use those descriptions as the starting point for discussions with the organization. Extreme Programming and other rapid development approaches hint at this idea, but still seem to expect users to be able to tell prescient stories about what their lives will be like in the new world that technology opportunities create. If we’re not able to do that, why do we expect our partners to be able to?
Given our IT history of draping a few token alternatives over our deeply held convictions to give our partners some illusion of choice, success in a description and dialog approach requires a real change for IT. We have to understand and admit that our early descriptions are almost complete works of fiction. Like good fiction, the early descriptions should illuminate significant issues and ideas. Peers and partners should be able to relate our descriptions to their everyday work life.
We have to back that up by making changes to the descriptions to reflect our partners’ understanding of their work lives and to satisfy their need to have an ownership stake in the final result. That’s what defines a partnership, after all.
Using description and dialog requires a certain faith in the power and fidelity of imagination, as well as the confidence to absorb suggestions and share decision-making, but that’s probably already present in an innovative organization. If your challenges are common and well understood, you can get started on solutions just by asking questions, both inside and outside your organization. But the more you’re faced with uncommon situations, the more innovative your organization, the more likely you’ll have to do some description to get the ball rolling.
Byron Glick is a principal at Prairie Star Consulting, LLC, a planning and program development consulting firm in Madison, Wisconsin. He can be contacted via the e-mail at firstname.lastname@example.org or via telephone at
The opinions expressed herein or statements made in the above column are solely those of the author, & do not necessarily reflect the views of Wisconsin Technology Network, LLC. (WTN). WTN, LLC accepts no legal liability or responsibility for any claims made or opinions expressed herein.