I’ve been having some discussions within my organization as of late with regards to how IT can help the business outside of the traditional break/fix scenarios. In the past our IT has been involved with all sorts of non-typical projects including (but not limited to) installing communications gear on-site at jet fuel line install at a major airport, assisting in environment monitoring in a skyscraper, and being involved with a window replacement project (glass windows, not MS Windows).
I figured I would capture some of the key points that I have realized over the years that has helped to greatly increase the success of IT projects. The points below are roughly in order of importance to me, but of course this can vary wildly for anyone else.
Buy-in from management
First off the bat is to make sure that management (preferably Senior) is on-board with the project. Whether IT approaches them, or they approach IT, if you don’t have buy-in from above then the project likely won’t get far. Resources like budgets and man-hours are key to any project, and if you don’t have those in the right proportions then success will be all but impossible. It is also important so that the end-goal is accepted when it is released. A lot of folks are resistant to change (sometimes with good reason), and if they aren’t explicitly told that things will be changed then your new shiny project might just sit there and gather dust.
Build a task force
This tip changed my life; I had a fairly large project (for our organization) that was going to result in huge savings. It was super important, and everyone agreed on that, but nothing was getting done. On my end I would have demos and proof of concepts setup, but I could never get consistent or timely feedback from users. I ended up approaching key members from the operations side and accounting side (the project impacted both departments) and we ended up just meeting regularly every Friday morning.
Meetings were booked for an hour and sometimes we would go over and sometimes it would only be 15 minutes, but the key here was that we met regularly. During that time each person would present an update on what their tasks were from the previous meeting, we would discuss anything that came up since the last meeting (vendor updates, process changes, etc.) and then we would define clear tasks for each person to have done for the next meeting.
This worked wonderfully as people were being held accountable (myself included) but we also all knew what needed to be done, who was going to do it, and because of the regular meetings we would be able to make any ‘course corrections’ immediately.
Get to know who your users are
Another big tip is to know your users; I’m not just talking about their names or roles, but get to know them at a bit more of a personal level and understand what they do and how they work. For example, I remember talking to one user and I asked him how his son was doing. We started talking about kids and he mentioned that he was scrambling to find someone to go on a site visit in another city. Someone needed to go and check to see if a seal was leaking, and if he couldn’t find someone he would have to go and he would miss one of his kid’s extracurricular activities.
Although I couldn’t help him out with his logistics, I immediately pulled up the status page for one of our environmental monitors in a server room. I showed him all of the stats and followed up with the fact that a moisture sensor was available too. For about the cost of one trip, we were able to setup a portable rig that would alert them as soon as moisture was detected.
This was all sparked by simply asking how his kids were and it resulted in a huge win for the division (fewer travel costs, quicker response times, and being able to offer this as a service).
Make yourself visible
One trend that I have noticed over the years with a lot of IT pros (particularly those in a support role) is that they like to make any changes in a covert fashion. It might be my limited experience, but I feel like all too often changes are pushed out with no mention to the end user. Things like icons magically appearing, or new network drives or printers can all be a little confusing for users. Because of this, folks in IT are rarely recognized as individuals, rather we are referred to collectively as ‘IT’. How often have you heard an exchange like this:
User 1: Yeah, my computer was down this morning but it seems to be fixed.
User 2: Great – did you have wait long?
User 1: About 20 minutes; IT showed up and fixed it pretty quick.
User 2: Yeah, IT is awesome – let’s go get them beer and pizza
OK, that last part I made up, but I think the rest is pretty typical. IT is just some faceless person who shows up, does what they need and disappears behind a door.
Yes, things like patching or updating software across the board should be automated, but sometimes for the one-off’s I like to take the time to go see a user in person. It creates a different type of experience, and if it is a hot topic a face to face almost always yields better results than emails back and forth.
It is also amazing what comes up during an informal conversation. There have been numerous times where I’ll just be chatting with someone (usually while we wait for a reboot or something) and then all of a sudden they will say something like ‘Oh, by the way, we are in talks with Company X to acquire them – it is still a few months out, but I thought you might want to know’. Usually I hear about things when it is too late (that could be a great horror story post on its own), but by putting in a little face time I often get these little nuggets of information that I wouldn’t if I just fixed an issue over email.
This isn’t an end all / be all list, and there are a ton of great books on the topic. Rather this is my short form list of relatively simple tasks that can yield great results for IT.