# Unit IV: Project Tracking and Control

4.1 Introduction

What is Project Tracking and Control?

**Project Tracking** is the process of **measuring actual project performance** against
the planned baseline. **Project Control** is the process of **taking corrective actions**
when deviations are found.

Together, they form the **monitoring and controlling process group** — one of the most
critical ongoing activities throughout a project's life.

*"You cannot control what you cannot measure."* — Peter Drucker

Why is Tracking and Control Necessary?

Software projects are **dynamic** — things rarely go exactly as planned:
- Requirements change mid-project
- Team members get sick or leave
- Technical problems arise unexpectedly
- Vendor deliveries are delayed
- Estimates turn out to be wrong

Without tracking and control, these deviations go **undetected until it's too late** to fix
them.

The Tracking and Control Cycle:

```
Plan (Baseline)
↓
Execute Work
↓
Measure Actual Performance
↓
Compare Actual vs Planned
↓
Deviation Found?
■■
No Yes
↓↓
Continue Analyze Cause
↓
Take Corrective Action
↓
Update Plan
↓
Continue Execution
```

What is Controlled in a Project?

Dimension What is Tracked
--- ---
**Scope** Is the right work being done? Any scope creep?
**Schedule** Are tasks completing on time?
**Cost** Is spending within budget?
**Quality** Are deliverables meeting standards?
**Risk** Are risks being managed? New risks emerging?
**Resources** Are resources being used efficiently?

Key Principle — Management by Exception:

Rather than reviewing everything constantly, project managers focus attention on
**exceptions** — areas where performance deviates significantly from the plan. This is
more efficient and allows focus on what truly needs attention.

**Thresholds** are set (e.g., ±10% variance is acceptable; beyond that, action is required).

Project Control vs Project Monitoring:

Monitoring Control
--- ---
Passive — observing and measuring Active — taking action
Data collection and reporting Decision making and corrective action
"What is happening?" "What should we do about it?"
Ongoing throughout project Triggered by deviations
4.2 Collection of Project Data

What is Project Data Collection?

To track a project, you need **accurate, timely data** about what is actually happening.
Project data collection is the process of **gathering information about actual project
performance** from various sources.

Types of Project Data:

#### 1. Work Performance Data (Raw Data)
The **raw observations and measurements** collected during project execution:
- Percentage of work completed for each activity
- Actual start and finish dates
- Number of defects found in testing
- Actual hours worked by each team member
- Actual cost spent to date
- Number of change requests received

#### 2. Work Performance Information (Processed Data)

Raw data **analyzed and contextualized**:
- Schedule variance (planned vs actual progress)
- Cost variance (budgeted vs actual spending)
- Defect density (defects per 1000 lines of code)
- Resource utilization rates

#### 3. Work Performance Reports (Reported Data)

Information **formatted for communication** to stakeholders:
- Status reports
- Progress dashboards
- Exception reports
- Earned Value reports

Methods of Collecting Project Data:

#### Method 1: Time Sheets / Timesheets
Team members record **hours worked** on each activity daily or weekly.

**Information captured:**
- Effort expended per task
- Which tasks are consuming more time than estimated
- Remaining effort estimates

**Challenges:**
- People often fill timesheets inaccurately (after the fact)
- Psychological resistance to detailed time tracking
- Doesn't capture quality of work — only hours

#### Method 2: Checkpoint Meetings (Status Meetings)

Regular **team meetings** (weekly, bi-weekly) where each member reports:
- What they completed since last meeting
- What they plan to do before next meeting
- Any **blockers or issues**

**Formats:**
- **Stand-up meetings** (Agile) — 15-minute daily meetings
- **Weekly status meetings** — more detailed reviews
- **Sprint reviews** (Scrum) — end-of-sprint demonstrations

**Best Practices:**
- Keep meetings focused and time-boxed
- Use a structured format (done / doing / blockers)
- Follow up on action items from previous meetings

#### Method 3: Percent Complete Estimates

Each activity owner reports the **percentage of work completed**:

Estimation Method Description

--- ---
**0/100 Rule** Activity is either not started (0%) or complete (100%) — no in-between
**50/50 Rule** Activity gets 50% credit when started, 100% when finished
**Milestone-based** Credit given at defined milestones
**Subjective estimate** Team member estimates % based on judgment

**Warning:** Percent complete estimates are **notoriously unreliable** in software. The

"90% done" syndrome is famous — projects often get stuck at 90% for a long time.

#### Method 4: Deliverable-Based Tracking

Progress is measured by **completed deliverables** rather than percentage estimates:
- Requirements document: Done ■
- System design document: Done ■
- Login module: Done ■
- Search module: In Progress ■
- Payment module: Not Started ■

**Advantage:** More objective — either the deliverable is done or it isn't.

#### Method 5: Test Results and Defect Tracking

In software projects, **testing data** is valuable for tracking:
- Number of test cases written vs planned
- Number of test cases passed vs failed
- Number of defects found, fixed, and remaining open
- Defect trends (are we fixing faster than finding?)

