If you’ve worked in the IT world for any length of time you’ve implemented technology. If you’ve implemented technology you probably know what it’s like when things go wrong. Two or three hours on a weekend can turn into 48 hours of sheer terror. To avoid the terror, planning is the key. Many IT technicians think they are pretty good because they have successfully followed a set of directions or a wizard. The reason they are so successful is because of the planning that went into creating that set of directions or that wizard. The modern network architect needs to not only know how to follow directions, but also how to write the directions. When the directions fail, the team is in for a long sleepless weekend.
Imagine that it’s Saturday morning you’ve started working on the upgrade since 6:00. You’ve run into a few problem and you think you’ve just about got it. A call interrupts your concentration on the problem. It’s your significant other asking if everything is ok? You had predicted about 2 hours to complete your work and it’s been three. Not a big problem but this is definitely taking longer than expected. You predict another 30 minutes. Four hours later another call interrupts your concentration. Again your significant other asking how things are going…?? This is how the rest of the weekend goes.
In the beginning of my IT career this was the way many of my weekends went. Luckily technology was not complicated back then and I learned a lot over those weekends. As the technology and infrastructure became tougher and more complicated whole teams of IT professionals would be having the same calls with the significant family members waiting at home. Most of the time, our loved ones began recognizing the cycle and stopped believing we’d ever come home.
A successful weekend project is about planning. Then testing the plan and fixing the plan until we get it just right. In the early days we could work after hours or on the weekends. Now with international teams there are times of the day when it’s impossible and other times of the day when it’s almost impossible. Over the years though I noticed that my projects were getting less and less crazy on the weekends. I wish it was because I could say that I was a better technician, or incredibly experienced. The reality is that I was just becoming more organized. One of my technicians summed it up by saying, “James I like working on your projects, because the instructions are so clear, nobody can make a mistake.”
With experience comes wisdom. Get hit over the head enough times and you remember to duck the next time. Here are some of the pitfalls I’ve found that plague weekend technology work.
Poor technical directions – So if you have a team coming in for the weekend, how much do they know about the project you are working on? Most project managers have been thinking about the project for weeks, months and even years. For the technical team this could be the only time they’ll be working on the project.
Complete Documentation – Writing bullet proof instructions for the team members is an art form, but it means they make fewer mistakes. The team will just run through the instructions, and then they are done. Documentation for many projects is non-existent. So technicians begin making mistakes. Time consuming mistakes that you, the project lead, will be required to troubleshoot and fix.
No Testing of process – How often have you tested your own documentation? Every time I walk through a process I learn where I made a mistake in documentation or in understanding the real problem. Every large implementation has at least one test environment to simulate the problem. Every project lead should be testing the weekend process in this environment.
Forgetting about the details – I was working on a project in Los Angeles California building out a small server room. Suddenly we were stopped because we had not included patch cords for the servers. I am a Seattle IT Consultant not an LA IT Consultant. I know all the vendors in Seattle and the fastest routes to find them. It seems silly in retrospect, but we hadn’t even planned in the costs associated with the patch cords. It just seemed like a detail that would take care of itself.
If you’ve ever dealt with LA traffic it can take an hour just to drive to a store that carries just what you need. So purchasing the cabling, the driving etc. took ½ the day waiting on congested freeways. Imagine our frustration after our first trip when we realized some of the cables were too short. Which meant another two hour round trip drive for more patch cables. A week later we had taken at least one trip a day for small details we had ignored. To this day I associate patch cables with traffic congestion and a symbol of unplanned expenses.
The first time I started using Microsoft Project, I finally began learning about how to track the details of a project. An application like project allows tracking of each step between each milestone of every project. Then by analyzing the steps you begin to see and list dependencies and then prioritize each step. Finally dates and time can be associated with each step and the calendar can be accurately predicted.
Over time I began to realize that my portions of the projects were no taking any time at all. Not because they weren’t complicated. Rather because my projects were well planned with contingencies and roll back planning. People wanted to work on my projects because they knew we would be waiting for the other projects teams rather than feeling the stress knowing that their team was holding up the project.
I’m curious to hear what other aspects of planning may have helped your projects.