“Software is a constantly degrading environment.”
Although that statement has, perhaps, more double entendre than ideal, it’s at least literally true. It’s also in quotes because it didn’t originate with me, but with an engineer who worked closely with me at EMA for years. He was brilliant, insightful and creative, but ultimately more at home designing new solutions than commenting on those that weren’t his own.
Now, you might also say that printed paper, or for that matter, monuments carved in marble, are also “constantly degrading” through the forces of decay and erosion. Let alone any living thing. But the speed of “degradation” in software is so accelerated that it is the dark half adding dimension and depth to the brighter side of technology -— which is of course the impressive pace of innovation.
This constant race to new functionality and more resilient code often comes at a price when the people making the changes haven’t properly prepared, and when they haven’t thought through both the technical and human impacts.
I’m not just talking about developing actually new application software, but also what should be routine upgrades. EMA, for instance, recently had a less than successful transition for e-mail and Web hosting from one server to the other from its IT hosting provider ... impacting many hours of productivity for each individual in the firm.
From a BSM perspective, a few of the lessons are pretty clear.
1. Remember that all change, even minor change, has the potential to be disruptive. This includes the otherwise “seamless” delivery of new functionality or design points that will invariably cause delays in work rhythms as each professional gets used to the new environment.
2. While not always possible, the timing and the content of changes should fit in with business versus just technology requirements -— and directly support business versus just technology objectives. The industry as a whole is still so far away from this (even cloud makes only a small dent) that most people, especially those of us in high tech, tend to brush it all aside. Security and patch updates are still often far from transparent, while new designs with new or relocated icons and mysterious new drop down menus are so routine that most of the time we just shrug them off. We like to think that it’s all in the name of progress. But is it? Not when people don’t use or don’t even want the new functionality and recurringly lose time trying to navigate across unfamiliar visual landscapes. Or worse, when they constantly fail the developer’s “multiple choice” quiz when it comes to menus and menu options.
3. As a corollary to this, there is deep-seated and well established mindset that users will benefit when software “gets to know” them and not only responds to, but actually anticipates their requests. If you are planning new services, I would be cautious about expecting any of these technologies in your organization ... including software from third parties delivered on premise or as SaaS. These heuristics work best when they tackle simple objectives, such as most recent areas of access or interest –- or Outlook’s memory for addresses. But applications that try to anticipate everything -- from what you need to know to what you like to how you really want to format this document -- too often create cul-de-sacs that take the users up blind alleys where they can’t find a way to back out.
4. And don’t forget the really basic things that can sabotage transitions, such as failures to maintain address lists, or access rights, or user profile settings -- all of which were, for instance, issues in our case.
5. And finally, as everyone says, but so few really do, try to find out how and why your customers are using your services. If your company is large enough to have the benefit of working with business analysts, remember that as good as they may be, they are still surrogates for the end users themselves. Proactive dialog and good listening is, as it so often is, the very best recipe for ensuring that “upgrades” – whether as trivial as a server switch, or as major as a new application release – don’t turn into “degrades” in your end customers’ eyes.
Related Links:
