Planning Documents and Performance Baselines

Introduction

Software projects are controlled through documented intentions and approved reference points. A plan explains how work will be performed, measured, communicated, governed, and changed. A baseline is the formally approved version of a plan used for comparison with actual performance. Without clear baselines, statements such as “the project is late” or “costs are increasing” lack an agreed reference.

Planning documents and baselines are therefore not administrative paperwork. They are management instruments that connect the product scope to schedule, cost, resources, quality, communications, risks, procurement, releases, and configuration management. Their value depends on integration: a scope change may alter activities, resource demand, cost, quality controls, release dates, and risks simultaneously.

This chapter uses conventional project-management terminology, while recognising that predictive, iterative, and hybrid software approaches require different levels of detail and different update frequencies.

Learning Objectives

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

1. Explain the purpose and characteristics of integrated project plans and approved baselines.
2. Describe the principal planning documents for a software project.
3. Construct a practical scope, schedule, cost, resource, quality, communications, risk, procurement, release, and configuration-management planning set.
4. Apply earned value measures to interpret schedule and cost performance.
5. Explain how baselines are approved, protected, monitored, and changed.
6. Evaluate the governance, ethical, and practical limitations of planning and control systems.

1. Planning Documents as an Integrated System

A project plan is a coordinated set of decisions about what will be delivered, how it will be produced, who will perform the work, when it will occur, what it will cost, and how uncertainty will be managed. An integrated plan should answer five questions:

• Purpose: Why is the project being undertaken?
• Deliverables: What products, services, or outcomes will be produced?
• Method: How will the work be organised and controlled?
• Performance: How will progress and quality be measured?
• Governance: Who may approve decisions and changes?

Typical components include a project management plan, product vision or requirements baseline, work breakdown structure, schedule, cost plan, resource plan, quality plan, communications plan, risk register, procurement plan, release plan, and configuration-management plan.

The documents should not be treated as isolated files. For example, a requirement in the scope baseline should be traceable to acceptance criteria, design and development work, test activities, a planned release, and an accountable owner. This traceability reduces omissions and makes the consequences of change visible.

Characteristics of a useful plan

A professional plan is:

• Specific: it identifies deliverables, responsibilities, dates, and decision criteria.
• Realistic: it reflects available capability, constraints, and uncertainty.
• Traceable: links exist between requirements, work, resources, tests, and releases.
• Measurable: progress and quality can be assessed using defined indicators.
• Version-controlled: readers can identify the current approved version.
• Adaptable: the plan can be changed through an authorised process.
• Accessible: relevant stakeholders can obtain the information they need.

Planning detail should be proportional to risk, complexity, contractual obligations, and organisational governance. Excessive documentation can delay delivery; insufficient documentation can create ambiguity and uncontrolled change.

2. Baselines: Approved Reference Points

A baseline is a formally reviewed and approved version of a plan or product specification. It is not necessarily permanent. It remains the reference until an authorised change is approved. Common baselines include:

• Scope baseline: the approved scope statement, work breakdown structure, and work-package descriptions.
• Schedule baseline: the approved activity sequence, dates, milestones, and dependencies.
• Cost baseline: the time-phased approved budget, excluding or separately identifying management reserve.
• Performance measurement baseline: the integrated scope, schedule, and cost reference used for performance analysis.
• Product or configuration baseline: an identified and controlled version of software, documentation, or other technical artefacts.

A baseline should have an owner, approval date, version identifier, assumptions, constraints, and change history. “Freezing” a baseline does not mean that no change is permitted. It means that change is visible, assessed, authorised, and recorded rather than silently incorporated.

Baseline governance

A sound baseline process follows these steps:

1. Develop: prepare the plan with relevant stakeholders and specialists.
2. Review: test completeness, feasibility, dependencies, risks, and compliance.
3. Approve: obtain authority from the sponsor, customer, product owner, or change-control body.
4. Record: store the approved version in a controlled repository.
5. Measure: compare actual or forecast performance with the baseline.
6. Change: assess proposed changes for impact on scope, time, cost, quality, resources, risk, procurement, and releases.
7. Rebaseline when authorised: preserve the former version and document the reason.

