Monitoring and Controlling the

Project

1
 Control vs. Risk
• Controls are used to discover the out-of-balance
situations early and put the project back to track
as quickly as we can.
• Senior managers generally aren’t interested in
reading long reports only to find out that
everything is on schedule.
• Variety of repots as control tools:
– Numeric and tabular form,
– Graphics.
2
 Purpose of Controls
• Controls are actions taken as a result of reports.
• Controls are designed to bring actual projects status back into
conformance with the project plan.
• The reports are designed to support control activities by drawing
attention to certain aspects or characteristics of the project, such as
planned versus actual schedule, trends in the schedule, and actual
versus planned resource use.

• Typically we want to track

– performance levels,
– costs,
– time schedules.
3
 Three Reasons to use Reports in a Project
• To track progress. Project manager needs a periodic (biweekly or
weekly) reporting system that identifies the status of every activity
scheduled for work since the last progress report. These reports
summarize progress for the current period as well as the cumulative
progress for the entire project.

• To detect variance from plan. Variance reports are important to

management. To get the variance, the project manager compares
planned performance to actual performance.

• To take corrective action. If there is significant variance from plan,

the next step is to determine whether corrective action is needed and
then act appropriately.

4
 Progress Reporting System
• A reporting system would have the following
characteristics:
– Provides timely, complete, and accurate status
information
– Doesn’t add so much overhead time as to be counter
productive
– Is readily acceptable and understood to the project
team and senior management
– Warns of pending problems in time to take action

5
 Types of Project Status Reports
• There are five types of project status reports:
1. Current period reports. These reports report
progress on those activities that were open or
scheduled for work during the period. These reports
might highlight activities completed and variance
between scheduled and actual completion dates.
2. Cumulative reports. These reports contain the
history of the project from the beginning to the end
of the current report period. They show trends in
project progress.

6
Types of Project Status Reports
3. Exception reports. Exception reports report variances from
plan. Mainly designed for senior management.
4. Stoplight reports. Use stickers to signal the status of your
project.
1. On Track : green sticker on the top right of the first page of the project
status report.
2. Under Control: yellow sticker when there are problems but under
control
3. Out of Control: red sticker.
5. Variance reports. Variance reports report differences
between what was planned and what actually happened. The
report has three columns: the planned number, the actual
number, and the difference, or variance.

7
 Measuring Duration and Cost Variances
• There are five reasons why we want to measure duration
and cost variances:
1. Catch deviations from the curve early. The cumulative actual cost or actual
duration can be plotted against the planned cumulative cost or cumulative
duration.
2. Dampen oscillation. Planned versus actual performance should display a
similar pattern over time. Wild fluctuations between the two may imply a
project that is not under control.
3. Allow early corrective action. The project manager be alerted to a schedule
or cost overrun early.
4. Determine weekly schedule variance. Reporting progress on activities open
for work should be reported on a weekly basis. This allows the project
manager to discover overrun and take corrective action before the situation
escalates to a point where it will be difficult to avoid schedule slippages.
5. Determine weekly effort (person hours/day) variance. The differences
between the planned effort and actual effort has a direct impact on both
planned cumulative cost and schedule. If effort is less than planned, it may
suggest a potential schedule slippage. 8
 What to report?
• The list of what should be reported by the activity
manager and project manager:
1. Determine a set period of time and day of week to submit the updated
information.
2. Report actual work accomplished during this period. What was planned
to be accomplished and what was actually accomplished are two different
things.
3. Record historical and re-estimate remaining (in-progress work only).
4. Report start and finish dates. These are the actual start and finish dates of
activities started or completed during the report period.
5. Record days of duration accomplished and remaining.
6. Report resource effort (hours/day) spent and remaining (in-progress
work only). The above numbers report calendar time and these numbers
report labor time over the duration of the activity. There are two numbers.
One reports labor completed over the duration accomplished. The other
reports labor spent over the remaining duration.
9
 Variances
• Variances are deviations from plan.
• A variance is the difference between what was
planned and what actually occurred.
• There are two types of variances:
– Positive Variances: These are deviations from plan
that indicate that an ahead-of-schedule situation has
occurred or that an actual cost was less than a planned
cost.
– Negative Variances: Negative variances are
deviations from plan that indicate that a behind-
schedule situation has occurred or that an actual cost
was greater than a planned cost.
10
 Graphical Reporting Tools
