MAINFRAME > Administrator > Networks

Project Planning for a Network

Project planning


Just as in other aspects of an IT department, an information processing network’s complexity, security, function, performance and pervasiveness have evolved into a mushrooming flow of proliferating data types, protocols, disciplines, challenges and pitfalls that require constant attention and enhancement. It’s a moving target in a constant state of flux, exponentially different from the networks I implemented forty years ago, similar in the need for ongoing enhancement and expansion, but with a rate of change and technical diversity that dwarfs those early days by several magnitudes.

As a consequence, project planning and management has become absolutely vital for the operation, expansion and enhancement of networks. When I joined IBM, I had the good fortune of working with an excellent and seasoned account team, along with large, technologically advanced insurance companies. Thanks to their leadership, I learned the importance of creating project plans, project tracking, project reporting and project tailoring as necessary.

When I left IBM after 17 years to start my own consulting firm, project planning became drasticially more important. Now, projects were a blend of my staff and client staff, and defining everyone’s roles and tasks became imperative. Furthermore, client management required regular briefings on project progress, and a periodic (usually weekly) project plan review was a great way to do it. Project complexity grew, fueled by technology’s increasing pace of evolution, the intensity and unique requirements of Y2K conversions, the advent of security breaches and technology’s increasing impact on everyday life.

All these factors made project planning essential to successful engagements, and the companies I engaged were delighted with the insights and control they provided. As project leader, I was the keeper of the plan as well as the plan creator. Project plans unavoidably had some manual aspects, so a project assistant was needed. Project reports were established, projections produced and financial aspects identified. The project team worked from the plan, provided input, submitted changes and attended weekly project reviews. The plan was the engine for the effort.

Just as with computer software or hardware changes, project planning and management is vital to smooth network upgrades, reconfigurations, expansions or other modifications. Project plan creation, tracking and implementation gives the overall effort direction, impetus and enlightenment. It instigates interaction and generates chemistry between project participants, keeps management informed on the project’s current status and provides a backdrop for making changes in reaction to problems, delays, unanticipated shortcomings or functional deficiencies. A project plan keeps the parts working in concert.

Network Project Plans Are Novel

There are some characteristics that distinguish a network project plan from other IT project plans. Probably the greatest difference is the substantial involvement and investment network providers have in equipment, access authority, service agreements, performance standards, standards, protocols and numerous other business or technology metrics. Unlike computer-based IT institutions, where the client often owns or leases most of the hardware and software, network-based vendors often own much of the hardware, software and microcode. In addition, many of a network provider’s clients share these transmission and communications facilities, so network vendors have to cater to client needs. Consequently, vendors also often control much network testing, maintenance, facilities and technology decisions, thus assuming primary responsibility for product installation, problem determination and resolution, monitoring, and security administration and enforcement.

The Value of a Network Project Plan

A major project plan advantage is to unify and organize a group of people toward the common objective of successful project completion. This unification can provide the following benefits:

  • Individuals clearly understand their and other team members’ responsibilities
  • The majority of research gets done up front and documentation becomes more accessible
  • Realistic project scope and schedule get efficiently determined
  • Project tracking and reporting functions get clearly defined
  • Reassignment of work to meet priorities becomes clearer and simpler
  • Communication between members is more efficacious and clear

Project Plan Components

With today’s project management tools, a plethora of attributes can be assigned to a task, but using too many parameters can confuse and complicate the plan. A project plan doesn’t need to be fancy and sophisticated to be effective. Here are some key plan components:

  • Task name. It’s vital to identify as many project tasks as possible, plus subtasks of a task. Most important is exhaustive task identification during the planning cycle, and the addition of new ones as they emerge.
  • Task sequence. This organizes work in the desired order of completion.
  • Task pre-requisites. This further organizes task order of completion.
  • Task assignee. Individual(s) assigned to each task.
  • Task start and end dates. These should be realistic and attainable.
  • Estimated hours. Optional but usually used. They need to be realistic.
  • Completion amount. Task by percentage completed. 100 percent means the task may be filtered out.
  • Supporting information. Footnotes, supporting documentation or hyperlinks to information resources.
  • Task number. Number assigned to a task.

Other components can be included, but the above items comprise the key elements.

A Project Plan Is a Living Document

I prefer to start a project plan alone, using one or more templates I’ve created. When a project was for something I had no template for, I’d still do a first cut and create a new template. I’d research the project, soliciting input from individuals involved in the project, knowing drastic changes would be made before it became “The Plan.” The first cut was a starting point, a basis of discussion. The next step was a kickoff meeting—the centerpiece of project plan creation, and a 1-3 day affair depending on project size. All key project participants attended, and we’d exhaustively review every aspect, updating the plan each day for the next day’s scrutiny. After the meeting, the proposed plan was sent out to everyone and updated one last time based on feedback.

But even then, the project plan wasn’t complete. In fact, a good project plan continues to evolve as a project progresses. New tasks crop up, existing tasks and time/date estimates change, project re-assignments occur, tasks are completed and change is continual. Weekly project updates, progress reviews, problem assessments and other details arise, only becoming apparent as a project proceeds. The revisions are constant, and a project plan is complete only when the project itself is complete.

Detail Is Vital

The importance of attention to detail—especially during early project plan creation—can’t be overstated. The deeper you dig, the more tasks arise. The more tasks are found, the more accurate and complete the project plan. Project plans set expectations—especially with management—and there are always surprises as a project proceeds. Surprises don’t go well with expectations, and can result in undue pressure and demands that lead to mistakes and missed schedules. The more work invested in building a project plan, the better.

The Complexity Is Worth Your Time

The dynamic interplay between network providers and IT enterprises is both subtle and convoluted, adding complexity to project plans designed to plot the path to network enhancement, expansion and reconfiguration. But the fundamental value of a project plan hasn’t changed over the years; it’s the best way of planning and organizing a project, and the more comprehensive it is, the more effective it is.

Be careful about hourly estimates; they’re dependent on skill level, how well a task is understood and whether there’s history on which to base an estimate. Getting these estimates wrong can be demoralizing. Allow for tasks or issues that simply can’t be foreseen but that have major impact on project success. Nothing is perfect, but a good project plan gets you closer.

Jim Schesvold is a technical editor for IBM Systems Magazine. Jim can be reached at jschesvold@mainframehelp.com.



Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.


comments powered by Disqus

Advertisement

Advertisement

2018 Solutions Edition

A Comprehensive Online Buyer's Guide to Solutions, Services and Education.

Mainframe > Administrator > Networks

Bringing Voice and Data Together With VoIP

IBM Systems Magazine Subscribe Box Read Now Link Subscribe Now Link iPad App Google Play Store
Mainframe News Sign Up Today! Past News Letters