Simple Project Planning for Sysadmins (Part 1 of 3)

In this episode, we are going to look at a system for managing small projects from start to finish. This episode series has been broken into three logical sections covering: gathering user requirements, planning and executing, and finally sign-off and delivery.

This episode is a little different from what I normally cover, but I thought it would be useful to share a simple project management system that I have been using for many years, as it has helped me a great deal. What follows is not rocket science, you might actually think it is more common sense than anything else. I have personally used this method for managing around 50, multi-month projects, up to around 400k in cost, and includes several staff members. For those not involved with project planning, it can seem like a bit of a black box, a request goes in on one end, and a finished product pops out the other. So, I thought it would be worthwhile to share a simple project planning system, along with some lessons learned, in the hopes that you would find it useful.

As sysadmins, we typically have two main areas of work, helpdesk type tickets, and then projects for larger tasks. What is the difference between tickets and projects? Well, to be honest the line can get pretty blurred. I typically think of tickets as work that takes less than a couple days to complete, configuration changes or password resets, those types of things. Whereas, I think of projects as anything that requires a fair amount of planning, involves several people, or spans more than a couple days worth of solid work. A good example of a project type task, would be the deployment of new equipment, say in a mass upgrade exercise, or hardware life cycle management. It is a total judgement call as to where you draw the line though, and sometimes you might be working on a ticket, and think, this is starting to morph into a project, because it requires additional planning. Also, depending on the company you work for, and where you are in your career, the ticket to project ration can be all over the place. My personal experience has been, that as my career advanced in years, I started working on more project type tasks, and far less tickets. I think this kind of makes sense, in that as your career advances, you have more skills, so you are entrusted with additional projects, your skills grow, so your projects grow in complexity too, and the cycle continues.

I think the best way to teach this project planning method, is to just work through an example project, but before we do that, let me just give you a brief overview of what the project planning cycle looks like again at a high level, and how this episode series is broken up.

In part one, which you are watching right now, we are going to cover the initial stages of gathering user requirements for a project. You will likely be surprised at how simple this entire planning process is. We are basically working with glorified checklists, with just enough process so that things do not slip through the cracks.

In part two, we are going to cover planning and executing on the project, this is where we will translate our user requirements into IT requirements, by way of a project task list. The idea is that we flush out what needs to be done, step by step, by breaking it apart into manageable and actionable chunks of work, along with human resource implications. You might be wondering how this system compares to with project planning and documentation tools, like using Basecamp, Trello, Asana, Redmine, or what I prefer, Wiki pages and MS Project. Well, personally, I think they are complimentary, in that you will likely need to flush the user requirements out anyways, then create some type of high level task list. I think of this planning system as a type of precursor to heavy weight project planning, in that, if at a later point you want to feed the task list into MS Project, or any of the other software packages I mentioned, you could very easily. But honestly, do what ever works for you, this just works really well for me, so I thought I would share it.

Then, in part three, we will cover project sign off, and finally delivering the project, to the end user. Project sign off might mean different things to different people. I am talking about internally signing off the project, to ensure that we have actually delivered on the user requirements, and have complied with internal policies and procedures, for things like documentation, monitoring, updating inventory, labelling, remote management, password safe entries, etc. But we will chat about all the in part three. Again, this is basically a glorified checklist, and it is very complimentary to using MS project or something like that.

I think it is important to do project planning for several reasons. Mainly, that it helps you mentally work through the project, without actually having to physically do anything. You will start to develop a mental model of what the thing is going to look like, anticipate problems before they happen, and hopefully find solutions too. I am not going to lie, when I first started out as a sysadmin, I thought planning and documentation was a big waste of time. I just wanted to dive in and get my hands dirty, figuring things out as I went, and planning was a road block to making that happen. But, after many years of work, and countless projects, I now know that planning makes things go much more smoothly, does not actually take more than a few hours, helps you find better solutions, and do not waste nearly as much time. You will also build up a repository of project plans that you can reuse down the road, and as you encounter issues while working through projects, you can feed this knowledge back into the user requirements and project sign off checklists, so that your future self will not make the same mistakes.

Okay, so that is the planning process in a nutshell.

So, I mentioned before, that I think the best way to teach this project planning method, is to just work through an example project. So, lets do that now, by defining an example project, and then gathering our user requirements.

As I talked about in episode #17, I prefer to use Wiki pages for pretty much all technical documentation, policies and procedures, along with, you guessed it, project plans. It just allows you, and everything on the team, access to a central place where you can all edit and share documents. So, with that in mind, here is a basic template for how you can layout the project planning pages, you can also find these page templates in the episode notes below. I have broken this page into two logical sections, first, we have our supporting checklists, for things like gathering user requirements and project sign-off, and finally our project plans.

Helpful pages for gathering user requirements, planning & executing, and finally sign-off and delivery of projects. 

=== Supporting Checklists ===

* [[User Requirements Checklist]]
* [[Sign-off Checklist]]

=== Project Plans ===

* [[Storage Upgrade 2014]]
* [[Project B]]
* [[Project C]]
* [[Project D]]

In my experience, the IT department actually generates the majority of projects itself, rather than some external user. For example, within the past couple weeks I worked on a disk upgrade project for a heavily used storage server, which had some aging disks, and was almost at full capacity. So, while this is still fresh in my mind, lets work through the upgrade planning process, start to finish.

Lets open up our user requirements checklist and have a look. I use this as a type of planning aid, something to jog my memory, or to help think about aspects of a project that might not seem obvious at first. For example, what is the deadline, what about forecasting our storage requirements for the coming years? Is our updated hardware going to support the growth? What about supporting services? This machine just happens to many NFS exports and some samba shares to other servers and several client machines. What about uptime requirements? How much downtime can be accept?

Have the user write, or work with them to write, a brief overview of the expected result is. 

Things to think about while working through the user requirements:

* when is the hard/soft deadline (mention testing time)
* how much traffic/bandwidth/interconnects?
* how much hardware?
* storage requirements?
* network access rules (are people going to use this outside the company) / ACL rules
* user access / passwords (local accounts, ldap, etc)
* backup requirements
* power requirements
* monitoring requirements
* single-mode/multi-mode fiber?
* sfp/gbic specs?
* HVAC cooling?
* supporting services? (nfs/smb/ldap/dns/dhcp/etc)
* weight?
* uptime requirements
* hostnames
* custom DNS?
* ssl certs
* known image or configuration management tweaks?
* known software or something we need to figure out?
* NFS home directories?
* custom NTP?
* remote management (console, ipmi, remote reboots, sensors)

Your list will likely look different, based on the types of projects that you work on, there as also some lessons to be had in here. For example, these single-mode vs multi-mode fiber and sfp/gbic lines. I was once working on a project to deploy a bunch of servers and 10g switching gear into a remote data centre. We had our own little contained environment which was going to uplink into our hosting providers network infrastructure via a 10g fiber connection. I made the mistake of thinking they would use multi mode fiber, just like us, how wrong I was. Fortunately we built in enough redundancy, and had shipped spares gbics, so we ended up gifting one of our spares to the hosting provider as our 10g network uplink. I guess my point is, is that as you run into these types of issues, you can feed this back into the planning phase of the project, just so that you will know not to make that mistake again. You will also help other staff members, or your future predecessor, to think about these types of mistakes by writing them down.

You will notice up here, I have writing: Have the user write, or work with them to write, a several sentences overview of the expected result is. This is how I like to start the project plan, by having a little section about what the user expects, in this case we are the driver for this upgrade project, in that we need to ensure we have enough storage capacity for our users future growth.

So, lets jump over to our Project Planning Wiki page for a minute. You will notice that I have already created a Storage Upgrade 2014 project entry. In the interest of saving time, I have already writing a couple sentences to describe the project. Lets go have a look at them.

Internal project to upgrade 36x2TB disks with 36x4TB disks on the mercury research server. The goal is to roughly double raw storage capacity from 72TB to 144TB (although usable will be less).

== User Requirements ==

Bob Smith updated the ABC Research Group storage forecasts for 2015-2017, and submitted a request for 10TB of additional storage on the mercury research server. They are expecting data to arrive early March 2015. Low priority until the due date. ABC Research Group would like to have minimal downtime of NFS and Samba exports during upgrade process, so they can continue publishing research papers based off existing data.

We start the page off with a description of what this project is all about, it is an internal project to upgrade 36x2TB disks with 36x4TB disks on the mercury research server. The goal is to roughly double raw storage capacity from 72TB to 144TB (although usable will be less). Just in case you are curious, the machine looks something like this, 24 x 3.5 inch drive bays in the front, and 12 x 3.5 inch drive bays, along with 2 x 2.5 inch drive bays in the back. Often times with projects, you will already know what needs to be done, you just need to create a plan for making that happen. In this case, it was a no brainer to upgrade the disks, since the hardware was still current, just the disks were getting a little old, so there was not much discussion about it.

Then just after our brief project description, we have a section about user requirements based off our checklist from earlier, and it goes like this: Bob Smith updated the ABC Research Group storage forecasts for 2015-2017, and submitted a request for 10TB of additional storage on the mercury research server. They are expecting data to arrive early March 2015. Low priority until the due date. ABC Research Group would like to have minimal downtime of NFS and Samba exports during upgrade process, so they can continue publishing research papers based off existing data.

Sounds like a fairly simple job, but when you have close to 60 TB of existing data you need to juggle around, all while trying to minimize disruption, you need to have some detailed planning.

This is probably the best place to stop the episode, at this point, you should know what the planning steps are at a high level, what the user requirements checklist looks like, and we have started our example project plan. In part two of this episode series, we will flush out our project plan and start to execute the plan.

#40 - Simple Project Planning for Sysadmins (Part 1 of 3)

Links, Code, and Transcript

You may also like...