Confessions of an Operations Guru Turned Legal Ops Novice, Part 7
Overcoming Software Implementation Roadblocks: Setbacks Aren’t So Scary
Software selection and implementation is such a large, invested project that when hurdles in the process come along, they can be absolutely bone-chilling. If you’re anything like me, you’ll spend at least one sleepless night trying to figure out how you could have avoided this setback in the first place. While learning from it is always a good exercise, it’s important to focus on solutions first.
Today’s post will focus on getting rid of the ghosts and ghouls you encounter in your implementation to take it from nightmare to daydream.
To do this, we’ll go over some common software implementation roadblocks. First up, Saboteurs.
Spooky Saboteurs
While these team members often feel like they’re flying around your implementation on broomsticks, I like to think that they’re very well intentioned. I call them my “particularly passionate people” (PPPs) Through my many implementations over the years, my passionate team members are often responding to some perceived threat that the software brings. Whether that’s to the way they work, their perceived value on the team, a concern about the company or their position in it, or something else, if you can identify the threat, you can identify a solution.
For some of my PPPs, I’ve had to bring them in to the selection process so they felt heard and important. For others, I had to partner with their direct report to assure them that when the software makes their job easier, it doesn’t mean their job will be eliminated but will actually give them the time they need to invest in the parts of their job that they love. Still others needed to understand that the tool will empower them to spend more time with their families, dogs, or otherwise enjoying time away from work. For these particularly passionate people who had more than one person’s job on their plate to begin with, learning a new way of doing things was terrifying. It took too much time that they already didn’t have. But introducing the software to them one piece at a time – leading with the most impact to their workload – helped them understand the tool will help, not hurt.
Frightening Feedback Loops
You want your teams to offer feedback on your tool. It’s a critical part of making sure that what you design works in a real-world setting. But, if you don’t set boundaries and create places and ways you receive this feedback, it can get a little scary. If you can, at the beginning of the process, create a rough schedule for when you’ll be meeting with different teams. Help each group the software will be serving understand that you’re looking for the best solution for everyone, and let them know that they can send feedback whenever they like, but may have to wait until the next meeting to discuss it with you.
If you’re in the middle of your implementation and are getting overwhelmed by the feedback loops in your organization, it’s not too late to provide structure. Set some boundaries, don’t have an ‘open door policy’ on when folks can meet with you when they have feedback, and get them to write down their thoughts, think through them, and then present them.
One more note here. If you have a suggestible group, make sure you have an agenda for your meetings that goes over feedback you already reviewed. If a new feedback item comes up and there’s push back on a feature, etc., just mark it down on the agenda for the next meeting so the group discussion doesn’t devolve.
Spidery Scope Creep
Scope creep can easily turn in to a tangled web of terror if you’re not careful. Part of the frightening part of feedback loops is that, when it gets out of hand, your team can create internal expectations about what the software needs to do for them, and your initial goals/design of the software can get muddied. This is what we call scope creep. It’s a common occurrence when building software, and it can have a few different consequences:
- Time Cost
The scope of a project is determined before the software is developed. When additional features and needs are added after the scope is defined, it can take a lot of additional time to determine if this new feature actually needs to be added to the scope, and if not, can take a lot of time to explain to the reporter. - Emotional Cost
‘Emotional cost’ may be a strange way to put this, but any time a particularly passionate person provides feedback (often last-minute) that’s not taken, it can cause a variety of consequences if not handled properly. This can vary from them simply feeling unheard, to them refusing to use the product, to them forming a coalition of others who don’t want to use the product if it doesn’t meet every single one of their needs (something no software truly ever does). - Financial Cost
Financial cost can show up in a couple of places with scope creep. Most obviously, it can show up by needing to expand the budget to pay for additional features. In addition, you may see financial costs increase because you won’t be receiving the ROI of the system as quickly while the initial build takes place and you’re devoting additional human resources to the design and testing. One other place I’ve seen scope creep cost is through the amount of time it takes to get my PPPs on board if they don’t get what they asked for. Their lack of participation can result in time lost across entire teams, which can show up in lost ROI overall. In some cases, I’ve added a small additional feature that only marginally increased cost and development time to make sure I have the needed buy-in at the smallest possible cost.
Daunting Dependencies
Speaking from experience, if your implementation project isn’t dependent on the departments that will be using the tool, you’ll have to re-do your work. That being said, dependencies on other parts of the organization can be tricky. When teams, or even worse, their leaders aren’t bought in to the solution – or are just busy! – your deadlines are often the last thing on their mind.
You can get through these dependencies by making deadlines clear, getting the buy-in of team and department leaders, and working with managers to free up time on their team’s plates to accomplish the work for the system. The financial cost of delays can often get leaders to buy-in to the timelines and help open up the space in the calendar.
However, this is not true for every leader. During one of my implementations, we had a department head that was intent on not using the software. They and their team did not show up to planning sessions and ultimately did not give input on the way their usage was designed. The head of the company understood we needed to move forward and left the design up to the implementation team and their understanding of the work being done. Ultimately, we got a few things wrong and when the team was brought into the software, their work wasn’t optimized. We had to invest some additional financial resources to bringing them up to speed, but that was removed from their department budget because of their choice not to participate on the front end.
Every software implementation has its fair share of tricks and treats. You can often reduce software implementation roadblocks by planning ahead, but if you find yourself at a bump in the road, don’t worry. We’ve all been there. You don’t need witchcraft to get out of this, just patience, strategy, and a little bit of luck.
