Reason 4: Ambition
The fourth major cause of PSA implementations failing is actually being too ambitious.
The sales process will have set you up to fail if you’re not careful. And, worse, you may have pitched this story internally, setting your ambition in stone with your boss.
Your sales rep will speak on a continuous basis about how wonderful their solution is and how automated things will be, how easy your life will become and of course, how much money it is going to save you. “PSAs are really free, because they save (or help you earn) more than they cost, the ultimate free lunch! Sign now, don’t delay etc. etc..”
Is it true? Well, let’s say it’s not a lie, but it’s also not the whole truth.
Get it all correct, bedded in, running smoothly, other systems switched off, think of a Swiss watch of business and then yes, it’s probably better than free and it’s certainly not a cost. It is a far better way to run a company and it will help you scale the business with significantly less cost drag. But two-three months in, no, it will still be costing you money, don’t trust anyone who tells you anything different.
And this is where ambition can cause projects to fail.
As I’ve said before, PSAs change working practices, they change lives and not everyone likes that. In particular in the early stages when you’ve probably not got everything right. 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 throw stuff up you didn’t think 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.
Make sure your plan has the post-live fix period included, don’t consider these early issues a failure, the sooner they come out the sooner you can get on with aiming for the vision you started out with. Make sure your ambition (and messages to management) recognise this.
It is such a shame when early issues cloud what is otherwise a successful implementation and generate a failure message when all that is needed is a little more tuning. So, don’t allow this to be seen as failure, stick with it and work the problem to the end.
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 do this is really strong, in particular if your plan doesn’t include the troubleshooting phase.
Expect there to be issues, have this stage in mind from the start and you will overcome it.