It’s an echo from a bygone era: just say no. It’s become part of pop culture and in certain respects has taken on an irreverent mocking tone. Nevertheless, the underlying sentiment is well intentioned: don’t do things that you know are destructive – in the world of package software this is also true. When faced with a decision about whether to customize the software instead of changing something else to fit the capabilities of the software it seems like an easy choice, say yes to the customization and keep moving forward. However – to trot out another cliché – the road to hell is paved with good intentions. Saying yes in the short term seems like the right thing to do and feels good, but in the long run can be a poor choice.
Why it is hard to say NO
The obvious answer is that saying yes is easy. After all, saying yes gives people what they want and rapidly sets a direction. Yes is water flowing downhill, it is the path of least resistance, although water doesn’t care whether it fills the reservoir or floods the town.
You’ve probably heard stories about how saying yes to everything a child asks for leads to an unhealthy sense of entitlement later in life, let alone the immediate tantrums when you try to say no. On top of this, not everything that they ask for may not be in their best interests. It takes fortitude, will power and frankly some stubbornness to say no when a child is having a meltdown in public.
On some level this is what happens when a client who has bought package software insists on making modifications or customizations. They are asking for something that in the long run is going to have an undesirable outcome.
Now, I implore you, dear reader, to cut me some slack here. I am not saying clients are like small children with poor impulse control. What I am saying is that those impulses can lead to a bad place and it is our collective responsibility on a project to manage those desires and make sure any modifications and customizations are done for the right reasons.
Assume the Answer is NO and Proceed from There
My colleague Cehunt Duong wrote about the value of staying within the confines of standard software capabilities and described many impacts from deviating from delivered functionality.
Intellectually these reasons make sense, but getting a project to buy into a standard solution can be a challenging task. Here are some of the obstacles I’ve encountered and potential solutions. As you read these it is worth remembering that the solutions are not necessarily meant to be easy.
- Challenge: If we use standard delivered functionality we become just like everyone else who runs SAP
- Response: companies are usually the same only at the most superficial level in that they provide goods and/or services, but once you get under the covers no two companies are the same. Each has its own way of operating, organizational structure, values and culture that combine into the “secret sauce”.
- Challenge: we need to do it this way, we’ve always done it this way
- Response: The purpose of a project is rarely, if ever, to recreate the existing systems and processes on a new platform. People can be trained to use new tools, systems and processes. Learning can be painful, but it is going to happen anyway. It’s better to be actively involved and – cliché alert – be part of the solution. Come to the table with business knowledge and an open mind focusing on what the solution needs to do, not how it does it
- Challenge: we need to do it this way, it is a competitive advantage and a differentiator in the marketplace
- Response: now we’re on to something. Whenever possible the competitive advantage needs to be tangible, specific and measurable. This is something you want to hold on to and need the new solution to deliver. Still don’t be intransigent and too emotionally attached, be ready to back up this position.
- Challenge: I don’t like the way SAP works
- Response: Frankly not many people like the native SAP GUI, but these days a lot can done with Personas, Fiori, portals, Lumira, such that it becomes a question of project priority and budget. Earlier project discussions should have covered what the solution needs to do, whereas this is addressing usability and how the solution works. Being closely involved with the solution and some good UX design can work wonders and ease adoption.
- Challenge: we had this situation that happened a couple of years ago, it was bizarre, a strange combination of circumstances, up all night fixing it, it hasn’t happened again since but we need to be ready for next time
- Response: that’s a good war story but it needs to go up against a likelihood test. It hasn’t re-occurred, there have probably been system changes since and it didn’t highlight a shortcoming in the legacy systems requiring major overhaul. It was a one-time event. It is doubtful that it is worth customizing the solution for an event that is extremely unlikely.
Getting Comfortable with NO
It is important for a project to be able to evaluate requests for changes to the core software and mechanisms to support saying no. Here are a few suggestions.
- Make it clear across the organization the default answer is NO. Explain there are no free lunches and that requests are evaluated looking at both short and long term impacts.
- Set up a formal review process:
- Make it an impersonal process to manage emotions and positional authority
- Create pre-defined evaluation criteria
- Make it evidence based
- Communicate outcomes
- Recognize transient issues related to the decision compared to the long term or permanent impacts. For example, training is a transient issue, whereas core software changes are not.
- Practice: don’t be afraid to say no and force teams to go away and develop alternatives.
Learning to say NO can be a difficult cultural adjustment, making it easier and socially acceptable is a hill worth climbing.