How to prepare your team for new software: training, adoption and resistance to change

How to prepare your team for new software: early communication, key users, role-based training, post-launch support, measuring adoption and leading change.

Implementing new software is often treated as a technical project. You choose the platform, configure servers, migrate data, create accounts and set a launch date. From an IT perspective, the project can be flawless.

And yet, after a few weeks, problems appear.

• Users keep working in Excel.
• Documents are stored in local folders.
• People say “the old system was simpler.”
• Managers find that only part of the staff use the application.

Parallel procedures emerge, and the software the company paid for ends up being used only partially.

The problem is not always technology. Most often, the problem is adoption.

New software changes how people work. It changes habits, responsibilities, flows, sometimes even relationships between departments. That is why implementation success depends as much on preparing people as on the quality of the application.

A company does not implement software alone. It implements a new way of working.

Resistance to change is normal

When an organisation introduces a new system, the first impulse is often to treat user resistance as an attitude problem.

“They do not want to learn.” “They are used to the old system.” “They do not understand the benefits.”

Sometimes these statements are partly true, but resistance to change is more complex.

For an employee, new software can mean uncertainty. It can mean a task they mastered well must be learned again. It can mean work becomes more transparent. It can mean certain mistakes are easier to spot. It can mean processes that could previously be handled informally become standardised.

Sometimes there is even fear that automation will reduce the importance of a role.

From this perspective, resistance should not immediately be treated as sabotage. It must be understood.

People accept change more easily when they understand why it is necessary and what they concretely gain from it.

The first mistake: announcing the software too late

In many projects, users learn about the new system almost at launch time.

IT works for months. Management approves the project. The vendor configures the application. Then an email appears: “From Monday we will use the new system.”

For the team, change arrives suddenly. That is one of the surest ways to create resistance.

Users must be involved earlier. Not every employee needs to take part in choosing the platform, but it helps if the organisation explains in advance:

• why the change is happening;
• what problem it tries to solve;
• what will change;
• what will stay the same;
• when implementation will start;
• how users will be supported.

Early communication reduces uncertainty. And uncertainty is one of the main sources of resistance.

Do not present the software. Present the problem it solves

Another frequent mistake is presenting the new system through a feature list.

“We have workflow.” “We have OCR.” “We have a dashboard.” “We have Active Directory integration.”

For the technical team, these things may matter. For the user, the question is different: How does this make my job easier?

If you implement a DMS, do not start by explaining the system architecture. Say:

• “You will no longer search for contracts in five different folders.”
• “You will no longer email documents for approval.”
• “You will see who has the document and what stage it is in.”
• “You will not have to enter all data manually if the system can extract it automatically.”

If you implement a CRM: “You will no longer keep leads in a separate Excel file.”

If you implement an ERP: “You will no longer enter the same information in three applications.”

The benefit must be expressed in the user’s language.

Identify key users before implementation

In almost every organisation there are people who become informal reference points. They are not always managers. They are the people others go to when they do not know how to do something.

These users are extremely important in a software rollout. They can become key users or change ambassadors.

Ideally, each important department should have at least one such user.

Their role is not only to attend training. They must be involved in testing, checking flows and identifying practical problems.

If someone from Accounting says a process does not reflect reality, it is better to learn that before launch. If the person responsible for the registry notices a missing essential field, the issue must be fixed before dozens of users start working.

The key user also becomes a local support point after launch. People tend to ask a nearby colleague for help more easily than opening an IT ticket immediately.

Training must be role-based

A general three-hour training for the whole company is rarely effective. People need different functions.

• A registry user must know how to register and classify documents.
• A manager must know how to approve.
• An administrator must understand configuration and permissions.
• An HR user may need only a few specific flows.

That is why training must be built by role.

Operator: sign-in; document entry; metadata; attachments; search; correcting errors.

Manager: notifications; approval; rejection; comments; signing; delegation.

Administrator: users; permissions; configuration; audit; monitoring.

Training becomes shorter and more relevant. A user does not need to learn 50 features if they will use only 7 daily.

Training must not be a demonstration

There is a big difference between seeing a feature and using it.

A trainer can give a perfect demo: open the system, upload a document, fill in fields, start the workflow. Everything looks simple.

Two days later, the user tries alone and cannot remember the step order.

That is why training must be practical. Each user must perform the main scenarios themselves. Not just watch.

A good session can include exercises such as:

• “Register this document.”
• “Add two annexes.”
• “Send the document for approval.”
• “Find documents created last week.”
• “Correct wrongly entered information.”
• “Open the previous version.”

The more training resembles real work, the better the adoption.

Use real data and scenarios

Training becomes much more effective if users recognise the processes.

A generic example with “Test Document 001” helps less than a scenario close to real activity.

If the company works with contracts, use a demo contract. If the system is used for registry, simulate a real registration. If staff process invoices, show exactly an invoice flow.

The user must be able to say: “Yes, this is the process I do every day.” At that moment, the software becomes relevant.

Long manuals are useful, but not enough

