Why PSA Implementations Fail, Part 2

Pay attention to data cleaning lest you build on a weak foundation, and set realistic deadlines. Remember, it’s not done once it’s live — it’s done once it’s all working properly.

July 26, 2018

6 Min Read
PSA, professional services automation
Shutterstock

By Harmony PSA's Steve Duckworth

Warren Buffett is quoted as saying, “It’s good to learn from your mistakes. It’s better to learn from other people’s mistakes.”

Following is the second half of a two-part examination of the most common factors that can lead to integration failure, as well as tips to make sure that your organization does not fall prey to these unfortunately common stumbling blocks. The first half is here.

In other words, this continues my list of other people’s mistakes.

Reason 3: Poor Data aka “Garbage In, Garbage Out”

If you’ve come from a world of spreadsheets and fragmented point solutions, this may well be your first PSA adventure. In this case, your main concern will be data quality.

For example, let’s start with counterparty data. Do you have a clean customer list? If you do, or think you do, what do you mean by a “customer list?” Let me give you some options to help you decide. You could have a customer list that:

  • Contains only customers with active current contracts.

  • Includes those, plus customers with whom you do business regularly, but not on a continuous basis.

  • Includes those that may have recently come off contract but who you hope to sell to again.

  • Includes those that are close to signing.

  • Includes those that you hope will sign.

  • Or even includes all those that you have ever done business with (this is probably the one you use in your accounts but not the right one to load).

You will have companies sitting in your CRM system that have not yet bought anything. Even leads can exist as companies. Are they worth populating? That’s before we get into the aspects of a parent company, separation between business and financial counterparties, definitions and deduplication of sites and contacts.

If you have this data separated across many systems, which themselves may have differing counterparty data structures, you will need to deduplicate, clean and agree to the current state of each customer record in each operational system.

When you are migrating from an existing system, you must also consider the data-model differences between the two systems and make sure that’s been taken into account in the data cleaning. If you have a system that allows only one site per customer, but you have customers with multiple sites, it’s likely that you will have created duplicate customer records — this is quite common. When moving to a system that supports multiple sites, you must deduplicate and locate that customer under one record. The same issue frequently occurs with contact records: whether they are attributes or independent objects makes a difference to data population.

Even seemingly simple data issues often turn out to be quite complex, needing consideration and external data cleaning plus population of any custom fields you may need to analyze performance. Fail to focus on these data population/data model differences early on – including asking the right questions, getting the differences clear and building the right lists to populate – and you will end up building an instance on bad data. This will at the very least cause frustration and waste time; in some cases, the implementation will fail.

So don’t rush this stage. Consider it a great opportunity to re-baseline your data and build the next phase of your business on a clean foundation.

Reason 4: Being Too Ambitious

The sales process will set you up to fail if you’re not careful. Your sales rep will wax poetic about how wonderful the solution is and how automated things will be, how easy your life will become and, of course, how much money it’s going to save you.

You’ve likely heard some version of: “PSAs are actually free because they save – or help you earn – more than they cost. It’s the ultimate free lunch! Sign now, don’t delay!”

Worse, you may have pitched this story internally, setting your ambition in stone with your boss. Here’s the reality: Don’t expect the sun to come out the day you go live; expect rain, and tell your boss the same. No matter how careful you’ve been, how well you’ve documented processes, how much training you’ve done, how clinical you’ve been with the data load, suddenly joining everything up in one system will reveal problems you never even thought of. This is not a failure. It is the most vital lesson to learn, because now comes the stage that’s probably not in the plan: troubleshooting the install.

Don’t be that person who promises perfection on Day 1. Make sure your plan has a post-live fix period factored in. Don’t consider these early issues a failure — the sooner they come out, the sooner you can fulfill your vision. Make sure your ambition (and messages to management) recognizes this.

What we also see are issues at this point causing a reduction to the scope. In effect, you use what works and abandon what doesn’t. This really is a failed implementation, because even though you may be live, you’ll have lost the full benefit case. The temptation to abandon some functionality is quite strong, particularly if your plan doesn’t include a troubleshooting phase. It’s such a shame when an otherwise successful implementation generates a failure message when all that is needed is a little more tuning. Don’t allow this to happen — stick with it and work with your supplier until it’s right.

In conclusion, these four reasons for failure all step from a single mistake: You did not take the process as seriously as it should be taken. This is your company. Take the time to make sure the tool does what you need it to now and has the capacity to change as you do in response to market pressures. Ask every hard question you can think of, not just about the vendor’s road map, but about existing features and how adaptable they are. Ideally, you only want to do this once every five years, maximum. Don’t be afraid to challenge and confirm.

If you take a trial run, take it seriously. Test the boundaries of how configurable the PSA is, and then decide if it has room for your business model to flex and grow. If you plan to find customers overseas, how good is the multicurrency aspect? If you plan on acquisitions, can you add multiple legal entities? There are platforms out there that do all these things, so there is no longer any need to buy one that is limited.

Set achievable goals. Future-proof your choice. Lead from the front, and be not only decisive, but pragmatic. Done correctly, a solid PSA implementation will place a rocket under you to propel your business forward. Do it badly and it will hold you back — possibly more than you can imagine.

In a career that began in offshore engineering, migrated into investment banking and ended up with the co-founding of a software company 10 years ago, Steve Duckworth, CEO of Harmony PSA, has devoted his career to developing solutions solving project, accounting and business process problems.

Read more about:

AgentsMSPsVARs/SIs
Free Newsletters for the Channel
Register for Your Free Newsletter Now

You May Also Like