HarmonyPSA Blog

The latest news and insights from the HarmonyPSA team

Part One: Why do PSA implementations fail?

Written by HarmonyPSA on 2017-06-26 Last updated 2017-11-06
Reason One: Software still catching up with changing business needs

This is the first in a series of blog posts about implementation failures and how to avoid them.

ERP implementation failures became endemic (almost apocryphal) during the 90s and onwards as expansion in the adoption of business software reduced prices. The driver for this was the change from bespoke instances (all with significant localisation code changes), to a more configuration-based commoditised offering.

The customer specific code-base support model of the 80s was great, if you could afford it. It was certainly cheaper than 100% bespoke business solutions of the 70s. If you wanted a feature, you paid for it on your instance, the only compromise being cost. Once you bought commoditised software, you lost the ability (money or no money) to have exactly the features you wanted. A lesson not learned by everyone, then or now.

ERP systems learnt this lesson the hard way with the first generation tools not being sufficiently configurable to really work in every case. A key reason sighted for failed implementations.

Current generation ERP PAAS (Platform as a Service) offerings have now emerged to address this issue.

Like ERP, a PSA tool is bought to operate your business, from sales, through operations to finance, all functions should have a stake in the success of the tool. The early generation of PSA tools aimed at MSPs were addressed at specific business operating models. Far from selling configurability, part of their attraction was that they included business training to help you run an MSP in the optimum manner, using their software, as designed. So, they were selling a full business environment (even including telling you how much to charge!) not just software. And that’s great if everyone is the same, which in the early years of MSPs they were.

But what happens when the MSP decides to change their offering under competitive pressures of the cloud?

They can find that the software which worked well for the narrowly-defined early-days model is not really flexible enough to model today’s products practices and services. So the customers end up writing additional systems to compensate, breaking the core benefit case for the PSA tool.

It is only now that newer PSA systems are emerging with enough PAAS thinking built in to deal with this problem.

So, to the question, “Does the tool do XYZ?” Increasingly, the answer will be “Yes, but you need to configure it yourself with our rules engine/workflow engine/custom fields etc” and inevitably this will require more training and some degree of compromise on the part of the user. That mind-set of compromise is not only important when looking at the market, it matters hugely during implementation and preventing failures.

Enquiries often ask about a single non-critical feature out of the thousands available, indicative of a mind-set designed for failure, a lesson not learnt. So, to avoid this pitfall, set your goals to a reasonable level and look to the benefits for the business of adopting the overall solution, don’t allow the team to focus on moaning about one of two nice-to-have features that may be missing.

Read Part Two

Read Part Three

Read Part Four

Read Part Five

Tags: BUSINESS, feature coverage, implementation, MSPs, GENERAL PSA, system evaluation


Recent posts

Subscribe to our blog