• Senior managers are interested in brief reports
only because they are always short on time

• There is no need to read several pages to know

that the project is on schedule.

• Always summarize the data in a way that will be

easy to find out that status of the project within
few minutes NOT hours
11
 Gantt Charts
• A Gantt chart is one of the easiest ways to
understand the status of the project activities.
• The chart is formatted as a two-dimensional
representation of the project schedule with
activities shown in the rows and time shown
across the horizontal axis.
• It can be used during planning, for resource
scheduling, and for status reporting.
• As you recall, the main drawback for Gantt charts
is that they do not contain dependency
relationships.
12
 Milestone Trend Charts
• Milestones are zero-duration activities and merely
represent that a certain condition exists in the project.
• For example, a milestone event might be that the
approval of several different component designs has been
given.
• This event consumes no time in the project schedule. It
simply reflects the fact that those approvals have all been
granted.
• The completion of this milestone event may be the
predecessor of several build-type activities in the project
plan.
13
 Milestone Trend Charts
• The following milestone trend chart plots the difference
between the planned and estimated date of a project
report period.
• In the original project plan the milestone is planned to
occur at the ninth month of the project. That is the last
project month on this milestone chart.
• The horizontal line represents one, two, and three
standard deviations above or below the forecasted
milestone date.
• Any activity in the project has an expected completion
date that is approximately normally distributed.
14
 Milestone Trend Charts
Early

1
On Schedule

Late

1 2 3 4 5 6 7 8 9

Project Month

15
 Milestone Trend Charts
• The first project report (at month 1) shows that the new forecasted
milestone date will be one week later than planned.
• The second project date (month two of the project) shows that the
milestone date is forecasted on target.
• The next three project reports indicate a slippage to two weeks late,
then three weeks late, then four weeks late, and finally six weeks late
(at month 6).
• In other words, the milestone is forecasted to occur six weeks late,
and there are only three more projects months in which to recover
the slippage.
• Obviously, the project is in trouble. The project appears to be
drifting out of control. Some remedial action is required of the
project manager.

16
 Milestone Trend Charts
• The following are examples of certain patterns
that signal out-of-control situations:
1. Successive slippages. The following figure
depicts a project that is drifting out of control.
Each report shows additional slippage since the
last report period. And require special corrective
action from the project manager.

17
 Milestone Trend Charts
Early

1
On Schedule

Late

1 2 3 4 5 6 7 8 9

Project Month

18
 Milestone Trend Charts
2. Radical change. The following Figure while it
shows the milestone to be ahead of schedule,
reports a radical change between report periods.
Activity duration may have been grossly over-
estimated. There may be a date error. In any case,
the situation requires further investigation.

19
 Milestone Trend Charts
Early

1
On Schedule

Late

1 2 3 4 5 6 7 8 9

Project Month

A change of more than three standard deviations

20
 Milestone Trend Charts
3. Successive runs. The following Figure signals a
project that may have encountered a permanent
schedule shift. In the example, the milestone date
seems a permanent to be varying around one
month ahead of schedule. Barring any radical
shifts and the availability of resources over the
next two months, the milestone will probably
come in one month early.

21
 Milestone Trend Charts
Early

1
On Schedule

Late

1 2 3 4 5 6 7 8 9

Project Month

Seven successive data points above

the planned milestone date
22
 Milestone Trend Charts
4. Schedule shifts. The following figure depicts a
major shift in the milestone schedule. The cause
must be isolated and the appropriate corrective
measures taken. One possibility is the discovery
that a downstream activity will not be required.
Perhaps the project manager can buy a
deliverable rather than build it and remove the
associated build activities from the project plan.

23
 Milestone Trend Charts
Early

1
On Schedule

Late

1 2 3 4 5 6 7 8 9

Project Month

Two successive data points outside three

standard deviations from the planned milestone date
24
 Cost Schedule Control
• Cost schedule control is used to measure project
performance and uses the dollar value of work as the
metric. Or the resource person hours / day can be used
when the project manager does not directly manage the
project budget.
• Actual work performed is compared against planned and
budgeted work expressed in these equivalents.
• These metrics are used to determine schedule and cost
variances for both the current period and cumulative to
date.
• One drawback that these metrics have is that they report
history.
25
 Cost Schedule Control