A baseline should not be changed merely to conceal poor performance. Rebaseline decisions should distinguish between legitimate changes in project direction and attempts to make results appear favourable.

3. Scope and Requirements Planning

The scope plan establishes the project boundaries. It normally includes the product scope, project deliverables, exclusions, assumptions, constraints, acceptance criteria, and responsibilities for requirements management.

A work breakdown structure (WBS) decomposes the total project scope into progressively smaller components. The lowest useful level is a work package: a manageable unit that can be estimated, assigned, scheduled, monitored, and accepted. A WBS is deliverable-oriented, not simply a list of departments or activities.

For example, a mobile banking enhancement might be decomposed into:

• customer authentication
• requirements and acceptance criteria
• user-interface design
• service implementation
• security testing
• user acceptance
• transaction notifications
• notification rules
• message templates
• integration testing
• operational readiness

The scope baseline should include a requirements traceability matrix (RTM). A simplified RTM links each requirement to its source, design element, implementation work, test cases, acceptance evidence, and release. Traceability is particularly important for regulated, safety-critical, financial, or privacy-sensitive systems.

Scope control requires a defined distinction between:

• Defect correction: correcting nonconformance to approved requirements.
• Change: adding, removing, or modifying approved scope.
• Clarification: resolving ambiguity without changing the intended requirement.

Uncontrolled additions are commonly called scope creep. Agile teams may maintain a changing product backlog, but they still require control over release scope, acceptance criteria, capacity, and stakeholder expectations.

4. Schedule Planning and the Schedule Baseline

Schedule planning converts scope into ordered work. It involves identifying activities, estimating durations, determining dependencies, assigning resources, setting milestones, and analysing constraints.

Important relationships include finish-to-start, start-to-start, finish-to-finish, and start-to-finish. The schedule should also show external dependencies, such as supplier delivery, regulatory approval, or access to a test environment.

The critical path is the sequence of activities that determines the earliest possible project completion under the stated network logic and duration assumptions. Activities on a critical path generally have zero total float, although the exact result depends on the scheduling method and constraints. A delay on a critical-path activity can delay the project unless corrective action or resequencing occurs.

Useful schedule documents include a milestone list, network diagram, release calendar, iteration plan, dependency register, and assumptions log. A schedule baseline should be date-stamped and linked to the scope and resource assumptions used to create it.

Schedule estimates are uncertain. A useful three-point estimate is the PERT expected duration:

where a is the optimistic duration, m is the most likely duration, and b is the pessimistic duration. This weighted estimate assumes that the three-point values are meaningful and that a beta-like distribution is a reasonable approximation. It is not a guarantee and should not replace professional judgement.

For example, if a testing activity has a = 2 days, m = 5 days, and b = 11 days:

The result is an estimate of expected duration, not a promise that the task will take exactly 5.5 days.

5. Cost, Resource, and Performance Baselines

Cost planning estimates labour, tools, licences, infrastructure, training, suppliers, travel, contingency, and other project costs. Costs should be associated with work packages and time periods so that the project can compare planned expenditure with actual expenditure.

A cost baseline is often time-phased: the approved budget is distributed across the schedule. Management reserve may be held for unforeseen work within the project’s overall objectives; it should not be confused with contingency for identified risks and should be governed explicitly.

Resource planning identifies the people, skills, equipment, environments, and facilities needed. It should address availability, role responsibilities, workload, onboarding, succession, and specialist bottlenecks. A resource plan that assumes full-time availability from people who are shared across projects is not realistic.

Earned value analysis

Earned value management integrates scope, schedule, and cost. The principal quantities are:

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

The measures are expressed in the same monetary unit, although EV is a value of completed work rather than a direct cash receipt.

