Chapter 10 Monitoring and Information Systems CHAPTER OVERVIEW Overview – This chapter describes the “inverse” of the planning process, namely monitoring. For projects, monitoring involves collecting, recording, and reporting information about the project for the benefit of the PM, teams, organization, and clients. The chapter emphasizes the idea that for the information being monitored to be useful, it must be timely. 10.1 The Planning-Monitoring-Controlling Cycle – The key elements to be monitored in projects are time (schedule), cost (budget), and scope (performance). This process will fail, however, if the upfront planning process is inadequate. Also, the monitoring and control process should be an integral part of the project’s and the organization’s normal activities, not something imposed (and perceived) as an artificial add-on. · Designing the Monitoring System – For the monitoring system to be successful, the PM must define exactly which characteristics of time, cost, and scope he/she believes are worth watching. In addition the range or boundaries, the data should fall in for the project to be considered “in-control,” must be defined. The project action plan should provide the basis for the majority of the key items to be measured. However, the PM needs to guard against collecting massive amounts of data that do not contribute to the goal of keeping the project on track. It is crucial to remember that effective PMs are not primarily interested in how hard their project teams work. They are interested in achieving results. · Five telltale signs of project trouble to monitor · Muddy waters – a project plan that is unduly long or confusing in its goals, scope, deliverables, and processes · Mysterious stakeholders - incomplete documentation of all stakeholders · Unconstrained constraints - knowing how much leeway there is in your schedule and budget for each task, and where delays or cost overruns can be made up, keeps a project out of trouble · Suspicious status reports - status reports that are unclear, inconsistent, late, or lack specific measures · Discord and drama - unhappy team members · How to Collect Data – For the monitoring process to be successful, the frequency, type, and amount of data to be collected must be precisely defined. Data collected typically takes one of the following forms: · Frequency counts – How often an event occurs. · Raw numbers – Amount of something, like hours spent on a task. · Subjective numeric ratings – Subjective estimates often applied to quality measures. · Indicators – Indirect measures, such as transaction processing speed, being used to suggest customer satisfaction. · Verbal measures – Descriptions of characteristics like the morale of the team. Once the data has been collected, it may be beneficial to subject it to some statistical analysis. This will help determine the size of data variance significant for the project. When the level of significant variation is determined, then the PM ca ...

1. Chapter 10
Monitoring and Information Systems
CHAPTER OVERVIEW
Overview – This chapter describes the “inverse” of the planning
process, namely monitoring. For projects, monitoring involves
collecting, recording, and reporting information about the
project for the benefit of the PM, teams, organization, and
clients. The chapter emphasizes the idea that for the information
being monitored to be useful, it must be timely.
10.1 The Planning-Monitoring-Controlling Cycle – The key
elements to be monitored in projects are time (schedule), cost
(budget), and scope (performance). This process will fail,
however, if the upfront planning process is inadequate. Also,
the monitoring and control process should be an integral part of
the project’s and the organization’s normal activities, not
something imposed (and perceived) as an artificial add-on.
· Designing the Monitoring System – For the monitoring system
to be successful, the PM must define exactly which
characteristics of time, cost, and scope he/she believes are
worth watching. In addition the range or boundaries, the data
should fall in for the project to be considered “in-control,” must
be defined. The project action plan should provide the basis for
the majority of the key items to be measured. However, the PM
needs to guard against collecting massive amounts of data that
do not contribute to the goal of keeping the project on track. It
is crucial to remember that effective PMs are not primarily
interested in how hard their project teams work. They are
interested in achieving results.
· Five telltale signs of project trouble to monitor
· Muddy waters – a project plan that is unduly long or confusing
in its goals, scope, deliverables, and processes

