If you’ve noticed I’ve been MIA the past 2 weeks…here’s the scoop.
I am neck-deep in a system migration right now, thanks to the shutdown of our online ticketing system. (If the phrase “Desk to Service Cloud” means anything to you, reach out. You’re likely a Salesforce admin doing the same thing, so we can commiserate together! 😅)
Any database manager will tell you that when it comes to implementing a new system, seamless-ness is next to godliness . If no one complains on launch day, then you knocked it out of the park. That’s my goal.
But that kind of success takes TONS of work. Between the coordinating, pivoting & maneuvering involved, I promise you…it almost doesn’t matter if this is your first implementation or your fifth. Things are bound to crop up regardless, and if there’s one thing I’ve learned, it’s that you’ve got to get comfortable thinking on your toes.
Which brings us to this list. From my personal experience, here are 11 truths you’ll need to get onboard with before moving forward with that system.
11 Things To Know When Implementing a New Tech System
1. You won’t anticipate every roadblock. But still try.
Some stuff you won’t see coming – like that feature that should work one way, but actually works a completely different way. Product demos simply can’t uncover all that nuance, which means surprises are inevitable.
But there’s a difference between uncovering an issue early on and letting it catch you off guard! Begin anticipating those pain points, which you can do by thinking through your implementation plan and scouring any availabe documentation.
2. The tech challenges will sound ridiculous to your boss. Explain them anyway.
The tech gods have a sense of humor. Anyone else find that their biggest challenges are the things that sound SUPER simple? Even better when you have to explain that to your directors. “But wait, why can’t the system just do xyz?”
‘Why can’t the system just’ is every admin’s migraine.
But as I shared recently, our orgs don’t understand this work. And we need to do our best to explain (in plain-ish language!) what those roadblocks mean for our progress.
3. The rumors are true. Your leaders need to back you up on this.
This is only obvious until you find yourself in a situation where executive buy-in is lacking. Gang, buy-in from the top isn’t just about getting your directors to ‘okay’ the project, or force your staff to use it!
It’s about sustaining their involvement through each phase of the implementation. It’s your C-Suite’s commitment to seeing the project through and providing sufficient resources along the way. And it’s about having them spearhead the cultural elements of adoption that are way above our paygrade, so that teams embrace and actually use this new tool.
4. Everything’s fine! But you may still feel overwhelmed.
Change is hard, and organizational change is no different. Even when it’s welcome, there are bumps on the highway to tech implementation bliss. So it’s natural to feel some pressure when you’re the one in the driver’s seat!
But when you’re organized, things tend to magically work out. Which brings us to the next item.
5. You need to organize your tasks, even if you don’t normally.
I’m totally guilty of hap-hazardly (half-hazardly?) managing my day-to-day tasks. But implementations are a different beast, and that simply doesn’t work! So make sure you have a good way to organize your to-dos, so that you stay focused and adhere to deadlines. Consider a spreadsheet, or other tools like Trello or Asana where you can collaborate with your colleagues.
6. You’re better off documenting as you go. Not afterwards.
Yeeaaaah. We all know we should be documenting our work. With how chaotic implementations get, it’s easy to “decide” that we’ll get to this once the dust settles.
But if you put this off, you’re likely never getting to it. Truth hurts, gang.
That’s because good documentation is time-consuming, and those nitty gritty details you need aren’t top of mind once the chaos passes. It’ll be more work trying to gather all that info after-the-fact, then it is to spend 15 minutes documenting your configurations each day.
*Resource Alert* Figuring out what to document can be overwhelming and a pain. So I created a checklist of all the things you’ll want to include. You can grab it here.
7. Give yourself ample leeway for your target launch date.
The easiest way to drive yourself mad during an implementation is to set a launch date that is close to the last possible day you can afford to not be on the new system. This is the only reason why my implementation is slated for October and not November.
Regardless of how long you think this will take, give yourself a few weeks buffer time in the event of the unexpected. This way, you won’t lose sleep if someone calls out for a few days, a tech feature breaks , or one of your stakeholders sits too long on a decision.
Which reminds me….
8. You’re going to have to chase after people.
I used to lean towards the shy, hate-to-bother-people end of the spectrum. Being in this line of work has cured me.
Whether it’s your ED, department head, end users, the account manager who sold you the thing or the consultant setting it up, your success is going to depend on some combo of stakeholders. And they won’t all appreciate the urgency when you tell them you need something by x date. 🤷🏻
9. You can’t leave user training for the last minute.
The technical aspects of a system launch demand so much focus that training can become an afterthought. But even if it’s the “last” thing we do, it can’t be the last thing we consider. An implementation is only successful if staff adopt it. Training is what gets them there.
Plus, there are decisions you’ll want to think through in advance anyway – like the agenda, when/how long your trainings will be, and the best format.
p.s. It may feel a little early to be thinking about your user manual! But the early bird gets the worm. Once you’re at that point, here are some tips for putting one together.
10. You need a launch-day barometer for success.
People aren’t going to clap and cheer when your new system goes live (unless your org is that kind of place). And that’s fine: we don’t need that kind of validation!
But we do need some way to gauge our effectiveness on D day. Figure out what that looks like – whether it’s measuring the system’s usage upon launch, or even the number of day-of incidents.
11. You need to acknowledge your success once it’s over.
Years ago, I was drawn to the attention I saw development managers receive for their work. Donors loved to schmooze them, and they were greeted with cheers whenever they brought in gifts! It was a big reason why I decided to try being external-facing for a period.
In my experience, system implementations are rarely met with that kind of enthusiasm.
But unless you’re doing this every single day, implementing a system is a HUGE milestone for both yourself & your org. Acting on end-user requirements, corralling a bunch of people and resources together, and producing a way of working that moves your mission forward?
Update the resume, grab a pastry and do your happy dance.
What are your implementation tips & tricks?