Schedule variance (SV) and cost variance (CV) are monetary-valued indicators: SV > 0 indicates more budgeted work has been completed than planned, while CV > 0 indicates that completed work has cost less than its authorised budget. The schedule performance index (SPI) and cost performance index (CPI) are dimensionless ratios. An index of 1.00 indicates alignment with the baseline; less than 1.00 indicates unfavourable performance under the stated measurement rules.

If the approved budget at completion is BAC, a simple forecast of final cost under the assumption that current cost efficiency will continue is:

This forecast is appropriate only when CPI is a meaningful indicator of future performance and remaining work is expected to behave similarly. Other EAC methods are appropriate when the original variance was exceptional or when remaining work has been re-estimated.

Worked example. Suppose PV = $80,000, EV = $72,000, AC = $90,000, and BAC = $200,000.

The project has completed less work than planned and has spent more than the budgeted value of the work completed. If current cost efficiency continues, the forecast final cost is $250,000. EVM does not explain the cause; managers must investigate requirements volatility, rework, estimation error, productivity, supplier costs, or accounting timing.

6. Quality Planning

Quality planning defines the standards, methods, responsibilities, and evidence used to determine whether deliverables are fit for purpose and conform to requirements. It should distinguish:

• Quality assurance: planned and systematic activities that provide confidence in processes and outcomes.
• Quality control: inspection, testing, measurement, and correction of deliverables.
• Acceptance: formal confirmation by an authorised stakeholder that specified criteria have been met.

A software quality plan may address coding standards, peer review, test levels, automation, security testing, performance thresholds, accessibility, defect classification, audit evidence, and definition of done. Quality measures should be operationally defined. “High quality” is too vague; “95% of critical test cases pass before release” is more measurable, although the appropriate threshold depends on context and risk.

Quality targets must not encourage harmful behaviour, such as closing defects without fixing them or reducing test coverage to meet a date. Metrics should support learning and product reliability rather than punish honest reporting.

7. Communications and Stakeholder Planning

A communications plan identifies stakeholders, information needs, message owners, channels, frequency, format, security classification, and escalation routes. Different stakeholders require different information: executives may need risk and milestone summaries, developers need technical decisions and acceptance criteria, testers need build and environment information, and customers need release impacts and support arrangements.

A communication is effective when the intended recipient receives, understands, and can act on the information. Meeting frequency alone is not evidence of effective communication. Plans should account for time zones, accessibility, language, confidentiality, and the difference between formal records and informal discussion.

Decision logs, action logs, status reports, dashboards, demonstrations, retrospectives, and change notices are common communication artefacts. Significant decisions should be recorded with date, decision owner, rationale, alternatives considered, and consequences.

8. Risk and Issue Planning

A risk is an uncertain event or condition that may affect objectives positively or negatively. An issue is a problem that has already occurred. A risk register normally records description, cause, event, effect, owner, probability, impact, response, trigger, due date, and status.

Qualitative risk assessment often uses probability and impact categories. A simple risk exposure calculation is:

where P is the probability of occurrence and I is the quantified impact, measured in a stated unit such as dollars or days. This multiplication is meaningful only when the scales and assumptions are consistent; ordinal labels such as “low,” “medium,” and “high” should not automatically be treated as precise numbers.

Responses include avoiding, reducing or mitigating, transferring or sharing, accepting, exploiting, enhancing, and escalating. A risk response should have an owner and a trigger. For instance, “monitor vendor reliability” is weaker than “the procurement manager will review delivery performance weekly; if two milestones are missed, an alternative supplier will be assessed.”

Risk reserves, where used, should be governed transparently. They should not become an unexamined pool that conceals weak estimates.

9. Procurement and Supplier Planning

Procurement planning determines what will be acquired externally, why it is needed, how suppliers will be selected, and how contracts will be managed. It may cover cloud services, software licences, specialist development, testing services, hardware, or support.