• The following figure shows an S curve, which represents the
baseline progress curve for the original project plan. It can be used
as a reference point.
• You can compare your actual progress to date against the curve
and determine how well the project is doing; progress can be
expressed as either dollars or person hours / day.

Progress 2/3 Time – ¾ Progress

1/3 Time – ¼ Progress

26
Time
 Cost Schedule Control
• As shown in Figure A, by adding the actual progress curve to the
baseline curve, you can now see the current status versus the
planned status which shows the actual progress curve to be below
the planned curve.
• If this represented dollars, we may falsely conclude that the project
is running under budget; Projects rarely run significantly under
budget.
• A more common reason for the actual curve to be below the
baseline is that the activities that should have been done and thus
the dollars or person hours / day that were planned to be expended
have not been.
• The schedule variance is depicted in Figure B below.
27
 Cost Schedule Control

Progress

Cost Variance

Update
Date

Time

Figure A 28
 Cost Schedule Control

Progress

Schedule Variance
Cost Variance

Update
Date

Time

Figure B 29
 Cost Schedule Control
• To determine whether there has really been a progress schedule
variance, you need some additional information.
• Cost schedule control (CSC) comprises three basic measurements:
– budgeted cost of work scheduled,
– budgeted cost of work performed,
– and actual cost of work performed
• These measurements result in two variance values, schedule
variance and cost variance.
• The following Figure is a graphical representation of the three
measurements
• The figure shows a single activity that has a five-day duration and
a budget of $500. The budget is prorated over the five days at an
average daily value of $100.
30
 Cost Schedule Control

BCWS BCWP ACWP

5 days 5 days
5 days

$500 $300 $200 $400 $200

Scheduled/ Schedule slippage permits only Actual cost of work performed-$400

Budgeted to do work over 5 days 3 days/$300 work to be ACWP=$400
in a 5-day window performed Actual cost variance=($100)
BCWS=$500 BCWP=$300
Schedule variance=($200)

31
 Cost Schedule Control
• The left panel of the above Figure shows an initial (baseline)
schedule with the activity starting on the first day of the week
(Monday) and finishing at the end of the week (Friday). The
budgeted $500 value of the work is planned to be accomplished all
within that week. This is the budgeted cost of work scheduled
(BCWS).
• The center panel shows the actual work that was done. Work did
not begin until the third day of the week. Using an average daily
budget of $100 we see that we were able to complete only $300 of
the scheduled work. This is the budgeted cost of work performed
(BCWP).
• The rightmost panel shows the actual schedule as in the center
panel, but now we see the actual dollars that were spent to
accomplish the three days work is $400. This $400 is the actual
cost of work performed (ACWP).
32
 Cost Schedule Control
• The BCWS, BCWP, and ACWP are used to compute
and track two variances.
– The first is schedule variance (SV). SV is the difference
between what was done and was planned to be done,
expressed in dollars or person hours / day equivalents.
– The second is cost variance (CV). CV is the difference between
the BCWP and the ACWP, which is $100 in this example. That
is, we overspent by $100 (ACWP-BCWP) the cost of the work
completed.

33
 Cost Schedule Control
• Generally, it will be misleading just when we find the actual cost
is below the baseline to conclude that the project is on a healthy
track.
• The more reliable conclusion will be inferred by comparing both
budget variance and schedule variance, as shown in the following
Figure.
• In the following figure, by Comparing the BCWP curve with the
BCWS curve you see that you have under spent because all of the
work that was scheduled has not been completed.
• And Comparing the BCWP curve to the ACWP curve also
indicates that you overspent for the work that was done.
• Clearly, management would have been misled by the previous
Figure A.
34
 Cost Schedule Control

Progress
Schedule
Variance

Cost
ACWP Variance

Time

35
 Cost Schedule Control
• The CSC can also be used to predict the future status of
a project.
• From the previous figure, By cutting the BCWS curve at
the height from the horizontal axis, which has been
achieved by the BCWP, and then pasting this curve on to
the end of the BCWP curve, you can extrapolate the
completion of the project. Note that this is based on
using the original estimates for the remaining work to be
completed. And doing the same for the ACWP.

36
 Cost Schedule Control
