Make hard things look easy…
Make hard things look easy…and easy things look hard. That is your job as an IT professional in a nutshell, for non-trivial tasks at least. For trivial tasks (reset my password, get me a new printer, connect my iPhone to email), just do them and do them without an eye-roll or a sigh.
If you do not make easy things look hard, you will find your staff and your budget will be limited. If you hear your non-IT colleagues say, "We'll just have the IT team whip up a database and a series of insightful, actionable reports. That should take, what, maybe eight hours?" then you know you are not translating the complexities of your world into the requirements of their world.
When you hear that word "just," you should be afraid. If you use the word "just," you should be very afraid. ("We'll just tweak the data flow and it'll be fine.")
If you do not make hard things look easy, you will find you do not have a job. It is your responsibility to do the things you promise to do when you promise to do them. This means that once you commit, you need to be like a duck on a pond and appear calm on top and paddle like heck underneath!
How you make sure you make hard things look easy:
- Ask questions so you know what is expected. This also lets the requester know that you appreciate the complexity of the request. These questions are not "how to do it" questions but "what and why" questions and their follow-up thoughts:
What do you want to be able to do with the database that you can't do now? (Maybe there is an existing report that will do the job.)
Is there a date by which this must be done? (If your colleague has already promised a client this will be done, you want to know it now.)
Who is going to use this? (Can you get one of them to be your requirement approver/beta-tester?)
What is this going to do for us? (Be careful here. You are not second-guessing the need. You are looking for the value, so listen for items like, "We'll be able to close the ABC deal.")
- Document the request formally so the requester gets a chance to refine his/her thinking before you do more work. Send back one page, no more, recapping the responses you got to your questions in the previous point and making whatever commitment you are going to make. Your colleague already believes you have committed to doing something, so you might as well grab the pen and take control of the communication. If you don't own the communications, you'll hear (or over-hear), "I just asked IT for a database. I didn't expect them to cure world hunger. Sheesh!"
- Keep the requester up-to-date on your progress. No, he/she does not care that you had to spin up a new instance of a server with disk space and an IP address and a license and a backup schedule etc. He/she does care that YOU care since those tasks are needed to get him/her what you promised. If it is going to take less than a week to do the task, just get it done! Otherwise, put out a weekly status update marking progress against the schedule you promised. A short and sweet recap is fine, but be sure to have the full-blown project plan in your back pocket.
- Be gracious in delivery and in the changes that are inevitable.
So, you asked questions so your colleague knows you understood the request. You documented it so you knew you were in sync. You reported progress so your colleague did not have to do your job of communicating. And you did all this with a smile. Your reward is that you get to do this all again with the next request!
Oh, and the answer to the equation at the top: 1.
The opinions expressed in this Blog are those of Paul T. Cottey and do not necessarily represent those of IDG Communications, Inc., its parent, subsidiary or affiliated companies.
This article is published as part of the IDG Contributor Network. Want to Join?