We’ve all been there. Regardless of your capacity during a technology deployment, we’ve all experienced the pain of things not being designed, planned, or thought through before going live with the deployment.
Some of these things should be addressed during the design stage, yet a lot of them would fall under best practices in most businesses. It’s still amazing how much of it slips through the cracks.
1. Lack of a Complete Deployment Script/Checklist
This sounds simple and straightforward, yet it is one of the most often neglected items. How can you expect a technician to do every step of the deployment without everything being on the script?
Telling someone isn’t good enough. People forget things, like their keys, where they put their glasses, where they parked, etc. Without a complete, step-by-step script, how do you expect them not to make a mistake?
So how do you create a complete script? By actually completing machines before the deployment and documenting every step. Assume nothing! If you must type something to get where you need to be, put it in the script! If you need screenshots, put them in the script! This is especially true if you are using contract technicians, as they won’t know your processes like your IT team does.
After a few machines, the technicians may not need the full script, so just create a checklist with the milestones of each step on it. That way, they can just check it off. Doing these things in preparation for the deployment will set you up for success, and many fewer headaches.
2. Lack of Training for the Deployment Technicians
This also sounds like a no-brainer, yet many of the lower-tier contract technicians are straight out of school, if they have even finished school yet. They have technical skills, sure, or they wouldn’t be working in this field.
But have they ever been taught people skills? Have they ever been taught proper dress code? Have they been coached on how to interact with the users in your offices? More professional appearances and mannerisms will go a long way in putting your users at ease when someone comes into their office or cubicle to replace their equipment.
Technicians who are too busy playing games on their phones to pay attention to other users or things going on around them do not give a sense of confidence to either the users or the office managers.
3. Lack of Proper and Concise Communication with the User
In the same vein, these new technicians may be lacking in the communication skills necessary to not only convey to the user what is going to happen during the deployment but also to walk the user through their new machine or software setup.
Sometimes it’s difficult for a technical person to put themselves in the place of the non-technical user and walk them step by step through a new setup. The technicians must be coached to slow down and take that time to make sure the user can open their email, find their files, print to their default, etc.
Again, these things should be on the deployment script, and if the technician follows the script, this will be covered. Coach them not to rush the user. No matter how many machines you must do, the most important one is the one you are doing at that moment!
Coach the technicians to be aware as they walk through the office. If you see one of your users whose machine you have already finished, ask them if everything is working well. This will give the entire office a sense of calm, something in short supply during technology deployments.
4. Required Software Not Installed or Available
This should definitely be addressed early in the design stage. There are few things worse for both the user and the technician than to spend an hour backing up, installing, restoring, and prepping a new computer, then find out that user-required software isn’t installed! Then you are left to put the old machine back in place, so the user can go back to work, after losing two hours of work.
I cannot stress this enough: If different departments use different software, then each department will need to be scanned and have machines imaged specifically for each department. Test this before the deployment starts! Having to send a tech back for a revisit because this wasn’t done only costs more money.
5. Non-Compatible Hardware
This also should be vetted long before the deployment starts. If there is equipment used that has been around since the XP era (printers, scanners, etc.), you need to make sure it is compatible with your new systems before going ahead with the deployment. If it isn’t, then you will know which machines not to replace during the deployment. You can address those later when either driver becomes available, or you buy new equipment.
6. Dealing with Out-Of-Scope Work
It’s inevitable, as technicians are working, that users will ask them about other IT problems they have been having. If the technicians are contract workers, you probably don’t want them working on things other than the deployment.
I understand the user's point of view. They’ve had this problem for a long time. IT has never come to fix it, now I have an IT guy here right now, and he can fix it! Coach your technicians that if it is something simple, 10 minutes or less, go ahead and help the user. If it looks like something longer than that, or something you are not familiar with, just politely inform the user that you are not with the IT department, only a contractor, and they need to put in a ticket. Spending too much time on these things as a contractor costs the project money.
As you can see, with a little foresight and design work on the front end of the deployment project, not only will you have a smoother, more professional deployment, but you will also have a much happier user staff — while saving the company money. And that’s a total win-win!