2. · Mysterious stakeholders - incomplete documentation of all
stakeholders
· Unconstrained constraints - knowing how much leeway there
is in your schedule and budget for each task, and where delays
or cost overruns can be made up, keeps a project out of trouble
· Suspicious status reports - status reports that are unclear,
inconsistent, late, or lack specific measures
· Discord and drama - unhappy team members
· How to Collect Data – For the monitoring process to be
successful, the frequency, type, and amount of data to be
collected must be precisely defined. Data collected typically
takes one of the following forms:
· Frequency counts – How often an event occurs.
· Raw numbers – Amount of something, like hours spent on a
task.
· Subjective numeric ratings – Subjective estimates often
applied to quality measures.
· Indicators – Indirect measures, such as transaction processing
speed, being used to suggest customer satisfaction.
· Verbal measures – Descriptions of characteristics like the
morale of the team.
Once the data has been collected, it may be beneficial to subj ect
it to some statistical analysis. This will help determine the size
of data variance significant for the project. When the level of
significant variation is determined, then the PM can apply
“management by exception.” In this technique, the PM only acts
on a variance when it exceeds the pre-determined significant
variance level. Statistical analysis may reveal data trends that
allow the PM to act before the significant variance level has
been reached. The issue of creating an atmosphere that fosters
honesty on a project is widely ignored, but it is of major
importance.
10.2 Information Needs and Reporting – The monitoring system
will collect a lot of data, but the reporting system it is tied to
should tailor the reports to the level of management. Senior

3. managers will not need as much detail as the team members, but
all must be working off the same base data. Today many
electronic tools are available to aid in the analysis and
dissemination of project data.
· The Reporting Process – Reports are a common way of
disseminating data. Reports should also express relevant
information to the manager viewing it and should be tailored
according to the needs of the manager. Reports, when timely
and well-constructed have a number of benefits to the project
team and other interested parties, primarily through the
consistent communication of data important to managing the
project.
· Report Types – Reports can be divided into three types:
routine, exception, and special analysis. Routine reports are
those that come out periodically or to some other predetermined
schedule. Exception reports support instances of decision-
making and are distributed to the participants in that decision.
Exception reports may be issued when a decision is made on an
exception basis and it is desirable to inform other managers as
well as to document the decision. Special analysis reports are
used to disseminate the results of special studies or problem
reports.
· Meetings – Meetings are an important tool for disseminating
information and making decisions. The PM will be responsible
for many meetings and can take several steps towards improving
their quality:
· Have a clear purpose for each meeting and make sure the
participants understand the purpose.
· Have an agenda and start and stop the meeting on time.
· Ideally, both the PM and the meeting participants should be
prepared for the meeting. Publishing the agenda in advance
helps.
· Have a designated person take minutes for the meeting. The
author’s advice on who should take minutes is contrary to many
other works on the subject of good meetings. Most PMs find it
very difficult to take minutes, facilitate the meeting, and be a

4. participant. These are in fact three distinct roles, and should be
divided up if possible. If no one else is available, then the PM
must take minutes to ensure that there is some record about the
meeting.
· Minutes should be an honest and professional record of the
reasoning and decisions, but not necessarily of the discussion
that took place at the meeting.
· Avoid overly formal procedures. People need to feel that they
can freely participate in the meeting without having to be
experts in parliamentary procedures.
· Special and open-ended meetings may be necessary to solve
serious problems.
· Common Reporting Problems – There are three common
problems in the design of the project reporting system:
· The reports are too detailed for their intended purpose.
· Poor interface between the project’s and the parent
organization’s information systems. The project collects and
reports data that the parent organization can’t use and vice
versa.
· Poor correspondence between the planning and the monitoring
systems.
10.3 Earned Value Analysis – A valuable technique for
monitoring overall project performance is earned value.
· The Earned Value Chart and Calculations – The key element
of the earned value technique is the measurement of progress in
addition to cost and schedule. If progress is not measured, then
data about cost and schedule is meaningless because the PM
does not know what resulted from the expenditures. A team
member may have spent considerable time on a task and
achieved nothing. On the other hand the team member may have
spent very little time on the task, but completes it. By
combining the results of these analyses at the task level, a
reasonably accurate estimate can be made of the overall
project’s progress against cost and schedule. There are several
conventions for estimating progress at the task level:

