Successfully implementing software: Avoid the 7 biggest mistakes

Once you have successfully completed your selection project for a new enterprise software, you can initiate the software introduction project. In the definition phase of the implementation project, the choice of the appropriate implementation strategy is the central factor that determines the success or failure of the software implementation.

The motive for which companies decide to introduce ERP or project management software is usually that they are not satisfied with the flow and coordination of internal processes or want to fundamentally restructure them and make them more efficient. This is exactly what many software vendors promise in marketing texts: Each one supposedly offers the omnipotent universal tool that eliminates all your pain points without any intervention.

First, define your work processes and your workflows. Existing processes have grown historically and in many cases have long since been overtaken by time and are no longer the most efficient solution. How should your business areas mesh, which information flows should converge where to achieve what?

• Define concrete goals (SMART goals),
• develop a concept and
• describe your internal process map.

These individual processes defined by you should be part of your requirements catalog or specifications when you start looking for suitable software. This may seem like a lot of work at first, but it is a mistake to adapt your processes to the capabilities of the software. The software should adapt to your processes and provide you with the best possible support to execute them as automatically and efficiently as possible, not the other way around.

Therefore, the rule is: optimize processes first, then digitize them.

A good software manufacturer will take the time to get to know your processes and open up opportunities for you to optimally support them with individual configurations. He will be helped by concrete application scenarios/use cases that you describe in detail with desired goals. You should take the time for this.

Expectations often only develop in the course of communication between the software provider and the prospective customer:

• Prospective customer formulates requirement: software that solves problem XY.
• The provider explains how his solution solves this problem. In doing so, it presents features and functions that also solve other problems.
• The prospect adjusts his expectations based on the possibilities presented and usually expands his horizon of expectations.

The software introduction of a project management or ERP software usually affects almost every department of your company. Naturally, at least the management, possibly the PMO, all project managers and department heads do not want to miss the opportunity to have a say in the selection and subsequent implementation. As we learned in Mistake 4, miscommunication is fueled as the number of sharing people increases.

Mistake 5 is therefore a classic: there is no clear person in charge. Too many people are talking, making clear and purposeful communication difficult.

In order to keep communication as direct as possible and implementation time as short as possible, it is therefore recommended that you appoint one person from your side as project manager.

The project manager...

• is the contact person and negotiator with the software company
• takes up the requirements and expectations within the own staff and represents these appropriately in the requirement catalog
• informs the workforce about the progress of the negotiations and the status of the implementation
• formulates and communicates requirements to the vendor
• initiates coordination and negotiation with the software vendor's consultant
• supervises the entire system implementation

The project manager should be given the resources necessary to see the project through from start to finish. A clear timeline and budget are also required. No implementation project of complex software is free and finished after two weeks.

Determine who will define the requirements even before a requirements catalog is created. Usually, this is the IT department on the one hand, and the business units that will use the software most intensively as lead users on the other. The primary interest of the IT department is that the new software integrates seamlessly into the existing system landscape. Lead users, on the other hand, pay attention to usability and functional aspects. The project manager should take up the interests of both parties and map them in the specifications.

Introducing new enterprise software inevitably results in profound changes

• Work processes change for all users in your company.
• Old habits, structures and processes have to be questioned.
• Knowledge and information sovereignties are taken away through more transparency and simplified data access.
• Areas of activity change or even become obsolete.

It is understandable that not all those affected are enthusiastic about this. It is therefore perfectly normal for resistance to the system change to arise. The mistake is to deal with this resistance in the wrong way or not at all.

There are different forms of resistance, which must be dealt with in different ways:

1. Open resistance: employees openly express their concerns. Encourage constructive criticism to expose real weaknesses in the software and the implementation process.
2. Covert resistance: Employees express criticism only among themselves and sabotage the implementation by creating new requirements, insisting on secondary requirements, ignoring new process specifications, or expressing unspecific criticism of the user experience.

Resistance is usually caused by employees' fears of the changes described above:

• Fear of being overwhelmed
• Fear of losing power
• Fear of loss of control

The key to acceptance of the new software is therefore to prevent these fears and - where they do occur almost inevitably - to counter them with appropriate measures. It is therefore advisable to accompany the change process through the software introduction with continuous change management. Change management should always be a sub-project within the software introduction project and should be regarded as an integral part of the project.

Among other things, it involves preparing those affected for the upcoming changes at an early stage by providing comprehensive and appropriate information ("change communication") and involving them in shaping the change throughout the entire process. Change management in this sense is extremely diverse and can include a wide range of different measures, including information and training measures.

Representatives of sustainable change processes clearly advocate the earliest possible involvement of all stakeholders, i.e., all future software users. Consultants from experienced software providers can prevent resistance and create acceptance through appropriate training and workshops even before the actual introduction of the software. Knowledge of software usage gives affected employees the necessary security in the process. The greater the security, the greater the willingness to change.

In order for complex business software to fulfill its actual purpose, namely to handle internal company processes more efficiently, all relevant data must first be initially imported and then continuously maintained. Especially directly after the introduction of the new software, it is important to establish a routine for data maintenance in all departments. Data maintenance does not seem to bring any immediate benefit to the individual users themselves and therefore means unnecessary effort for them.

In many cases, the employee who would have to feed information into the system is not the one who benefits from it afterwards. Therefore, there is a temptation to treat documentation and data maintenance stepmotherly. However, this leads to a patchy database and to the software being used and maintained even less by employees and, ultimately, to the software being useless and workflows collapsing.

In the development of Projektron BCS, we place particular emphasis on ensuring that all these aspects are sufficiently taken into account in all functional areas of our project management software. See for yourself and test Projektron BCS right now, free of charge and without obligation.

Test Projektron BCS

If you avoid the seven sources of software implementation errors mentioned in the article, this does not mean that other errors not listed here cannot occur. However, if you are aware of the biggest risks, your software implementation project will have a much better chance of success.