Change management: How to make your software change a success

“Why do we need new software when the old one works?” Many employees ask this question when faced with a software change. Change is often perceived as a threat rather than an opportunity for improvement. Yet it’s precisely these innovations that are crucial to increasing efficiency and reducing costs. Clever change management can address employees‘ concerns, positively influence their motivation, and thus make the change a success.

Markus Kawollek, Managing Director of nuboworkers GmbH, reveals in an interview how this process can be designed. As a cloud specialist and change manager, he and his team support companies in the efficient implementation of digitalization projects within the Microsoft 365 ecosystem.

How many digitization projects have you been in charge of?

We now manage between 30 and 40 digitization projects per year. nuboworkers has been around since 2017, and since then we’ve completed a total of around 200 projects. If you include smaller applications and workflows, we’ve completed about 250 digitization projects.

Are digitization projects one-offs or do some clients work with you on multiple projects?

There are different situations. Smaller customers often have just one digitization project, such as moving from a bulletin board to an intranet. For example, we support a relatively small house builder with 30 employees, where everyone in production now has a smartphone. The bulletin board is being replaced by an intranet based on SharePoint Online.

Larger customers often have several projects, such as an accident report form that needs to be mapped as an app, or a digital approval cycle that used to go through the company in paper form and is now done digitally. The result is a log that is stored in the SharePoint library. We sometimes do eight or nine projects like this for customers.

How long does it take to complete a digitalization project?

For smaller processes, such as the implementation of a single application or a digitized circulation system, the time-frame is usually fairly predictable. Depending on the size of the application or process, this can be done relatively quickly with coordination, setup and testing in about two to twelve weeks. It’s important to note that we don‘t work continuously on the topic during this time, as feedback and self-testing from the customer takes time. You develop something, fine- tune it, and implement it. Then there’s a bit of support and the process is complete.

The situation is different with large projects like a Microsoft Teams rollout. A project like that touches basically everything that happens in the company. How do we collaborate? How do we manage tasks? How and where do we communicate? What devices do we use? Such projects also expose how open the company’s communication culture is.

Change takes time. It can’t be limited to a year or two, especially with constant updates from Microsoft. A lot of communication, training, and knowledge transfer is required at the beginning. Ongoing change management is also required, even if the level of support decreases over time. The customer should be aware of this before the project starts.

»The primary goal is always  to increase efficiency or simplify an application.«

What are your customers‘ main goals when implementing or changing software?

The primary goal is always to increase efficiency or simplify an application. Efficiency is key, whether through processes that simplify an application, increase the response rate, or improve reliability. Workers in the field don’t walk by the bulletin board every day, they need a push notification on their smartphone to receive new jobs.

Cost savings and getting the most out of your licenses are also important. For example, when you license Microsoft 365, you typically have a package that includes Power Apps, Power Automate, and SharePoint Online. This package already provides a solid foundation that can be used for an intranet. You should take advantage of this option.

In other words, these projects aren’t primarily about digitalization for the sake of digitalization?

Not necessarily, there’s usually a specific problem or challenge. For example, we recently digitized an approval cycle for budget requests. The previous paper process was very error-prone. It required six to seven approvals at different stages. This was done using a paper form that was carried around the company. We tracked the process over a fourmonth period to see how long it took. The average was 21 to 24 days. It also confirmed that the request often never made it to the planning office or department. By digitizing the process, nothing was lost and the turnaround time was reduced to three days. This automatically reduces costs because there are fewer opportunity costs.

How and when do you need to inform and involve your stakeholders about the upcoming project?

Ideally as early as possible, at least with an announcement that changes are imminent. Ideally – depending on the situation – let stakeholders have their say. It makes little sense for IT alone to decide to digitize a process. It has to be coordinated. This means that functionalities are more often questioned critically: is a function absolutely necessary or rather nice to have?

Questioning functionality is also important when digitized processes are already in place and are to be replaced by another tool or brought onto a standardized platform. Even in such cases, it may not make sense to adopt a process one-to-one because it may not work well or user feedback may show that the interface is too complicated. The only way to find out is to talk to stakeholders as early as possible.

Is there a set process to follow for these projects?

We believe in an iterative approach. We always start with an analysis where we look at the current situation and then capture ideas and requirements. That’s a lot of work in the beginning, but it saves a lot of time during the actual implementation. It gives us a clear understanding of what the customer really needs. It’s best to document not only the actual process, but also who’s involved and what permissions are available. Where do emails or general notifications go? Who works with whom? Who can see what? Who shares what information? This creates a documented profile of the project. It doesn’t necessarily mean that you end up with an 80-page document. It’s more about creating a foundation and a common understanding.