A procurement plan should define requirements, evaluation criteria, commercial assumptions, responsibilities, contract type, acceptance evidence, service levels, intellectual-property ownership, data protection, audit rights, security obligations, exit arrangements, and escalation procedures. Supplier dependencies should appear in the schedule and risk register.

The lowest price is not necessarily the lowest total cost. Evaluation should consider quality, resilience, integration effort, support, switching costs, compliance, and lifecycle cost. Contracts should avoid incentives that reward unsafe shortcuts or concealment of defects.

10. Release, Configuration, and Change Control

A release plan coordinates the movement of approved software and associated documentation into an environment or to users. It may include release scope, readiness criteria, deployment sequence, rollback strategy, data migration, training, support coverage, communications, and post-release verification.

Configuration management establishes and maintains the integrity of identified artefacts throughout their life cycle. Configuration items may include source code, requirements, architecture documents, infrastructure definitions, test scripts, build pipelines, database schemas, and user documentation. Core activities are identification, version control, status accounting, change control, and configuration audits.

A configuration baseline is a precisely identified collection of artefacts. A release should be reproducible: the organisation should be able to determine which source revision, dependencies, configuration values, and build process produced it. Continuous integration and automated deployment can improve this capability, but automation does not replace approval or accountability.

A change-control record should explain the requested change, reason, urgency, impact analysis, decision, implementation owner, verification, and updated documents. In iterative development, backlog prioritisation is a form of change control, but release commitments and technical baselines still require explicit governance.

11. Integrated Change Control

Integrated change control examines changes across the entire project rather than approving them in isolation. A proposed change to a payment feature, for example, may affect:

• requirements and acceptance tests;
• design and development effort;
• security and privacy assessment;
• schedule and release date;
• cost and supplier commitments;
• training and support materials;
• operational risks and regulatory evidence.

A practical impact assessment asks what changes in scope, time, cost, quality, resources, risk, procurement, communications, release content, and configuration. The decision authority should match the change’s significance. Minor technical changes may be approved within delegated limits; changes to contractual scope, budget, or regulatory obligations may require sponsor or governance-board approval.

Illustrative Case: The Atlas Learning Platform

Background

A fictional university, Northbridge College, plans an online learning platform called Atlas. The first release must support student login, course enrolment, assignment submission, and lecturer feedback before the new academic term. The project has a fixed term date, a limited internal team, and a supplier providing identity integration.

Problem

During development, lecturers request video annotation and students request mobile notifications. The requests are valuable, but neither feature is in the approved scope baseline. Meanwhile, identity integration is two weeks late and security testing has found a serious authentication defect.

Analysis

The project manager updates the requirements traceability matrix and identifies impacts. Video annotation requires additional storage, interface design, accessibility testing, and support training. Mobile notifications require a messaging service, privacy review, and additional operational monitoring. The supplier delay threatens the critical path. The authentication defect threatens release acceptance and cannot be traded away simply to preserve the date.

Approach

The change-control group decides to:

1. retain authentication, enrolment, submission, and feedback as the minimum release scope;
2. defer video annotation and mobile notifications to a later release;
3. add a supplier recovery plan and a contingency identity-test environment;
4. move security testing earlier and require closure of the critical defect before release;
5. update the schedule, risk register, release plan, communications, and configuration baseline;
6. publish the decision and rationale to lecturers, students’ representatives, the supplier, and support staff.

The project uses a controlled pilot with representative courses before wider deployment. The release baseline identifies the exact application build, infrastructure configuration, database migration script, and approved documentation.

Outcome

The first release meets the essential academic need and passes the security acceptance gate. The deferred features are not lost: they remain visible in the product roadmap with preliminary estimates and risks. Stakeholders understand that the baseline changed through an explicit decision rather than through informal promises.

Learning points

The case demonstrates that integrated planning is not about refusing change. It is about making trade-offs visible, protecting essential quality, preserving traceability, and aligning stakeholder expectations. A schedule recovery action that ignores security could create greater organisational harm than a delayed release.