**Defect Burn-down Chart:**

Shows defects over time — ideally trending toward zero.

#### Method 6: Automated Tools and Dashboards

Modern projects use **project management tools** that automatically collect data:
- **Jira** — tracks issues, bugs, stories; auto-generates burndown charts
- **GitHub/GitLab** — tracks code commits, pull requests, code reviews
- **MS Project** — tracks schedule progress
- **Toggl/Harvest** — time tracking tools

These tools reduce manual data collection and provide **real-time dashboards**.

Data Collection Challenges:

Challenge Description Solution
--- --- ---
**Inaccurate reporting** Team members over-report progress Verify with deliverables
**Late reporting** Data collected too infrequently Increase reporting frequency
**Sandbagging** Hiding problems to avoid scrutiny Create a blame-free culture
**Data overload** Too much data, hard to interpret Focus on key metrics
**Inconsistent definitions** Different people measure differently Standardize measurement criteria

Key Metrics Collected:

 Metric Definition Why Important
--- --- ---
**Actual Start Date** When task actually began Compare to planned start
**Actual Finish Date** When task actually completed Compare to planned finish
**Actual Duration** How long task took Compare to estimated duration
**Actual Cost (AC)** Money actually spent Compare to budget
**Earned Value (EV)** Budgeted value of work done Central to EVA
**Remaining Duration** How much time still needed Forecast completion date
**Remaining Cost** How much money still needed Forecast final cost

4.3 Visualizing Progress

Why Visualize Progress?

Raw data is hard to interpret. **Visual representations** make it easy to:
- Quickly understand the **current state** of the project
- Spot **trends** over time
- Communicate status to **non-technical stakeholders**
- Identify **problem areas** at a glance

Visualization Technique 1: Gantt Chart with Progress

The **most common** way to show schedule progress.

**How it works:**
- Planned bars are shown in one color
- Actual progress is shown as a fill within the bar (% complete)
- A **"today" line** (vertical line) shows current date
- Activities that extend past the today line are **behind schedule**

```
Activity Jan Feb Mar Apr
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
Requirements [■■■■■■■■] ← Completed on time
Design [■■■■■■■■] ← Completed on time
Development [■■■■■■■■■■■■■■■■] ← Behind!
Testing [ ■■■■■■■■] ← Not started
↑
Today
```

**Legend:**
- ■■■■ = Completed work
- ■■■■ = Remaining planned work

Visualization Technique 2: Milestone Chart

A simplified chart showing only **key milestones** — useful for **executive reporting**.

```
Milestone Planned Actual Status
■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■
■■■■■■■■■
Requirements Signed Off Jan 15 Jan 15 ■ On Time
Design Complete Feb 10 Feb 14 ■■ 4 days late
Dev Complete Mar 30 TBD ■ At Risk
Testing Complete Apr 15 TBD ■ At Risk
Go-Live Apr 30 TBD ■ At Risk
```

Visualization Technique 3: S-Curve (Cost/Work Curve)

The **S-Curve** is a graph showing **cumulative planned vs actual** work or cost over
time. It gets its name from its characteristic S-shape.

**Why S-shape?**
- Slow start (project setup)
- Rapid middle (bulk of work)
- Slow end (finishing, testing, handover)

```
Cumulative
Work/Cost
100% ■ ■■■■■■■ Plan (S-curve)
■ ■■■■■
■ ■■■■■
50% ■ ■■■■■■■
■ ■■■■■■
■ ■■■■■■
0% ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■→ Time
```

**How to read it:**

- Plot both **Planned Value (PV)** and **Actual Cost (AC)** and **Earned Value (EV)**
- The gap between curves reveals **cost and schedule performance**
- Used extensively in **Earned Value Analysis** (Section 4.5)

Visualization Technique 4: Burndown Chart

Popular in **Agile projects**. Shows the **remaining work** over time.

**Ideal burndown** — work reduces steadily to zero.

**Actual burndown** — shows reality.

```
Remaining
Work
100 ■\
■ \ ← Ideal burndown
75 ■ \
■\
50 ■ \■■■■■■■■■■■■ Actual (behind schedule)
■\
25 ■ \
■ ■■■■■■■■ Actual (catching up)
0 ■________________________________→ Sprint Days
1 2 3 4 5 6 7 8 9 10
```

**How to read it:**

- If actual line is **above** ideal → Behind schedule
- If actual line is **below** ideal → Ahead of schedule
- Flat line (no downward movement) → **No progress being made**

Visualization Technique 5: Traffic Light Reporting (RAG Status)

Simple **Red / Amber / Green** status for each area:

Area Status Meaning

--- --- ---
Schedule ■ Green On track
Cost ■ Amber Minor concern, monitoring
Quality ■ Red Serious problem, action needed
Risk ■ Green Under control
Scope ■ Amber Some creep, being managed

**Why it works:**
- Instantly communicates status
- No numbers needed for high-level audience
- Focuses attention on problem areas (Red = needs action)

Visualization Technique 6: Velocity Chart (Agile)