5. · The 50-50 Rule - Taking credit for 50% complete when the
task begins and the other 50% when the task ends.
· The 0-100 percent Rule - Taking no credit for progress until
the task completes.
· Critical Impact Use Rule - Taking credit for progress based on
the use of a critical input. This works only if the process
consuming the input is reliable and well defined.
· The proportionality Rule - Taking credit for progress based on
either the percent of the budget that has been expended or the
percent of the elapsed time that has passed.
All of these methods have some error, but when applied to a
large project, the errors become insignificant. There are a
number of acronyms associated with the earned value process,
the most commonly used are:
· AC (actual cost) – The actual cost incurred in working on the
task. Also known as ACWP, the actual cost of work performed.
· PV (planned value) - This is the budgeted cost for the work
scheduled on a task up to a given point in time. Also known as
BCWS, the budgeted cost of work scheduled.
· EV (earned value) - This is the amount of money budgeted for
the work that has been performed to date. Also known as
BCWP, the budgeted cost of work performed.
· SV (schedule variance) - This is the difference between the
EV and the cost of the work we scheduled to be performed to
date, or the PV. Calculated as SV = EV – PV.
· TV (time variance) – The difference between the scheduled
and actual times.
· ST (scheduled time) – The time scheduled for the work.
· CV – Cost variance. The difference between the earned value
and the actual cost. Calculated as CV = EV – AC.
· CPI (cost performance index) - The ratio of the earned value
to the actual cost. Calculated as CPI = EV/AC.
· SPI (Schedule Performance index) - The ratio of the earned
value to the planned value. Calculated as SPI = EV/PV.
· TPI (time performance index) – The ratio of scheduled time to
actual time. Calculated as ST/AT.

6. · CSI (cost-schedule index) – A combination of CPI and SPI.
· BAC – Budget at completion. This is the total planned budget
for the project.
· ETC – Estimate to complete. This is the current estimate of
the cost to complete the project from a given point in time. The
ETC changes based on the project performance to date. There
are several ways to calculate it, but the most common is ETC =
(BAC + EV)/CPI.
· EAC – Estimate at completion. This is the current estimate of
what the total cost of the project will be. Calculated as EAC =
AC + ETC.
· Example: Updating a Project’s Earned Value – The text works
through an example of the earned value calculation.
· MSP Variance and Earned Value Reports – Microsoft® Project
can be used to perform the earned value calculations. The user
should be cautioned, however, that the use of earned value in
MSP is not straightforward. Further, depending on the version
used, MSP does not follow the standard conventions for some of
its earned value calculations.
· Milestone Reporting – The text gives an example of project
reporting based on milestones.
· Burnup and Burndown Charts – Charts used to help monitor
overall project progress.
· A burndown chart is created with scope on the vertical axis
and time on the horizontal axis.
· A burnup chart contains the same axes as the burndown chart,
but two different lines are plotted on it. The first set of data
plotted is the amount of work completed to date and second set
of data is the total amount of work, including scope changes,
yet to now be completed
10.4 Computerized PMIS (Project Management Information
Systems) – Real projects with large volumes of data require
computers to manage the monitoring process. The decreasing
cost and increasing power of computers has led to the
widespread availability of reliable and inexpensive project

7. management software.
The availability of project management software has led to
some problems:
· Computer paralysis – Spending more time on the computer
than managing the project.
· PMIS verification – The data from the PMIS may not report
real or significant problems occurring in the project.
· Information overload – The PMIS makes it easy to overwhelm
the participants with data.
· Project isolation – The PMIS is used in lieu of face-to-face
communication.
· Computer dependence – The PM and other managers wait for
the computer to tell them that there is a problem.
· PMIS misdirection – Different areas of the project get
different levels of scrutiny because of the nature of the PMIS.
· Choosing Software – When choosing project management
software, the potential user should read several software
surveys conducted with project managers. There are a number of
surveys and reviews available on the current crop of project
management software. There are a number of characteristics to
evaluate, including the ability of the software to support the
development of schedules, budgets, resource plans, and
monitoring reports. The following steps are usually followed for
selecting software.
· Establish a comprehensive set of selection criteria.
· Set priorities for the criteria.
· Conduct a preliminary evaluation of the software packages
relative to the criteria.
· Limit the candidate packages to three and obtain demos of
each.
· Evaluate each package with a standard project typical of the
current and projected future needs.
· Negotiate on price.