Software Adoption: The Inertia Problem

When implementing new software within an organisation many businesses run the risk of it failing by neglecting to address, engage, support and listen to their staff. Chris Grosberg explains how a company can safely navigate this complex process.

“If you build it, they will come”, is a now-classic line from the 1989 film, Field of Dreams. In many ways, this has come to represent the mantra of businesses when approaching the roll-out of software, particularly office productivity software. There is usually either an explicit or implicit idea that by simply making a new piece of software available, or even forcing people to use it, that is somehow sufficient for it to be a success.

In certain cases, where there is reasonable (and realistic) familiarity with the replacement this may be true, for example, a shift to a new E-mail program, or a new version of a Word processor. Unfortunately, in many cases, businesses may receive a push-back from their users, either through objection, indifference or active subversion. This can, in turn, lead to resentment toward the business and/or people imposing the change and could result in a loss of productivity, and with it potentially wider ramifications for the business.

This doomsday scenario is clearly at odds with the bright and rosy picture that the marketing for each new product will often paint, “Our product is so simple and intuitive, just start using it!”. This is hardly surprising as what product would want to draw attention to the difficulties that might await any who try to use it? That said, there are certain providers who do recognise the difficulties, and are taking steps to guide customers on this journey. One example is Microsoft with its Office 365 FastTrack program, covering areas such as user engagement and data migration. However, this appears to be more of an exception than the rule.

Why Do So Many Businesses Fail?

The reasons that businesses fail to address these challenges are complex, and to a degree, etched in history. The issue most often occurs when the new software is not entirely analogous to the old one, particularly when people have to grasp a new and significantly different concept to all of their previous experience. For example, moving from Network Shares to a Web-based System, from a desktop Word Processor to a Web-based editor, from Email to Group Chat software.

In essence, the challenge is that we are trying to change years of working, built up habits and working patterns; moving from the familiar and comfortable to the new and unknown. This is the inertia problem.

This isn’t a new problem, and it doesn’t only affect software. However, from both [my] experience and perspective, this appears to be a growing issue when it comes to Office, Collaboration & Productivity software. With the expansion of the ‘Cloud’, more businesses are looking to utilise the new classes of software now available to them to fit their often mobile and ‘always on’ workforce. At the same time, the ‘Cloud’ for its part has lowered the barrier for companies to obtain these technologies.

Whereas previously a deployment of an enterprise product may have taken a substantial amount of time and investment to implement, it can now often be deployed and accessed in a matter of minutes, with potentially very little/no traditional IT interaction.

Acceptance is the First Step to Recovery

So, having painted the picture, the question then remains, how do we tackle this issue? The first step, as with any recovery, is acceptance. Indeed this can be the hardest pill to swallow. There needs to be an acceptance that this will be a step change for many people, and will not be as intuitive as we would like. Once a business has accepted this, it sets the business’ frame of mind and helps smooth the way for the steps that need to be taken to ensure successful adoption.

The next step is the important one, asking “Is it right and, is it worth it?”.

This can mean several things:

  • Does this fit with the business vision in the short / medium / long term?
  • Is this going to lead to a substantive improvement in the business?
  • Will this be better than what we have now? / If we don’t do this, will we be negatively affected?

The questions above are certainly not all of the questions we should consider, more so they should be our indicators on whether to proceed. The steer should be ensuring we are implementing a technology because it serves a business need, not the other way around.

Equally, sometimes requiring such a high bar can inhibit “bottom-up” adoption of software. This may be where a particular team is using the software in a way that intimately addresses their needs, and could positively impact the wider organisation. In this case, the team could (if applicable) be the pilots for the software and help lead a later roll-out.

Once we are happy that the technology we are implementing is justified and we are aware of the likely impact, cost and timescales for the project then we can consider how to roll it out to the business. When considering this, you should consider the phrase: “You can’t turn an oil tanker on a dime”.

By this, we mean that deploying and adopting new software in the business is going to take time and effort. The bigger the oil tanker (or years of ingrained experience) the more time and distance (effort) this will take. So, how can we tackle the problem? The solution consists of many different pieces that fit together.

Understanding the People We Want to Change

Every business is different, and the demographics within a business will vary. What one person may understand and find easy, another person may find confusing and difficult.

What you could do is draw up a cross-section of the affected people inside (and perhaps outside of) the business — this can be as fine grained or as rough as you like. This is also known as a stakeholder analysis or persona mapping.

With this exercise, you might consider:

  • Who are the people this will affect? E.g. what is their job role, years of experience, location, etc.
  • What challenges do they have? E.g. lone working away from the office in the middle of nowhere with a satellite phone
  • What perceptions or perspectives may they hold? E.g. previous relevant experience of success/failure, relationship with management, etc.
  • Are there any special considerations? E.g. Needs specific to their role or department, do changes need to be approved by a union, etc.

Listen and Engage

Once we have determined the people who need to adopt and use the software it is important we engage with them; take their input to shape the solution and have them help inform on the roll-out. Often, as they are the day to day users, they will have a different (and likely more accurate) way of understanding their requirements than the IT department, etc.