12. Challenges, Ethics, and Contemporary Practice

Planning is limited by uncertainty. Early estimates may be based on incomplete requirements, novel technology, or optimistic assumptions. Baselines can also create false confidence when teams treat them as predictions rather than conditional models. Managers should record assumptions, use ranges where appropriate, review forecasts, and avoid presenting uncertain dates as guarantees.

Ethically, project leaders must report performance honestly, protect personal and confidential data, avoid discriminatory allocation of resources, and ensure that governance does not silence technical concerns. Quality and security risks should be escalated even when doing so is unpopular. Documentation should be accessible to authorised users without exposing sensitive information unnecessarily.

AI-assisted planning tools can help summarise risks, identify dependency patterns, draft test cases, estimate from historical data, or detect inconsistent documents. However, AI outputs may reproduce biased historical assumptions, omit context, expose confidential data, or generate plausible but incorrect dependencies. Human owners must validate AI-generated plans, preserve decision accountability, and comply with organisational data and intellectual-property policies.

Contemporary software projects increasingly use living documentation, version-controlled infrastructure, automated traceability, continuous delivery, feature flags, and telemetry. These practices can shorten feedback cycles, but they do not eliminate the need for approved objectives, release criteria, change authority, and auditable records.

Best-Practice Checklist

Before approving a project baseline, confirm that:

• deliverables, exclusions, assumptions, and acceptance criteria are explicit;
• every major requirement is traceable to work and verification;
• schedule logic reflects real dependencies and resource availability;
• costs are time-phased and assumptions are documented;
• quality and security gates are measurable;
• stakeholders know what information they will receive and when;
• significant risks have owners, triggers, and responses;
• suppliers and contractual dependencies are controlled;
• release and rollback arrangements are feasible;
• configuration items are identified and version-controlled;
• change authority and escalation routes are unambiguous;
• the approved version and approval evidence are preserved.

Chapter Summary

Planning documents convert project intentions into coordinated decisions about scope, time, cost, resources, quality, communications, risk, procurement, releases, and configuration. Baselines are approved reference points used to measure performance and control change. They should be versioned, traceable, realistic, and protected from unauthorised alteration.

The scope baseline defines what is included and excluded; the schedule baseline organises activities and milestones; and the cost baseline provides a time-phased financial reference. Earned value measures such as SV, CV, SPI, and CPI help compare planned, earned, and actual performance, but they require careful interpretation. Quality, communications, risk, procurement, release, and configuration plans complete the control system.

Integrated change control ensures that a proposed change is assessed across all affected dimensions. Effective governance does not prevent useful change; it makes consequences, authority, and accountability visible. Ethical planning requires honest reporting, protection of stakeholders, attention to security and privacy, and responsible use of automation and AI.

Key Terms

Baseline: An approved reference version of a plan or product specification.

Configuration item: An artefact placed under configuration management.

Configuration management: Practices for identifying, versioning, controlling, and auditing project artefacts.

Cost baseline: The approved, usually time-phased, budget used for cost comparison.

Critical path: The sequence of schedule activities governing earliest project completion.

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

Issue: A problem or condition that has already occurred.

Milestone: A significant point or event in a project schedule.

Planned Value (PV): Budget authorised for work scheduled by a specified date.

Procurement plan: Document describing external acquisitions and their governance.

Quality assurance: Planned activities providing confidence in processes and outcomes.

Quality control: Inspection and measurement used to evaluate deliverables.

Release baseline: The precisely identified content and configuration approved for release.

Requirements traceability matrix: A record linking requirements to design, implementation, testing, and acceptance.

Risk: An uncertain event or condition that may affect objectives.

Scope creep: Uncontrolled expansion of approved scope.

Schedule baseline: Approved activities, dates, dependencies, and milestones.

Work breakdown structure: Deliverable-oriented decomposition of total project scope.

Review Questions