Shows how much work (in **story points**) a team completes per sprint.

Used to:
- Predict how much can be done in future sprints
- Identify if team productivity is increasing or declining

```
Story
Points
40 ■ ■■
35 ■ ■■ ■■ ■■
30 ■ ■■ ■■ ■■ ■■
25 ■ ■■ ■■ ■■ ■■ ■■
■■■■■■■■■■■■■■■■■■■■■■■■■■■■→ Sprint
12345
```
Visualization Technique 7: Defect Trend Chart
Tracks **number of defects** found and fixed over time.

```
Defects
50 ■ ■■■■■ Found
■ ■■■■■
30 ■■■■
■ ■■■■■■■■■■ Fixed
15 ■ ■
0 ■■■■■■■■■■■■■■■■■■■■■■■■■■■→ Time
```

**Healthy trend:** Defects found is declining, defects fixed is catching up → project

nearing quality standards.
**Unhealthy trend:** Defects found keeps rising → quality problem getting worse.

4.4 Cost Monitoring

What is Cost Monitoring?

**Cost monitoring** is the process of **tracking actual spending** against the planned
budget and taking corrective action when variances occur.

Why Cost Monitoring is Critical:

- Software projects frequently **exceed budget**
- Budget overruns can **kill a project** or organization
- Early detection of overspending allows **corrective action**
- Clients and sponsors need **cost transparency**

Key Cost Concepts:

Term Definition
--- ---
**Budget at Completion (BAC)** Total planned budget for the project
 **Actual Cost (AC)** Money actually spent to date
**Planned Value (PV)** Budgeted cost of work planned to be done by this date
**Earned Value (EV)** Budgeted cost of work actually completed
**Cost Variance (CV)** EV – AC (positive = under budget, negative = over budget)
**Cost Performance Index (CPI)** EV / AC (>1 = efficient, <1 = over budget)

*(EV, PV, AC are covered in detail in Section 4.5)*

Types of Project Costs:

#### 1. Direct Costs
Costs **directly attributable** to the project:
- Team salaries (the biggest cost in software projects)
- Software licenses and tools
- Hardware purchases
- Training costs
- Travel expenses

#### 2. Indirect Costs (Overheads)

Costs **shared across multiple projects**:
- Office rent and utilities
- Administrative staff salaries
- Internet, phones
- HR and finance department costs

#### 3. Fixed Costs

Costs that **don't change** with the amount of work:
- Software licenses (annual fee)
- Hardware purchase (one-time)
- Facility rental

#### 4. Variable Costs

Costs that **change with the amount of work**:
- Developer hourly rates
- Cloud computing costs (pay per use)
- Contractor fees

#### 5. Sunk Costs

Costs **already spent** that cannot be recovered:
- Critical concept: Sunk costs should **NOT** influence future decisions
- Example: "We've spent ■50 lakhs already, we can't stop now" — this is the **sunk cost
fallacy**

#### 6. Contingency Reserve

**Buffer money** set aside for known risks:
- Typically 5–15% of project budget
- Used when identified risks materialize
- Managed by the **project manager**

#### 7. Management Reserve

**Buffer money** for unknown risks (unknown unknowns):
- Typically 5–10% of project budget
- Used for truly unexpected events
- Controlled by **senior management**, not the PM

Cost Baseline (S-Curve of Planned Spending):

The **cost baseline** shows the **cumulative planned spending** over time. It forms an
S-curve because:
- Spending is slow at start (planning, setup)
- Peaks during execution (team working, resources in use)
- Slows at end (deliverables done, wind-down)

This baseline is used to compare **actual spending** at any point in time.

Cost Control Process:

```
Step 1: Establish Cost Baseline (approved budget)
↓
Step 2: Record Actual Costs as work progresses
↓
Step 3: Calculate Variances (Actual vs Planned)
↓
Step 4: Analyze Variances — Root Cause?
↓
Step 5: Forecast Final Cost (Estimate at Completion)
↓
Step 6: Take Corrective Action if needed
↓
Step 7: Report status to stakeholders
```

Cost Forecasting — Estimate at Completion (EAC):

**EAC** is a forecast of what the **total project will cost** at completion, based on current
performance.

There are multiple EAC formulas:

**Formula 1: Based on current CPI (typical case)**

**EAC = BAC / CPI**

If spending efficiency continues at the current rate:

- BAC = ■1,00,000
- CPI = 0.8 (spending 20% more than planned)
- EAC = 1,00,000 / 0.8 = **■1,25,000** (project will cost 25% more)

**Formula 2: Remaining work at planned rate**

**EAC = AC + (BAC – EV)**

Assumes remaining work will be done at original planned rate.

**Formula 3: Remaining work at combined SPI/CPI rate**

**EAC = AC + [(BAC – EV) / (CPI × SPI)]**

Most conservative — accounts for both cost and schedule inefficiency.

4.5 Earned Value Analysis (EVA)

What is Earned Value Analysis?

