One of the most common questions we hear is:
“What guarantees a successful software implementation?”
The truth is, there’s no single answer. Google it and you’ll find endless advice, success stories, and horror stories. The reality? Success depends on a mix of factors: the size of the system, the size of your company, and how prepared you are.
As the old saying goes: fail to prepare, prepare to fail. Or as one of my old bosses so gracefully put it: PPP (P*** Poor Planning) is the root cause of failures.
Based on my experience, here are the three stages that make or break an implementation:
1) Pre-Implementation
Understand your processes – Look at how the new software interacts with existing systems and how the data flows in and out. Some call this “value stream mapping.”
Not many companies will have the time or resources to map out precisely all the fields needed and all the processes that must be satisfied by the new software. That, is a big mistake.
On that cheerier note – data review. Boring? Yes. Important? Absolutely. Miss a single field and you can trigger a chain reaction of headaches – handover emails, manual documents – and the snowball of dissatisfaction starts rolling. You might even end up paying for yet another bit of software to plug the gap.
Remember: Sh*t in = Sh*t out. I’veyet to see a perfect dataset. Even basics like addresses, dates, or currencies can be a nightmare! I’ve seen and heard horror stories about accidental double accounting due to mismatched fields.
Champion – Probably one of the most important factors in any successful deployment. Your champion and influencer are the people inside the business who will communicate, defend, and smooth things over if problems crop up.
Involve the right people – Those who know the process inside out – the frustrations, the workarounds, the “must-haves.” They don’t have to be an IT Project Manager, just someone who understands how things are done, what works, what doesn’t, and whom the customer team respects. That will smooth the whole process remarkably.
Share data safely – Stay on the right side of Privacy and GDPR laws. Emailing data is OK-ish, but best to use a secure site. SharePoint can do the job and double as a hub for bug lists, schedules, queries, shared docs, etc.
Needs vs wants – You might want new features you’ve never had before. Be sure to get input from both end users and management so everyone’s needs are covered. This is your chance to try to get those features in as part of implementation, but be ready to justify them.
My experience says: ‘simplicity usually wins over flashy features.’ Why? Because at the end of the day, you just need to get things done. A flashing, colour-changing dashboard might look fun, but will it save you time? Probably not.
Know what works (and what doesn’t) – Often overlooked yet a good one to note. Most systems share core components, but they differ in add-ons, UI/UX design, integration capability and so on. Small frustrations in your current system are worth noting. Otherwise, you risk carrying them straight into the new one.
Think about growth – A “vanilla” setup might do for now, but will it work when you double in size, or when your IT guru leaves? Spreadsheets plus Monday.com and Microsoft apps might work for your turnover today, but growth changes everything.
Integrations – They can be big and they can be scary. Decide whether you want them before implementation; ideally after process mapping and data analysis. In a past life, I was asked to integrate Salesforce with our Project Management app. We only needed two fields. But getting API access? Whole different ball game – and we never got it.
2) Implementation
Testing – Always test with real life examples. Test scripts from your vendor are fine, but they’ll never cover all the messy realities of real data and human habits. I’ve seen software pass testing with flying colours, then fall apart in daily use.
Test end-to-end, give users time to play with the system during training, and match wish-lists to reality.
Participation – Get as many different users involved as possible. I recommend two environments:
- One pre-loaded with sample data so it doesn’t feel like a blank page.
- A copy of the production environment based on pre-deployment feedback.
Why? Because a blank page can stump people. A little structure helps them imagine how it’ll work for them and what’s missing.
Fix bugs now, not later – If you leave them, they’ll likely never get fixed. I’ve been there. A big ERP implementation, 10 “must-fix” items left for post-deployment, and after a year… only two were done. Don’t sign off until every “must” is met.
Online vs in-person training – Minimal online training works for small changes, but for anything bigger, or if your processes weren’t fully mapped, go for live training. Yes, it costs more, but the benefits of having experienced people on-site are huge.
In-person implementation gives visibility, quick answers, and relationship-building between your team and the techies. People remember faces more than names in an email inbox – and that helps later when you need support.
Documentation – These should be available during the testing stage, however, that’s not always the case. It’s important to get hold of technical information on how things work. Even if you don’t use them often, they’re priceless when you do need them.
3) Deployment & Post-Deployment
Easiest stage for your team, most nail-biting for the tech team (at least for the first two weeks). Something always goes wrong somewhere, so steady monitoring is a must.
Communication – Anything that crops up needs to be addressed, and quickly. One negative can outweigh seven positives in the customer’s mind.
Follow-up schedule – Schedule regular calls with your champion/influencer to review progress, solve issues, and share updates. This is your chance to test ideas and influence future developments. It’s a win-win.
I’m sure I’ve missed things, but these are the ones that stood out for me – some big, some small – and they should give you an idea of how to make your software implementation go as smoothly as possible.
If you’d like to discuss any of these (or add your own lessons learned), get in touch. Just, don’t get too technical about it…
