Rolling out a new piece of software, or a new policy, or a new and exciting piece of technology usually tends to wind up being something of a disaster. Rarely are all the players working together to make for a smooth transition and the result is a debacle that usually falls in the lap of someone like me: the generic network admin. As a front line for complaints and questions, the botched rollout leads to an endless source of long, tedious busy work, stressed phone calls, and general annoyance.
Recently I took the point on the rollout and I’m happy to say it came together. During the two to three weeks it took to get everything in place I jotted down a few notes, so the next time I do this I know ducks I need to line up before the product goes live.
1. Test the Product
In the past, half the issues that have arisen are due to unexpected behaviors, not on the part of the users, but from the software itself. Not every single thing can be fixed, but making sure the people that will be supporting the new device are solid with its workings is vital.
2. Dodge the Creep
The first, biggest, and highest commandment with any rollout is minimizing the surface area for problems. Roll out as little as possible while still retaining the core functionality. Roll the product or software out to as few as possible, while making sure the key players are all included. Don’t stretch too far, don’t turn a small task into a big one.
3. Prep the Field
Drop hints that changes are coming. A prepared staff is better than an unprepared staff. Even if the users in questions are pleased by the changes, they’ll appreciate the advanced knowledge. This is especially true with the people in crux positions. This obviously includes certain managers, but also the more charismatic employees and the individuals most likely to cause problems.
4. Get Everyone on Board
Sadly, this is never truly possible and it’s really just addendum to the note above, but it’s an important thing to attempt. People on the top need to support the decision and people on the bottom need to be given the tools to accept it. Receiving feedback prior to a final rollout, offering up training, and getting a few strong voices of supporting in the ranks before the rollout makes the whole process go a lot smoother.
5. Plan the Rollout
All the preparation in the world can dissolve into nothing if the last day becomes chaos. The steps need to be outlined long before the final day. An introductory email should be written and tested, a process for manually introducing the software should be in place, a response network to complaints and questions has to be ready for the first day.
6. Back it Up
The final thing and the most important for an extended project is holding the line. There will almost always be complaints and they have to be dealt with, without compromising the original project. A person prefers to use the old software-response: we’ll train you on the new software, but you still have to use it. Allowing for loopholes and cracks turns into a support nightmare, undermines the new product, and makes a mess of the whole process. A strong line has to be taken and held in order to have a successful rollout.
My rollout (of spiceworks and a few other things) have gone smoothly. The best thing was dropping hints and giving small contained demonstrations long before I was ready to push the thing. I showed a handful of people I knew would likely to either use the software or have some leverage over those who would or would simply be responsive. In the end, when the big day came, the process was smooth and pretty damn well flawless. Result: I get to sick back and let out a big sigh of relief.