**Earned Value Analysis (EVA)** — also called **Earned Value Management (EVM)** —
is a powerful project performance measurement technique that **integrates scope,
schedule, and cost** into a single framework.
EVA answers: *"Are we getting value for the money we're spending? Are we ahead or
behind schedule and budget?"*

The Core Insight of EVA:

Traditional cost tracking only compares **money spent vs money budgeted**. But this
ignores whether the work was actually done!

**Problem with Traditional Approach:**

- Planned: ■50,000 spent and 50% of work done
- Actual: ■50,000 spent but only 30% of work done
- Traditional view: "We're on budget!" ■
- EVA view: "We're over budget AND behind schedule!" ■

EVA captures this by measuring the **value of work actually performed**.

The Three Key EVA Parameters:

#### 1. Planned Value (PV) — "What did we PLAN to accomplish by now?"
Also called **Budgeted Cost of Work Scheduled (BCWS)**

**PV = % of work planned to be done × BAC**

**Example:** Project budget (BAC) = ■1,00,000; by today, we planned to complete 40% of

work
PV = 40% × ■1,00,000 = **■40,000**

#### 2. Earned Value (EV) — "What did we ACTUALLY accomplish?"

Also called **Budgeted Cost of Work Performed (BCWP)**

**EV = % of work actually completed × BAC**

**Example:** We actually completed only 30% of work

EV = 30% × ■1,00,000 = **■30,000**

#### 3. Actual Cost (AC) — "How much did we ACTUALLY spend?"

Also called **Actual Cost of Work Performed (ACWP)**

**AC = Actual money spent to date**

**Example:** We actually spent ■45,000 so far

AC = **■45,000**
EVA Variance Measures:
#### Schedule Variance (SV):
**SV = EV – PV**

SV Value Meaning
--- ---
**SV > 0** (Positive) ■ Ahead of schedule
**SV = 0** On schedule
**SV < 0** (Negative) ■ Behind schedule

**Example:**
SV = ■30,000 – ■40,000 = **–■10,000** → We are ■10,000 worth of work behind
schedule

#### Cost Variance (CV):

**CV = EV – AC**

CV Value Meaning
--- ---
**CV > 0** (Positive) ■ Under budget (good)
**CV = 0** On budget
**CV < 0** (Negative) ■ Over budget

**Example:**
CV = ■30,000 – ■45,000 = **–■15,000** → We are ■15,000 over budget

EVA Performance Indices:

#### Schedule Performance Index (SPI):
**SPI = EV / PV**

SPI Value Meaning

--- ---
**SPI > 1** ■ Ahead of schedule
**SPI = 1** Exactly on schedule
**SPI < 1** ■ Behind schedule

**Example:**
SPI = 30,000 / 40,000 = **0.75** → For every ■1 of scheduled work, we are only
accomplishing ■0.75 worth
#### Cost Performance Index (CPI):
**CPI = EV / AC**

CPI Value Meaning

--- ---
**CPI > 1** ■ Under budget (efficient)
**CPI = 1** Exactly on budget
**CPI < 1** ■ Over budget (inefficient)

**Example:**
CPI = 30,000 / 45,000 = **0.67** → For every ■1 spent, we are only getting ■0.67 worth
of work done

EVA Forecasting Formulas:

#### Budget at Completion (BAC):
Total planned project budget = **■1,00,000**

#### Estimate at Completion (EAC):

Predicted total cost of the project:
**EAC = BAC / CPI**
EAC = 1,00,000 / 0.67 = **■1,49,254**

*(The project will cost about ■1.5 lakh instead of ■1 lakh)*

#### Estimate to Complete (ETC):

How much more money is needed to finish:
**ETC = EAC – AC**
ETC = 1,49,254 – 45,000 = **■1,04,254**

#### Variance at Completion (VAC):

How much over/under budget at end:
**VAC = BAC – EAC**
VAC = 1,00,000 – 1,49,254 = **–■49,254** (over budget)

#### To Complete Performance Index (TCPI):

CPI needed for remaining work to finish on budget:
**TCPI = (BAC – EV) / (BAC – AC)**
TCPI = (1,00,000 – 30,000) / (1,00,000 – 45,000) = 70,000/55,000 = **1.27**
If TCPI > 1 significantly (like 1.27), it means we need to be **27% more efficient** for the
rest of the project to finish on budget — which may be unrealistic.

Complete EVA Summary Table:

Formula Name Formula Interpretation
--- --- --- ---
**PV** Planned Value % planned × BAC What we planned to do
**EV** Earned Value % done × BAC What we actually did
**AC** Actual Cost Actual spending What we actually spent
**SV** Schedule Variance EV – PV + ahead, – behind
**CV** Cost Variance EV – AC + under, – over budget
**SPI** Schedule Performance Index EV / PV >1 ahead, <1 behind
**CPI** Cost Performance Index EV / AC >1 efficient, <1 over
**EAC** Estimate at Completion BAC / CPI Predicted final cost
**ETC** Estimate to Complete EAC – AC Remaining cost needed
**VAC** Variance at Completion BAC – EAC Final over/under budget
**TCPI** To Complete Perf. Index (BAC–EV)/(BAC–AC) Efficiency needed to finish on budget

