an abstract image of a grid adhering to waves with various spotlights of teal and purple

A Rough Guide - Upgrading Your Software



Mike Vincent
Mike Vincent

When it comes to upgrading various information systems software (like ECM, CMS, PIM, CRM, DAM, ecommerce, etc.), the only common threads between upgrades are perception and poor prioritization. What key actions can you take to set the right expectations?

Fair warning, I will be Soap Box adjacent for some of this post, occasionally perched, trying to avoid full ascension.

TL;DR: There's never a good time to upgrade, reduce cost and anxiety by upgrading often, assume no one else is aware of the need to upgrade, set expectations - Sell, Plan, Budget, Repeat.

In this post I want to relay my experience upgrading information systems. Specifically, the symbiotic relationship between the needs of the business, and the needs of the systems they rely on.

Every upgrade is unique, the combination of Possible Versions, enhancements, modules, and integrations between systems is infinite. Often, the only common threads between upgrades are perception and poor prioritization.

The need to upgrade is an expectation that should be set early and often. It should be clearly acknowledged by all stakeholders and agreed to be a business need.

Most of us don't hold this expectation. What follows is opinion, a perspective shaped by experience, by stakeholders and organizations that already hold these expectations, and those that came to these conclusions through one or more traumatic experiences.

Let me begin by stating the problem as I've observed it.

The deck is stacked against us! As people we can be naturally apprehensive towards change, and ambivalent towards future consequences. Faced with competing interests, prioritizing the mundane option over the awesome, or even the slightly less mundane option, is just not instinctive.

For most consumers, the relationship with Information systems is unidirectional - they serve. In reality the information systems we frequent are dependencies that we are beholden to. Recognizing this dependence is critical to approaching the topic of maintenance.

Like it or not, we are losing both the ability, and to some extent the instinct to repair and reuse. While companies push legislation to encourage a culture of discard and replace. Without valuing a thing it's difficult to find any perspective that would motivate us to take care of it. The assertion here is that we don't value information systems, only what they can do for us, and that we don't maintain software because we have other tendencies.

It's entirely understandable. The pace of technological advancement, the instant gratification that new devices and applications deliver - our understanding of complexity is diminished while our expectations of simplicity and perfection have sky rocketed.

My experience has been that the need to upgrade is discovered rather than expected. Software maintenance isn't going to be highlighted by any sales team, it's rarely considered relevant to an initial implementation project, and it's unlikely to be included in any blue-sky vision board, or digital strategy roadmap. Instead we wait for something or someone to point out our accountability.

When attempting to prioritize upgrades over feature development, it’s important to reserve some empathy… Simply put, it's human to prioritize immediate opportunities over longer term risks. Especially when that longer-term risk is difficult to define.

So how do we get from ambivalence to upgrade? What steps can we take to minimize the risk of a forced upgrade? How do we change the culture?

The simple answer is to choose to upgrade, and to do so often.

In practical terms the key is not to make upgrades a trade off, but instead a condition of ownership. Feature development and upgrades should never be contestants in the same beauty contest, or tickets in the same raffle…. how you prioritize features isn't important, just keep them separate.

So how do we make the culture more pragmatic? In my experience there are three (3) key actions an organization needs to take.

  1. Selling…

    Selling the upgrade requirement to stakeholders is critical. In theory the risks alone should sell the need, but if you aren't playing that record, it's safer to assume that the business won’t be tuned into a station that is.

    To move forward together, an organization needs start from the same place of understanding... Carrot and stick time - do you sell the risk or the potential benefits of upgrading.

    Risks…

    • Technical debt increases over time.
    • Unable to take advantage of new features potentially reduces agility, productivity, competitiveness.
    • Increases the likelihood of timeline and budget surprises. The need to upgrade may be found during an already scheduled enhancement. This can lead to budget and time being diverted to the upgrade over the original requirement/expectation, potentially delaying other initiatives.
    • An external, dependent system might have to declare End of Support for your system, or an external dependency might stop supporting a framework or protocol you rely on.

    Rewards…

    • Reduce the build-up of technical debt.
    • Take advantage of new features - be more agile.
    • Reduce timeline and budget surprises.
    • Maintain support for connected systems.

    In my experience fear is going to be the easier pitch, but having folks engage with the benefits of an initiative is always the preferred approach, lead with the benefits, and create advocates where you can.

  2. Planning…

    Understand how frequently vendors release major versions, and based on your company’s tolerance for risk, plan to stay current - usually no more than 6-12 months behind the latest release.

    No hard rules here, just prioritize and evaluate what you know and budget for what you don't. Add upgrades to the compliance agenda, or schedule quarterly meetings to asses new major/minor releases.

  3. Budgeting…

    If you don't include scope for upgrades then a lack of budget will always be a great excuse to never upgrade, and potentially problematic when you have no choice.

    By not allocating budget to upgrades, we are implying that a system has stopped evolving, and is of low importance. Your upgrade budget should reflect the value of the system to the organization.

A rough guide to upgrades felt like a fitting title, at least experientially. However, it isn't just word play. Here are some general notes and observations, that I have found help with expectation setting.

Generally speaking, the thing that makes software upgrades so testing, is the amount of literal testing we need to perform. We need to confirm that every functional and transactional part of the system is returned in either a functionally equivalent, or enhanced state. Critically the intent of our application must be protected.

Optimism can be earned through meticulous planning, co-ordination, execution and rigorous testing. Completing an upgrade is more likely to be marked with a sigh of relief than anything approaching celebration. While It may feel like you've just climbed a mountain, to those around you it can be perceived as running on the spot. Seek glory elsewhere!

The mere utterance of the word "upgrade" can be traumatic for some, so while it may feel self-destructive to push that agenda. The frequency with which you upgrade inversely correlates to the complexity of the upgrade. Increase frequency, to decrease complexity, risk and potential trauma.

This has been a rough guide to upgrading. Why we don't, why we should, and what you can do to help foster care & respect for the information systems in your life.

I'll leave you with a meeting agenda of sorts, some basic questions to get the conversations started.

  • Do we have an upgrade schedule for this system?
  • Do we have budget set aside for system maintenance?
  • Which team should own this responsibility?

… and one last piece of advice - Schedule your next upgrade today!

Let's Get Started

We'd love to hear from you. We probably have a lot in common. I mean, you like chatting about data-binding, UX patterns, and javascript functions, right?

X

Cookies help us improve your website experience. By using our website, you agree to our use of cookies and our privacy policy.

Accept