My nine biggest blunders as an IT pro

#5: Possessing unique knowledge
Although it may seem that possessing unique knowledge and skills within a company should offer some job security, not only is this a delusion, but the possession of such knowledge can also become a burden that negatively affects your personal life. On several occasions throughout my career, I have allowed myself to be in just such a situation, where my failure to share my knowledge led to interrupted weekends with the family, phone calls at all hours of the night, phone calls while on vacation, and my favourite, a phone call to the ICU less than six hours after brain surgery.

Lesson learned? Document, share and train. Sometimes, in a small company or during an implementation, it can be impossible not to possess unique knowledge. But staying aware and alert to the danger can minimise this risk. When provided with the appropriate documentation, it is surprising what even a relatively unskilled alternate can achieve in a crisis.

#6: Creating inadequate self-documentation
In addition to failing to document procedures for the purpose of sharing knowledge, I have shot myself in the foot on more than one occasion by failing to document a procedure or configuration I was sure I would remember. While working under pressure, with users breathing down my neck, it's all too easy to take shortcuts and make worthless self-promises to document later, when the crisis is over. Unfortunately, the next crisis hits, and then the next, and soon the documentation is forgotten until it's needed in the midst of yet another crisis.

Lesson learned? This lesson hasn't been fully learned yet. I've started taking screenshots and brief notes while working under pressure, but I still procrastinate in doing a full write-up after the crisis is over.

#7: Failing to establish the extent of my authority at the start of projects
Over the years, I have been the project manager for a variety of implementations, upgrades and migrations. With one exception, each project was successful, in that the defined objectives were met by the deadline. But the process by which this was achieved was not necessarily the most efficient or the least stressful.

I hadn't seen the need to establish my authority at the start of a project as, until recently, all the members of each team had respected it. On a more recent project, in a very hierarchically structured company, my team consisted of a few peers, my boss, a couple of managers and a vice president. A more experienced project manager suggested that I call a meeting specifically to determine exactly how much authority I had over the members of my team. I thought this was unnecessary and soon began to suffer as a result.

The project had various critical path items that had to be completed by specific dates, but despite my fervid attempts to communicate this to the team members responsible for the items, they would frequently thwart me: "I'm taking Friday off. My boss approved it"; "I can't do that today; I need to do this". I had all the responsibility for the success of the project but none of the authority necessary to ensure its success. As a result, it was my first project not to meet the deadline.

Lessons learned? The first step of any project I am managing will be to establish what authority I am to be accorded. And if it's not sufficient to guarantee the success of the project, I'll have the temerity either to ask for more or suggest that a more senior project manager be appointed.

#8: Sending an insensitive email to an employee
I received an email from an employee detailing an extensive list of problems she was experiencing with her computer. Without any malicious intention, I shot off a reply saying that it sounded like time for a new computer. Thinking no more about it, I added her problems to my list of tasks for the day. A few minutes later, I was summoned into an emergency meeting with my supervisor and his boss. As I walked in the door, I was handed a printout of my email reply to the employee and told to explain myself.

Thoroughly confused, I stated that I didn't understand what was going on. My boss explained that the employee was extremely offended by my email as she had interpreted my levity as a refusal to take her problems seriously or help her. I was shocked that a few innocent words and an attempt at a lame joke had been so drastically misunderstood. I was instructed to apologise to the user and fix her problems immediately.

Lessons learned?

• Do not attempt to be funny or clever in email; play it completely straight.
• Have a formalised procedure for handling requests for help.
• Always inform users of when they can expect their problems to be addressed upon receipt of their request for help.

#9: Not taking advantage of free training and certification opportunities
Each time I have updated my CV in preparation for seeking a new job, I've regretted not having formal certifications to accompany my experience. This has been particularly irritating when the company I am trying to leave has a policy of paying for any classes the employees want to take, whether they're relevant to the business or not. It's kept me from applying for several jobs for which I was otherwise qualified simply because they required possession of particular certifications.

Lessons learned? Take advantage of all free training opportunities, even if they have to be pursued out of business hours.