Ask any master woodworker what the most important skill is in woodworking. The answer won’t have anything to do with saws, chisels, or hand planes. It won’t be about design, planning, or building. The most important skill is fixing their mistakes. Master woodworkers will saw outside their line, they’ll have an errant hit with a chisel, they’ll ding the corner of their piece. They all make mistakes. Great woodworkers, however, know how to fix their mistakes.

It’s not the building that makes the masterpiece - it’s the fixing.

When the System goes Wrong

You’ve done it. You built your business case, selected a tool, and spent months implementing. You went live to fanfare and praise from the executives. Hooray! Now, a year later, you’re not seeing the ROI you expected. There are system issues, low user adoption, and you are not realizing the benefits laid out in your business case. What do you do?

Enter Remediation

Now is the time for remediation. Remediation is the fancy term for “fix the problems with the system”. It is inevitable that any S2P solution - any software system - will have issues. In an implementation spanning many months, it is inevitable that something will be missed.

Let’s talk through when it’s time for remediation, and what you can do to ensure it’s successful. Like the master woodworker, now it’s time to fix the mistakes.

Before Remediation

After you go live, you should keep a record of any user complaints, system issues, and user praise. When an issue comes in, capture it, via a ticketing system, a shared inbox, or even an Excel sheet. If your admin can fix it, then fix it. However, some issues require a heavier lift, either from a technological, organizational, or configuration standpoint.

You should track:

1. The Issue – descriptions, steps to reproduce, etc.
2. The frequency with which it occurs
3. What the impact is

When remediation kicks-off, having a well-defined list of issues, missed requirements, and user complaints will be key. This list will be much more valuable than relying on your core team to identify the issues with the system. We’re looking for objectivity here, and a list of user feedback will be key. You can’t fix the system if you don’t know the problems.

You’ll notice I also mentioned user praise. It’s important to fix issues, but it’s also important not to screw up what users love. User adoption isn’t just about forcing use of the system - it’s about creating a system that users want to utilize. People don’t use Amazon because they must - they use it because it’s easy, and it does what they want.

When is it time for Remediation?

Now we come to the first of many decisions that must be made during the remediation lifecycle - when is it time to start? I wish I could give you a precise metric - like “when user adoption drops below X%”, but it’s just not that simple. You should consider your business case, your users, and your needs.

There are 3 factors that almost always drive the need for remediation:

1. Low Adoption
2. Low ROI
3. Implementing a new module

Low Adoption: Your users just aren’t using the system. The issue isn’t that you didn’t tell them about it. It’s not that you’re not requiring them to use it. The issue is that they don’t like the system. It’s buggy, or confusing, or annoying. The fix for user adoption is simple: make the system easy to use.

Low ROI: This usually follows low user adoption. If your employees aren’t using the system, you cannot capture ROI. You may also have to look at your configuration. Are you letting all your invoices pass through? Do you not have the right people approving requisitions? The S2P system is great, but if it’s not designed correctly, it won’t stop rogue spend.

You’re implementing a new module: It’s not all doom and gloom. Even if things are going well, you may be implementing a new module. In that case, it makes sense to treat it as a remediation project and not a new implementation. Many of the principles of remediation apply (most notably, do no harm), and you will do well to include an implementation partner that has experience with remediation.

Guiding Principles

Now let’s talk project principles. Any new project should have a project charter - defining what the goal is for the project, and the guiding principles that will drive the team behavior. A remediation project is no different; however, there are some additional principles that should be considered.

1st Principle: First, do no harm.

It’s part of the Hippocratic oath (actually, it isn’t, but it’s still a good phrase, so we’ll pretend it is), and it applies here as well. Remember, we captured all the user praise in addition to their complaints. Well this is the time to use it. If users love the workflow for entering requisitions, but they’re burdened by unnecessary approvals, then you better not to touch the requisition entry procedure. Said another way, keep what works, change what doesn’t.

2nd Principle: Regression testing.

Okay, this is really just a follow on to the first principle, but it’s important. You must ensure that you didn’t break anything while you were fixing something. The level of regression testing you will need will vary, and it’s a case-by-case discussion. We’ll discuss this in more detail below.

3rd Principle: Communicate. Communicate. Communicate.

Step 1: Listen. Communication is often used as a synonym for “send overly wordy e-mails to the company wide distribution list that 80% of employees have set to auto-filter to the trash”. But communication is a two-way street. The first step to communication is to listen to users. They are your customers, so listen, without judgment, to what they have to say.

Step 2: Act. Take action on what your users have to say. Fix the system, and if you can’t, take note of why you can’t. Ask for feedback as you go.

Step 3: Tell. Now that you’ve taken action, tell your users what you did, and why. They’ll be happy to know they’ve been heard, and your system will improve.

Now, repeat the cycle.

Elements of a Successful Remediation

There are certain elements that should be included in a remediation project to improve the odds that the project is successful.

Gather System Experts: You will need a team of individuals that know your system. You need someone who can answer the question “why was this custom field created?”. You can’t fix the system if you don’t have a firm grasp of how it was built. In that same vein, gather all the documentation from your original implementation and any follow-on work.

Well-defined requirements: We’ve discussed this before, and hopefully you’re getting how important this is. As Lewis Carroll said, “If you don’t know where you’re going, any road will get you there.” The problem is, “there” isn’t always where you want to be.

IT/Integration/ERP Experts: Inevitably, changes will impact your ERP integrations. You will need experts on hand to assist with updating your integrations so that documents get where they need to go. And by the way, many remediation projects also tend to end up fixing integration issues - even more reason to make sure you have the experts on hand.

A partner who has done it before: Remediation isn’t simple. There are hurdles you’ll face, problems you can’t anticipate, and inevitably, you WILL break something. It makes sense to work with a partner who has been through this process and knows how to jump the hurdles. Many firms can handle a fresh implementation, but not all of them can handle the special challenge of remediation. Pick your partner carefully.

{{cta('b5a69d54-0671-4cae-8749-203341234ac0','justifyright')}}

Testing Guidelines

I promised we’d get to testing. The number 1 question in remediation projects is “do we need to do regression testing”.  The answer is almost always “Yes, but not as much as you think you do” (The real answer is “It depends”, but everyone hates that answer). The only way to verify we’ve done no harm is to prove it through testing. The level of remediation that is necessary depends on what changed.

Did you move from an outdated integration method to CIG (Cloud Integration Gateway)? Then you should do a full regression - you must ensure that your documents are flowing with the right data.

But what if you haven’t touched the integration? Your core team should still do some testing to ensure nothing has gone wrong, but you don’t need a full regression. What is important in this case is Quality Assurance testing (QAT), and User Acceptance testing (UAT).

QAT and UAT exist to answer two important questions.

Quality Assurance Testing: Did we build what we said we would build?

User Acceptance Testing: Does the system work for our needs?

We’re making the system better for users - so we need their feedback. If I went into the principles of testing here, it would consume an entire additional blog post, but just remember the following rules.

1. If you touch integration, you need regression testing
2. If you touch the system, perform QAT to ensure you built what the core team was expecting
3. If you touch the system, perform UAT to ensure users are happy with what you built

The implementation of any tool will end up with some issues. Missed requirements, misunderstood needs. Even a perfect implementation has a shelf life. New requirements arise, and the system needs to change to meet them.

Remediation isn’t an admission of failure, but simply a recognition that needs change. Modern organizations must change to meet their evolving needs, and that includes updating the systems that drive their world.