The IT Project Plan

It is surprising how many organizations begin projects without having spent time planning for them. There is the code like hell syndrome, which is to begin coding before a plan is in place. This syndrome is based on the belief that all things can be fixed with software. Furthermore, those who practice this syndrome believe there is no time waste. Another often heard question is: Why spend the time planning when technology changes so rapidly anyway?

In a well-planned project, the cost of analyzing requirements, building a project team, planning the project work, designing and optimizing the deliverables, and hiring vendors or teammates can easily consume 50 percent of the project budget before the project is ever implemented. Without a plan, preparing and controlling this expenditure is not possible.

Project planning is necessary and important. If it is done correctly and the organization supports it, approximately 50 percent of the project's budget is used up by the time the project itself is implemented. That means that half the budget is spent on analyzing the requirements, building the project team, planning the work, and designing the deliverables. Without a plan, none of this is possible.

Plans vary from industry to industry and from organization to organization. However, all project plans have basic components. The next section describes a generic project plan that can be tailored to any industry.

The IT Project Plan Format

Exhibit 6-1 illustrates a generic project plan format. This format has been developed over many years by practicing project manager in various industries. The plan's components are discussed below so that you understand what is typically provided in each section and so that you can easily adapt the sections to your own organization and project.

Exhibit 6-1: A generic project plan format.

start example
  1. Executive Summary

  2. Project Description

    1. General description of the project

    2. Project objectives

    3. Project fit with strategic goals

  3. Technical Approach

  4. Contractual Requirements

  5. Resource Requirements

    1. Equipment

    2. Materials

    3. People

  6. Schedules

    1. Master schedule

    2. Detailed phase schedules

    3. Milestone chart

    4. Deliverable schedule

    5. Meetings or other customer-required schedules

  7. Cost Estimates and Budget

  8. Potential Risks

  9. Evaluation Criteria

  10. Appendixes

    1. Systems engineering management plan

    2. Risk plan

    3. Communication plan

    4. Logistics or other special-purpose plans

end example

Executive Summary

The executive summary is written last because it is meant to be a short description of the project and it is intended for senior managers. The idea is to provide a description of the project that key stakeholders can quickly read and digest without burdening them with technical details—a synopsis of the reasons for the project and its major characteristics and functional capabilities. If a stakeholder needs more information, she can get it from the remainder of the project plan.

The executive summary should be viewed as exactly that—a summary. It usually is relatively short, about two pages, but can be longer, depending on the size and complexity of the project. It should be written as succinctly as possible so that readers can quickly read and digest it but still be able to talk about the project with some authority.

Project Description

This section provides a narrative description of how the project manager and team will accomplish the project's goals. It should describe both the management and the technical approaches to accomplishing the project. Precise details of how to manufacture a part or of the steps in developing some software are not required, but the general processes of each step of the project should be described.

This section should also discuss the relationship of the project's technical approach to existing technologies. If it is anticipated that new and different technologies will be required, this section should discuss how they would be integrated into the project.

This section also describes the requirements of the project, the objectives, the scope (how large the project is), the time line, the type and number of end products, what the measure of success will be, and how the project goals mesh with the organization's goals. This section is usually very detailed and can be several pages long.

Technical Approach

This section is an opportunity for the project manager and project team to explain what processes are required to achieve the goals of the project. Both the management and technical processes should be outlined here. It is not necessary to describe the exact manufacturing steps of building a piece of equipment, but the general processes of each step of the project should be described.

This section should also discuss the relationship of the project's technical approach to existing technologies. If it is anticipated that new and different technologies are required, then this section will discuss how these new technologies will be integrated into the project. Remember that rapidly changing technologies are a burden and one of the primary risks in attempting an IT project. Therefore, it is to the project manager's benefit to have a plan for dealing with these changes before they occur. Not only is it wise to be ready to cope with such changes, but your project stakeholders will certainly feel more comfortable with your leadership.

Contractual Requirements

Often this section will not apply to your project, but occasionally a project comes about because of an external contract. In this case, there are some specific and far-reaching contractual clauses that must be considered before the project progresses too far. For example, it is common in the public sector to let a contract for a needs analysis. In such cases, the buyer, in this case a government agency, always stipulates that the contractor performing the work will not be allowed to bid on any resulting follow-on contracts. This type of special contractual requirement needs to be in the project plan because all stakeholders need to be reminded, in writing, that this project will end the organization's participation in the work that follows.

Other contractual requirements that should be mentioned in this section include customer-mandated milestones or special reporting requirements—anything that the project manager feels should be brought to the attention of key stakeholders.

