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.
Resources
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.
Standards
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
