Project management for networking geeks

Network professionals are typically well versed in the technical aspects of networking: router and switch configuration, server deployment and management, and so on. They are rarely trained on how to manage projects, however. This is unfortunate, because many of the problems that networking pros face in projects can be mitigated with just a few project management skills and techniques.

Design and install networks long enough, and you'll be sure to have some projects go awry as a result of unforeseen surprises. Sometimes, the power in a communications room isn't ready when you need to install an Ethernet switch. Other times, the one piece of network equipment you need is on perpetual back order. Or users decide they need greater wireless coverage than they asked for — for the same cost, of course.

Managing network projects doesn't have to be an exercise in fortunetelling, however. At heart, a network project is just like any other project: It has an objective, a timeline, a budget and client expectations.

Properly trained project managers command hefty salaries because they understand these factors, but I've discovered in my own pursuit of a Project Management Professional certification that applying a few simple project management tips can make a big difference.

Triple Constraints

I once saw the following on the wall of an oil-change service station: “You can have it done cheap, fast or right; pick two.” This is true of all projects, and it illustrates the so-called triple constraints rule: Projects are subject to cost, schedule and performance parameters. Changing one will affect at least one of the remaining two.

For example, let's say you're installing a network to allow for Internet access and e-mail at Shelbyville Bank and Trust. The project includes configuring a Microsoft Exchange server and installing a virtual private network firewall for security. The deadline is in two months.

One week into the project, things change, and the network needs to be done in three weeks instead of two months. Your staff is already fully devoted to this and other projects. You can't cut out functionality, because the office still requires all of the network connectivity and e-mail functionality. What can you do?

The only way to accommodate the schedule is to increase manpower by paying overtime to your employees or subcontracting. Either way, the cost will go up, yet the bank will likely balk at that. At that point, armed with the understanding of the triple-constraints principle, you can calmly explain why the new deadline will increase the overall network project cost.

Charter and Scope

To reduce the likelihood of a network project growing uncontrollably, make sure everyone understands the project deliverables — what the network will provide, how long it will take and at what cost. Your key constituencies here are the project sponsor (the person requesting the network installation or change) and the network administrator.

Start from the general (the project charter) and migrate to specifics (project scope).

The project charter could simply be, “Provide network connections for the new Shelbyville Bank and Trust building at 123 Main St.” Details, including the number of connections, security protections needed and services desired, are best left to the project scope. The scope simply supports the goals defined in the charter while providing more details; it is not a complete network-engineering plan in itself.

You can create an initial cost estimate for the project from the scope. If the scope is too broad (or missing), precise estimates are impossible.

A good trick is to take a network project of comparable scope that you worked on previously and use that as a basis for the estimate. Give a range rather than a single-figure estimate — maybe 50% on either side of the estimate derived from historical knowledge. As the scope becomes more clearly defined, refine the cost estimate by changing the midpoint as appropriate and reducing the range size.

Schedule

Once scope is known, determine a project schedule. You'll already know the two most important project points: the beginning and the deadline. It's up to you to fill in the blanks.

Here's where a project management software package such as Microsoft Project really comes in handy. It can tie all aspects of the network project together. Setting up the plan can take some time, but it will pay dividends many times over the course of the initiative.

How do you start? Let's take the bank project, which is slated to begin on March 5 and demands that the network be completed by July 31. Suppose you know from experience that you generally receive network equipment from your supplier four weeks after ordering.

Furthermore, you know that it typically takes two weeks to configure and burn in the equipment and another two weeks to install and test. Start from the deadline and count backward eight weeks; that's your milestone date for ordering the equipment. And so on.

Scope Creep

Scope creep is a change in project requirements after the project is under way. A common example that most networking professionals have encountered is when the customer decides it needs more network capacity (number of jacks) than what you planned for.

But changing the number of connections doesn't just affect network electronics costs. Additional cable drops and patch panels for terminations may be needed. Additional switches or servers may require heftier uninterruptible power supplies and may increase heat generation, forcing an upgrade of the HVAC design of the communications room or data center.

Scope creep arises because of an assumption that everyone was in agreement, when in reality, everyone was not. When all parties truly agree on the scope at the beginning of the project and understand the costs of scope creep, it's less likely that it will occur.

If the scope really needs to change, simply create a new cost estimate and timeline to accommodate the modification. Changes are not necessarily all bad, as long as everyone involved understands their effects.

Closing Out

Once the network infrastructure is completed, there are still three major tasks to accomplish before the project can be closed. The first is rather obvious — ensuring that the network functions as the customer intended. The customer should perform as many business-related tasks as possible to test the infrastructure and then formally sign off and accept the project. This prevents end-of-project scope creep.

The second job, too often neglected, is to fully document the network to ensure that it is manageable and supportable. Network drawings, router configurations, circuit numbers, server disk partition information, IP address assignment — everything that was pertinent to the successful completion of this project — should be documented and stored where it can be easily retrieved.

Finally, a postproject review, particularly of what went wrong, will help prevent the same mistakes from happening on a future project.

Remember, you don't have to be a certified PMP to think like one. Try it!