Everyone's favorite thing to hate: planning.  I don't have all the answers, but I want to try to provide some guidance to someone specific.  Yes, you, the dude who recognizes the need for planning when nobody else around does. The dudette who is tired of having projects go awry every... single… time. Beers are great to celebrate a project victory, but a lot of us can often find ourselves using them throughout the project cycle to help numb the pain. I get it; I've been there.  

There are a lot of things that this post is not.  It is not a crash course in project management.  I don't talk about cool buzzwords like agile or scrum, and I'm not going to talk about change management processes.  It is simply a collection of my observations around the businesses I've worked in or with, and the multitude of projects I've seen succeed and fail. But read on, I think you'll still find it useful.

Why Don't We Plan?

Fail to plan, plan to fail, right?

So first, let's answer this question - why don't organizations plan, or why do they plan poorly?  Many companies have huge gaps in planning.  There are many reasons here, but here are a few of the ones I see most frequently.

Misconception 1: many organizations (or projects within an organization) think they are too small to even need to plan.  Let me disabuse you of that notion immediately.  Every organization and every project needs a plan.  It is with some irony that I've noticed that massive, complex projects tend to be more smooth and successful than small, "easy" ones.  Why is that? Simple - because people actually take the time to organize an action plan for big projects.  Those little critters that sneak through, those are the ones where dependencies are missed and you accidentally take down production.

Misconception 2: no time, no resources, no leadership, etc.  It is difficult to find extra time to do anything, and planning is no exception.  It takes valuable time and money.  It takes encouragement and buy in from managers and business leaders.  But again let me tell you, it pays off.  It is one of the best investments an organization can make.  8 hours of planning can stave off days, weeks, or even months of scrambling to get something to work right.  You may shake your head but I have seen it.  Over and over again.  It can be hard to convince people to let you take the time to plan, I know.  More on this later.

Misconception 3: no plans are needed because no impact is ever seen. Sometimes upper management is lead to believe this is because they have super heroes leading the charge for all of their projects, when in reality lower management is obscuring the truth.  Most often what this means is that your sysadmins, your engineers, your operators, they are putting in a ton of after hours, overtime, and extra work making things fit together after the fact.  They are getting pulled in a ton of different directions, always at the last minute, always fighting fires.  You can only run an organization like this for so long before people get burned out.  It is good to report a project as a success after a near disaster, but it is definitely not something to be celebrated if it took your admins out of commission for nights and weekends, away from their families, moments they can’t be returned to the team members. Even though from the top this looks like success, this is not a culture to be celebrated.

How Can I Start?

So you want to plan, right?  But you can't find the time, resources, management approval, etc.?  

My advice here is to start small.  Don't try to plan out something monumental first.  In fact, I would find something that is almost comically small.  It could be getting the physical cables for two servers.  This is a good idea because it is almost guaranteed to be successful (even without a plan), and it will give you experience in what it takes as well as expose others (and hopefully others in charge) to what the process will look like.

Next, establish a framework.  I will give you a short sample below but look for something generic that can fit most projects you do.  Don't come up with an impossibly long workflow or a lengthy list of forms that people need to fill out.  Keep it as simple as possible in order to meet your goals.  Having a framework is important because it will show that you are serious about the process.  Calling a meeting with some people with no agenda to talk about some random thoughts in your head - this frustrates everyone in the room.  But inviting people together to tell them concretely what you need from them (and they need from you) to be successful in your endeavor is welcomed and a great use of resources and time.

Lastly, recognize that in a lot of ways, planning is a little more of an art than a science.  Your process, requirements, and workflow will be different than others.  And like with anything else, you will get better the more you do it.  You'll hone your process and your craft over time.  The important thing is to start!

Got a Plan for a Plan?

Yes, in fact I do.  Here is a very high level generic workflow for project planning I try to follow.  

  1. Players and Goals - identify what the project is and what the goals are.  Why are you getting two new servers?  Also identify who is directly involved in the project.  
  2. Data Gathering/Inventory Gathering - Identify what you have today.  This could be anything from number of physical ethernet cables to number of VMs to storage array size.  Depending on the project, this will take a while, but it is both the most valuable and the most ignored part of projects that I've seen.  Good data gathering is your best weapon against unknowns - missed dependencies, missed requirements.  And as a bonus you can use data you gather for project or internal documentation.  Don't skip it!
  3. Requirements, Gap and Impact Analysis - Based on your data and your understanding of the project, identify any requirements you have, and identify any missing items that you need to make the project successful.  Also identify who and what will be impacted by this project.  You may have a gap simply because an important group doesn't know that your project is going on and they will be affected.  Make sure that your requirements have a designate name being assigned to them as you check them off!  If you need 6RU of rack space and John Brown from the DC Ops team tells you that he's got it reserved for you, write his name next to the requirement.  If I ask if we need a change window reserved in advance for this project and Jane Doe tells me no, then I write Jane Doe next to that item.  This isn't about assigning blame as you are all on the same team. It is about accountability.  Requirements that people usually miss are the most basic things - rack units, power, network ports, power and network cables (quantity and type), maintenance windows, change management processes, data center access tickets. Seriously these things are IT 101 but they can delay projects for an absurd amount of time.  
  4. Execution Steps - this should be (as detailed as you need it) steps to actually accomplish the project, which should flow from the previous 3 items.  If you write a step down here and you haven't accounted for it in the previous 3 steps, something is wrong and you need to go back and figure it out.  
  5. Post-Project Tasks - This can be anything from update documentation to post-mortem analysis.  Anything that needs to get done after the main execution window of the project is over.  And yes, now you can drink the beer!

Again, the more you do it, the easier and more natural it will become. Planning is a skill like anything else.  And the more you show that you are committed to it (and the more others see your projects succeeding because of it) the more buy in you'll get across the board.


Joel Cason

ROVE | Senior Technical Consultant



Member Login
Welcome, (First Name)!

Forgot? Show
Log In
Enter Member Area
My Profile Not a member? Sign up. Log Out