Project Execution, Monitoring, and Control

Introduction

Project planning establishes intended scope, schedule, cost, quality, resources, and risk responses. Execution turns those intentions into deliverables. Monitoring collects evidence about what is happening; control compares that evidence with approved expectations and supports timely corrective action. These activities are closely connected: execution without monitoring creates surprises, monitoring without control produces reports but little improvement, and control without reliable evidence encourages arbitrary intervention.

In software projects, execution is rarely a simple linear progression. Requirements evolve, technical discoveries alter estimates, teams depend on one another, and partially completed work may reveal quality problems. Effective project management therefore combines disciplined baselines with adaptive decision-making. The objective is not to prevent all change, but to make change visible, evaluated, authorized, and incorporated coherently.

Learning Objectives

By the end of this chapter, you should be able to:

• coordinate work, milestones, dependencies, and impediment resolution;
• distinguish monitoring from control and select useful performance measures;
• design effective status reports and dashboards;
• explain schedule, cost, scope, and quality baselines;
• calculate and interpret basic earned value measures;
• evaluate variances and trends using evidence;
• recommend corrective or preventive actions; and
• apply governance, ethical, and practical considerations to project control.

1. Execution as Coordinated Delivery

Execution is the organized performance of approved project work. It includes assigning tasks, facilitating collaboration, acquiring resources, developing and integrating software, conducting reviews and tests, managing suppliers, communicating with stakeholders, and producing accepted deliverables.

A useful execution model has four interacting elements:

1. Work authorization: people know what work is approved, its acceptance criteria, and its priority.
2. Flow management: work moves through a system with limited queues and visible states.
3. Integration: outputs from individuals, teams, vendors, and technical components are combined.
4. Feedback: information from reviews, tests, users, and operations influences subsequent work.

In predictive projects, execution is often organized around work packages and scheduled activities. In agile projects, it is organized around a product backlog, iterations, releases, and a definition of done. These are not completely opposing approaches. Both require clear ownership, agreed quality criteria, dependency management, and evidence that completed work satisfies its intended purpose.

Work authorization and ownership

Every significant work item should have an identifiable owner, a definition of completion, relevant dependencies, and a route for escalation. A responsibility assignment matrix can clarify who is responsible for doing work, accountable for its result, consulted for expertise, and informed about progress. Ambiguous ownership creates delays because participants assume that someone else will act.

A work item should not be reported as complete merely because coding has stopped. Completion may require code review, automated tests, security checks, documentation, deployment, user acceptance, or operational handover. The project’s definition of done should therefore be explicit and consistently applied.

Managing flow

Flow describes how work moves from initiation to completion. Common states include ready, in progress, in review, in test, blocked, and done. Visualizing these states helps reveal queues and bottlenecks. Work-in-progress limits reduce multitasking and encourage teams to finish existing work before starting more work.

A basic flow measure is cycle time: the elapsed time from starting work to completing it. Lead time is usually broader, often measured from request or commitment to delivery. The precise definitions must be agreed because inconsistent measurement makes comparison unreliable.

Little’s Law is sometimes useful for stable systems:

Here, L is the average number of items in the system, λ is the average throughput rate in items per unit of time, and W is the average time an item spends in the system. The relationship assumes a sufficiently stable system over the measurement period and consistent definitions of entry and exit. For example, if a team completes 4 items per week and an item spends an average of 2 weeks in the system, the average work in progress is 8 items. The formula is descriptive, not a guarantee that increasing work in progress will increase throughput.

Milestones and integration points

A milestone is a significant event or decision point, such as completion of architecture, approval of a release candidate, or acceptance testing. Milestones should represent observable outcomes rather than activity alone. “Testing finished” is weaker than “release candidate passes agreed acceptance tests.”

Integration points are especially important in software projects. They may include API integration, database migration, infrastructure provisioning, security review, or vendor delivery. A project can appear on schedule while integration risk accumulates. Frequent integration and demonstrable increments expose incompatibilities earlier than a single end-stage integration event.

2. Dependencies and Impediments

A dependency exists when one activity, team, decision, resource, or external party affects another. Dependencies may be:

• Technical: one component requires an interface or service from another.
• Schedule-based: one task cannot begin until another is completed.
• Resource-based: several activities compete for a specialist or environment.
• Organizational: approval or policy decisions are required.
• External: a supplier, regulator, customer, or platform provider controls an input.

Dependencies should be recorded with an owner, expected date, predecessor and successor, impact if missed, and escalation path. Dependency reviews should focus on the few relationships most likely to affect delivery, not merely on maintaining a large list.

An impediment is an obstacle that reduces progress or quality. Examples include an unavailable test environment, unclear acceptance criteria, unresolved design disagreement, excessive production defects, or delayed access credentials. A mature team distinguishes an impediment from a normal task. The response may require management action, negotiation, technical investigation, or removal of organizational barriers.

A practical impediment process is:

1. identify and describe the obstacle using observable evidence;
2. assess its effect on scope, time, cost, quality, security, or morale;
3. assign an owner and target resolution date;
4. remove, mitigate, transfer, or accept the impediment;
5. escalate when authority or time limits are exceeded; and
6. verify that the resolution actually restored progress.

Escalation is not failure. It is a control mechanism when the person closest to the work lacks the authority or resources to resolve an issue.

3. Monitoring: Evidence About Performance

Monitoring is the systematic collection, validation, analysis, and communication of project information. It should answer questions such as:

• What has been completed and accepted?
• What is forecast to be completed, and when?
• Which risks, issues, and dependencies threaten objectives?
• Is delivered quality acceptable?
• What decisions are required, from whom, and by when?

Monitoring must be designed for decisions. A large volume of data is not necessarily useful. A metric is valuable when its definition is clear, its source is credible, its frequency is appropriate, and a decision-maker can act on its interpretation.

Leading and lagging indicators

Lagging indicators describe results after they occur, such as released features, actual cost, escaped defects, or missed milestones. Leading indicators provide earlier signals, such as growing work in progress, increasing review queues, unresolved dependency age, declining automated-test coverage, or a rising number of blocked items. Both are needed. A project may meet current milestones while leading indicators show that future delivery is becoming less likely.

Common monitoring measures

Metrics should not be used as isolated targets. For example, maximizing velocity may encourage splitting work into smaller units or lowering quality. A balanced set of measures reduces the risk that people optimize one number at the expense of the project outcome.

4. Status Reports and Dashboards

A status report is a decision-oriented communication, not a diary of activity. An effective report normally contains:

• reporting period and overall status;
• accomplishments linked to deliverables or outcomes;
• work planned for the next period;
• milestone and forecast information;
• major risks, issues, dependencies, and impediments;
• changes since the previous report;
• variance explanations and proposed actions; and
• decisions required, including owner and deadline.

A dashboard is a visual summary for rapid interpretation. It should use a small number of defined indicators, display trends rather than only current values, show data dates, and make exceptions visible. Traffic-light status can be useful, but its thresholds must be defined. For example, “amber” might mean that a milestone forecast is at risk but recovery is plausible; it should not be a vague expression of anxiety.

Dashboards require governance. Data sources, calculation rules, update frequency, access permissions, and responsibility for validation should be documented. A dashboard that combines data from different dates or inconsistent definitions can create false confidence.

5. Baselines and Change Control

A baseline is an approved version of a plan used for comparison. Common baselines include scope, schedule, cost, and quality. The baseline is not an immutable prediction; it is a controlled reference that records the assumptions and commitments in force at a particular decision point.

A scope baseline may include the approved requirements, work breakdown structure, and acceptance criteria. A schedule baseline contains approved activities, logic, durations, milestones, and dates. A cost baseline contains time-phased authorized costs. A quality baseline defines standards, measures, review points, and acceptance thresholds.

The control cycle is:

1. establish and approve the baseline;
2. collect actual performance;
3. compare actual and forecast performance with the baseline;
4. explain significant variances;
5. evaluate proposed changes and their consequences;
6. approve, reject, or defer the change through governance; and
7. update controlled plans and communicate the decision.

A baseline should not be changed simply to make performance appear better. If approved scope changes, the revised baseline should preserve an auditable record of the original and the reason for revision. Otherwise, the organization loses the ability to learn from estimates and decisions.

6. Variance and Earned Value Analysis

Variance analysis asks why actual or forecast results differ from the plan and what that difference means. A variance is not automatically bad: spending less than planned may reflect efficiency, delayed work, or missing quality activities. Interpretation requires context.

Earned value management (EVM) integrates scope, schedule, and cost using three quantities, normally expressed in the same monetary unit:

• Planned Value (PV): budgeted value of work scheduled to be completed by a status date.
• Earned Value (EV): budgeted value of work actually completed by that date.
• Actual Cost (AC): actual cost incurred for the completed work by that date.

The basic variances and indices are:

Schedule variance SV and cost variance CV are expressed in budget units. A positive SV indicates more budgeted work has been completed than planned, while a positive CV indicates that the earned value exceeds actual cost. Schedule performance index SPI and cost performance index CPI are dimensionless; values above 1.00 are favorable under the conventional interpretation. These measures assume that scope has been defined and that EV measurement is credible. EVM does not measure customer value or product quality by itself.

A common estimate at completion is:

Here, BAC is the budget at completion and EAC is the forecast total cost, assuming current cost efficiency will continue and remaining work will perform according to the original budget relationship. Other EAC formulas may be appropriate when the variance is atypical or when a new bottom-up estimate is available. The assumption must always be stated.

Worked example

Suppose a project has a budget at completion of $100,000. At the status date, the plan assigns $40,000 of budgeted work, but the team has completed work whose budgeted value is $35,000. The actual cost is $50,000.

Thus, PV = 40,000, EV = 35,000, and AC = 50,000.

SV = 35,000 − 40,000 = −5,000. The project has completed $5,000 less budgeted work than planned.

CV = 35,000 − 50,000 = −15,000. The project has spent $15,000 more than the budgeted value of completed work.

SPI = 35,000 ÷ 40,000 = 0.875.

CPI = 35,000 ÷ 50,000 = 0.70.

Using the stated continuation assumption, EAC = 100,000 ÷ 0.70 ≈ 142,857. This is a forecast, not a guaranteed final cost. Management should investigate causes such as underestimated complexity, rework, low productivity, late dependencies, or unreliable EV measurement before selecting corrective action.

7. Corrective and Preventive Decisions

Corrective action addresses an observed deviation; preventive action addresses a potential deviation before it occurs. A sound decision process connects evidence to cause:

1. define the variance or threat precisely;
2. validate the data and measurement method;
3. identify the underlying cause rather than treating the symptom;
4. develop options and assess effects on scope, time, cost, quality, risk, and people;
5. select an authorized action with an owner and due date;
6. update forecasts and relevant plans; and
7. review whether the action produced the intended result.

Possible actions include resequencing work, removing a dependency, adding specialist support, reducing work in progress, improving acceptance criteria, automating a test, renegotiating scope, changing a technical approach, or formally accepting a risk. Fast action is not always good action. Adding people to a late software project may increase coordination overhead, and compressing testing may convert schedule pressure into operational risk.

Decision records should state the evidence considered, alternatives rejected, assumptions, authority, expected effect, and review date. This supports accountability and organizational learning.

8. Applied Case: The Meridian Benefits Portal

The following is a fictional illustrative case.

Background

Meridian Services is developing an online benefits portal through six two-week iterations. The target release includes identity verification, claims submission, and status tracking. A product team, a security team, and an external payment-service provider are involved.

Problem

After the third iteration, the dashboard reports that 60% of planned backlog points are complete, apparently close to the planned 65%. However, the release forecast has moved by three weeks. The integration environment is frequently unavailable, security review has a queue of 18 items, and several “done” stories require rework because acceptance tests were incomplete.

Analysis

The apparent completion percentage is a weak indicator because it counts development progress without confirming integrated acceptance. Flow data shows that work in review and test is accumulating. Dependency data shows that the payment provider has not delivered a required sandbox capability. The quality baseline requires security review before release, but that activity was not represented in the team’s iteration definition of done. The project is therefore experiencing hidden work and a misleading status signal.

Approach and solution

The project manager and product owner agree to:

• redefine done to include agreed automated tests, acceptance evidence, and security intake;
• create a visible integration lane and limit work entering it;
• escalate the unavailable environment to the infrastructure manager;
• hold a dependency meeting with the payment provider twice weekly;
• reforecast the release using remaining work and current throughput;
• prioritize a thin end-to-end transaction path rather than more isolated features; and
• report both delivery progress and quality readiness to the steering group.

The team does not erase the original baseline. It records the approved change to the release scope and retains the earlier forecast for learning.

Outcome

In the next two iterations, the review queue falls, the environment becomes available, and the team identifies two security design changes before production deployment. The release remains later than the original date but is delivered with fewer escaped defects and a more credible forecast. Stakeholders accept the revised date because the report clearly explains evidence, options, and trade-offs.

Learning points

The case demonstrates that execution control is not the pursuit of attractive status colors. It requires integrated definitions of completion, visible dependencies, leading indicators, honest baselines, and decisions based on validated evidence.

9. Governance, Ethics, and Technology

Project control involves power over priorities, information, workload, and acceptance. Ethical practice requires truthful reporting, transparent assumptions, fair treatment of team members, and escalation of material risks. Managers must not pressure staff to hide defects, manipulate estimates, or report incomplete work as complete. Quality, safety, security, privacy, and regulatory obligations should not be traded away without authorized evaluation.

Monitoring tools may collect individual productivity data, code activity, or communication patterns. Such data can be misleading and intrusive. Organizations should define a legitimate purpose, minimize collection, protect access, explain use to employees, and avoid treating activity counts as direct measures of contribution. A team member who resolves a difficult architectural issue may produce fewer visible work items than someone completing routine tasks.

AI-enabled tools can assist with dashboard summaries, anomaly detection, forecast comparison, dependency extraction, and draft risk analysis. They should not be treated as authoritative without human validation. Risks include fabricated explanations, biased predictions, exposure of confidential code or personal data, and automation of flawed metrics. Human owners remain accountable for decisions, and sensitive project data should be processed only under approved security and privacy controls.

10. Challenges and Limitations

Several conditions make monitoring and control difficult:

• Unstable scope: changing requirements make historical comparisons difficult; use versioned baselines and distinguish approved change from uncontrolled drift.
• Poor measurement: subjective completion percentages and inconsistent work-item sizes undermine analysis; define measures and calibrate them.
• Late information: monthly reporting may be too slow for a rapidly changing technical issue; match reporting frequency to decision speed.
• Metric gaming: individuals may optimize reported numbers rather than outcomes; use balanced measures and periodic audits.
• Distributed work: time zones and communication delays can conceal impediments; make ownership and escalation explicit.
• Forecast uncertainty: early estimates contain wide uncertainty; present ranges, assumptions, and confidence rather than false precision.
• Tool dependence: dashboards can create an illusion of control when source data is incomplete; verify data lineage and talk to practitioners.

Best-Practice Checklist

Before closing a reporting period, the project manager should confirm that:

• completed work meets the agreed definition of done;
• actuals and forecasts have clear dates and sources;
• major dependencies and impediments have owners;
• variances have explanations, not merely colors;
• baseline changes are authorized and traceable;
• quality, security, privacy, and compliance evidence is included;
• corrective actions have measurable expected effects; and
• stakeholders know which decisions are required and by when.

Chapter Summary

Project execution converts approved plans into coordinated deliverables through ownership, flow management, integration, and feedback. Monitoring collects reliable evidence about scope, schedule, cost, quality, risk, dependencies, and team conditions. Dashboards and status reports are effective when they support decisions rather than merely display activity.

Baselines provide controlled references for comparison, while change control preserves traceability when assumptions or objectives change. Earned value measures—PV, EV, AC, SV, CV, SPI, CPI, and appropriately selected forecasts—help integrate scope, schedule, and cost, but they do not replace judgment about quality or customer value. Corrective decisions should validate data, identify causes, evaluate trade-offs, assign ownership, and verify results. Ethical governance requires honest reporting, protection of personal and confidential information, and human accountability for technology-assisted decisions.

Key Terms

Baseline: Approved reference plan used for comparison.

Corrective action: Action taken to bring performance toward an approved objective.

Dependency: Relationship in which one activity, decision, resource, or party affects another.

Earned Value (EV): Budgeted value of work actually completed.

Impediment: Obstacle that reduces progress or quality.

Lead time: Time from request or commitment to delivery, as defined by the project.

Milestone: Significant event or decision point in a project.