• The three basic indicators yield one additional level of
analysis for us.
• Schedule performance index (SPI) and Cost performance
index (CPI) are a further refinement. They are computed
as follows:
• SPI = BCWP / BCWS
• CPI = BCWP / ACWP

37
 Cost Schedule Control
• Schedule performance index. The schedule
performance index (SPI) is a measure of how close the
project is to performing work as it was actually
scheduled.
• If we are ahead of schedule, BCWP will be greater than
BCWS, and therefore the SPI will be greater than 1. On
the other hand, an SPI below 1 would indicate that the
work performed was less than the work scheduled.

38
 Cost Schedule Control
• Cost performance index. The cost performance index
(CPI) is a measure of how close the project is to
spending on the work performed to what was planned to
have been spent. If you are spending less on the work
performed than was budgeted, the CPI will be greater
than 1. if not, and you are spending more than was
budgeted for the work performed, then the CPI will be
less than 1.

• Some managers may prefer this type of analysis. Any

value less than 1 is undesirable; any value over 1 is
good. 39
 Using the WBS to Report Project Status
• Because the Work Breakdown Structure (WBS) shows
the hierarchical structure of the work to be done, it can
be used for status reporting, too.
• Each activity box can be shaded to reflect completion
percentages. As lower-level activities are completed,
the summary activities above them can be shaded to
represent percent complete data.
• Senior managers will appreciate knowing that major
parts of the project are complete. Unfortunately, the
WBS does not contain scheduling or sequencing
information.
40
 Level of Detail
• How much detail and and what is the frequency of
reporting in project status reports?

• The more you report, the more likely that others will
micro-manage your project.

• Let’s go over the reporting requirements at the

activity manager, project manager, and senior manager
levels.

41
 Level of Detail
• Activity Manager: The activity manager needs the
most detailed information available, since the activity
manager is directly responsible for getting the work
done. He is a type of person that will micro-manage
the activities he will be interested to know what
happened, what was scheduled to happen, who did
what (or didn’t do what), why it happened as it did,
what problems have arisen, what solutions are within
reach, and what changes need to be made.

42
 Level of Detail
• Project Manager : The project manager is mainly
concerned with the status of all activities open for
work during the report period; it is important to
remember that there are reports for the project
manager and reports from the project manager to
senior management.
• Senior Management: Report project status to senior
management in some graphical form, Gantt chart.
Reports at the activity level will be appropriate but for
large projects milestone-level reports are more
effective.
43
 Project Status Review Meetings
While the format of the status review meetings should be flexible, as project needs dictate,
certain items are part of every status meeting, here is a general description for the agenda:
1. The project champion reports changes that may impact the future of the project.
2. The customer reports reports changes that may impact the future of the project.
3. The project manager reports on the overall health of the project and the impact of
earlier problems, changes, and corrective actions as they impact at the project level.
4. Activity managers report on the health of activities open or scheduled for work since
the last status meeting.
5. The project manager reviews the status of open problems from the last status meeting.
6. Activity managers of future activities report on any changes since the last meeting that
might impact project status.
7. Attendees identify new problems and assign responsibility for their resolution
8. The project champion, customer, or project manager, offers closing comments.
9. The project manager announces the time and place of the next meetings.

44
 Change Control
• A good project management methodology shall have a
change management process in place.
• Two documents are part of every good change
management process:
1. project change request
2. project impact statement.

45
 Change Control
• Project change request:
– Every change requested by the customer must be
documented.
– That document might be as simple as a memo but it
might also follow a format provided by the project team.
– In any case, it is the start of another round of establishing
Conditions of Satisfaction.
– Only when the request is clearly understood can the
project team evaluate the impact of the change and
determine whether the change can accommodated.

46
 Change Control
• Project impact statement:
– The response to a change request is a document called a
project impact statement.
– It is a response that identifies the alternative courses of
action that the project manager is willing to consider.
– The requestor is then charged with choosing the best
alternative.
– The project impact statement describes the feasible
alternatives that the project manager was able to identify,
the positive and negative aspects of each, and perhaps a
recommendation as to which alternative might be best. The
requester will decide on the final decision.

47
 Change Control
