Management Institute focuses on the trade-offs among the project
triad of scope, time
and cost in order to frame
its approach to project management. Our experience indicates that
there is a fourth variable in any
project management decision to be considered - quality.
As practicing project managers,
and as individuals who have been asked to turn around projects in
trouble, we have faced the reality
of this fourth variable time and time again. A project manager
can always save time and dollars
by pushing quality issues into the
future. In software development, this often leads to releasing
software that contains "known bugs". Anyone who uses commercial
software has been subjected to the results of such decisions.
Key Project Management Ideas
- Every one involved with
any project, or any phase of a project, must know its anticipated
sunrise (start) and
sunset (estimated completion).
- A project that is initiated without an explicit
risk assessment is a project where project team members
and project clients are unaware
of the risks that they are
- A project without project
metrics is an
- Large projects need time-boxed
phases or sub-projects.
- The amount of planning detail
required for a project is a direct
function of the aggregate
risk of the project.
- The main purpose of a project
plan is to educate the team
members and the project clients about who
must do what with whom when. It is a work
definition, and relationship
- Projects where the project team
members do not know the deliverables
expected by project clients and their
personal part in creating them are
An Eighth Overriding Project Reality
There can be only one top level project
manager and one top level project client for a project.
- Individuals who share final project management accountability
need to be able to become one integrated
decision making personality - which human beings do
not know how to do. Similarly, individuals who share the
top level client need to be able to become one integrated decision
- Both the top level project manager and the top level project
client can have others who act in
the same role but are subordinate
to them for the decision making purposes.
Project often have steering committees. Project management training
(see the Project
Management Institute web site for information) includes guidance
for project managers on dealing with the members of such steering
committees. However, little guidance exists for members
of project steering committees. If you are in this role,
you may find it useful to download the following guide for project
steering committee members.
for New Members of Automation Project Steering Committees"
Pilot or prototype projects
are very different from structured automation projects. The few
pages in the link below describes some of the main differences that
both project managers of such projects, and members of their steering
committees, need to be aware of.
Project Risk Assessment
Time-boxing has a second benefit. It limits the amount
of risk taken at any one point in time on high risk projects.
After several years of experience with explicit
risk analysis for all projects, we know that such analysis
is a necessary part of
all project initiation. Our experience with this approach
started with software development. However, we quickly learned to
modify the approach to organizational
change and other types of projects.
Essentially, the technique applies a template
of risk assessment questions
to a project plan. Such templates involves scoring the project on
the project on the following types of factors.
- Size - the
bigger the project (time and dollars), the greater the
- Newness - the newer
the technologies and the
processes used, first in
the industry, and then to the people impacted by the project,
the greater the risk.
- Players - the more
varied the players involved in, or impacted by the projects,
the greater the risk.
- Organizational Boundaries
- the more internal and external
organizational boundaries that
have to be crossed during
project activity, the greater the risk.
- Experience - the less
the experience of the project
players with the technologies, the processes, the organizations,
and the fewer the number
of established preexisting proven
relationships between them, the greater the project risk.
The scoring is done very quickly
(days). It is best if both project
leaders and project clients
participate in the scoring. It can done in either survey
or workshop mode. The
first is faster. The second, when led by an experienced facilitator,
creates a greater degree of understanding
and consensus among key
project individuals. The results lead to action.
For each area where project risk is beyond a low
or medium level, explicit risk
management and mitigation activities
must be part of the project plan. For any project phase where the
aggregate risk level is above a low or medium level, regular
risk review dialogue must occur among the project
manager and the senior project
A project which does not keep track of its key input and output
metrics is an unmanaged project.
Even low or medium risk projects go off track with regular
reporting of basic metrics.
This is not the same as project accounting.
Like all accounting, project accounting must track
project costs accurately to the penny.
It is simply a subset of fiscal accounting and must face the same
rigorous accounting standards that normal accounting meets.
That takes time. It often takes more
time than a project has available if team members are to
take effective corrective action.
Project metrics therefore must meet a somewhat different standard.
Project measurements must correctly predict the trend of a project's
consumption of resources and the size and quality of its output.
Accurate estimates are often
as effective at doing this
as "every transaction" accounting methods. Estimates are
usually cheaper and faster
to collect and to trend.
Project managers on all projects need to establish (or use already
existing) processes that allow them:
- to collect,
- to trend into the future
- to project end,
- to regularly report at
intervals which do not exceed 20% to 25% of the estimated project
the following basic metrics. Everyone on the project
team needs access to these metrics so that they know where
the project stands. All project clients
need access to the same metrics.
- Project team hours expended
- Estimated committed project dollar
expenditures to date (if the only major project resource
is talent, that is, there are no major equipment or facilities
expenditures, then project teams hours is a good substitute for
- Some reasonable measure(s) of
specific project output - one that makes sense given the
nature of the project (some examples follow)
- lines of software code in production,
- number or percentage of software modules or components delivered,
- number of engineering designs, plans or drawings completed,
- number of people converted to or trained in new processes,
- Generic project output
- actual and number of or percentage of planned project deliverables
- number or percentage of project activities completed,
- project gateways or key targets met on target or late by
- ... ...
- Project client satisfaction
with progress to date -
Even an informal measure collected
in conversation by the project manager with key project clients
and reported as a simple average ranging from 1 (not satisfied
at all) to 10 (totally satisfied) is
better than "hidden
In the past years, we have had the opportunity to work with software
project management approaches that address the scope, time, cost
and quality trade-offs by consciously
limiting the scope of any one phase of a larger project.
Called time-boxing, this approach
essentially says do what you can do
in 30, 60, 90 or 120 days. Focus on delivering something
that has some utility to the
project clients. Let them experience
these results. See if they are prepared to
fund the next phase of the project
based on this experience. Time-boxing
replicates the basic principle of limiting
the available resources which has proven
so successful in managing pilot projects in many other disciplines.