Author: mathiaseverson

Photo by Possessed Photography on Unsplash

I’ve always been interested in solving problems and finding out how things work, and so naturally this interest has evolved to how people and technology interact. Over the years, I’ve learnt a few things about implementing a new solution, both here at Threesides and for our clients. The lessons learnt are not new. Harvard Business Review wrote about it back in 1985, and I listened to a podcast about it this week. What is “it”?

Change management. Specifically, how change management is integral to new system implementation.

The key takeaway? The hype of promised improvements is not enough to change your team.

It is easy to overlook change management as part system implementation, but when this is missing, it impacts how long, and how well, a solution is used. Helping your team to adapt to change improves efficiency and team collaboration.

So you’re familiar with the language I’ll use in this article, here is a short glossary:

• Solution: The thing that’s changing – it can be a new piece of software or website designed to address a problem or concern; or working with an agency. This can be used interchangeably with the word “system”
• Environment: Where the solution will be used, your people, context, and industry
• User: A person who will be using this solution, generally day-to-day as part of their work.

I have included some examples based on a recent implementation of Zendesk, a customer service platform, for a client.

The steps to implementing a new solution look different based on the size and scope of the project. There are projects where you will document, discuss, and approve each step. In other projects you can consider, accept, and then progress through these steps quickly.

1. Structure the playing field

It can be exciting to discover a system that promises to solve problems, simplify processes, and make life easier. It’s even more tempting to sign up for a free trial and start playing around, make a snap decision, and then just implement it.

But first, you need to understand the flow-on effects of introducing a new solution. If you don’t know where the change will happen in your organisation, you can’t measure how successful or effective the solution is. This is a critical risk management step and helps to ensure that your team can adapt to the change.

Understand the environment

Keep in mind what’s happening in the space that you will be changing. Ask yourself and key stakeholders who will be impacted by the change:

• Are there legislation or regulations that you need to consider?
• What components can change? Is it just one platform or business area, or will it cover the whole organisation?
• What needs to stay the same? Are there established processes and systems that need to stay the same?
• What do current processes look like? Are there any workarounds that are common practice? Is there a “right way” of doing things that are currently documented?

Our client would be interacting with sensitive personal information so we needed to consider what information Zendesk would store. The team was relying on emails and phone calls to arrange meetings and progress people through their services. Personal details and notes would need to be recorded in a separate but pre-existing platform.

Understand the people

Often the team setting up the solution is the one that also needs to manage implementation. There are different roles to play, and without clearly explaining who does what, things can fall apart. Think about:

• Who will be sharing the requirements of the solution?
• Who will be setting up the solution?
• Who will be responsible for supervising the solution in the long term?
• Who will be using the solution?
  • How broad is the range of experience in the team?
  • Is there any current experience with the new solution?
• What do people enjoy about current processes? What annoys them?

The director and office manager shared the workflow requirements that needed to be handled. Threesides was responsible for setting up Zendesk before handing this over to the client. The office manager was nominated to be the ‘advocate’ for using Zendesk. The team had no experience with Zendesk and was comfortable working with Outlook.

Understand the timing

There are drawbacks and benefits to changing systems and processes. Timing and speed play a significant role in how risky change is. This needs to be understood as part of your risk assessment for this project.

The time begins when you identify the solution. The project speed is determined by how quickly it takes for the solution to become part of day-to-day operations. Consider how much change you want to subject your team to, and for how long. This will determine which approach you can take to adopting your new system.

Approach	Benefits	Drawbacks
Adopt Early	– Shared learning and problem-solving – Shared sense of ownership and responsibility – Transparency of decisions and processes – Address high-level pain points	– Can miss critical use cases and not solve the problem – Higher training overhead – Business processes can’t be established properly – Miss key project goals if not identified early
Adopt Late	– Solution is tested broadly – System mapping identifies opportunities for integrations	– Problems are perpetuated longer – Opportunity for scope creep leads to additional delays
Adopt Quickly	– Team training happens quickly – Shorted time of severe change	– Establish operating procedures that may not be best practice – Miss capturing relevant/critical information
Adopt Slowly	– Reduced severe change – Identify and mitigate risks as they arise – Encompass additional requirements as identified	– Extended project planning process – Prolonged change – “Perfection” paralysis: the attempt to resolve all errors/concerns

Consider how open your team is to change. If your team can adapt and respond to new requirements and learn how things work, early or quick adoption can mean your systems are implemented in a shorter amount of time. Teams that need more time benefit from slow adoption, allowing for more training and a chance to become familiar with the new system.

2. Define the parts

System implementation is only effective if you know what needs to be done. This involves defining the project team, key stakeholders, project schedule, and requirements. Save yourself from ambiguity and scope creep by defining what will and won’t be included in this solution.

Writing a project plan may seem over the top but comes in handy when you need to share this with the team, and defines the critical pieces of your implementation:

• Who is part of the implementation team?
• Who are the stakeholders involved?
• What is the scope of the project?
• When are the milestone dates?

One approach to defining your solution is to document the different types of workflows that you want to improve. Understand what data is associated with each, then create your project plan around how they can be incorporated into the new solution.

