Then one day an upgrade/update/version release/service pack/call-it-what-you-will gets laid down, and the torture begins. There are three types of cruel and unusual punishment that can be included in your software upgrade. The first is a gentler form of coercion: you are informed that problems you didn’t know you were having have been expertly remove or repaired. The evidence that you’re asked to accept is that a problem that you didn’t know was happening is no longer happening. And you’re welcome.
It’s best not to worry your pretty head about what changed. You’ll just spend sleepless nights wondering what else isn’t fixed that you won’t know about until after you know about it, but the good news will be that by then it’s fixed. This is where the experienced upgrade recipient simply evokes the Frozen Elsa rule: let it go.
The second upgrade scenario is that things that were broken and supposed to be fixed are still broken, or, in a popular variation on that theme, the software is now broken in new and more interesting ways. It’s odd to find yourself in the position of yearning for the good old days, when you knew how and where your system was broken, and not having to puzzle your way through an online scavenger hunt for defects.
Sadly, there is often a third outcome, the one that users dread the most: a part of the system that was hale and hearty has taken a sudden turn for the worse. Here, we venture into a situation that I refer to as an “upgrade downgrade.” The particulars of each encounter remain a mystery right up until the moment of discovery, much like a landmine. And often the similarities don’t end there.
The collection of problems I am discussing appear so frequently as to constitute a modern upgrade cliché, but I wonder if the real problem is the sad state of 21st Century software development, or if it’s our expectations of what an upgrade is or is likely to be. I am beginning to suspect the latter.
The average person construes “upgrade” to mean that if s/he submits to the process, s/he will finish in better place than where s/he started. Upgraders should be better off for having upgraded, but we seem to have arrived at a place and time where simply being “better off” doesn’t quite cut it in a world full of technological wonder. We have advanced technologically beyond what our parents couldn’t even imagine, and in that transition to a post-modern world, we believe that we should arrive on the far side of an upgrade with everything valuable we previously had still in hand, minus problems and issues, plus magical new capabilities and transformative experiences. But flawless isn’t real and perfection isn’t the standard against which we operate. In a complex world, we must settle for reasonable, as reasonable people still do. The tricky question is, “what is reasonable?”
Reasonable is that complex change is a net process. In a complex environment, an upgrade is a software delivery that produces more benefits than drawbacks, not something that delivers a drawback-free environment. I am not attempting to absolve the software development industry from their obligation to provide high quality, workable products that conform to industry expectations. I am only saying that they can’t be expected to deliver an upgrade that fixes everything and breaks nothing for every client site they service. We aren’t an industry of linear improvement and universal agreement. The hospitality industry is an eclectic band of artists who want their technology to accommodate their vision. Sometimes getting us all to drink from the same source and equally enjoy the experience is a very big ask indeed.
We tend to forget that complex change ends up being a collection of plusses and minuses, especially when software systems are written with a broad community in mind, as they almost always are. In a widely diverse software community (meaning a community made up of more than one hotel), what works perfectly for one user is a nightmare for another. The reality that we need to accept is that software vendors can’t survive without creating products for common consumption within the widest marketplace possible. When they do that for a mixed audience, they get mixed results, even with code that is thoughtfully designed, well written and thoroughly tested. And if it’s reasonable to expect mixed reviews with well-constructed code, imagine the upgrade fallout you’re likely to experience from poorly constructed or inadequately tested code.
And speaking of testing, even with electronic assistance it’s often near impossible to replicate the geometric variations in hotel data in a laboratory environment. Just telling software engineers what to look for through use cases that may vary by occupancy, number in party, rate season, room type, guest type or affiliation and reservation source, just to name a few simple variables, is an overwhelming task. It’s not surprising – and perhaps very reasonable – that a single user can accidentally find more problems, exceptions and variations faster in live data than a whole team of software engineers can produce with rigorous methods applied to mountains of scripted testing scenarios.
Now expand these checkered circumstances to encompass not just a simple upgrade within an existing system, but to address the process of removing one complex system and replacing it with something similarly complex but entirely different. I’ve logged several decades engaged in that specific process, and I’m always surprised when a user community discovers that it hasn’t so much eliminated previous challenges, but rather swapped them out in favor of a new set of challenges. Does going through that arduous and expensive process just to end up with a new set of challenges meet our test of reasonability?
Almost always the answer is a yes; the change justifies the challenge because it usually accomplishes some other strategic initiative or business imperatives. But does the outcome meet the heightened management and employee expectations that accompany the process of buying and installing a brand-new system? Hardly ever. If delivering a new system also delivered rainbows and unicorns, everyone in the industry would be madly tossing out their legacy solutions and replacing them with whatever miraculous solution that was.
The point of expounding on all this rampant disappointment is to emphasize the importance of change management. In the hands of technologists, “change management” always manages to include Gantt charts, detailed specifications and cutover dates, but it often overlooks the human aspects of managing expectations, resolving misunderstandings and, if required, mitigating product shortcomings. The one thing that every new installation or upgrade has in common, regardless of vendor, customer, size or scope, is that the deliverables also encompass needs, hopes, desires and expectations. Every recipient is a human being… so far. Remember, if you’ve had nine steps forward and two steps back, you’ve had a great day and a positive upgrade or buying experience. And if you can accept that premise and keep your smile, your faith and your sanity, then you’ve successfully managed the change.
And you’re welcome.