Resource Requirements

Resources include anything needed to accomplish the project's goals. The resource of greatest concern is people to work the project. That is because projects usually start with inadequate numbers of people or with individuals who possess less than acceptable skills. Some resources, such as materials or equipment, are easy to acquire—but acquiring the right people for the job is not so easy. Other major resource requirements include special equipment, such as computers, special test equipment, or desks and office space, and any kind of materials, that is, hardware, special connectors, or cabling.

It is important to break out these costs for several reasons. First, it is easier for the project manager to negotiate for resources if he can enumerate them precisely. Second, it really is the only way to identify the exact project costs. Third, having a detailed accounting of costs enables the project manager and team to determine where cost cuts can be made without jeopardizing the project.


The schedule section of the project plan quickly becomes unwieldy. My personal preference is to give a brief overview of the schedule requirements, perhaps a milestone chart as well, and then attach the schedules as an appendix. This approach serves two purposes: First, it eliminates the necessity of having foldouts to accommodate the size that schedules generally require, and second, appendixes are easy to detach and use as a separate document. Initially, of course, the appendixes need to be a part of the plan for approval purposes and so that the whole plan approach is understandable. But considering that there can be a number of schedules (master, task, milestone, meetings, and so on), summarizing them in this section and attaching them as appendixes makes a lot of sense.

One thing that many new project managers don't understand, or are surprised by, is the number of meetings that a customer can require. For example, I once had a government customer who required that we schedule a meeting every two weeks for the duration of the project, which was three years long. The project plan contained only one schedule of meetings.

One other important type of scheduling tool that is often overlooked for this section is the network analysis. A network analysis, either a PERT or precedence diagramming analysis, is required to determine the critical path and other risk areas. The schedule section is the place to show this analysis.


The WBS is the key project management tool. With it, the project requirements are completely captured along with the tasks needed to accomplish the work of producing the deliverables. With the project tasks identified, the schedules are developed with a PERT or precedence diagram. So the WBS must be developed first, then the schedule.

After the schedule is set and the number of resources are determined, the cost estimates can be developed. Some project management specialists determine the schedule before resources are considered; others determine the available resources, then develop the schedules around them. The fact is, these two approaches to planning have to be worked together. That is, one cannot determine the schedule without having determined the resources. Likewise, the schedule, particularly if the customer sets it, can drive the number of resources required. Hence, schedule and resource analyses must be done together and the appropriate trade-offs made to optimize both factors.

Usually, the project is approved and ready to begin before the project manager is even assigned. The best-case scenario is one that includes the project manager in the analysis and selection of the project. If, however, the project manager suddenly finds himself in charge of a project with no knowledge of its beginnings, it is indeed wise to verify the budget. The project manager should always determine whether the assigned budget is adequate to accomplish the project requirements. After all, if the project is a success, perhaps the project manager will get the credit. But if it is a failure, the project manager certainly will be held responsible. Developing a cost estimate to verify adequacy of the budget may not get the budget changed, but it will allow the project manager to document that the analysis was accomplished and the key stakeholders were notified. At the very least, the project manager and team will know whether they have to cut costs to meet the given budget.

Potential Risks

Analyzing project requirements is the first opportunity to identify potential risks. It is imperative that any potential risks are identified and documented in this section. Furthermore, a contingency plan to handle these risks is crucial. Generally, the type of risks that surface this early in the project revolve around resources and, often, schedule. For instance, a requirement needing the services of specialized skills not resident in the organization poses a significant risk to the project's success. Also, if the customer sets the schedule because of, say, some operational or marketing need, then this might increase the risk to the success of the project. These risks should be identified in this section. In the previous examples, a plan that provides a contingency contract with a vendor or consultant who has the requisite expertise and the addition of resources to reduce the time it takes to accomplish the work should be provided, respectively. However, remember that adding resources generally does not result in reducing the schedule in the IT industry. In fact, adding resources often increases the time to finish a task or project because of the learning curve required to bring new resources up to speed. (This is not the case in other engineering or construction projects—adding resources usually reduces the schedule significantly.)

Clearly, the project team will not be able to identify all the project risks, but with experience, the use of the initial team, the WBS, the network diagram, and general lessons learned information, many of the likely risks can be identified. One very good way of capturing these potential risks in this section is with a matrix similar to Exhibit 6-2. This matrix identifies the risk, its level (high, medium, or low), a brief description of how the risk will be dealt with, and the risk level after the contingency plan is implemented.

Exhibit 6-2: Risk analysis and contingency strategy matrix.

start example




Risk Level

Contingency Strategy

Risk Level After Strategy Implementation

