Strategy and technology

Strategy and technology

Strategy and technology combine into one of the most volatile mixtures available to modern business. After numerous singed eyebrows or much worse, we’ve learned that randomly throwing matches at that combination is not a good idea. Unfortunately, many organizations seem to have translated that lesson into the belief that there is no useful combination of strategy and technology. Handle the business strategies first and then the technology to serve the strategy, and always in that order. Methodologies and project approval processes have grown thick in piles on the ground and enforce the business equivalent of an urban legend. It sounds right. We can imagine the processes actually working. And it would certainly address the horrors of the “dot-bomb.”
But, like an urban legend, somehow the details just don’t work out. Just when we most want our methodologies and processes to guide us, they are most likely to give the same old results — leaving us pretty much where we were before we started. As the economy recovers, many organizations find they are once again spending more money on technology than they want to, and with fewer results than they had hoped for. So how do we get the spark from strategy and technology without getting the bomb?
The first step is to realize that tactics used for fire suppression probably won’t work for generating sparks or vice versa. Getting the most out of the strategy and technology takes time. Approaches that are appropriate early on aren’t sustainable over the long haul. Approaches that work over the long haul can’t get the process started.
Getting the spark is a creative process that reveals a unique combination of business perspectives and technological capabilities that are useful to your business. Like any creative process, it’s messy. You can start almost anywhere. In fact, you may have to start almost everywhere all at once: restlessly shifting from feeling the business’ needs, to imagining designs that will meet those needs, to playing out how it all works in the trenches and back again. Yes, it’s OK to start drawing architectures before you have requirements. It’s OK to scribble out a testing approach before the system is designed. Just don’t get wedded to that first draft. Use the drafts to ask questions and discover what you don’t know about requirements, business procedures or the data and information needed. Be willing to throw things away and start over, or take many small iterative steps. Being creative is an inefficient process, but it’s absolutely essential to discovering new ways of doing business.
Then something clicks and relatively quickly your organization has to shift from getting the spark to controlling the burn. Obtaining the spark is tough but managing the transition is even more difficult. Apply methodologies and processes too early and they’ll kill the spark. Apply them too late or not at all and you can burn through a pile of cash without much to show for it. In considering the transition from spark to control, I’m drawn back to John Kotter’s book, “Leading Change.” It’s not a new title, but if your organization has lots of good ideas that never make it all the way into production, you might find this an interesting read.
I don’t want to leave you with the impression that I have no time for methodologies, sequence or control. Discipline and focus, from leadership to line staff, are early indicators of successful organizations. Organizations, especially large ones, need formal processes to thrive. They are absolutely necessary but they are also absolutely not sufficient. Getting the most out of that high-octane mix of strategy and technology will require some alchemy as well as the standard chemistry.
________
Byron Glick is a principal at Prairie Star Consulting, LLC, a planning and project management consulting firm in Madison, Wisconsin. He can be contacted via the email at blglick@charter.net or via telephone at 608/345-3958.
*****
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.