• Six possible outcomes can result from a change request:
1. It can be accommodated within the project resources and
timelines.
2. It can be accommodated but will require an extension of the
deliverable schedule.
3. It can be accommodated within the current deliverable
schedule but additional resources will be needed.
4. It can be accommodated but additional resource and an
extension of the deliverable schedule will be required.
5. It can be accommodated with a multiple release strategy and
prioritizing of the deliverable across the release dates.
6. It cannot be accommodated without a significant change to the
project.

48
 Change Control
• An integral part of change control processes is the
documentation. Every change request shall follow the
procedure listed in the following flowchart.

• And the change request is submitted by the customer

using the form shown in the following figure and
forwarded to managers charged with reviewing such
requests.

49
Change Control Process
Submit
change
request

Reject Review Rework & Resolution

change
request

Request
impact
study

Reject Review Rework & Resolution

impact
study

Change
approved for 50
implementation
Change Request Form
Project Name

Change Requested By

Date Change Requested

Description of Change

Business Justification

Action

Approved by Date

51
 Software Quality Control
and
Software Quality Assurance

52
 SQC & SQA

Software Quality Control

Is about the Software Product

Software Quality Assurance

Is about the Process that governs the

delivery and development of the
software product 53
 Software Quality Control
Theory-W : Win-Win
• Theory-W moves the productivity equation outside
of the internal organization
• What makes a “win” for key stakeholders
• Basic Steps:
1. Establish a set of win-win preconditions
• Understand how people want to win
2. Structure a win-win software process
• Establish a realistic process plan and keep
people involved
3. Structure a win-win software product
• Match product to users and maintainers win
conditions 54
 Software Quality Control
Software Measurement
• Metric is a measure or combination of
measures that provides insight into a
software issue or concept. Every metric
should have a purpose

• Measure is quantifying an attribute of a

process or product; i.e. result of counting

• Data is the raw number

55
 Software Quality Control
Software Measurement

Data Measure

Data Measure
Process
Execution Metric
Data Measure

Data Measure
56
 Software Quality Control
Software Measurement

Head-Count
SLOC
per
Staff Month
Months
Process Modules/ Productivity
Execution Modules Month

SLOC
$ Cost
Per SLOC
Dollars
Spent
57
 Software Quality Control

What is Quality?

Quality is the degree of

excellence

58
 Software Quality Control
What is Software Quality?

•Ease of Use From

•conformance to Customer
requirements and Perspective
specifications
•High Availability 99.999%
•Low number of defects
found by the customer
59
 Software Quality Control
What is Software Quality?

•Reusability From
•Flexibility Technical
•Extensibility Perspective

•Readability
•Maintainability

60
 Software Quality Control

Why software quality may fall?

Not Following the

process is the root cause
of the problem
61
 Software Quality Control

What else?

Testing wasn’t based on the RSD

62
 Software Quality Control
Trends and Directions …

• Implicit dependency between the cost

and quality
• In the marketplace, higher quality
means more profit
• Higher quality means lower
maintenance cost
• Poor quality means loss of customers
63
 Software Quality Control
What is the cost for software
quality control?

• Clearly NOT free

• Budget: May add up to the final cost
of the software product
• Schedule: May add up to the final
delivery date of the project

64
 Software Quality Control
What we gain from controlling
the software quality?
• All the external and internal quality
properties of the software system
• Defected software products wouldn’t
be delivered to customers
• Avoiding penalty for defects
discovered by customers

65
 Software Quality Control
How to control the software quality?

• Follow the SW development process

• Compliance with ISO standards
• Testing
– White-box : code inspections based on
requirements and design documents
– Black-box : behavioral testing based on
requirements
66
 Software Quality Control
Measuring software testing :

• How many requirements tested

• How many test cases passed/failed
• Do fixes inject more defects
• Tester productivity: number of tests
executed per day

67
 Software Quality Control
Improving software testing :

• Always based on the requirement and

specification document
• Automation for test case generation
and execution
• Fault=Defect=Bug are results from
misunderstanding of the requirements
by the developer and system engineer
68
 Software Quality Assurance
What does it mean?
• Provide a more effective quality
control mechanism

• SQA is meant to assure that quality

is achieved as intended and planned

• Look into the SWD process and

improve that process 69
 Software Quality Assurance
How it is achieved?
• Ensure SW project participants
comply with the process
• Participate as moderator in design
and code inspections
• Audit development groups to comply
with the ISO standards