Short Answer Questions

1. What is a project baseline, and why must it be formally approved?
2. Distinguish between a risk and an issue.
3. What information is commonly recorded in a requirements traceability matrix?
4. What is the purpose of configuration management?
5. Why should a cost baseline be time-phased?

Long Answer Questions

1. Explain how scope, schedule, cost, resource, and quality plans should be integrated.
2. Describe the process for approving and changing a project baseline.
3. Explain the meaning and limitations of PV, EV, AC, SPI, and CPI.
4. Discuss the role of release planning and configuration management in reliable software delivery.
5. Evaluate the ethical risks of manipulating baselines or performance reports.

Analytical / Application Questions

1. A project has PV = $120,000, EV = $100,000, and AC = $125,000. Calculate SV, CV, SPI, and CPI, then interpret the results.
2. A stakeholder proposes adding a major reporting feature two weeks before release. Identify the documents and baselines that should be reviewed before a decision is made.
3. A supplier delay affects a security integration milestone. Develop an integrated response covering schedule, risk, procurement, quality, communications, and release control.

Multiple Choice Questions with Answers

Question 1

Which statement best describes a project baseline?

A. An informal estimate that can be changed by any team member

B. A formally approved reference used to compare performance

C. A list of unresolved technical defects

D. A supplier invoice record

Correct Answer: B. A formally approved reference used to compare performance

Question 2

Which item is normally part of the scope baseline?

A. The approved work breakdown structure

B. The organisation’s annual financial statement

C. The team holiday calendar only

D. The supplier’s marketing plan

Correct Answer: A. The approved work breakdown structure

Question 3

If PV = $80,000 and EV = $72,000, what is schedule variance?

A. $8,000

B. −$8,000

C. $152,000

D. 0.90

Correct Answer: B. −$8,000

Question 4

If EV = $72,000 and AC = $90,000, what is CPI?

A. 0.80

B. 1.25

C. $18,000

D. 1.60

Correct Answer: A. 0.80

Question 5

What does a requirements traceability matrix primarily connect?

A. Office locations to travel expenses

B. Requirements to design, implementation, tests, and acceptance evidence

C. Employees to payroll deductions

D. Suppliers to advertising campaigns

Correct Answer: B. Requirements to design, implementation, tests, and acceptance evidence

Question 6

Which statement correctly distinguishes a risk from an issue?

A. A risk has occurred, while an issue is uncertain

B. A risk is uncertain, while an issue has already occurred

C. They are exactly the same term

D. An issue can never affect project objectives

Correct Answer: B. A risk is uncertain, while an issue has already occurred

Question 7

What is the main purpose of a release baseline?

A. To identify the exact approved content and configuration of a release

B. To remove the need for testing

C. To replace all project requirements

D. To authorise unlimited scope expansion

Correct Answer: A. To identify the exact approved content and configuration of a release

Question 8

A CPI of 0.80 generally indicates that the project is:

A. Obtaining $0.80 of earned value for each $1.00 of actual cost

B. Obtaining $1.25 of earned value for each $1.00 of actual cost

C. Exactly on budget

D. Ahead of schedule by 20 percent

Correct Answer: A. Obtaining $0.80 of earned value for each $1.00 of actual cost

Question 9

Which is the strongest example of a controlled risk response?

A. Someone should watch the supplier

B. The supplier risk will be ignored until delivery

C. The procurement manager will review milestones weekly and assess an alternative supplier after two missed milestones

D. The risk will be removed from the register

Correct Answer: C. The procurement manager will review milestones weekly and assess an alternative supplier after two missed milestones

Question 10

Why should a proposed scope change be assessed through integrated change control?

A. Because scope changes can affect schedule, cost, quality, resources, risk, and releases

B. Because approved baselines must never be changed

C. Because only the finance department can understand software

D. Because testing is unnecessary after a change

Correct Answer: A. Because scope changes can affect schedule, cost, quality, resources, risk, and releases