Information Technology Reference
In-Depth Information
To avoid arbitrary change of colors or calls to action, it must be
supported by a set of neutral trigger conditions defined at an appropriate
level of detail. For example, Yellow be defined with respect to both Green
and Red. If we are going over the planned spend at this stage in the
product by below 10 percent, change the status to Yellow. If it is more
than 10 percent, change it to Red.
Status as Information
There is a natural reluctance on the part of many project managers to ask
for help, or escalate a problem. The manager may appear in poor light.
Occasionally, it is based on an optimism that things will be brought back
under control soon. Some managers prefer to bring the status to Yellow
at the earliest possible time, because some issues will always crop up.
In some environments, one does not like to be the messenger of bad
news. In other environments, formal notification of bad news is frowned
upon, while informal notification is acceptable. The official documents
only show the good stuff. In such environments, formal status reports are
often unreflective of ground reality.
For the receiver of a status report, status flags are often used as a
partitioning mechanism. The receiver might concentrate his or her attention
on projects in “Red.” Without some historical analysis of the reliability of
such flags in one's particular environment, this is a risky and unreliable
approach. It must be accepted that managers vary in their ability or
inclination to set flags properly.
The Three Popular Vectors
The vectors most commonly selected for status reporting are money, time,
and scope. In software development projects, these vectors do serve useful
purposes, yet may be inadequate indicators of project status, mainly
because they ignore the nature of the project. They also ignore the fact
that the vectors of interest may be different at different points in the life
cycle of the project.
Another reason given for selecting these three is that they are good
candidates for comparisons between projects. Money takes numerical
values, which allows meaningful aggregation between departments and
divisions in the reporting chain. Time could also be considered numerical,
but adding a two-week delay on one project, with a five-week delay on
another, is rather meaningless. Scope gets squeezed into some percentage
that is again meaningless, even within a project, much less across projects.
A 10 percent increase in scope identifies the scale of the problem — it
