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. However, network pros are rarely trained on how to manage projects. This is unfortunate, because many -- if not most -- of the problems that networkers 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 of those projects go awry due to unforeseen surprises. Sometimes it's because the infrastructure you need, such as power in a communications room, is not ready when you need to install an Ethernet switch. Other times, your network equipment vendor may seem to be perpetually on "back order" with the one module you need. Or perhaps it's the all-too-familiar "scope creep" -- when users decide they need greater wireless coverage than they asked for at the beginning of the project, without increasing costs of course.

Managing network projects does not have to be an exercise in fortune telling. When digested down to the core components, network projects are just like any other project, IT or otherwise: There is an objective, a time line, a budget and expectations of those who will benefit from the network once it is completed.

Properly trained project managers command hefty salaries because they understand these processes. A casual search on or will lead to many job postings for certified project managers in many IT fields. And for good reason: CEOs and CIOs know that certified project managers are less apt to have projects run away from them.

But while attaining project management certifications such as the Project Management Institute's Project Management Professional (PMP) could be just as valuable to you as a network professional as a Cisco Certified Internetwork Expert or a Microsoft Certified Systems Engineer, you don't have to earn the full PMP certification to reap some benefits. I have discovered in my own pursuit of the PMP that applying a few simple project management tips will quickly earn you a reputation for delivering network projects on time and within budget -- the sort of reputation that opens doors.

Triple constraints

I once saw the following on the wall of a drive-in oil-change service: "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 for a local bank branch office to allow for Internet access and e-mail. The project includes configuring a Microsoft Exchange server and installing a virtual private network firewall for security. You included labor in your project schedule and quote to ensure that the project is done in two months, as requested.

One week into the project, the bank announces acceleration in plans, and therefore the office 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 is to add more staff, either by paying overtime to your employees or subcontracting another IT firm. Either way, the cost will go up, yet the bank will likely balk at the new cost. At that point, armed with the understanding of the "triple constraints" principle, you as a network pro knowledgeable in project management concepts can calmly explain why the request to change time will increase the overall network project cost.

Project charter and scope

To reduce the likelihood of the network project growing uncontrollably, make sure that 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.

By following project management methodologies, this can be accomplished by starting from the general (project charter) and migrating to specifics (project scope).

For network projects, the project charter could be simply "provide network connections for the new Shelbyville Bank and Trust building at 123 Main Street." 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. When the scope is broad (or perhaps when there is only a charter), precise estimates are not possible.

A good trick, however, is to take a network project of comparable scope that you worked on previously and use that as a basis for the estimate. It's also wise to not give a single figure estimate but rather a range, say maybe 50% on either side of the estimate derived from historical knowledge. As the scope is more clearly defined, refine the cost estimate by changing the midpoint as appropriate and reducing the range size.

Project schedule

Once scope is known, a project schedule should be determined. You'll already know the two most important project points: the beginning (most likely following immediately after the project scope is determined) and the end (when the network is needed as dictated by the sponsor). 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 project together by providing a relatively easy way to create the plan for the network installation. Setting up the project plan can take some time at the beginning, but it will pay dividends many times over the course of the network project.

When planning network projects, I prefer to break the project into the following six phases:

• Information gathering -- scope, existing infrastructure

• Purchasing decisions -- which switches, routers, firewalls, servers and so on are needed

• Ordering equipment

• Configuring and installing the servers and network equipment, and testing connectivity and functionality

• Customer acceptance

• Documentation

However, you decide to manage your network project, breaking it into smaller miniprojects makes the overall project more manageable.

For example, take the Shelbyville Bank and Trust project, which demands that the network be completed by July 31 and is slated to begin on March 5. Suppose you know from experience that you generally receive network equipment from your supplier four weeks from order. Furthermore, you know that it typically takes two weeks to configure and burn in the equipment and another two weeks to install and test. So, start from the end of project date and count backward eight weeks; that then becomes your milestone date for ordering the equipment.

Network project management

The Shelbyville Bank and Trust network project plan created with Microsoft Project 2007

Click to view larger image

Scope creep

Performance constraints can also change, and in networking, they are usually on the side of more functionality, not less. Scope creep is a change in project requirements after the project has been planned and is under way.

A common example of scope creep that every network professional I know has experienced is when the customer decides he needs more network capacity (number of jacks) than what you planned for at the beginning of the project. I like to inform customers upfront about the magic number: 24. Many vendor enterprise workgroup switches have a minimum of 24 Ethernet ports (some allow 48). Pass the magic number, or a multiple thereof, and expect the project's cost to increase (refer back to the "triple constraints" rule).

Of course, changing the number of connections does not just affect network electronics costs. Additional cable drops and possibly patch panels for terminations may be needed. An increase in electronics (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. It's clear to see that expanding the project requirements increases its cost, which is a problem when budgets are limited and fixed.

These problems exist because all involved with the project -- the sponsor, network administrators and the other stakeholders (end users, equipment vendors, cabling contractors, customers) -- assumed that everyone was in agreement at the beginning of the project. But this was not the case. When all parties agree on and understand the scope at the beginning of the project, it is less likely that scope creep will occur.

Finally, should the scope still need to change, simply create a new cost estimate and timeline to accommodate the scope modification. Changes are not necessarily all bad, as long as all involved understand the effects that any changes may have.

Closing out a project

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 the network functions as the customer intended. The customer should perform as many business-related tasks as possible to test the infrastructure and formally sign off accepting the project when complete. The latter will prevent end-of-project scope creep as well as provide a milestone for you to close the chapter on this project.

The second job, too often neglected, is to fully document the network. Remember, one of the goals when the project scope was created was to ensure the manageability and supportability of the network. Network drawings, router configurations, circuit numbers, server disk partition information, IP address assignment -- anything and everything that was pertinent to the successful completion of this project should be documented and stored where it can be easily retrieved.

Finally, network projects rarely go exactly to plan, and sometimes surprises occur that could really not have been foretold. A postproject review, particularly of what went wrong, will help prevent the same mistakes from happening on a future project. I recall one network installation in which a concrete slab was poured before conduits were installed, necessitating cutting the slab to install the conduits. The lesson learned was to include regular on-site network infrastructure inspection dates as tasks in the network project plan.

For more information

Again, you don't have to be a certified project management professional to take advantage of project management techniques to aid in your network projects. There are numerous Internet resources related to project management, including the following:

  • The Project Management Institute is the source of the Project Management Professional as well as other certifications. In addition, PMI chapters nationwide allow professionals (certification not required) to meet and discuss project management topics.
  • Prince2 is another project management methodology with certifications popular in Europe, particularly in the U.K.
  • The Project Management Podcast is an excellent regular (usually weekly) podcast on various project management issues.
  • is another project management podcast site with additional project management resources.

Greg Schaffer, CISSP, is a freelance writer in Tennessee. He has over 20 years of experience in networking, primarily in higher education. He can be reached at

Copyright © 2009 IDG Communications, Inc.

7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon