Deploying SaaS software? Here’s what you need to know

This month at WNDYR, we’re talking about change. Read why we believe adapting to change is a crucial skill set for the future here.

I spent some time recently thinking about the recurring pain points our clients and their teams experience during the deployment of SaaS software. Some have been known to verbalise their concerns, defining it specifically and vociferously during the transition while others are vague, unaware or disengaged. Very few, despite great attitudes, intentions and/or leadership, feel fully prepared to embrace the impending pain that is so deeply associated with shifting from what we know today (regardless of its efficacy), to the unknown of what could be.

While waiting for the WNDYR team and partners to get back to me with their ‘from the trenches’ thoughts on the topic, I happened to stumble across three things. Perfect timing!

1. A new word
2. A new approach
3. A simple diagram of the change continuum

LUDDITE, a new word

Luddite:  someone who resists technological change. Spanning back to the industrial age, it’s not a ‘new’ word, but it’s new to me. Zooming through to modern day, the shift to SaaS in the mid-1990s and it’s more recent boom as a model of success has proved itself popular. Companies, regardless of their size, find themselves with multiple disparate technologies causing work to become even more fragmented than before. Add to the mix, long hours, tight delivery deadlines and the threat of being replaced by a robot, I can understand how the fear of adopting new software, despite being necessary to remain competitive and relevant, conjures up a mass of resistance.

A NEW APPROACH

One of our consultants shared an image in our chat stream that made me smile. Her client is currently onboarding a new project management tool and had been asked to track the pain points during the process. Right at the beginning of their onboarding journey, 75% had their sticky note positioned in the ‘severe/moderate pain’ sections with the remaining 25% selecting ‘minor pain’. It’s our team’s job to work collectively with the client to shift them to a place of comfort in the quickest time possible and we’ve become experts at doing this. This image provided the visual evidence of the initial reactions to adopting a new software. The pain is real.

CHANGE CONTINUUM

With change management being an ingredient infused into our onboarding process, we are not strangers to the science behind change, resistance to buy-in (of various degrees) and the cycles we see our clients and their teams go through during the process. I found this simple image on Mileorate which I thought explained the situation well. In my opinion, knowing what to expect is half the battle won with the ROI being exponential.

THE BIGGEST PAIN POINTS WHEN DEPLOYING SOFTWARE

Digging into the weeds with the team revealed a consistent themes in answer to the question, What are the biggest pain points your clients experience when deploying software? I’ve grouped the answers together in order of frequency for ease of reference.

1. Not enough time. The amount of time required in setting-up, learning and getting up and running with new software is a massive mental and physical barrier to most teams. Multiple activities, emergencies, issues and day-to-day work is enough to deal with, without having to onboard new software. The daily grind makes it a huge challenge to invest physically and mentally during the early stages of the project. Looking at the change continuum above, you can easily see that early stage resistance is normal and expected. Pushing through however is imperative to success. Leadership buy-in supports this shift.
2. Management buy-in. This needs to be both a top-down and bottom-up approach. If the software is mandated without getting buy-in from people (think about what’s in it for them), you can expect to experience resistance and lack of commitment when it comes to planning schedules and adapting to tight time constraints. Without senior management buy-in, it’s equally difficult to prioritise driving software forward resulting in more pain from another system that’s not effectively utilised.
3. Misaligned expectations. It’s not unusual for expectations to be misaligned on multiple fronts resulting in frustration.
   1. You may have expected your team to be onboarded within a nanosecond without understanding there’s a process involved to ensure time to value.
   2. Even if the process is known, your team may well feel that everything should be perfect from the get go, and become frustrated when it’s not.
   3. Thirdly, it’s believed that the software will be able to deliver everything you ever imagined vs a defined set of problems.
4. No plan B. Diving in is one thing, changing behaviour is another. Adopting new software, despite even the greatest intentions, could find people slipping back into default behaviours, especially when pressure hits. This is normal and should be expected. Planning for it however is a way to mitigate the project from derailing.

There is a lot to ponder in the mission of less pain, more gain. Working with a success team will, can and should help navigate through short-term pain, lay foundations and build buy-in for long-term gain. This is where the sweet spot lies; a strong vision in WHY we’re doing what we’re doing, a dedicated team who pushes through till acceptance and ultimately confidence, and a phased approach with realistic milestones and managed expectations.