Tec(h)tonic

Insights into building a solid I.T. foundation in the mid-size business world.

Making your project rollout a success

I’ve spearheaded a number of tech projects in my day, from software roll-outs to custom systems to one-off projects, and I’ve learned a few things (mostly through trial-and-error) about what makes an effort a success or a failure.

Don’t Show It Until It’s Ready

I tend to let my enthusiasm get the better of me and want to talk about or show someone something I’m working on before it’s really ready for primetime. I tend to forget that a) most of the people around me aren’t as in to tech as I am and b) people tend to remember being unimpressed.

I’ve had more than one disappointment when I show someone something I’m working on and naively assume they “get what it’s about,” despite the fact that all the pieces aren’t in place. It just takes the wind out of my sails and, worse, reduces the chance that, when your work IS done, that that person will be able to look at it with a fresh eye.

So, as excited as you may be, don’t show others your work until it’s in functional order.

Do the Work for Them (also known as “Force It Down Their Throats”)

Back in the day, my earliest attempts at imposing a standardized IM tool throughout the company fell flat because I relying to much on their proactivity (“Of COURSE they’ll be all excited about this and get onboard of their own accord!”). I made the mistake of simply sending an email out with a download link, asking them to install an app, create an account for themselves and then let me know what their username was so I could create a directory for everybody to refer to.

Yeah, I know – stupid.

What works is when YOU do all of the leg work – from remotely pushing the installs to every system, to configuring those systems to autostart the app (in the case of IM), to creating all of the accounts on their part and then simply delivering the credentials. Better still, preconfigure their system to sign them in so they don’t even have to think about it.

Conduct a Mandatory Overview

Get yourself in front of the users and introduce the tool in-person. I’ve tried other methods: holding open invitation meetings, scheduling groups of people at a time, sending an e-mail, scheduling one-on-ones and none of them work.

The truth of the matter is that taking time from their jobs to learn about your new tool, no matter how beneficial it may be to them, is a big ‘ask.’ Instead, find a time when you have a captive audience by default and hit them then – departmental meetings, all-staff meetings, that sort of thing.

Keep it BRIEF and to the point. Further, have follow-up documentation ready on your computer to hit “send” as soon as you’re done so people get it while it’s still fresh in their minds.

Make Sure It Works Reliably

I’ve found that most people are enthusiastic when presented with a new tool you’ve created for them to use. However, if it turns out to be buggy then you’ll find that those people will be quick to abandon it and it’s nearly impossible to get them back on-board after that.

It’s true: you really DO only get one chance to make a good first impression.


Leave a Reply

Your email address will not be published. Required fields are marked *