Monitoring: Collection and analysis of evidence about project performance.

Planned Value (PV): Budgeted value of work scheduled by a status date.

Preventive action: Action taken to reduce the likelihood or effect of a potential problem.

Quality baseline: Approved quality standards, measures, and acceptance thresholds.

Schedule variance: Difference between earned value and planned value.

Status report: Structured communication of performance, forecasts, risks, and decisions.

Throughput: Rate at which work items are completed.

Work in progress: Items started but not yet completed.

Variance: Difference between actual or forecast performance and a reference expectation.

Review Questions

Short Answer Questions

1. What is the difference between monitoring and control?
2. Why should milestones represent observable outcomes rather than activity alone?
3. Name four categories of software-project dependencies.
4. What information should a useful status report contain?
5. Why should a baseline not be changed merely to improve reported performance?

Long Answer Questions

1. Explain how work authorization, flow management, integration, and feedback interact during project execution.
2. Compare leading and lagging indicators, giving software-project examples of each.
3. Explain the purpose and limitations of scope, schedule, cost, and quality baselines.
4. Describe a complete process for investigating and responding to a project variance.
5. Discuss ethical risks associated with individual productivity dashboards and AI-assisted project control.

Analytical / Application Questions

1. A project has PV = $80,000, EV = $72,000, and AC = $90,000. Calculate SV, CV, SPI, and CPI, then interpret the results.
2. A team’s review queue is growing while development throughput remains stable. What additional evidence would you collect, and what corrective actions might you consider?
3. A supplier dependency threatens a release milestone, but adding developers will not change the supplier’s delivery date. Recommend a control response and explain the trade-offs.

Multiple Choice Questions with Answers

Question 1

Which statement best describes project control?

A. Recording every activity performed by team members

B. Comparing evidence with approved expectations and taking authorized action

C. Changing the baseline whenever performance is unfavorable

D. Replacing planning with daily status meetings

Correct Answer: B. Comparing evidence with approved expectations and taking authorized action

Question 2

What is an impediment?

A. An approved project milestone

B. A completed work package

C. An obstacle that reduces progress or quality

D. A measure of customer value

Correct Answer: C. An obstacle that reduces progress or quality

Question 3

If a project has PV = $40,000, EV = $35,000, and AC = $50,000, what is the CPI?

A. 0.70

B. 0.875

C. 1.14

D. 1.43

Correct Answer: A. 0.70

Question 4

Which is a leading indicator?

A. Actual final project cost

B. Number of escaped production defects

C. A growing queue of items awaiting review

D. Accepted functionality at project closure

Correct Answer: C. A growing queue of items awaiting review

Question 5

What does a positive cost variance generally indicate in conventional EVM?

A. Actual cost exceeds earned value

B. Earned value exceeds actual cost

C. Planned value exceeds earned value

D. The project has no remaining risk

Correct Answer: B. Earned value exceeds actual cost

Question 6

Why are baselines maintained under change control?

A. To prevent all changes to the project

B. To preserve a traceable reference for performance comparison

C. To ensure every task has identical duration

D. To eliminate the need for forecasts

Correct Answer: B. To preserve a traceable reference for performance comparison

Question 7

Which practice most directly improves dependency management?

A. Removing all milestones

B. Assigning each important dependency an owner and escalation path

C. Reporting only completed coding tasks

D. Increasing work in progress without limit

Correct Answer: B. Assigning each important dependency an owner and escalation path

Question 8

What is a major limitation of EVM?

A. It cannot use monetary units

B. It measures customer satisfaction directly

C. It does not by itself measure product quality or customer value

D. It cannot compare planned and actual performance

Correct Answer: C. It does not by itself measure product quality or customer value

Question 9

What should a corrective-action process do first after identifying a variance?

A. Validate the data and measurement method

B. Replace the project team

C. Delete the original baseline

D. Increase the budget immediately

Correct Answer: A. Validate the data and measurement method

Question 10

Which is an ethical practice when using AI in project dashboards?

A. Allowing AI output to replace accountable decision-makers

B. Uploading confidential project data to any public tool

C. Using AI outputs as validated decision support under approved controls

D. Using activity counts as definitive measures of individual contribution

Correct Answer: C. Using AI outputs as validated decision support under approved controls