Think Twice if You Hear yourself Say or Ask One of these Statements or Questions

When working with a client, there are a handful of phrases or questions that I’m on the lookout for. None of them are true red flags, they’re not bad or wrong to ask, but over the years they have become more of a yellow, caution flag that we need to dig in a bit. In this article we’ll go over these and identify where they come from and how to get at what you really need.

1. “What is ‘Best Practice’?”

On the face of it, this is one of those questions that sounds like it’s coming from someone who wants to focus on doing things the right way. Unfortunately, and without intent, it’s very rarely being asked for that reason. “Best practice” is one of those terms that gets thrown around like it’s gospel. It truly does have real meaning and a benevolent purpose, but it’s very easy to treat it as a catch all or a cop out.

The truth is that it’s a misnomer. Best practice isn’t one size fits all. What is best practice for Company A may completely cripple Company B. There are certain aspects where there really is a best practice, such as maintaining GAAP accounting practices and system audibility. However, most areas of a system require that a fully thought out and vetted process is completed before determining your “best practice” for a given process.

If you find yourself asking this question, take a step back and ask yourself these instead, to get to the question you really need answered:

• Do I fully understand how we are accomplishing this today? Can I describe our process step by step?
• Is our process prone to workarounds and ambiguity that lead to low quality or untrusted data? (What are our current challenges?)
• Is our process completed outside the system?

Answering these gives you the ability to dig into what you actually need to fix to make the process better. “What is best practice?” will get you a boilerplate answer to how the system thinks you should do it, or what has worked for your consultant in a particular situation in the past. Based on subtle differences in your process, this can lead to heartache and inefficiency down the line when implemented.

2. “We don’t know what we don’t know.”

Over the years I’ve heard some of the smartest people I’ve met say this. It’s not a bad statement, and it’s obviously true. Why it raises the caution flag is similar to the reasoning behind question number one, but it goes deeper in its generality. When I hear this phrase, I pump the brakes and ask a few general questions.

• What overall challenges are we experiencing in the business today?
• Are we getting good and actionable data?

• What processes or areas of the business are:

  • Slowed down by process or data entry
  • Informational black holes
  • Prone to inaccuracy in reporting

With these questions answered, we now have directionality instead of generality. Business systems are big, complex applications and there’s no way for you to know every nook and cranny—and there’s also no need unless you want to be a consultant. (And even after 25 years in the field, I still learn new things!) “We don’t know what we don’t know” doesn’t move the needle for your business. Focus on the challenges, the things you do know. Then collaborate with your consultant to eliminate those and actually move the needle.

3. “We need to be agile.”

Sometimes this is worded as Company Name-Fast! This can be a key indicator that there are process issues and potentially a lack of business maturity or system readiness. Not always, but when a business leader tells me that they are afraid of losing their ability to do things fast or “turn on a dime,” it’s usually a sign that one of two things has occurred:

• High and unplanned growth, either in a new market or a startup company
• A company that has been through a growth period and band aided their system together with a lot of external processes

Neither one of these is bad. Growth is great, but it comes with lessons and the need for tighter and known processes. If the choice is to learn from these lessons and build for the future, that’s great. If the desire is to just trust that you’ve always found a way and continue with current and painful processes, that’s going to be problematic down the line.

With good process and the right software selected, agility is natural. While there is effort up front, it’s far less than the effort needed down the line. In reality, it's inevitably slower, to keep the principle of “Company-Fast!”

4. “We’ll fix that after go live.”

This one comes up a lot, especially late in an implementation. It’s typically something found once you get into broader user testing: a forgotten process, key report, or unhandled exception. It’s very easy to drive to a date and shuffle these items to Phase 2 after go live. However, the magical “Phase 2” may not be the right path, and it becomes a far too easy box to shove things into simply to hit a date.

Here are a few questions that should be asked before an item is moved out of scope for go live:

• Is my go live date driven by reality or calendar? Is there a business consequence to shifting our go live that outweighs the consequence of not fixing this issue if more time is needed? 

• Dates are important. They matter. They keep us accountable for tasks and driving toward a common goal. Having said that, the goal is a fully functional business system, and if you don’t get that result, did hitting the date really accomplish anything? Make sure your date has a compelling business reason to accept the consequence of not fixing the issue before shifting it to Phase 2. While they matter, dates are just as likely to have more importance as a KPI than as a true business driving line in the sand.

• If we go live with this issue, is there a workaround that still captures the information we need and allows the affected process to move forward? 

• This is a key question. Some workarounds seem simple on the face of them until you see them in practice. Make sure you understand the full implications and consequences of a workaround… and then ask yourself the first question again.

• WHO will this affect? Does a workaround create excess work on an employee or team? Is that understood by them? 

• Make sure you have the right people in the room when making the decision to move an issue to Phase 2. Is the person who actually has to perform the workaround, or the person who has to deal with the data impacts, in the room or represented? User adoption is key to the success of your implementation. If you lose the team’s faith in the system because it makes their jobs harder, it can be nearly impossible to get it back. We want system advocates, not system detractors, for a successful implementation. Now, ask yourself the date question again—just to be safe.

5. “We’re too specialized for a traditional software.”

This one might be my favorite yellow flag. It often comes from companies that have done things their way for a long time and for good reason. They’ve built a process that works, they know their niche inside and out, and it’s helped them carve out a competitive advantage. The caution comes when “we’re too specialized” really means “we haven’t looked at whether our specialization is process or habit.”

Very few companies are truly so unique that no standard or configurable system can accommodate them. Most of what feels “specialized” turns out to be a collection of workarounds that grew up around old software limitations, legacy personnel preferences, or just the evolution of the business over time. All understandable—but usually not structural.

When you hear yourself or your team say this, pause and ask:

• Is this specialization really part of what makes us better, or just what makes us comfortable?

• Does this process deliver measurable value, or is it simply “how we’ve always done it”?

• If we were starting fresh today, would we design it the same way?

A good consultant won’t try to jam you into a box, but they also won’t take “we’re too different” at face value. Sometimes, you truly do have a one off process that needs to stay unique, and that’s fine. That’s what configuration, and occasionally customization, is for. The trick is to separate what’s truly specialized from what’s unexamined tradition. Once that distinction is clear, the rest of the implementation gets a whole lot easier.