Monday, May 11, 2015

Planning an IT project

Successful IT projects don’t happen by accident. Good project management is one of the keys to ensuring that the project is completed according to expectations.

In this article, let’s start with the assumption that the project is approved, and it is time to start building the project plan. This article outlines some items to consider when planning an IT project.

Define Objective and Results

First of all, it’s important to define the purpose of doing the project. Outline the business need the company is trying to fulfill, and how this project fits with long-term goals.

Describe the end results of the project including which software modules will be developed or implemented, which end users will be trained, which manuals will be completed.

Project Scope

Outline what exactly is within and outside the scope of this project. Remember to include items such as hardware set up, testing, documentation, and end user training.

In setting expectations for the project team and the end users, defining out-of-scope items is just as important as defining in-scope items.

Project Work Schedule

Figure out an overall plan for the project. For example, define which modules will be developed or implemented in what order. Decide whether training and implementation will be done by module, by region, or all at once for the whole company.

Break down the overall plan into smaller parts to create a work schedule. Outline which activities will be done at what time during the project. Determine which parts of the project depend on others being completed first and which can be done at the same time.

Set the Budget

Determine the budget for internal and external resources, software, hardware, travel, and accommodation costs. Include costs for publishing documentation and equipment needed for training of end users.

Based on the work schedule, determine how much money will be spent in each time period.


Identify what types of resources are needed to work on the project. Decide how many people who already work for the company can fill these project positions.

When using staff from inside the company, determine how their regular duties will get done while they are involved in the development or implementation project.  Be specific, and don’t accept assurances that the staff will be able to cope with their regular duties as well as their project responsibilities. Loss of internal resources who get pulled back to their regular jobs can be a serious problem in achieving the project objectives.

For project roles that cannot be filled by internal staff, determine where they will be found. They may be loaned from another division, hired as consultants, etc.

Determine the Completion Dates

Be realistic in setting the intermediate and final completion dates for the project. Find out when vacations are, so there are no surprises later and the plan can be laid out with the vacations built in. The project team members will be attending progress meetings and maintaining their part of status reports, so allow enough time for these elements of their work.

Add extra learning time to the schedule if team members are relatively inexperienced or if a new technology is being used.

Keeping the completion dates reasonable may be one of the most difficult parts of planning the project. There is frequently pressure from others (for example, upper management) who don’t know what is really involved in accomplishing the various milestones but want to set them anyway. Explain how the dates were derived and resist the demands for unreasonable dates.

Unmovable Deadlines

Sometimes there really are unmovable deadlines (for example, implementation of new tax policies). In these types of circumstances, do a draft of the schedule to determine what the project completion dates would be based on work to be done and resources. Then, if the completion date calculated is too late, determine what changes can be made to the plan in order to meet the deadline. “We’ll work harder” is not a reasonable solution. To correct a deadline problem, either add extra resources, or reduce scope. If you need to cut scope to meet the deadline, you can create a second phase of the project to complete the remaining work.

Assess the Risks

Identify potential sources of risk to the project. For example, if a new technology or new software product is being used, assess the impact on the project if the product doesn’t work as well as expected. Or, determine the risk and implication of losing a key member of the project team.

If any of these risks have a high likelihood and/or have a serious impact on ability to complete the project, find a way to reduce the risk if possible. For example, additional product testing early in the project could be scheduled. Cross training of key members of the project team may reduce the impact of losing one key person.

Contingency planning can also be used to mitigate risk. For example, if a vendor missing a delivery date would be a serious problem, find out if it would be possible to buy from another vendor or if the equipment can be rented temporarily.


Establish standards to be followed by team members during the project. For example, in a development project, it is important that programmers and testers know the programming, testing and documentation standards to be followed.

In addition, set the standards to be followed for creating end user documentation, tracking issues, and maintaining multiple versions of project documents. For example, is there a specific form or database to be used for logging issues?

Status and Coordination

Determine how the status of the project will be reported to the stakeholders. Some options include meetings, newsletters, and reports. Decide how the project steering committee will be kept informed of progress, how frequently the committee meetings will be held and who will attend.

Find out if there are other projects going on in the company at the same time or external projects (e.g. customer or supplier) that have to interact with the new software. Decide how the new project will be coordinated with the other projects. Options include wikis or other knowledge-sharing software, coordination meetings, and conference calls.

Change Control

Outline the procedure for making changes to the project while it is underway. Decide who will be responsible for gathering cost and benefit information, and who will be authorized to approve the change to the project.

Revise the Plan

Completion of the project plan is an iterative process. At any of the steps outlined, it may be necessary to re-work one or more previous steps. For example, perhaps staff will not be available internally and the deadline cannot be achieved. In that case, it will be necessary to reduce the scope of the project, adjust the deadlines or add external staff. Then, if external staff are being added, the budget will also have to be changed.

Approval of the Plan

Review the project plan with the steering committee. Obtain written approval from the steering committee for all aspects of the project plan.

Execution and Completion

The first step in good project management is a good project plan. Now that you know what to include in your plan for the project, I’ll cover the execution of the plan and completion of the project in the next article.

Copyright 2015 Debbie Gallagher