Deliver fully functional prototype within six months of contract date,

Customer is not clear on functional needs.


Involve customer in prototype design and development.


Integrate new version of XYZ operating system into communications package.

No expertise with XYZ OS; don't know extent of defects in new version.


Hire XYZ developing company to integrate new OS version into the communications package.


Provide 1,500 stations per month for customer operations.

Manufacturing capability currently at 1,300 per month.


Add second shift to manufacturing line.

Low to medium

Test first system by July 15.


Test software code as it is written.


end example

The matrix usually will contain ten to twelve risks, the approximate number that a team can actively monitor and control at any one time. The real importance of such a matrix is to communicate to the major stakeholders and especially to the customer. This matrix clearly identifies the risk, the risk level, the strategy for mitigating the risk, and how the strategy will reduce the risk level when it is implemented.

Risk identification begins with requirements definitions and continues throughout the project's life cycle. The primary tools that will help the project team identify risks are the WBS, because identifying tasks to meet the requirements will reveal resource, schedule, quality, and technology shortcomings in the organization, and the network diagramming techniques, because networks reveal interrelationships.

Once these key sections of the plan have been developed, it is time to consider how you will know whether the project is progressing satisfactorily. The section on evaluation criteria tells you what you need to do to find out.

Evaluation Criteria

The importance of establishing evaluation criteria designed to measure how well the project is doing against the customer's requirements cannot be overstated. The customer may mandate some evaluation criteria in the form of product demonstrations, status reviews, or tests. Furthermore, standards established by the industry, regulatory agencies, or environmental groups define processes or procedures for the organization. But the project manager and her team also have to establish criteria against which to measure whether they are meeting the project requirements. These criteria may include milestones, sign-off points by the customer, or quality checks by the project manager or, more appropriately, by an independent person or group. One good way of evaluating the project is to have an independent team perform a technical and financial audit on the project at various points in the schedule. Project teams do not generally view audits very favorably because the very word implies looking for something wrong and, more to the point, attaching blame for whatever is uncovered. But audits are important tools in the business of managing projects. If they are thoughtfully introduced and intelligently used, that is, not for punishment but for improvement, they become a very powerful means of evaluating the project's work.

One other major section of the IT project plan is often over-looked, or at the very least, shortchanged. This section deals with ancillary and additional plans or other informational documents that are pertinent to the project and/or important to the project team and stakeholders. This section is the appendixes.


The appendixes are a very good place to collect additional required plans and such things as schedules. I always attach my schedules and network analyses as an appendix because, first, they tend to be bulky and are usually on foldouts and, second, schedules and network diagrams are the kinds of things that the project manager and her team need to constantly consult. As appendixes, they are easily detached for daily use. More important, the appendixes are the place for other project-related plans, specifications, and engineering drawings.

Often, because of specialized needs, the customer will include specifications about the products needed. Let us say, for example, that the project is to develop and build a communication link to a remotely controlled drone for the military. In this case, the customer (the Department of Defense or the Central Intelligence Agency) would very likely include product specifications and perhaps even some engineering drawings of some of the components. If so, these documents would be attached to the project plan as appendixes.

Other appendix candidates are ancillary plans such as the risk plan, quality plan, the communication plan, and the systems engineering management plan. All these plans are important to the project team and have to be available for their use before the major work on the project begins. If the project has resulted from a contract outside the organization, particularly if the customer is from the federal sector, then these plans will have been required and will have to be approved by the customer. Even if the project is one internal to the organization, developing the plans before work on the project begins is crucial. This is because the project team usually doesn't have the time or the inclination to stop work and develop plans if they already are in the midst of completing their assigned project tasks.

The key to a successful project, or anything else for that matter, is a carefully thought-out plan. In the case of projects, it is absolutely imperative if the project has any hope of success. One problem all project managers have is getting the plan completed and in place before pressure from senior management requires that the project work, that is, actual designing, coding, and building, is begun. A phenomenon that plagues us all is the appearance that work is not being done unless we can actually see progress. Planning is a thinking and writing exercise and simply does not give the same appearance of movement that, say, writing code does. Thus, the project manager must find ways of convincing senior management that progress is being made even though the progress is largely mental. Whether the project requirements are met within the customer's expectations depends on how well the plan is developed and, of course, implemented.

Managing Information Technology Projects
Managing Information Technology Projects: Applying Project Management Strategies to Software, Hardware, and Integration Initiatives
ISBN: 0814408117
EAN: 2147483647
Year: 2003
Pages: 129
Authors: James Taylor © 2008-2017.
If you may any questions please contact us: