Top 5 SaaS Implementation Risks: #2 Decision Making

Ellen Loughrin Photo

“Which is best? A or B?” When this nonsense question was first asked of me in my youth my immediate and firm answer was “or”.

Decision making has never been a problem for me.

Today I’m a Project Manager implementing SAP’s SuccessFactor product with clients from all around North America and the Caribbean and how well my clients can make decisions can determine our project’s success in terms of time, cost and scope.

I’ve been writing about what I feel are the top five risks to SaaS implementations. Last time we looked at the Beginning: Procurement to Implementation Buy In. Today I want to look at Decision Making and how it impacts the very essence of our implementation projects.

Deciding Whether or Not to Look at Decision Making

Once, when I was working as a corporate trainer, I was asked to create a curriculum for development of the company leadership. One of the first course I proposed was “Decision Making”. They decided not to have a course on decision making. Why? I was told that they already knew how to make decisions. True…decisions were being made. But I wondered if they knew how they were making their decisions.

To me it is all about being intentional about understanding the decision making process. Anyone can make a decision as I demonstrated in 1979 with my pithy “or” selection. But to have an understanding and an intentionality of decisions so as to anticipate the effect of a decision or the efficiency of the decisions…well, to me that is a learned skill.


When we kick off an SAP SuccessFactors implementation project the lead technical/functional consultant and I like to meet with our client implementation team (ideally in person) and spend one to three days reviewing requirements and introducing the Configuration Workbooks—electronic documents that capture the myriad of decisions that are about to be made. SAP’s SuccessFactors is a highly configurable product. That means that there are A LOT of decisions to be made. A lot of What do you want the system and process to do? When do you want it to do it? Who do you want to give the ability to see each part? Edit a field? Move a workflow along? Decisions, decisions, decisions.

And these decisions need to be made in the time frame of the project and methodology. To do this a client organization’s implementation team needs to be prepared to make hundreds—if not thousands— of decisions over a finite period of time.

What does readiness for decision making on this scale look like?

Intentional Decision Making

When I wanted to create a Decision Making course for leadership development I did a bit of research and found that there were many models and theories of decision making—almost so many I couldn’t decide what I liked best. At the same time I was fortunate enough to go through Vital Smarts’® Crucial Conversation® course. This conflict-management course contained an engaging section on decision making that resonated with me.

It identified several methods of decision making. What the methods were was not as important to me as the realization that there are multiple decision making methods and leaders and teams need to be intentional about the one or more method they will use. When you are implementing your project, will the team employ a “command” style where one or more persons are empowered to make a decision with optional consultation with others? Will the team “vote” to decide—with a certain percent of majority deciding? What are the expectations of the team when a decision is to be made? Are they expected to consult any specific stakeholders? Are they empowered to decide as a team? Is one individual empowered to make the decision? Alone? After consulting with team members? The best advice I got from the course was to be clear on how decisions are being made with everyone before you start.

Document Decisions

Fortunately, the aforementioned Configuration Workbooks are designed to document implementation configuration decisions. Therefore, it is essential to be clear on who is to document these crucial decisions. Should the team? A team member? The consultant? Different methodologies of implementation do this differently so never assume what the approach is. And, no approach is wrong or right, but being clear who owns the documentation of the decision is critical. Never plan to “remember” what the decision is—document it.

Time is Money

I’ve seen project timelines experience costly extensions when decisions were not made per the agreed to project timeline. Initial decisions were not made or were frequently undone beyond the agreed to date. A couple of dynamics can be anticipated to help prevent these costly schedule slips.

I’m going to take us back to my last posting where I spoke of my informal mentor, Dr. W. Edwards Deming and his “14 Points on Total Quality Management”—specifically #8. “Drive out fear.” Team members experiencing organizational fear will not be able to effectively make decisions and stay with them. If they cannot trust that they have been equipped and empowered to make decisions that will be supported by those who have entrusted the job to them there will be costly delays. In a fearful environment projects are doomed to exceed all timelines with costly overruns. The decision maker(s) need to be both equipped and empowered to make decisions.

And here is the good news. This SAP SuccessFactors SaaS product is a configurable product. Configuration decisions can be changed. Yes, some decisions are more costly to modify than others, but many decisions can be modified by ever more powerful Administrative tools for the client System Administrator. Making an early effort to identify skilled System Administrators and having that person or persons be part of the implementation to understand and confidently manage changes later can decrease decision making anxiety and empower decisions through the implementation.

I also suggest that, beyond equipping your System Administrator, your implementation team and stakeholders make a plan on how you are going to collect suggested changes after you are in production, how you will analyze these changes, and when and how often you will modify your system. Get your Change Management plan under control before you go live and you can make implementation decisions with confidence.

Decide how you are going to decide and you can mitigate this risk before you even get started. Decidedly.

I welcome your comments or even a chance to chat…please reach out to me via LinkedIn if you would like to connect. Ellen

Get Started

Let Us Know How
We Can Help.