Documentation matters. But a 150-page manual alone does not solve adoption.

Users also need short materials. For example:

• How to register a document — 5 steps
• How to add an annex
• How to approve a document
• How to search by number
• How to reset your password

These guides can be a single page, include screenshots and be available inside the application.

Short 2–5 minute videos can be very effective for frequent operations.

The goal is not to document everything. The goal is for the user to find the answer when they need it.

The first two weeks after launch are critical

Go-live is not the end of the project. It is when the most sensitive part begins.

In the first days, users will ask many questions. Cases the implementation team did not anticipate will appear. There will be errors. There will be confusion.

Support must be much more available in this period.

If a user is stuck for two hours on their first operation, the impression of the system will be very hard to change later. If they get help in two minutes, the experience is completely different.

Ideally, immediately after launch there should be: a clear support channel; fast response; available key users; a central list of issues; prioritisation; communication about fixes.

Ignored problems quickly become arguments against the new software.

Do not make people use two systems for too long

A transition period is necessary in some projects. But keeping the old and new system in parallel too long can destroy adoption.

If the user knows they can keep working in the old Excel or old application, they will often choose the method they know. That is human nature.

Once the new system is stable enough, a clear rule must be set: from date X, this process runs only in the new application.

Of course, backup measures and recovery mechanisms must remain. But the official process must be single. Otherwise two sources of truth appear. And nobody knows which information is correct.

Measure adoption, not just installation

A software project is not finished because all accounts were created. You must measure whether the system is actually used.

Indicators can be simple:

• How many active users do we have?
• How many processes run in the new system?
• How many documents are uploaded?
• How many approvals are done digitally?
• How long does the process take before and after implementation?
• How many operations still happen outside the application?

These data can quickly show where problems exist.

If 90% of departments use the system but one has 20% adoption, the problem is not general. That department’s process must be investigated. Maybe training was insufficient. Maybe the flow is poorly configured. Maybe an essential feature is missing.

Listen to criticism, but do not implement every request

After launch many suggestions will appear. “We should have a button here.” “There should also be a report.” “In the old system we did this differently.”

Feedback is extremely valuable. But not every request should be implemented.

Sometimes the user asks for a feature only to reproduce exactly the old way of working. If the project goal was precisely to change that process, adding the feature can destroy the benefit.

Feedback must be analysed: Is it a real problem? Does it affect many users? Does it block the process? Does it reduce productivity? Or is it only a preference?

The team must distinguish between useless friction and necessary change.

Managers must use the system

Adoption cannot be demanded only from above. It must be demonstrated from above.

If the manager says all approvals must be done in the new system but keeps asking for documents by email, users will quickly understand the rule is not real.

If the director asks for reports from Excel instead of using the application dashboard, the team will keep maintaining Excel.

Leadership must use the new software in their own processes. Manager behaviour sends a stronger message than any internal communication.

Do not automate a bad process without analysing it

New software is also an opportunity to remove unnecessary processes.

If the old procedure had ten approvals only because “it was always done that way”, it does not necessarily need to be replicated in the new system.

Digitising an inefficient process produces a faster inefficient process.

Before configuration, analyse: Which step is mandatory? Which exists only through inertia? Where is data duplicated? Where is time lost? Who really needs to approve?

This analysis can deliver greater benefits than the software itself.

AI can create a new form of resistance

As business applications integrate Artificial Intelligence, a new dimension appears.

Users may ask: “Is AI checking my work?” “Will it make decisions instead of me?” “Will it eliminate my job?”

These questions must be discussed openly.

In most business implementations, the healthy positioning is: AI assists, people decide.

For example, AI can suggest document classification — the operator confirms. AI can extract metadata — the user verifies. AI can summarise a contract — the lawyer reviews the original document.

If people understand that AI reduces repetitive tasks and does not try to remove human control, adoption can increase.

The three stages of adoption

A simple way to view implementation is through three phases.

• Understanding — the user must understand why the system is changing.
• Competence — the user must know how to use it.
• Habit — the user must come to use the application without constantly thinking about the process.

Companies usually invest in the first two. They present the project. They run training. But they forget the third.

Habit is formed through repeated use, support and removing parallel alternatives.

Good software reduces resistance

This must be said too. Not every adoption problem is the user’s fault.

Sometimes the application is simply hard to use.

• If a simple operation requires 12 clicks, people will avoid the system.
• If the interface is confusing, training cannot fully compensate.
• If the application is slow, users will create alternative solutions.
• If the software asks for manual entry of information it already knows, people will see it as a burden.

That is why usability feedback must be taken very seriously.

A good system must not only be functional. It must be easy to adopt.

Success is not go-live. Success is behaviour change

Many projects mark success by launch date. “The application went into production.” It is an important moment. But it is not the real criterion.

Success appears when people stop thinking of the new software as “the new software”. It simply becomes the normal way of working.

• Documents are registered there.
• Approvals are done there.
• Information is searched there.
• Managers use system data.
• The old method is no longer needed.

At that moment we can say implementation succeeded.