Embrace Project Management or Die
Buzzwords, inflated job descriptions and over-complex tools cause administrators to shy away from project management, but that's the last thing they need to be doing.
The case for having project management skills has never been stronger. Senior-level systems administrators often find themselves leading change and implementing new and exciting systems. The old adage, "all roads lead to management," is certainly true, and those that embrace the inevitability climb the ladder more quickly--or, these days, keep their job.
Project management is about two things: documentation and a common vocabulary. You already do most parts of project management, mentally, and applying a framework can help refine your thought process and enable you to share your plan with others.
What Is Project Management?
Firstly, project management is not Microsoft Project. Second, it is not Gantt Charts. Finally, it is not reserved for people with the certification and title of project manager. Project management is something we all do. Too often, people get caught up in the tools designed for extremely large and complex projects. Managing small, or even large, projects is not supposed to require daily hours dedicated to wrangling the tool.
Project management is a framework for organization--and it doesn't have to be difficult. Project management boils down to a few simple steps. You list the component tasks required to get each major step in a project done, along with the estimated time they will take. Optionally, you assign resources (humans) to the tasks, and map out how much work they are allocated, often in relation to the amount of time the resource is allowed to work on the project in addition to his regular duties.
Simply graphing out these points of data is a major step, and the majority of all up-front project management work that gets done. The rest of project management is tracking progress, which gets into basic managerial skills.
Applicability to Sysadmin Work
The truth is, most people (even professional project manager) only use their project management tool of choice once per project. They input data, create a Gantt chart, and never go back unless major changes in the timeline occur. You already do this mentally, so why not take a few hours before a project starts to formally document it? Visualizing data like this, all at once, helps to gain a broader "perspective" view of it.
There are free Web-based project management applications available that provide this basic functionality. In fact, we reviewed a few of them recently. It may seem odd to refer first-time project management inductees directly to software, as a major complaint from even experienced project managers is that using the software is a constant struggle. Keep it simple, and use the tool to create a list of tasks and task dependencies, and you should find it palatable.
Some terminology and hints should get you pointed in the right direction. Most project management tools (and managers) speak a similar language.
It may seem obvious, but there are tasks and milestones, and they are not the same thing. A milestone is a major step in the project, and to get there, a number of tasks must be performed. Knowing which tasks come before others is intuitive and often makes logical sense. This is the part everyone already does, but as the complexity increases so do the number of tasks, and their relationship gets fuzzy.
The tool might support more, but the main type of task you will use is "finish-start." One task must be finished before another can begin. When many tasks overlap, and multiple finish-start relationships exist for a single milestone, mentally tracking these can be a hassle. This is where the Gantt chart helps you not only share the information, but understand it yourself.
Finally, if you are using software to help you, here is the most important thing to remember: do not constrain tasks to dates. If you do, it will disable auto-adjustments that happen to the timeline, and then you end up manually managing completion dates for all tasks. The idea is to define how long all tasks take, when the project starts, and whether or not the tasks can be worked on in parallel with other tasks. The application will tell you when tasks, and the entire project, will complete. Then, and only then, you have your deadline. Artificial deadlines chosen without information about each component of the project, are always a guessing game. Do not commit to a deadline until this process is complete.
Just try inputting lists of tasks in a simple interface--you will enjoy seeing a Gantt chart, allocating resources, and watching the whole schedule create itself. If thats the only feature you use, you will still be far ahead, and can claim to use "project management principals."
When he's not writing for Enterprise Networking Planet or riding his motorcycle, Charlie Schluting works as the VP of Strategic Alliances at the US Division of LINBIT, the creators of DRBD. He also operates OmniTraining.net, and recently finished Network Ninja, a must-read for every network engineer.