IEEE ENGINEERING MANAGEMENT REVIEW, VOL. 45, NO.
2, SECOND QUARTER, JUNE 2017
Project Management Tools—
A Few Basic Tools
—CELIA DESMOND
World Class Telecommunications
IEEE DOI 10.1109/EMR.2017.2701509
Authorized licensed use limited to: Staffordshire University. Downloaded on September 01,2020 at 08:13:58 UTC from IEEE Xplore. Restrictions apply.
25
I N the previous issue this column
introduced the concept of tools for
Project Management with a promise
to discuss, in this issue, a few of
those on the list below. Most of these
are basic tools which will be familiar
to project managers. For others,
some discussion will be valuable. As
a reminder, here is the list presented
in the last issue.
 Project Charter
 WBS (includes deliverables but
not money, time or people)
 Schedule (illustrated as a Gantt
chart or Network Diagram)
 Cost Baseline
 Resource Register
 Status Reports
 Risk Register
 Stakeholder Register
 Change Log
 Issues Log
 Requirements Specification
Document, Requirements
Traceability Matrix
 Minutes of meetings
 RACI Chart
 Project Management Software
 Storage facilities for project
management documentation
The Project Charter is one of the first
tools most project managers
embrace. This is a very useful
document, as it gives a high-level
description of the project. The
purpose of the Charter is to authorize
the initiation of the project, once
signed by the Sponsor and the
Project Manager. It describes the
charge passed from the sponsor to
the project manager and the team,
covering most of the areas of project
management – project scope, team,
timelines, budget, risks, assumptions,
constraints, possibly some
information on communications, etc.
Because the document covers such
a wide range of topics, many think
that this should be a long, detailed
document. That is not the case. This
document should be quite short,
probably in the order of 3 pages.
Therefore, the information included
must be high level for each of the
topic areas. The Charter can be used
as a communications tool, to describe
the project to key stakeholders, such
as team members, functional
managers who will support the
project, suppliers or subcontractors,
even clients. A longer document will
not be well received by some of
these.
In some cases the document that
officially activates a project is a
contract. When a buyer contracts a
supplier for a product or service, a
contract is often involved. The work
should not start until the contract
has been signed, thus making the
contract the official activator for the
project. In this case, the contract is
the Charter, but in addition to
containing legal terms most of which
are not useful in describing the
project scope and work, contracts
also tend to be too long to be useful
for communications. In this case,
the PM should prepare a separate
Charter for use in sharing the project
information with the stakeholders.
Of course, the team will need to have
considerably more information than
the Charter provides. The tool for this,
which is not included in the list above,
would be a Scope Statement or
Scope Description. This document
should contain all the details needed
to ensure that the team members
have clear understanding of the
scope and the work.
26
To be able to determine the key
aspects of the project, the details of
the scope and work, the timelines, the
required budget and the resource
assignments, a Work Breakdown
Structure (WBS) should be used. A
sample wbs showing a few segments
for a wireless conference is shown
here.
The idea is to start with the full project
at the top, and break this project into
components. Each of the top-level
Authorized licensed use limited to: Staffordshire University. Downloaded on September 01,2020 at 08:13:58 UTC from IEEE Xplore. Restrictions apply.
IEEE ENGINEERING MANAGEMENT REVIEW, VOL. 45, NO. 2, SECOND QUARTER, JUNE 2017
components will be a deliverable.
Be careful to ensure that this is the
case. The top boxes should not be
concepts or objectives. Deliverables
are things, so they should be
described using nouns, no verbs.
Each of these is broken down in turn,
to smaller deliverables, until the items
below become actions which make
up the work of the project. These
bottom level elements should have
verbs to clarify the action. The
concept of WBS has been covered in
earlier columns, so we will not
discuss it further here.
The WBS is used to breakdown the
scope of the project. This breakdown
technique can be used in other areas
of the planning as well, such as a Risk
Breakdown Structure used to analyze
risks.
Further information on tools will follow
in subsequent columns.