We defined a range of custom fields that are used to track relevant information. Custom statuses were used to easily filter Zendesk tickets for our client to understand who needs to be contacted.

3. Demonstrate how it will solve problems

Demonstrating your solution builds trust and understanding – critical factors in how receptive your team will be to changing their standard routines and learning a new system.

Here are some different types of demos you might encounter during your project:

• Demos by sales teams will often be high-level and broadly address common pain points. These are generic and can easily miss nuances and specific concerns that you may have.
• Demos of specific features showcase how effective a solution might be for you.
• Walk-throughs and demos during implementation are used as check-in points to ensure that everything is on track and aligned with your requirements.
• Demos can also be used to introduce a new solution to your team before they need it. This helps reduce shock once it needs to be used for day-to-day operations.

Keep in mind who will be involved. Including too many people early in your project can collect a lot of opinions and no actionable insights. On the other hand, not including people in the process can cause concern and disruption.

It can be helpful to pilot test change with key influencers in your teams. Their influence can reassure individuals that their concerns have been heard and help them retain a feeling of control.

We find this step particularly helpful when introducing a new system to a client, but it works just as well internally.

Early in the project, we demonstrated our understanding of the client’s requirements with a customised demo of Zendesk using sample data. This confirmed that we were on the right track and that Zendesk would be a useful tool.

4. Develop and test the solution

Now the project execution starts, the system gets set up, and relevant data are added.

How long this step takes varies depending on how much data you have, what needs to be set up and how much support there is.

If you’re working across teams or with an agency, a project management plan and Gantt chart help to keep track of delivery and ensure that you meet timeframes. Throughout development, you may realise new features or functionality are required. Assess and communicate whether these should be incorporated now or later, as this can have flow on effects to scope, cost and timing.

When developing and setting up your new system it can be easy to skip proper testing. You have validated the solution and know it will address the problems you have identified. What you need to test for is how it will handle being used by your team.

It might sound counterintuitive but try to break it. This is where edge cases arise. Edge cases happen in more uncommon circumstances, generally when unexpected or incomplete data are provided, or a specific process is not followed.

In a perfect world, you would always have all the information available when needed and follow the same process each time. In reality, people try to do things quickly with limited information and then move on to the next thing.

Your solution should be able to deal with unexpected or incomplete information. This is especially important when you’re working with integrated systems. You need to make sure that the information goes where it needs to go, and know where things go wrong if it doesn’t.

Some common edge cases or situations to consider:

• Project management system: What happens if you don’t have all the required information to start?
• Managing customer enquiries: What happens if your customers format their phone number, product name or address differently?
• Website: What happens if you don’t upload an image or provide content in a custom field?

We tested how data populated into Zendesk from integrated website forms to ensure data was not lost due to different formatting e.g., phone numbers formatted as +61 2 6249 1117 or 62491117.

5. Hand over and deliver training

This is a critical step. It’s where you understand not only how everything works, but how to use it. This is also the point where a lot of change happens – and can be make or break for successful ongoing use of the solution.

Handover and training are important steps for internal projects because the person setting up the solution is not always going to be the solution owner or user.

At Threesides, we like to hand over to who will own the solution in your organisation – this person will be the main point of contact to ask questions and communicate back to us.

There will generally be two types of training:

1. Involved Training: Owner

The owner will need to understand the structure and components of the solution to help troubleshoot when problems arise. This training will be more complex, and cover infrequent, but important aspects of your solution.

2. Task Training: Team

The people who will be using the solution can receive task-specific training. As people gain experience and become comfortable using the solution, you can start to introduce the more complex and technical aspects. Don’t feel that you need to inundate your team with all the information at the very beginning.

Tie your training back to the workflows you identified during defining the solution. Regardless of the system, this is what needs to be achieved. This also helps to draw similarities to the processes that are currently being used in your team.

It’s here that your change management process really takes effect – or not. Training people effectively in the solution plays a major role in whether the solution will continue to be used successfully.

6. Check-in, assess and update

Change doesn’t happen immediately or smoothly. Once the solution has been ‘in the wild’ for some time, it’s important to check that it’s still meeting expectations. Checking in with your team helps to reassure and link the success of the project with the team’s success in using it.

Change can feel abrupt and incomplete if you don’t check in once it’s been implemented.

Regardless of how much planning has taken place, there will be parts missing from your solution. Collect feedback from tools and people. The tools will show what parts of a system are being used, and how often. The people will share complaints and experiences.

It is important to dig deeper into what this feedback means. Are negative experiences a response to adjusting previous habits, or is there a broken component in your system? Are unused program features not required, or was there inadequate training?

Incorporate this feedback and update your solution. Depending on the scale of changes, you might need to repeat this whole process again.

Remember: Poor planning leads to poor performance

Change should be communicated.

It doesn’t have to be difficult, cause team frustration or fuel nightmares. Communicating the right information clearly and when relevant reduces fear and uncertainty.

If you need some advice or support implementing change in your team or want to work with Threesides to change your marketing, design, or digital systems – get in touch.