Before an implementation starts, there should be a dialog with the users and, if necessary, a test. Our experience shows that frequently there are changes that need to be made during implementation. Therefore, it’s important to have an early dialog with the users and to conduct tests. If the implementation is completed without testing, there are often many aspects at the end that the users had imagined differently.

»The biggest challenge in planning and implementing software is people, because they define the requirements.«

For example, interfaces can be tested with mock-ups, which is relatively quick. Intranet structures can be developed and tested with card sorting. The specific testing method depends on the size of the target group. For example, if the target group for an intranet is 18,000 employees, it’ll be difficult to give everyone a say. A survey might be helpful. It’s best to select a small group of users, multipliers (champions, power users, key users), and editors, mix them up a bit, and ask for feedback.

What role does management play in the conversion or implementation of software?

Management is needed both to make decisions and to meet management-specific requirements for the software or process. Without management awareness and support, the rest is useless. If we want to digitize a process for a department, but the department head is against it and doesn’t approve the solution, we won’t make any progress.

Management also plays a pioneering role. For example, when introducing platforms such as Viva Engage, management should be actively involved from the outset and present itself as a best practice. You need to approach managers with value-added communication. Depending on the magnitude of the change, it may be wise to offer different formats for managers to illustrate their use cases. For example: if a Teams rollout is planned, managers should be shown how they’ll benefit. Their needs may be very different from those of their employees: How can the tools support or change their management methodology?

What are some of the challenges of implementing new software, and what do you recommend to overcome them?

The biggest challenge in planning and implementing software is people. A classic question we hear is, “Why? We‘ve always done it this way.” This statement doesn’t just come from older employees, as you might think. We also hear it very often from younger employees, sometimes even from interns or students.

To meet this challenge, employees need to be involved. Learning and communication styles are very different. That must be taken into account in order to meet employees where they are. Content must be presented in a way that people want to understand and use. 

»In general, change management is a marathon, not a sprint. So don’t invest energy in a group that doesn’t want to change.«

Some people are more visually oriented and read content on the intranet or a help platform. Others are more auditory and rarely use the intranet. Different channels need to be used, which requires some training. But it has to be appropriate. If I’m introducing a particular application that four people are using, I don’t need to use five different training methods to explain it.

In other words, the biggest challenge is the human factor and not the technical implementation?

Yes, the technical implementation is ultimately a question of budget. Almost anything is possible. The challenge is people, because they define the requirements. This is illustrated by the example of Microsoft To Do. It started with a limited set of features. It evolved through user feedback. What’s positive for many people bloats the application with unnecessary features for others. You should never lose sight of people when developing the solution. Most of us probably never use more than 10% of Excel’s features, and only a very small percentage of us take full advantage of Excel. Therefore, a design with advanced menus and similar features is very helpful, instead of presenting all functions directly and thus overloading the user or giving the impression of a complicated tool.

How can resistance to change be identified early? How does it manifest itself?

Which brings us back to my favorite statement: “We‘ve always done it that way.” But it’s not always that obvious. Sometimes there are people who insist that certain features must continue to be available, that things used to work with one less click, or that the interface used to be nicer. Such insights can only be gained by sharing—how exactly depends on the size of the group. For example, you could conduct a survey asking about pain points or requirements. If there are a lot of pain points or requirements that are specific to the current software, then you know the replacement isn’t going to be a cakewalk.

Is there a risk that such a group of sceptics could be a threat to the entire project or a source of doubt for other employees?

It depends on the size of the group. In our experience, the group often tries to sort it out internally, which is usually very helpful. It also depends on the composition of the group. If it consists of C-level, top management, and middle management, the project will fail. As mentioned earlier, change cannot be implemented without management support but it also needs actual users’ buy-in. However, if only a few users are against it, the project can still be successful.

How should you deal with resistance and what are some strategies for overcoming it?

Communication is everything. You have to engage people and show them tangible value. But that doesn‘t work for everyone. There’s a rule in change management that says that 10 to 20 percent of the people in volved are “opponents”. You have to ignore this group and focus on those who want to change. You mustn’t dwell on the fringe. In a Teams rollout, there will always be people who don’t want to move to Teams and will stay on the old platform as long as possible. But experience shows that most of them will eventually come around.

In general, change management is a marathon, not a sprint. So don’t invest energy in a group that doesn’t want to change.

Are there any warning signs that you should refrain from deploying or converting software?

My gut feeling has proven to be a very reliable indicator in the past. If we find in the first meeting that the processes and decisions in the company are very cumbersome and there‘s little progress, then the projects usually don‘t go well either. In the worst case, we conclude that the company isn’t ready for such a project. Another warning sign is when people can’t clearly tell us what an improvement or the target process should look like. In such cases, the project often turns into a never-ending story.

