It was 2am; exactly two hours past the end of my data center "outage window." I was staring at the strings of network cabling weaving its way in and out of the equipment I had just re-racked, exhausted. The jet-like hum of a thousand equipment fans screamed at my head. My brain had just shut down on trying to process why things were not coming back online and could only process thoughts like, "What am I doing here?" and "Maybe technology isn't my thing - it's not worth this stress; nothing is worth this stress." Thankfully, I was working with one of the smartest and most positive people I know and after a few more hours of work, things were once again back online and functional. Smiling and glossy-eyed, I arrived home, waived to the family, and went to sleep.
I'd like to say this is the one and only time an event like this happened, but these late night data center nightmares became fairly common place in my engineering career. And I know I'm not alone.
Oftentimes at Veeya, I will tell our engineers, "We're here to keep technology simple...and doing that is really hard." That's because the first step of this process fights against everything that makes an engineer great: unbounded curiosity. This is how many start in the technology profession: either personal or professional technology catches their eye and thousands of hours (and Google searches) later, you have yourself a fairly competent IT professional. Yet, it's approaching an IT project with this same curiosity that causes it to go so poorly. Curiosity doesn't plan, it explores. Curiosity is what you need when you're relaxing and have, "I wonder if..." thoughts. In short...
The curious mindset kills IT projects.
Curiosity leads to innovation, not precision and IT projects are precision machines. For IT projects to go well, they should be approached with the preciseness of a military operation: nothing is left to chance. You get in, perform the operation, and you're back out.
"But wait! I like to 'wing it,' everything is usually fine! It's a rush!!"
- Unemployed Network Engineer
I know, I love the feeling too. You get the same feeling when you hit a home run on the first pitch or sink a fading 3-point shot at the buzzer (I've been told), but the difference is people expect you to to strike out the other 70% of the time. Technology is not a game of chance.
I think you get it, right? So how to make sure your project goes well? The first step is to Define.
Google will not be involved here
Defining is creating a written statement that says, "This is exactly what this IT project will do." It should be short, it should be simple, and it should only take you a few minutes. Once that is complete, take the next step and write a brief description on why you are doing this project. It will be slightly longer than the first statement, but shouldn't take you any more than 15 minutes to write.
That's it! And congratulations on creating your very first Statement of Work (SOW)! But don't call it that - it would get management all bent out of shape. For now, let's keep it simple.