Top 5 Implementation Risks: #4 Wow…That’s Different!

We are now more than half way through my top 5 list of risks that that impact a SaaS implementation project.

Ellen Loughrin PhotoAs a senior project manager implementing SaaS solutions for about nine years—from both the client and implementer perspectives— I’ve created my own list of what I’ve seen both negatively and positively impact project success. To me it is all about being aware of these risks and being intentional in managing them in our projects.

A First Time for Everything

I’m a “baby boomer”…more on the tail end of the spectrum…but I’m one nonetheless. This means that I remember the invention of the Internet, email, cell and smart phones, and a whole bunch of other things that have changed the very essence of my world. If I were honest, I’d admit that I’ve adopted some of these more willingly than others. But in my defense, these were some extreme changes! I was being asked to do things so much differently—and I was not only comfortable at how I was doing things before—I was good at them!

Today I work for a company that has no “brick and mortar”; we are proudly a 100% virtual company. I implement software that my clients are never going to “touch” or host on their servers. I’m still close with my co-workers but our office gossip happens over VOIP calls and not sitting in each others cubicles. Yes, I live in a brave new world.

I acknowledge that my brave new world has made me experience significant changes. So I am compassionate with my clients who struggle with the changes that an implementation of a SaaS solution can present. And if we are the first SaaS (Software as a Service) implementation of a product like SAP’s SuccessFactors in your organizations, then we are going to be introducing you and your organization to a lot NEW and DIFFERENT ways of working, concepts of approach, and a whole lot of CHANGE. The risk now lies in how your organization and implementation team approaches these differences.

Change Management

The field of Change Management grows every day. And it is no wonder as so much is changing and changing fast. And in the midst of these changes are the human beings with human-capacity for change and human responses to the amount of change. In short, it is a lot. And it needs to be managed.

But this is not about change management as much as it is about what changes in a SaaS implementation should be identified and intentionally managed.

On Premise to Cloud

One of the bigger challenges in this area I’ve experienced is technical organizations, who have successfully implemented and run large on premise enterprise software, adjusting to the concepts and skills of implementing “cloud” or SaaS software for the first time. From the concept that releases areautomatically made in the cloud and not installed with on-premise servers to the range of what can be defined in software that is “configurable not customizable” there is a assortment of new ways of thinking and approaching these powerful software solutions. Even the idea of how many instances are used to implement…from the on premise four to the SaaS two (now three in many cases) instances/environments challenges the implementation team’s approach and thinking.

Answers—Just Not Easy Ones

Honestly, I don’t have an easy answers to this set of challenges—I don’t think there are any. But I do think there are answers…just not easy ones.

My first suggestion is to assemble a team that is open to new challenges and ways of doing work. You may place your most competent, but adamant, IT/HRIS person on the implementation team but will this person help shepherd in this new type of technology solution/opportunity? Perhaps…perhaps not. I have seen this situation helped by the change-resistant’s manager or project sponsors being both empathetic to the challenges while also being very clear about expectations for the individual and the project team.

We Have Nothing to Fear but Fear Itself

I’m going to go back to W. Edward Deming (who seems to want to be present in all of my reflections on this top 5 list) and his “14 Points on Total Quality Management”—specifically #8. “Drive out fear.”

In my earlier confession on my reluctant adoption of new technology, I talked about being both comfortable and proud of my competence in the “old” way of doing things. “I was good at them!” I said feeling secure in my competence of doing things the “old” way. And, honestly, I was afraid of looking and feeling less than my old confident self when facing these changes.

For over 30 years I’ve been training adults in corporate settings. One of the first things I was taught in basic Adults Learning Theory is that I have to be very aware of “fears” that create resistance. Adults fear being made to look bad in learning situations (I don’t think children and teens much like it either). Create a situation where a person is feeling competent in one situation and then put those same people in new situations with new approaches and technology and  fear of failurealmost inevitably creates project-tanking resistance!

Again my solution is for the senior management and sponsors of the project to make the situation “safe” for those potentially experiencing fear. Management and leaders need to openly talk about the “newness” and “differences” of this new technology and the implementation and management methodologies. As senior management and sponsors who acknowledge the dynamics and environment of this change, you can create an environment where risk of learning—and not having all the answers—can exist if not flourish.

To go a bit further, senior management and sponsor could request reports and/or presentations on the “differences” of the old to new software systems and ask for learnings and recommendations allowing the experts in the “old” way of doing things to become the acknowledged experts in the “new” way of doing things. Eagerness and a successful implementation may be the results in this intentional and positive approach.


I’ve said it before and I’ll say it again. All projects are “people” projects…it is people who implement the technology. So the most significant risks to projects are people risks. If we manage the people on our implementation teams correctly, we are a long way into a successful implementation and the powerful technology it offers our organizations…and the people who work there.

Hello and thank you for reading this post. I welcome your comments and thoughts. Please feel free to reach out to me via LinkedIn.~Ellen

Get Started

Let Us Know How
We Can Help.