EVA Example for Exam (Complete):

**Given:**
- Project Budget (BAC) = ■2,00,000
- Planned completion by today = 60%
- Actual completion = 45%
- Actual money spent = ■1,10,000

**Calculate all EVA metrics:**

Metric Calculation Result

--- --- ---
PV 60% × 2,00,000 **■1,20,000**
EV 45% × 2,00,000 **■90,000**
AC Given **■1,10,000**
SV EV – PV = 90,000 – 1,20,000 **–■30,000** (Behind schedule)
CV EV – AC = 90,000 – 1,10,000 **–■20,000** (Over budget)
SPI EV/PV = 90,000/1,20,000 **0.75** (Behind schedule)
CPI EV/AC = 90,000/1,10,000 **0.818** (Over budget)
EAC BAC/CPI = 2,00,000/0.818 **■2,44,499**
 ETC EAC – AC = 2,44,499 – 1,10,000 **■1,34,499**
VAC BAC – EAC = 2,00,000 – 2,44,499 **–■44,499** (Over)

**Conclusion:** Project is **behind schedule (SPI=0.75)** and **over budget

(CPI=0.818)**. It will likely cost **■2,44,499** instead of ■2,00,000.

4.6 Project Tracking

What is Project Tracking?

Project tracking is the **ongoing process of monitoring the actual execution** of the project
against the plan — measuring progress, identifying deviations, and reporting status.

What Gets Tracked?

#### 1. Schedule Tracking
- Are activities starting and finishing on time?
- Which activities are behind schedule?
- Is the critical path being maintained?
- What is the new estimated completion date?

**Tools:** Updated Gantt charts, schedule variance calculations, SPI

#### 2. Cost Tracking

- Is spending within budget?
- What is the CPI?
- What is the revised estimate at completion?

**Tools:** Cost reports, EVA metrics

#### 3. Scope Tracking

- Is the team doing only the agreed work?
- Are change requests being managed properly?
- Is scope creep occurring?

**Tools:** Scope change log, WBS tracking

#### 4. Quality Tracking

- How many defects have been found?
- What is the defect removal efficiency?
- Are quality standards being met?
**Tools:** Defect logs, test reports, code review findings

#### 5. Risk Tracking

- Have any identified risks occurred?
- Are mitigation strategies working?
- Have any new risks emerged?

**Tools:** Risk register, risk review meetings

#### 6. Resource Tracking

- Are team members available as planned?
- Is anyone overloaded or underutilized?
- Are external resources (vendors) delivering on time?

Tracking Techniques:
#### Technique 1: Status Reports
**Regular written reports** (weekly or bi-weekly) summarizing:
- Work completed since last report
- Work planned for next period
- Issues and risks
- Overall RAG status

**Good Status Report Contains:**

- Executive summary (2-3 sentences)
- Schedule status (on time / delayed by X days)
- Cost status (on budget / over by X%)
- Issues and risks summary
- Key accomplishments this period
- Key activities planned next period
- Change requests pending

#### Technique 2: Earned Value Reporting

Using EVA metrics (SV, CV, SPI, CPI) to objectively report performance.

**Advantage:** Removes subjectivity — numbers don't lie.

#### Technique 3: Issue Tracking

An **Issue Log** (or Issue Register) tracks:
 - Issue ID
- Description
- Date raised
- Priority (High/Medium/Low)
- Assigned to (owner)
- Target resolution date
- Status (Open/In Progress/Closed)

#### Technique 4: Risk Register Updates

The **Risk Register** is continuously updated:
- New risks added
- Risk probability/impact updated
- Risks that have passed are closed
- Risks that have occurred trigger contingency plans

#### Technique 5: Milestone Reviews

At each milestone, a formal **review meeting** is held to:
- Confirm the milestone deliverable is complete
- Assess readiness to proceed to the next phase
- Update forecasts for remaining milestones
- Identify and resolve issues before proceeding

Tracking Frequency:
Project Stage Recommended Tracking Frequency
--- ---
Early stages (low activity) Bi-weekly
Active execution (peak work) Weekly
Near deadline (high risk) Daily
Crisis or recovery Multiple times per day

Common Tracking Problems:

Problem Description Solution
--- --- ---
**90% done syndrome** Tasks stuck at 90% complete for too long Use 0/100 or milestone-based measurement
**Happy path reporting** Team only reports good news Create blame-free culture; probe for issues
**Delayed reporting** Status reports come too late to act Shorter reporting cycles
**Tracking overload** Too many metrics to track Focus on key metrics only
**No baseline** Nothing to compare actual to Always baseline the plan before execution

4.7 Change Control

What is Change Control?

**Change Control** (also called **Change Management**) is the formal process of
**managing changes to the project scope, schedule, cost, or quality** in a structured,
controlled way.

Change is inevitable in software projects. Change control doesn't prevent change — it

**manages** it.

Why is Change Control Necessary?

**Without Change Control:**
- Anyone can request and implement changes freely
- **Scope creep** grows uncontrolled
- Budget overruns occur without accountability
- Schedule slides without formal acknowledgment
- Team is pulled in different directions
- Original objectives get lost

**With Change Control:**

- All changes are **documented**
- Impact is **analyzed** before approval
- Changes are **approved or rejected** formally
- Approved changes are **reflected in the baseline**
- All stakeholders know what changed and why

The Change Control Process:

```
Change Request Submitted
↓
Change Logged in Change Register
↓
Impact Assessment
(Scope, Schedule, Cost, Quality, Risk)
↓
Change Review Board (CRB) Reviews
↓
■■■■■■■■■■■■■
Approved Rejected
↓↓
Update Plan Notify Requester
Update Baseline Close Request
Implement Change
↓
Monitor Implementation
↓
Verify Change Complete
↓
Close Change Request
```

Types of Changes:
Type Description Example
--- --- ---
**Scope Change** Adding or removing features "Add a reporting module"
**Schedule Change** Changing milestones or deadlines "Move go-live by 2 weeks"
**Cost Change** Budget increase or decrease "Add ■5 lakh for new developer"
**Quality Change** Changing quality standards "Reduce test coverage from 80% to 70%"
**Technical Change** Changing technology stack "Switch from MySQL to PostgreSQL"
**Resource Change** Change in team members or vendors "Replace lead developer"

Change Request Document:

Every change must be formally documented:
 Field Description
--- ---
**Change ID** Unique identifier
**Date Raised** When change was requested
**Requested by** Who is requesting
**Description** What is being requested
**Reason/Justification** Why this change is needed
**Impact on Scope** What changes in deliverables
**Impact on Schedule** How many days added/removed
**Impact on Cost** Additional/reduced budget needed
**Impact on Quality** Any quality implications
**Risk Impact** New risks introduced
**Priority** High / Medium / Low
**Recommendation** PM's recommendation (approve/reject)
**Decision** Approved / Rejected / Deferred
**Approved by** Who authorized

Change Control Board (CCB / CRB):

A **Change Control Board** is a group responsible for **reviewing and approving or
rejecting change requests**.

**Typical Members:**
- Project Manager (chair)
- Project Sponsor
- Key Stakeholders
- Technical Lead
- Business Analyst

**Responsibilities:**
- Review impact assessment
- Make approve/reject/defer decisions
- Ensure changes align with project objectives
- Document decisions formally

Scope Creep vs Approved Changes:

Aspect Scope Creep Approved Change
 --- --- ---
**Process** Informal, uncontrolled Formal, controlled
**Documentation** None Change request document
**Impact assessment** Not done Always done
**Approval** None CCB approval
**Baseline update** No Yes
**Effect** Dangerous — hidden cost/time Managed — known impact

**Scope creep is the enemy of project success.** Change control is the weapon against it.

Integrated Change Control:

Changes rarely affect only one area. **Integrated change control** ensures all impacts are
considered:
- A scope change → may affect schedule (more time needed)
- A schedule change → may affect cost (more resource time)
- A quality change → may affect scope (fewer features to meet deadline)

All changes must be analyzed for their **cascading effects** across all project dimensions.

4.8 Software Configuration Management (SCM)

What is Software Configuration Management?

**Software Configuration Management (SCM)** is the discipline of **tracking and
controlling changes** to software artifacts — source code, documents, configurations, and
other project deliverables — throughout the software lifecycle.

SCM ensures you always know: *"What version of what is where, who changed it, and
why?"*

Why SCM is Critical:

- Software teams often work **in parallel** on the same codebase
- Multiple **versions** of software exist (development, testing, production)
- Need to **roll back** to a previous version if something breaks
- Need to know **what changed** between versions (for debugging)
- **Auditing** — know who changed what and when
Key Concepts in SCM:
#### 1. Configuration Item (CI)
A **Configuration Item** is any artifact that is placed under configuration control:
- Source code files
- Database schemas
- Test scripts
- Requirements documents
- Design documents
- Build scripts
- Configuration files
- Third-party libraries

#### 2. Baseline
A **baseline** is a **formally approved version** of a Configuration Item at a specific point
in time.

Types of Baselines:
Baseline When Set Contains
--- --- ---
**Functional Baseline** End of requirements phase Approved requirements
**Allocated Baseline** End of design phase Approved design
**Product Baseline** End of development Approved code + docs

Once baselined, items can **only be changed through formal change control**.

#### 3. Version Control

**Version control** (or source control) tracks **all changes** to files over time:
- Every change is recorded with author, date, and description
- Previous versions can be **retrieved** at any time
- **Branching** allows parallel development
- **Merging** combines parallel work

**Popular Version Control Tools:**

- **Git** (most widely used) — distributed version control
- **SVN (Subversion)** — centralized version control
- **GitHub/GitLab/Bitbucket** — cloud-hosted Git platforms

#### 4. Build Management

**Build management** is the process of **compiling, linking, and packaging** software
from source code into executable software.

- **Build scripts** automate the build process

- **Build tools:** Maven, Gradle, Ant (Java); Make (C/C++); npm (JavaScript)
- **CI/CD (Continuous Integration/Continuous Deployment)** — automated build and
deploy pipelines

#### 5. Release Management

Controls which **version of software is released** to which environment:
- Development → Testing → Staging → Production
- Ensures only **approved, tested versions** reach production

SCM Activities:
#### Activity 1: Configuration Identification
- Identify all items that need to be controlled (CIs)
- Assign unique identifiers to each CI
- Establish naming conventions and directory structures

#### Activity 2: Configuration Control

- Manage changes to CIs through formal process
- Ensure only authorized changes are made
- Prevent unauthorized modifications

#### Activity 3: Configuration Status Accounting

- Record and report the **status of all CIs**
- Track what version of what is in which environment
- Maintain audit trails of all changes

#### Activity 4: Configuration Audits

- **Functional Configuration Audit (FCA):** Verify software meets its functional
requirements
- **Physical Configuration Audit (PCA):** Verify software matches its documentation

Version Numbering:
Standard format: **[Link]** (e.g., 2.3.1)

Component When incremented Example

 --- --- ---
**Major** Significant new features or breaking changes 1.0 → 2.0
**Minor** New features, backward compatible 2.0 → 2.1
**Patch** Bug fixes only 2.1.0 → 2.1.1

Branching Strategies in Git:

**Feature Branching:**
```
main ■■■■■■■■■■■■■■■■■■■■■■■■■■■■→
↑ merge ↑ merge
feature/login ■■→ feature/payment■■→
```

**Gitflow:**
```
main ■■■■■■■■■■■■■■■■■■■■■■■■■■■■■■→ (production)
develop ■■■■■■■■■■■■■■■■■■■■■■■■■■→ (integration)
↑ feature/x ↑ feature/y
■■■■■■■■→merge ■■■■■■■■→merge
```

SCM Benefits:
Benefit Description
--- ---
**Traceability** Know what changed, when, why, and by whom
**Recovery** Roll back to previous working version
**Parallel development** Multiple developers work simultaneously
**Release control** Know exactly what is in each release
**Audit compliance** Meet regulatory and quality requirements
**Conflict resolution** Manage and merge parallel changes

4.9 Managing Contracts and Contract Management

What is a Contract?
A **contract** is a legally binding agreement between two or more parties that defines:
- What will be delivered (scope)
- When it will be delivered (schedule)
- How much it will cost (price)
- Terms and conditions (legal obligations)
- Rights and responsibilities of each party

In software projects, contracts govern relationships with:

- **Clients** (who are paying for the software)
- **Vendors/Suppliers** (who provide components, tools, or services)
- **Contractors** (external developers or consultants)

Types of Contracts:
#### 1. Fixed Price (Lump Sum) Contract
**Definition:** The **total price is fixed** regardless of actual cost incurred by the seller.

**Example:** "Deliver the complete e-commerce website for ■10,00,000."

Aspect Detail
--- ---
**Risk** Seller bears the risk (if it costs more, seller absorbs it)
**Best when** Scope is **well-defined** and stable
**Buyer advantage** Known cost upfront, no surprises
**Seller advantage** If they complete efficiently, they profit more
**Risk for seller** Scope ambiguity can cause losses

**Variants:**
- **FFP (Firm Fixed Price):** Strictest form — price never changes
- **FP-EPA (Fixed Price with Economic Price Adjustment):** Allows price adjustment for
inflation
- **FP-IF (Fixed Price Incentive Fee):** Bonus for early delivery or cost savings

#### 2. Cost Reimbursable (Cost Plus) Contract

**Definition:** Buyer **pays actual costs** plus a fee (profit) for the seller.

**Example:** "Pay all development costs plus 15% profit margin."

 Aspect Detail
--- ---
**Risk** **Buyer bears the risk** (if cost increases, buyer pays)
**Best when** Scope is **unclear or evolving**
**Buyer disadvantage** Open-ended cost — could be expensive
**Seller advantage** Costs always covered

**Variants:**
- **CPFF (Cost Plus Fixed Fee):** Fixed fee regardless of cost
- **CPPC (Cost Plus Percentage of Cost):** Fee is % of actual cost — **worst for buyer**
(seller benefits from higher costs)
- **CPIF (Cost Plus Incentive Fee):** Fee adjusted based on performance targets
- **CPAF (Cost Plus Award Fee):** Award given based on subjective performance
assessment

#### 3. Time and Material (T&M;) Contract

**Definition:** Buyer pays for **time spent** (hourly rate) and **materials used**. A hybrid
of fixed price and cost reimbursable.

**Example:** "■5,000 per day per developer, plus cost of tools and licenses."

Aspect Detail
--- ---
**Risk** **Shared** between buyer and seller
**Best when** Scope partially defined; short-term work
**Buyer advantage** Flexibility; pay for what you need
**Disadvantage** Cost can escalate if not capped

**Often used for:** Consulting engagements, maintenance contracts, staff augmentation

