Life After Working with the Same Application for More than 15 Years

Why is it that when a user has been working with an application for a year, she can do the work on autopilot, but if a user has been working with the same software for 15 years, she can’t picture life after that application? The user already has her vices: she can work with her eyes closed, knows all the programme’s hacks, knows how to search, knows how to find, knows how to deal with any errors that come up.

There are projects that are more complex when it comes to users feeling comfortable working with the new application than with customising the application itself to cover their use case.

Even though they know the current software has lots of limitations (every time you have to add a new field it’s a nightmare, it’s not supported anymore, you can lose data, etc.), their old application is a familiar friend and they cannot see beyond it.

Change management and project management

I recently read an article on whether change management includes project management, what the difference is, if the chicken comes before the egg, etc. Truth be told, I didn’t really understand which included which. What’s true is that there are projects whose management is highly organised, that are impeccable, that are on time, and everything else, but the users don’t feel like using the software. They resist it. Everything seems more difficult. They feel like they are doing more work than they used to with their old application.

And you ask yourself what happened here? We executed the project flawlessly and yet we are having problems. Change management. We don’t treat it very seriously. Bad move!

Sometimes it’s difficult, but you have to put yourself in the shoes of a user who has being doing things the same way for many years. Of course it’s going to be difficult to change!

Probably, any student of administration or project management would tell you that change management is key to any project. Or that there is no project without change management. The reality that I have found is that although we must always do some change management, in some projects, it’s more important than in others. It depends on many factors:

• How young the end users are, if they are digital natives or not.
• How long they have been working with the application.
• How big the change is.
• Who the project’s sponsor is.
• If there are negative leaders amongst the users.
• If key users have been left out.
• How the politics and internal dynamics amongst areas are.
• If they are paper to digital transition projects.
• How much pressure to get it up and running the project owners are exerting.

But, there are signs you can recognise to understand that you are going to have to make more of an effort when it comes to change management in a project and, definitively, users who have been working with the same tool for a long time is one of them.

A practical way to do change management

How do we proceed when we see any of the signs listed above? Below is some practical advice:

1. End users from the very beginning

From the time the project is presented, the users have to have shared responsibility for the results of the project. The only way to make someone responsible is to ensure that that person has actively collaborated on the project.

2. End users participate in defining the project

As strange as it seems, we continue to find projects in which we don’t have direct access to end users. We have access to their bosses or to the IT team. But their bosses and the IT team don’t spend hours working with the old application. They don’t know all the exceptions that tasks and processes have. The lower on the organisational chart we can reach, the better we are going to know how the operation works.

3. Tests must always be done with the end user

I’m sorry to say, but the tests done by users that are not from the business are practically worthless. Even if there are test cases to follow, the tests carried out by testing departments or technicians are, in the end, the same tests that I can do myself. If a user is not in the business, he or she won’t know what he or she is doing and is not going to notice all the errors in the process.

4. Tests must be done in situations that are as close to reality as possible

This means that we must test with:

• Real cases (real documents, real requests, real data).
• In the end users’ workplaces.
• With the end users’ network and computers.

Tests of this nature are going to help us detect exceptions to the defined flow; technical, computer, or infrastructure problems that users are going to have; information we are missing; and more.

5. Rolling deliveries with end user tests or UATs for each of them

You have to ensure that users are familiarised with the tool, that they aren’t afraid of it. This can only be achieved by using the platform. The more they try it, the better they understand it, the better they know it, and the more likely they will be to use it.

Also, rolling deliveries help us quickly detect design errors, bugs, cases that haven’t been considered, and more.

6. In-person UATs

Some users are more independent than others. Although we may not believe it, every time the software fails or something happens that the user doesn’t expect—whether it’s their fault or the software’s—the user has a scare. They lose confidence in the software and are afraid to play around with it too much. If we are there with them in person, we can ease their fears. We can say, “Look, this happened because you did it like this, and you have to do it like that. Don’t worry, it’s okay. You can change it here”. Having someone there gives the user confidence. They have the support they need to solve it.

7. Clear expectations

You have to be clear with users. You have to explain to them that software has errors. We have to tell them that like everything in life, the application needs running-in time. We cannot make false promises.

“I can’t promise you that the software will never fail. I can promise you that I will be there to fix whatever needs fixing”.

For this reason, we use BLP periods. These weeks ensure software stability following the production launch. The user knows they are going to find errors and our team knows that they have to be especially fast in solving them.