As part of this, it is also important to engage as much as possible with the implicit user base rather than just the explicit user base. The explicit users are people whom you may traditionally engage with these may be heads of department, IT workers, marketing teams, etc.

These are the people we would normally explicitly consider. While their opinions are certainly valid, it is important to understand they carry their own motives and perspectives, that may or may not be in the best interests of the solution.

The analogy I use is that of an iceberg, the explicit users sit at the top and are the most visible, but the implicit users are less visible, make up a much larger proportion, and in many cases keep an organisation afloat! Failure to engage adequately with this group can lead to confusion in the organisation, leading to lower uptake in adoption and what I term the Jurassic Park effect, namely “Life will find a way”.

Essentially, people will find a way around a system if they don’t like it. This does not mean we should let the implicit users dictate the direction the solution (and business) should take, merely we should ensure that valid needs and concerns are accommodated.

Giving Them Time and Support to Make the Change

Change takes time, and people feel less threatened the more time and information they have. It is therefore important to plan well, and well ahead for any implementation work. Part of this may involve drawing up a communications plan. This should draw from your stakeholder analysis.

It should address the people you need to communicate with, their needs, challenges, and the appropriate methods of communication, e.g. Emails, Town Hall meetings, Model offices etc.

As an example, field staff may have different needs, concerns and methods of communicating than office staff, who may have different needs than the Board of Directors.

The communication should be as transparent as possible, including if mistakes or delays are encountered, as the communications need to be the trusted source — not whispers or rumours heard in the canteen. It also needs to be consistent, and continuous, not simply an email sent out sporadically as an afterthought.

Doing so means you can also start to use the communications as a way of encouraging adoption and building case studies of where the new solution has realised benefit in the business, e.g. “Look at how finance cut down the time they spent on admin by 30%“.

This approach to communication should also be considered when planning user training. The amount of user training required may differ from product to product, site to site, even person to person. As such training should be provided in different forms and levels.

By levels, we mean a sliding scale of the complexity of training delivered. For example, ensuring everyone is given some form of foundation training, to cover the necessary basics.

On top of this, we may provide advanced training to a select few as needed — who may then coach and help other team members. The training material should be made available both live (if possible) where people can ask questions, as well as on-demand — such as videos, printed material etc, so people can consume and absorb at their own speed.

Once a training programme has concluded, it is important that users know where they can find additional support. This could, for example, be a drop in session every Friday lunchtime, or a support forum where people can post questions.

Don’t Disappear

It is typical of most implementation projects to finish and wrap up very close to the completion of the implementation or migration. Doing so without considering the longer-term support for your users can be disastrous.

People are most likely to encounter issues in the weeks and months following a go live. It is therefore important that support is readily available to them in this time, rather than leaving them ‘high and dry’.

This need is likely to grow and peak until enough of the organisation have reached ‘critical mass’ after which they are familiar with the system and can assist each other as needed. This support can be provided either by the project team directly or through the normal support stream — though do ensure the support team have sufficient resource and knowledge themselves before doing so, don’t simply “chuck it and run”.

The Fun Continues!

Even once the project is finished, it isn’t really finished. Most businesses will change over time, as will the technology they utilise. It is important that the solution has some level of continuous management and governance to ensure it doesn’t stagnate.

This should cover day to day challenges, such as compliance and security, but should also regularly review that the solution is still serving the business well. If it isn’t then the organisation should examine what steps are necessary to achieve this.

As with our earlier guidance, it is important that feedback is drawn from across the business. The metaphor I use is that of two rich neighbours, both of whom live in large houses. One day they talk and decide that their houses both need lavish gardens, so they set to work. Sparing no expense, they spend a lot of time and money, each resulting in magnificent gardens, the talk of people from miles around.

Neighbour one is pleased and proud with what he has accomplished. Every week he spends a bit of time maintaining the garden, keeping it well nourished and pruning where necessary. From time to time, he builds a new area of the garden, experimenting with new plants and themes.

Two years later he stands back, the garden has been transformed, and is even more beautiful than when he began, a real compliment to the house and a joy to spend time in.

Meanwhile, neighbour two decides that his work is done, he’s spent enough time and effort building the garden and goes on to other things. For a while the garden flourishes, but over time the neglect begins to show.

Some plants wilt and die off, others overgrow, covering the paths, making the garden inaccessible. After two years, the garden is a mess, a shadow of its former self, no longer complimenting the house but an eyesore.

The neighbour looks on it and realises he is back where he began, and has to decide whether or not to repeat all that time and effort (and money) building the garden again. Hopefully, you can see the parallels and agree that the second neighbour should have put time and effort into maintaining his garden, rather than repeating the process two years later!

And So…

I hope that gives you an initial idea of the challenges you may face when embarking on your next roll-out of software. As I’ve hopefully made clear, approaching a problem like this is challenging, time-consuming and very often underestimated. But, get it right and it will pay off many times over the long term.

Jisc | Data Matters

26 January 2021

We use cookies to ensure that we give you the best experience on our website. If you continue without changing your settings, we'll assume that you are happy to receive all cookies. However, you can change your cookie settings at any time. For further information about how we use cookies and how to change your settings, please read our Cookie Notice

I'm fine with this