Contract Comparison Table:

Aspect Fixed Price Cost Reimbursable Time & Material
--- --- --- ---
**Risk to buyer** Low High Medium
**Risk to seller** High Low Medium
**Best for** Well-defined scope Unclear scope Ongoing/flexible work
**Cost certainty** High Low Medium
**Flexibility** Low High High
**Admin effort** Low High Medium
Contract Management Process:
#### Phase 1: Plan Procurement
- Identify what needs to be outsourced or purchased
- Decide contract type
- Define selection criteria for vendors

#### Phase 2: Conduct Procurement (Vendor Selection)

- Prepare **Request for Proposal (RFP)** or **Request for Quotation (RFQ)**
- Evaluate vendor proposals
- Negotiate terms
- Award contract

**Types of Procurement Documents:**

Document Purpose
--- ---
**RFI (Request for Information)** Gather general information from market
**RFQ (Request for Quotation)** Get price quotes for standard items
**RFP (Request for Proposal)** Get detailed proposals for complex solutions
**IFB (Invitation for Bid)** Competitive bidding for clearly defined work

#### Phase 3: Control Procurement (Contract Administration)

- Monitor vendor performance against contract
- Review deliverables for acceptance
- Process invoices and payments
- Manage contract changes
- Resolve disputes

**Key Activities:**
- **Performance reviews** — regular meetings with vendor
- **Inspections and audits** — verify deliverables meet specifications
- **Claims administration** — handle disputes formally
- **Change management** — manage contract amendments

#### Phase 4: Close Procurement

- Verify all deliverables received and accepted
- Final payment processed
- Contract formally closed
- Lessons learned documented

Statement of Work (SOW):

A **Statement of Work (SOW)** is a document that **defines the work to be performed**
under a contract. It includes:
- Scope of work
- Deliverables (what will be delivered)
- Timeline and milestones
- Performance standards and acceptance criteria
- Location of work
- Applicable standards and regulations

A well-written SOW prevents most contract disputes.

Service Level Agreement (SLA):

An **SLA** defines the **expected level of service** from a vendor:
- **Uptime guarantee** (e.g., 99.9% availability)
- **Response time** (e.g., support tickets responded to within 4 hours)
- **Resolution time** (e.g., critical bugs fixed within 24 hours)
- **Penalties** for not meeting SLA terms

SLAs are commonly used in:

- Cloud service contracts (AWS, Azure)
- IT support contracts
- Software maintenance agreements

Key Contract Management Principles:

Principle Description
--- ---
**Documentation** Keep records of all communications, deliverables, and decisions
**Formal changes only** All contract changes must be written and signed
**Proactive monitoring** Don't wait for problems — monitor continuously
**Relationship management** Maintain good working relationship with vendors
**Dispute resolution** Resolve disputes at lowest possible level before escalating
 **Compliance** Ensure contract terms are followed by both parties

Common Contract Risks and How to Manage Them:

Risk Mitigation
--- ---
**Vendor delivers late** Include penalty clauses in contract
**Poor quality deliverables** Define clear acceptance criteria in SOW
**Scope disagreements** Detailed SOW; formal change process
**Vendor goes bankrupt** Escrow arrangements for source code
**Key vendor staff leave** Require knowledge transfer; documentation
**Hidden costs** Use fixed price contract when possible
**Intellectual property disputes** Clear IP ownership clauses in contract

■ Chapter 4 — Quick Revision Summary

Topic Key Point
--- ---
**Project Tracking** Measuring actual vs planned performance
**Data Collection Methods** Timesheets, meetings, % complete, deliverables, automated tools
**Progress Visualization** Gantt, S-curve, burndown, RAG, milestone charts
**Cost Monitoring** Track actual vs budgeted spending; forecast EAC
**Types of Costs** Direct, indirect, fixed, variable, sunk, contingency
**PV** % planned × BAC — what we planned to do
**EV** % done × BAC — what we actually accomplished
**AC** Actual money spent
**SV = EV – PV** Positive = ahead; Negative = behind schedule
**CV = EV – AC** Positive = under; Negative = over budget
**SPI = EV/PV** >1 ahead; <1 behind schedule
**CPI = EV/AC** >1 under; <1 over budget
**EAC = BAC/CPI** Predicted final cost
**Change Control** Formal process to manage changes to scope/cost/schedule
**CCB** Change Control Board — reviews and approves changes
**Scope Creep** Uncontrolled, informal scope additions — must be prevented
**SCM** Tracks and controls software artifacts and versions
**Configuration Item** Any artifact placed under version control
**Baseline (SCM)** Formally approved version at a point in time
**Fixed Price Contract** Fixed cost; seller bears risk; needs clear scope
 **Cost Reimbursable** Buyer pays actual cost + fee; buyer bears risk
**T&M Contract** Pay per hour + materials; shared risk
**SOW** Statement of Work — defines what vendor must deliver
**SLA** Service Level Agreement — defines quality of service

Ready for **Chapter 5: Agile Project Management** whenever you are! ■