How to manage 3 Outcomes Software Implementation Pitfalls

Outcomes software implementation is important, but it can be stressful, challenging, and sometimes overwhelming. Whatever system you are implementing, it will require an implementation process in order to contribute to the long-term health and sustainability of your new system.   However, there are three common pitfalls which many organisations face when implementing new outcomes software.  This blog will outline these three pitfalls and ways to mitigate them.

1. Underestimating processes

There are three components to an outcomes measurement system – the technology or the software itself (the “what”), the people who use the software (the “who”), and the processes or “how” the software and people interact (see SQI’s blog on this for more information).  So things like data entry, reporting, data quality, management and maintenance, workflow, and integrations are all processes that link people to the software.

Processes are the most flexible component of the implementation process as they can be adapted to meet the requirements of your technology and people. It is therefore critical to outline and define processes for new outcomes software early in the implementation project because underestimating processes may lead to a decrease in productivity, usually through duplication of work, and rejection of the software by users.

The adoption of a new software solution therefore offers your organisation an opportunity to redesign the workflow of the organisation and blueprint new systems to maximise internal resources and efficiencies.  So it is important to clearly define your processes and how your people will interact with the software and vice versa to work out if you need to modify any existing processes.  You can do this by answering these questions:

• How will we keep our data clean and consistent?
• How will we report our data and analyse the information?
• How will we maintain end-user and administrator knowledge?
• How will we get answers to our questions?
• How will we manage the system on a month-to-month basis?
• How will we integrate other information systems with the software?
• How will we interact with the software on a day-to-day basis?
• Can a constraint with the software be overcome by changing our processes?
• Is the constraint really a software limitation or a capacity limitation within our team?
• Can process improvements or adaptations improve our people’s interface with the software?
• Can we take advantage of more of our solution’s features and functions by adapting our processes?
• What processes are required for us to maximize use of this new system?

2. Not listening to users

In several other blogs, we talk about the importance of listening to and involving users (add link to 5 system implementation best practice tips) in order to create staff buy-in (add link to 5 ways to create staff buy-in when implementing outcomes software).  Users will be operating your database day in and day out, engaging in data entry, reporting, and data management.  Therefore, they will be the people closest to the software when it is fully implemented.  And although they may not have an in-depth knowledge of the software like your organisation’s software administrators, they will outnumber your software administrators and essentially contribute to the overall health and sustainability of your system.

Given users make up the majority of people who will interact with your database on a daily basis, it is therefore important to include their feedback, opinions, and insight early in the implementation process, from the discovery stage before the software is built, to the design of the new software, to training, and then all the way through to go-live and beyond.    This will ensure your users are invested in the software, and are therefore more likely to accept the changes that will come with new software implementation.

However, soliciting feedback from users isn’t enough.  It’s important to try to take on board this feedback and act on it by including it in the design of the software.  This demonstrates to users that they were listened to and that their feedback was valuable and taken seriously.  And even if some of their feedback cannot be incorporated into the new software, it’s important to identify why that’s the case and be transparent with end users to maintain their buy-in.

3. Being inflexible

The last pitfall usually occurs within the first 1-2 months after go-live, once the implementation project is complete.   During this time, the software becomes real as users begin to utilise the software and user feedback increases significantly because users are able to see how it affects their daily work.

Being inflexible during this post go-live phase is a common implementation challenge.  Closing feedback channels, locking down the ability to make changes, and saying “no” too often during this period can lead to rejection of the software by users.  Remember that most software platforms require lots of customisation and are never a perfect fit from the start, which means lots of changes as you learn the system, so you need to be flexible.  This might mean altering your internal processes to match the software’s features or vica versa.

Ultimately, you need to arrive at a point where the software reaches a steady-state, but to assume that point occurs straight after training and at go-live without any changes can be detrimental to the long-term success of the new software system.

To get around this, there are a few things you can do:

• Add a post-training phase to the implementation project for real-time changes and modifications to the system (usually between thirty and sixty days after go-live), rather than ceasing the project at go-live.
• Formalise a change order process and set expectations for the post-training phase so users know how and when to provide feedback
• Maintain flexibility with the system while also being prudent and practical with changes, updates, and modifications

Successful software implementation projects are a combination of planning, execution, and flexibility.   So, keep in mind these 3 common pitfalls to ensure success with your new outcomes system.