Organisations are seeking ways to refine budgets for digital transformation programs, and are seeking ways to accelerate the time it takes to implement or upgrade systems compared to what was typically set out for projects five years ago.
This is increasing the prevalence of two things:
1. Vanilla implementations.
2. Aggressive program timelines.
So how does this change the way we roll out technology to our people?
The combination of these two factors puts huge pressure on user adoption programs, which need to be looked at differently.
Firstly, an out-of-the-box vanilla system will always require an organisation to change the way they operate more than if a significant system customisation program is undertaken. From an end-user perspective there is no such thing as a vanilla system. It’s just the system.
This means that there is more onus on business process design and user adoption, which need more consideration, but equally these programs reduce the technical effort required – thus shortening the time frames of the project.
Which leads us to point two.
There has been a conscious and significant reduction in the timelines planned to undertake digital transformation programs over the past five years. This aggressive approach can pay off by costing down projects and stopping the bleed of project overruns, but it can also impact the organisation’s ability to be fully prepared for the change and take full advantage of the benefits.
In some cases, the desire to ‘chase a date’ can override the desire for a perfect solution. We are seeing business process design happening later and later in project cycles - and in the case of ‘chase the date’ scenarios – we have even seen projects go live with no detailed business process design or documentation at all.
The issue is that the process design is the most integral part of any adoption program and is the foundation from which the organisation can actually embed the change.
As a result of these current trends, there are more and more immature processes and immature system builds compared to what we were seeing five years ago.
From a user adoption perspective, traditionally we have tried to comprehensively prepare people for a go-live by providing information and training around the future state. We would look at what the change would mean for people, how their work would change from a process perspective and how they would use the system in the future state.
Typically, in the lead up to go-live, time would be spent preparing and deploying learning that supported the change, whether it was classroom-based training, eLearning, or any other form of training. By the time go-live came around, people would be well prepared to do their job in the future state. There would then be some support and transition to BAU activities, to make sure the business is up and running, with backup from user support material developed in the lead up to go-live.
However, there are a number of critical dependencies to enable this to happen, including system readiness, business process design and understanding of who will do what (largely driven from process design).
Consequently, it is impractical to use this strategy on most current digital transformation projects and, to be honest, it can become a bit of a waste of money. New ways of approaching user adoption need to be undertaken and, on the most part, a drive towards learning being embedded through various strategies after go-live is the way to go.
This is part I of a two-part blog post. Part II looks at developing effective user adoption strategies.