Select your location
Austria

Austria

Czech Republic

Czech Republic

Germany

Germany

Italy

Italy

The Netherlands

The Netherlands

Romania

Romania

Sweden

Sweden

Greece

Greece

Digital workplace migration: how to get started on the right track

3 non-technical risks you need to factor in right from the start

Digital workplace projects often involve some kind of legacy software migration. This comes with a bagful of technical challenges that need to be addressed early on, such as data validation and cleansing, security and application dependencies, to name just three. But there’s also another side to the story, which has nothing to do with technology, and everything to do with people.

In this post, we want to focus on three cultural issues that need to be factored in right from the start. These challenges usually get less ‘coverage’ than the technical hurdles, but turn out to be as crucial in getting your digital workplace project done properly first time around.

Risk 1: Pouring old wine into new bottles

Implementing a new application without changing any of the underlying processes is like taking the motor out of an old car, dumping it into a shiny new body and digitizing the highway underneath it. You lose when you do business the old way with a new system, and you lose more than just money (though that as well). What it boils down to is an unwillingness, inability or fear to take difficult decisions: about business processes or Shadow IT or legacy applications.

Shadow IT and legacy software can never just be wiped off the board in one go. If you can’t offer a (better) alternative, shadow apps will keep popping up. With legacy software, things are more complicated. Sometimes, core legacy applications need to be kept on board for various reasons. This introduces integration and management challenges that need to be addressed. In other cases, legacy software will need to be phased out over a period of time, technically and financially.

What this means is that the ‘new’ and ‘old’ world will need to coexist, for a certain or even an idenfinite period of time, with as little end user disruption as possible.

Risk 2: Taking middle management and IT for granted

When people talk about buy-in, they usually think of the C-suite and the end users, without whose cooperation the project will fail. Very often middle management and/or IT are somehow overlooked or taken for granted, ‘sandwiched’ as they are between these two groups.

And that is strange, since the people in middle management are often the ones who will need to evaluate whether or not the project is successful. If the main goal of a digital workplace project is 20% more efficiency, it will be up to middle management to determine if that is indeed the case. Which is why these middle managers need to be represented in the building coalition.

In the case of IT, it pays off to remember that any project where manual tasks are automated overnight may trigger a defensive reaction. The fear of losing control, coupled with a need to mark ‘IT turf’ can slow the project down considerably and jeopardize a succesful outcome on time and within budget. IT needs to be onboard and all-in. One way of doing that is by highlighting all the other – more challenging and interesting - projects IT will be able to tackle with the extra time.

Risk 3: Underestimating the impact of operational disruption

Operational disruption (such as the inability to ship products or close the books) are common pitfalls of IT-projects, and they have wide-ranging repercussions on the bottomline. Which is why it is crucial to do everything you can to contain or avoid it altogether. One of the tactics is to work with a pilot group on which you unleash and test your approach and roadmap.

Question is: which group or department is best suited to be a pilot? This depends, but it is not necessarily the group where the need for change is most urgently felt, or the department with the highest amount of issues. The willingness to change, for example, is more important than the need to change. That said, these are the characteristics of a good pilot group:

  • not mission critical
  • wants to change and is willing to change
  • has enough leverage in the organization
  • has a certain visibility in the organization
  • has enough ‘weight’ in terms of business processes (not necessarily people)

Conclusion: The technical challenges of a software migration project usually get a lot of attention and coverage online. But as important as the technology, are the people who have to work with it. Paying attention to the cultural issues right from the get-go, gives you a much better chance of succeeding.

More tips? Download our free guide for decision makers.

Digital Workplace Guide