70
 Software Quality Assurance
You can read more into the SQA term

• SW Product
– SWD compliant with the SWD process
– SWD conforms to RSD
• SWD Process
– Periodically evaluate the process
– Process improvement and Tailoring
– Removal of process defects
– Conforms to standards
71
 Software Quality Assurance
How to tailor and improve the process?

• Periodically gather and monitor

statistics about:
– Requirements Review
– Design Review
– Code inspections
– Test plans
• See whether what have been
gathered did meet the objectives
72
 Software Quality Assurance
SQA cost may fall into one of the
following:
• Proactive measures:
– Training, Predictive Metrics, Process
improvement
• Reactive measures:
– Design and Code inspections
– Testing

73
 Software Quality Assurance
• Monitor and loop back defects in the
following phases:
• Requirements Review
• Analysis and Design
• Implementation
• Testing

For the above phases, peer reviews

are the basis for quality guarantees 74
 Software Quality Assurance
During the requirement review phase:

• Review requirements for:

– Doability
– testability
– correctness

75
 Software Quality Assurance
During the Analysis/Design phase:

• Review A/D document for

– Design covers the requirements
– Design can be implemented
– Design correctness and validation
– Design based on formal model

76
 Software Quality Assurance
During the Implementation phase:

• Have a code inspection meeting to:

– Ensure that implementation is based
on the A/D document
– Code is healthy “Fat-Free”
– Discover logical errors
– Requirements are covered
– Implementation driven by CASE tools
77
 Software Quality Assurance
During the Testing phase:
• During this phase
– Write test plans
– Test against requirements
– Test results saved in a common
repository
– Ideally, this testing shall be a
black-box testing
– Test cases generated from models78
SEI CMM Maturity effects on SQ Cost

SEI CMM Effects on SQ Cost

35
Quality Cost as Percent
of Development Cost

30
25 External Quality
20 Internal Quality
15 Reactive Measures
10 Proactive Measures
5
0
1 2 3 4 5
SEI CMM Level

79
 SQA Planning

• A software project has a document

called Software Quality Assurance
Plan (SQAP)
• The intent of this document is to
document tasks to be executed,
standards of verification and
validation, procedures and
organizational structure

80
The Mythical Man-Month [Brooks]

Cost Progress
• Number of people • Output of people
involved in the involved in the
project project
• Amount of time • Decreased by
spent on the communication
project among them

Man-Month Man-Month doesn’t

expresses cost express progress 81
 Balancing the Software Quality
• To reach the aspiration goals of software
quality, we have to balance the 3 P’s
– People
• Value people
– Process
• Practice it, Improve it, and Level 1-
5 on the SEI-CMM maturity scale
– Product
• Customer satisfaction and reusability

82
 Theory of Constraints
• Triple Constraint vs. Quadruple Constrain
– Triple Constraint
• Quality
• Budget
• Schedule
– Quadruple Constraint
• Risk
• Quality
• Budget
• Schedule
83
 Theory of Constraints
• But monitoring Risk is done along three
dimensions
• Quality
• Budget
• Schedule

• Formal Monitoring documents:

• Test results
• Cost reports
• Project schedule
84
 Theory of Constraints
• Quadruple Constraint

• Needed when addressing planning

issues

• Triple Constraint
• Needed to monitor the software
project

85
 Theory of Constraints
• Within the context of Quadruple Constraint

• Quality is measured in milestone

achievements; sometime referred to
as quality gates.

86
 Theory of Constraints
• What the Quadruple Constraint can tell us?

• A particular software project may

have an increasing risk as cost
increases and risk decreases as
schedule lengthens
• However, another project may have
exactly the opposite situation.

87
 Theory of Constraints
• (a) Risk with Cost vs. Quality

Cost
Risk

Quality 88
 Theory of Constraints
• (b) Risk with Schedule vs. Quality

Schedule Risk

Quality 89
 Theory of Constraints
Satisfying the Quadruple Constraint is very
difficult because:

• The events that naturally occur

during the project lifetime conspire
to:
– Lower performance
– Drag project behind schedule which may
make it
» Exceed budget
» Raise the risk of failure
90
 Theory of Constraints
As a project manager,

you must stay alert to the

problems and strive
constantly to satisfy the
Quadruple Constraint

91