What causes project managers to be demotivated?

One possible reason is that projects are decided and delegated from the top down. Lack of motivation can also be due to someone simply not wanting to work on the project. This may not have anything to do with the project itself. It may be that the person is already involved in many projects and has no resources or capacity left. It may also be that the added value isn‘t clear to those involved in the project. Which brings us back to communication. It must be clear why something is being done before the project starts. Otherwise it’ll be bumpy.

What’s the best way to motivate employees to embrace change? What training and support should be provided?

It depends on the context. We often work with so-called champions, key users, or multipliers. They receive special support in the form of updates, innovations, or even pilot tests in which they can participate. In return, these people also take on responsibilities, for example in the area of knowledge transfer. They often act as ambassadors.

Depending on the customer, there are also incentives for this group in the form of champion events, where knowledge transfer is combined with socializing, for example over a meal. This practice has proven to be very successful, but there are other types of incentives as well.

What are the incentives?

One of the hottest topics right now is gamification, the playful transfer of knowledge. It doesn’t have to be complicated or expensive to implement. Let’s take IT security as an example: it’s often enough to post a question in an intranet article, and the first 20 people to answer correctly can win something. Then we prepare small gifts related to the topic, such as a keychain with a small flashlight or an emergency blanket. It’s not about doing big things.

Another way to introduce a new tool is through a challenge. Much like a postage stamp, employees earn points by posting a profile picture, posting their own post, or liking a colleague’s post. These points can then be redeemed for prizes. This motivates employees and makes them familiar with the tool. We’ve always received very positive feedback from such campaigns.

How do you measure the success of software rollouts or digitalization projects?

Very good question! We could spend hours discussing this. On the one hand, Microsoft provides a dashboard that gives you direct metrics in the form of usage statistics for the Microsoft 365 environment. It allows you to look at success from a technical perspective. On the other hand, there’s Power BI, which creates reports that can be easily downloaded. However, this requires a Power BI Pro license. Its “dry” data can tell you how many chats were held, how many emails were sent, how many phone calls and Teams meetings were held, or how much storage space was used. But those numbers only tell you so much about how people actually use the tools.

To find out what users are missing, there’s no way around a survey. A baseline survey is conducted before a new tool is rolled out. This is repeated periodically to measure progress or change. Questions are grouped by tool or process, depending on what’s being introduced. With a time horizon of two years, at least three or four surveys should be conducted to validate the baseline measurement. They will help determine if users are getting comfortable with the tool and know where to find features and content.

Which metric or KPI is most important to you?

I find user statistics very interesting, but they aren’t the most important numbers to me. They can sometimes be misleading. If I see that the amount of data is increasing, I might assume that everything is working fine. In reality, it could be that more and more files are being stored with version 1, version 2, version 3, etc. instead of using versioning in SharePoint Online or OneDrive.

For me, the most important thing is the security of the tool. This can only be determined by asking users detailed questions. That way, you can make sure they really understand the benefit or use case behind the tool. During a Teams rollout, we often hear customers say that everything worked perfectly and that everyone is using the tool. When we ask for more details, they often say: “We use it to chat and make phone calls.” That alone isn’t meaningful. If someone is chatting instead of writing a two-sentence email, they may have made the connection, but they don’t necessarily understand the functionality of Teams. For example, documents are often saved in Teams, but co-authoring or automatic saving isn’t used.

What does corporate culture mean to your projects and how can it be taken into account?

The feedback culture is critical. Even if we start the project with active communication, we’ll only get 12 to 20 percent response in surveys if there’s no active feedback culture. Then we have to think about how to change the situation to get the feedback we need.

What about companies that have worked primarily with analog technology and/or have many older employees?

If a company’s work has been predominantly analog, but there’s an active communication culture, no special effort is usually required. Employees are used to communicating and only need to change the tools.

However, if a company communicates little and doesn‘t work across departments, crossdepartmental projects can be difficult. For example, implementing an intranet requires the IT and communications departments to work together. Although these departments already communicated with each other before the change, they now have to actively share information and engage in dialogue. The result is much more transparent communication, but it has to grow.

»There’s a quote I like to use:  “Ever tried. Ever failed. No matter.  Try again. Fail again. Fail better.”  The most important part of any project is just getting started.«

Do you have a final tip for anyone who needs to plan and implement a change project?

There’s a quote I like to use: “Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.” The most important part of any project is just getting started. Of course you need a plan and structures. You need to think about the audience, the processes, the people involved. But most of all, you need to get started. Because collaboration starts in the mind, not with technology.