06 Sep Aging IT
How mature is your IT organization? Any temper tantrums lately? Or an adolescent episode of hormone-clouded judgment? How about a mid-life crisis? Or maybe just a bit of flagging memory?
Given that organizations exhibit all of these characteristics at one time or another, it’s easy to begin thinking about organizations as if they were people, collecting experience—if not always wisdom—as they age. It’s even understandable to want a model for guiding their development, for transforming all that potential in your IT group into a stable, contributing member of your business. What’s more, there are any number of folks ready to provide you with advice and frameworks or even the ponderously named “capability maturity models” for software development or manufacturing or whatever.
There always seems to be an unspoken aspiration for the relentless, predictable march from less mature to more mature. Wind up the model and off we go. Only problem is each organization, like each person, is unique and full of individual quirks, abilities and perspectives. You can read all the books on raising kids you want to, but when it comes time to deal with teething, or first dates, or a first cars, there’s the plan and then there’s reality. It’s that way with organizations as well. “Blueprint” is another idea that often pops up in this context, as if an organization is a finite, physical thing that can be cut to fit and bolted together. Maturity models and best practices are just different species of plans, and all too often we confuse planning and reality, with reliably disappointing results.
I’m not trying to say that the models and practices are all just works of fiction with no relationship to healthy organizations. They provide useful context in assessing processes and behaviors and even in suggesting areas for development and improvement. However, they are also not a replacement for the ongoing individual and collective judgment about what your organization values and how it translates that value into day-to-day activities. I’ve said elsewhere that the formal parts of most organizations are pretty much the same. What separates successful organizations from others is how they translate that into the informal knowledge and practice of day-to-day operations. It’s useful to notice that most models and best practices are aimed squarely at the formalized part of an organization.
It’s not surprising that the mother of all maturity models came out of a software engineering focus. We’re great at taking what’s analog and continuous and breaking it into discrete steps and digital data. Then we plug that into our computer systems for rapid and efficient replication and automation. What can’t be digitized might as well not exist. But before we assume the whole show can be documented, engineered and manufactured in a predictable reliable fashion, we might listen again to a local biotech executive. He’s says we lump research and development together, but they’re really two very different activities. Research is focused on finding something new, something not seen or understood before. Development is focused on taking that new thing and reliably reproducing it, making it something seen again and again. The maturity models, the blueprints, the best practices, are development tools.
To really find something new, something not seen before, some competitive advantage, you’ll need more than just a model or a practice that somebody else came up with. One useful aphorism says look inside your industry for efficiencies and outside your industry for innovations. Finding those innovations, bringing them over the wall, helping them emerge as something that works for your organization is the work of your own staff. When your organization has enough experience with the changes to begin to standardize and formalize, then it’s time to bring in the models and the best practices.
Byron Glick is a principal at Prairie Star Consulting, LLC, a planning and program-development consulting firm in Madison, Wis. He can be contacted via e-mail at firstname.lastname@example.org 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.