You Implemented A System, But Your User Engagement Isn’t Happening – Now What?

There are 2 phases of Change Management and Organizational Alignment that occur with a system implementation. The first is the most obvious – it happens during the initial implementation. The second, follows that implementation and is a step many organizations miss. Missing or shortening this 2nd phase directly impacts ongoing user adoption and engagement.

The initial phase of an implementation often occurs after a board, or the government mandates a systems change by a certain date. And so you and your team do the traditional communication with a little bit of change management thrown in – the who’s impacted, what’s that messaging look like, how do we get that messaging out to them basic comms. But you don’t have the time to go much deeper than that.

Once you have gotten through the mandated system change you realize your users aren’t happy, and you fear they might create workarounds. Or you are just plain frustrated, your users are frustrated because these mandated changes made life WORSE for everyone, not better! What do you do?

Well, what about using those inevitable next round of system upgrade cycles to your advantage? What if in 6 months from now you could add in some functionality your user base would love? Would find super helpful? Would meet their needs? How does that sound? 

Now, how do you get there from here?

I’m not bagging on the big box consulting groups – they have a place. They get you to that mandated finish line before the government fees and fines start coming. Or your promotion is put on hold, your bonus denied etc. They are really good at delivering within a constrained timeline. However, let’s face it – to meet your budget needs you weren’t hiring a large change management team. And those you hired are use to doing this 1 thing – the basic change management/communication for system implementations. They rarely have a team stick around to do Phase 2.

And then they leave, push everything onto the “sustaining team” and you have a lot of work to do to make this system really work for you.

The beauty of Phase 2 is now you actually have a system in place. Which means people (aka your user base) can more easily give you suggestions for improvements. Because they now have something tangible to work from. And they can see, after having been in the system, what works, what doesn’t work, what causes more time, and what is missing. Something they probably couldn’t relate to as well when the system was simply an idea.

Think of enhancements as you would when building a house. My first house was a track home. We were the 1st group of buyers. Before the models were even up – we bought in. In my kitchen, there was a beautiful window that was for a kitchen garden. The problem was, the builders had made the material for the bottom of that wide window alcove – the same as the walls! So try keeping that clean. The first time I over-watered and spilled dirt on that textured drywall, I was over it. I bought some fake silk plants and called it a day.

We had friends who loved our model, and bought in on the 2nd round. They heard my complaint about that window. Loved the idea of fresh herbs in the kitchen, but not the mess of that window alcove. So they had the builder add in the same material as the counters – for that alcove. Freaking genius! It wasn’t an option – they asked and paid for it to be done.

Why? Because they could see – with their own eyes – what worked, what didn’t work and why in my house. And they had the construction background to know what could work design/ build wise. So for example they probably had a discussion about the weight of that material vs the weight of the drywall material. And were able to help design what they needed – because they had architectural and construction background.

Think of your system upgrade like a house upgrade. Sometimes it is easier to see the tweaks that will help user adoption when you already have the structure in place. Meaning it’s easier for your end users to give you feedback about what is working, what isn’t working, what would be really helpful for them to have – once they have already seen the kitchen in version 1.0.

And because they are like I was when I bought my house – not aware of HOW to make that happen – your team can then take that feedback and decide how, and when to make the changes. They take the user feedback, and combine it with their expertise to create a more bespoke experience for their user base.

This second phase is where I help clients. I use a proven, 2 pronged approach, to uncover why adoption isn’t there, and what to change to get it.

Because I have no skin in the game, people are more open to talking with me. I also have years of experience doing this, so I can pull information out of people easily. I ask them how they are using the system. If they aren’t using it the way we thought they would, I ask them how they are accomplishing those tasks, and why they feel the system isn’t the ideal solution for that.

These may seem like simple questions, and in some ways they are. But you have to have time to ask them, and you need someone not attached to the outcome to do the asking. It helps if that person has training in holding space and having no judgement. And also helps to have someone experienced in synthesizing all those responses into helpful, actionable feedback for the engineers.

Sometimes, during these focus sessions, someone just doesn’t know a functionality exists. When that happens, these focus sessions work as a mini change management session as well as feedback about how to communicate better with that department. Other times we learn that their job really doesn’t fit into the box we created in the system. And then I find out how that box would need to be created in order for them to fit into it. (Occasionally the answer is, it can’t.) While most of the time people really aren’t that divergent from what was designed, occasionally there are some outliers that wouldn’t make fiscal sense to automate – because they really are outside the current functionality and design of the system.

Knowing all three of these audiences – is helpful to design your system and also enhance your user communication. There is also an obvious 4th group – those who are simply resisting the change. And that can be helped with a proven, parallel adoption process I discuss in depth here:

If you would like help achieving higher end-user engagement and system adoption, please email me at


To View The Rest Of The Videos In This Series:

2) What To Do When User Adoption Doesn’t Match Expectation. Don’t Stress This Is Doable With A Little Help

3) How Software Engineers Can Increase Both Experiment Success & User Adoption

4) Our Proven, 2 Pronged Approach for Increased User Adoption and System Uptake