Integrated Software Project Planning Practicum

Introduction and context

Software planning becomes valuable when separate management artefacts form one coherent decision system. A scope statement that is not connected to a work breakdown structure (WBS) cannot support reliable estimating. A schedule that ignores resource availability is not a credible commitment, and a budget that excludes quality, risk, or project management costs is incomplete. Integrated planning connects scope, deliverables, activities, estimates, dependencies, resources, cost, risk, governance, measurement, and change control.

This chapter presents a complete illustrative plan for a small software project. The example is intentionally realistic enough to demonstrate professional reasoning while remaining suitable for certificate-level study. It uses predictive planning for contractual control, with short iterative development cycles inside the approved baseline. The central lesson is that a plan is not merely a document: it is a set of linked assumptions and control mechanisms that must be defended, monitored, and revised responsibly.

Learning objectives

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

1. Define a practicable software project scope and acceptance boundaries.
2. Decompose scope into a deliverable-oriented WBS and activities.
3. Estimate effort, duration, resources, cost, and contingency coherently.
4. Construct and interpret an integrated schedule and baseline budget.
5. Identify risks and connect responses to schedule and cost decisions.
6. Design governance, metrics, reporting, and change-control procedures.
7. Defend planning assumptions and recognize limitations in a project plan.

1. The integrated planning logic

An integrated plan answers seven connected questions:

• What will be delivered, and what is explicitly excluded?
• How will the work be decomposed and performed?
• When can each deliverable be completed, considering dependencies?
• Who will perform, review, approve, and support the work?
• How much effort and money are required?
• What may go wrong, and what responses are justified?
• How will performance and approved changes be governed?

The logical chain is:

Scope → WBS → activities → estimates → dependencies → schedule → resources and cost → risks and controls → baseline and change management.

A weakness at an earlier point propagates forward. For example, omitting data migration from scope may produce a short schedule, but the omission will later appear as an emergency task, an unplanned cost, and a stakeholder dispute.

Important planning terminology

• Deliverable: A verifiable product, service, or result.
• Work package: The lowest WBS component normally estimated and controlled.
• Activity: A scheduled piece of work that consumes time and resources.
• Dependency: A logical relationship between activities.
• Baseline: An approved version of scope, schedule, or cost used for comparison.
• Assumption: A planning belief treated as true in the absence of certainty.
• Constraint: A limiting factor such as a fixed date, budget, or regulation.
• Contingency reserve: Budget or time held for identified risks or estimation uncertainty within the approved scope.
• Management reserve: Additional funds controlled by management for unforeseen in-scope work; it is not part of the performance measurement baseline unless formally authorized.

2. Case: the Campus Service Request Portal

The following is a fictional illustrative case. A university currently receives maintenance requests by telephone and email. Requests are often duplicated, lack location information, and cannot easily be tracked. The sponsor authorizes a ten-week project to implement a responsive web portal through which students and staff can submit requests, attach photographs, view status, and receive notifications. Facilities staff need a triage queue and basic reporting.

2.1 Business problem and success criteria

The problem is not simply the absence of a website; it is the absence of a consistent, traceable service-request process. The project will be considered successful when:

• at least 90% of pilot requests are submitted through the portal rather than email;
• users can submit a request in five minutes or less during acceptance testing;
• facilities staff can assign, update, and close requests;
• 95% of valid submissions receive confirmation within one minute under the agreed test load;
• no critical security defect remains open at release; and
• the product owner accepts the defined release scope.

These measures are preferable to the vague objective “build a user-friendly portal,” because they provide observable evidence.

2.2 Scope statement

In scope: responsive web interface; authenticated student and staff access using the university identity service; request categories and locations; photograph attachment; request status; email notifications; facilities triage queue; basic monthly report; security testing; deployment to the university cloud environment; user guidance and training.

Out of scope: native mobile applications; automated assignment using machine learning; integration with the finance system; historical migration of all email requests; 24-hour service operations; multilingual support beyond the university’s existing language.

Constraints: ten calendar weeks; maximum approved funding of approximately £60,000; use of the existing identity service; compliance with university privacy and records policies; part-time availability of the facilities subject-matter expert.

Assumptions: the identity service is available and documented; a cloud environment can be provisioned by week 2; the sponsor supplies decisions within two working days; a product owner is available for weekly demonstrations; no major change to the university privacy policy occurs during the project.

The explicit exclusions are important. A project can fail by delivering more than was authorized, because unapproved features consume time and create support obligations.

3. From scope to WBS

A WBS decomposes the total project scope into manageable deliverables. It is not merely a to-do list and should not be organized only by individual names. The following WBS uses deliverables and control accounts.

Each major element is decomposed further. For example, 4.0 includes request submission, attachment handling, status tracking, notifications, staff triage, and reporting. A work package should be small enough to estimate and assign, but not so small that administrative tracking overwhelms productive work. The 100% rule is useful: the child elements should collectively represent all approved work, neither omitting nor double-counting scope.

The WBS dictionary records each work package’s description, owner, assumptions, acceptance criteria, dependencies, and exclusions. This converts labels such as “testing” into a shared understanding of what testing includes.

4. Estimating effort, duration, and cost

Estimates are forecasts, not promises. A responsible estimate identifies its method, uncertainty, assumptions, and confidence. Three practical methods are useful at certificate level:

1. Analogous estimating: compares the project with a similar completed project. It is quick but sensitive to differences in complexity.
2. Bottom-up estimating: estimates work packages and aggregates them. It is more transparent but requires a reasonably understood scope.
3. Three-point estimating: expresses optimistic, most likely, and pessimistic values to acknowledge uncertainty.

For a simple three-point estimate using a beta-weighted approximation, the expected estimate is:

where O is the optimistic estimate, M the most likely estimate, and P the pessimistic estimate, all in the same unit (for example, person-days). This formula assumes the three judgments represent a plausible bounded range and that the most likely value deserves greater weight. It is a planning approximation, not a guarantee or a substitute for historical data.

A commonly used dispersion approximation is:

where σ is an approximate standard deviation in the same unit. It should not be interpreted as a statistically validated distribution unless the organization has evidence supporting that assumption.

Worked estimating example

Suppose integration and notification work is assessed as O = 8 person-days, M = 12 person-days, and P = 20 person-days. Then:

The approximate dispersion is:

The project manager may round the planning value to 13 person-days, while retaining the underlying range in the risk register. Rounding should be visible; false precision is misleading.

Effort versus duration

Effort is the amount of labor, such as person-days. Duration is elapsed calendar time. They are not interchangeable. If a task requires 10 person-days, assigning two people does not automatically make it five days: communication, specialized skills, testing, and serial dependencies may limit concurrency. A simple capacity check is:

The availability factor ranges from 0 to 1 and represents the proportion of time genuinely available after meetings, support, leave, and other assignments. This relation is a capacity check, not a universal duration formula.

For example, two analysts available at 0.75 capacity over four working days provide:

They cannot credibly be scheduled for 10 person-days of work in that period without overtime, additional staff, or a changed date.

Cost estimating

For a labor-based plan:

where effortᵢ is the effort for labor category i and rateᵢ is the approved cost per person-day. The units must match. If effort is in person-days, rates must be in currency per person-day.

The illustrative project estimate is as follows.

The budget is close to the £60,000 constraint. Therefore, adding optional features is not harmless; it threatens both funding and schedule. If identified risks are assessed as requiring a £4,000 contingency reserve, the authorized funding would need to be £62,550 unless the sponsor reduces scope or accepts a different risk position. This illustrates why “budget” and “cost baseline” must be distinguished from the sponsor’s total funding limit.

5. Building the schedule

The schedule is built from activities, durations, dependencies, calendars, and assigned resources. The project uses a hybrid approach: a controlled baseline and milestone plan, with two-week development iterations.

The stated relationships are simplified finish-to-start dependencies, except that C may begin after the key requirements needed for design are stable. D can proceed in parallel with B. The longest dependency chain is approximately A–B–C–E–F–G–H–I–J: 5 + 8 + 8 + 10 + 10 + 8 + 5 + 4 + 2 = 60 working days. This is approximately twelve five-day weeks, which conflicts with the ten-week constraint. The plan therefore requires deliberate overlap, reduced scope, or additional capacity.

This is a valuable planning discovery, not a scheduling failure. The project manager can shorten the plan by:

• starting environment setup during discovery;
• allowing development of stable components while lower-risk requirements are finalized;
• reserving only critical end-to-end testing for the final integration window;
• using a prepared training environment; and
• removing nonessential reporting from the first release.

The revised schedule targets ten weeks with milestones: requirements baseline at the end of week 2, design and environment readiness at week 3, feature-complete release candidate at week 7, system testing at week 8, acceptance at week 9, and deployment and handover in week 10. These overlaps require explicit entry criteria and are not permission to ignore unfinished predecessors.

A schedule network can be analyzed using the critical path method. For activity i, the earliest finish is:

where ES is earliest start and d is duration. For a finish-to-start network, the earliest start of an activity is the maximum earliest finish of its immediate predecessors:

Total float, when a latest-start calculation is available, is:

where LS and LF are latest start and latest finish. Activities with approximately zero float form the critical path under the stated network and calendar. These equations assume defined dependencies, a consistent calendar, and no unmodeled resource constraints. A resource-constrained schedule may differ from the purely logical critical path.

6. Resource plan and responsibility

The core team comprises a project manager, business analyst, UX designer, two developers, a tester, a facilities subject-matter expert, and a part-time security adviser. A RACI matrix clarifies responsibility:

RACI is a communication aid, not a replacement for professional judgment. “Accountable” should normally be singular for a decision or deliverable; otherwise approval becomes ambiguous.

Resource smoothing may move noncritical work without changing the end date. Resource leveling may change the end date when a scarce resource is overallocated. The plan should show planned availability rather than assuming every named person is continuously productive.

7. Risk, quality, and uncertainty

A risk is an uncertain event or condition that may affect objectives; an issue is a current problem. The risk register connects probability and impact to an owner and response.

A qualitative probability-impact matrix supports prioritization, but ordinal scores are not monetary forecasts. Responses include avoiding, mitigating, transferring, accepting, or escalating a risk. A trigger should be observable: for example, “identity-service test credentials not received by the end of week 1.”

Quality is planned into the work rather than inspected only at the end. Examples include code review, automated tests for validation rules, accessibility checks, security testing, traceability from requirements to tests, and a definition of done. Acceptance criteria should specify observable behavior, not personal preference.

8. Governance, metrics, and control

Governance defines who makes decisions, how information flows, and what evidence is required. The proposed structure is:

• Sponsor: owns the business case, funding, and major escalations.
• Product owner: prioritizes requirements and accepts deliverables.
• Project manager: integrates the plan, manages delivery, and reports status.
• Technical lead: owns technical coherence and engineering decisions.
• Steering group: reviews scope, risk, budget, and decisions at milestone gates.

Weekly team reviews focus on progress, impediments, quality, and the next two weeks. A weekly sponsor report contains milestone status, top risks, decisions required, budget position, and approved changes. Gate reviews occur at requirements baseline, release candidate, and deployment readiness.

Useful metrics must support decisions rather than reward superficial activity. Examples are:

• milestone forecast variance in working days;
• planned versus actual effort by work package;
• open defects by severity and age;
• requirements with verified acceptance tests;
• risk exposure and overdue responses;
• percentage of scope accepted; and
• cycle time from submitted request to tested change.

For a basic schedule variance measure:

A positive value means late when dates are represented chronologically. For cost variance:

These simple measures require a clear status date and consistent treatment of partial work. They do not explain causation by themselves.

Earned value can be introduced cautiously. Planned value (PV) is the budgeted value of work scheduled by a status date; earned value (EV) is the budgeted value of work actually completed; actual cost (AC) is the cost incurred. Then:

SV and CV are expressed in currency units, while SPI and CPI are dimensionless ratios. CPI or SPI above 1 indicates favorable performance under the chosen measurement rules; below 1 indicates unfavorable performance. These measures are meaningful only when completion rules and budgets are credible. A team must not claim earned value merely because hours were spent.

9. Change control and plan defense

Change is normal; uncontrolled change is harmful. The project uses the following procedure:

1. Any stakeholder submits a change request describing the need, urgency, and expected benefit.
2. The project manager logs it and checks whether it is already within approved scope.
3. The analyst and technical lead assess impact on requirements, WBS, schedule, resources, quality, security, risk, and cost.
4. The product owner recommends priority; the sponsor or delegated change authority decides according to thresholds.
5. If approved, affected baselines and plans are updated, versioned, and communicated.
6. The team implements and verifies the change; the decision record remains auditable.

A change request should not be rejected simply because it is inconvenient, nor accepted because a senior person asks informally. For example, a request for automated complaint classification is outside scope. Its assessment might identify 12 additional person-days, new privacy risk, model testing, and a two-week schedule impact. The sponsor can approve it with extra funding and a revised date, defer it to a later release, or reject it. The professional defense is based on traceable impacts rather than opinion.

The plan’s main decisions can be defended as follows:

• Hybrid delivery: preserves milestone and funding control while allowing feedback through iterations.
• Ten-week target: honors the business constraint, but requires early environment work and disciplined scope.
• No historical migration: avoids hidden data-cleaning effort and protects the release date.
• Early privacy review: addresses a high-consequence risk before design becomes expensive to change.
• Contingency discussion: makes uncertainty visible instead of presenting £58,550 as a certain final cost.

10. Ethical, regulatory, and contemporary considerations

The portal processes personal information, including names, locations, photographs, and potentially descriptions of unsafe conditions. Data minimization, purpose limitation, access control, retention rules, secure transmission, and incident procedures should be addressed with the university’s privacy officer. Accessibility should be treated as a quality requirement, not an optional enhancement. Users with disabilities must be able to navigate, submit, and understand status information through the agreed accessibility standard.

AI could assist with drafting test cases, identifying duplicate requirements, or summarizing status reports, but generated material requires human verification. Sensitive personal data should not be entered into an unapproved external AI service. AI-generated estimates may reproduce historical bias or false confidence; they should supplement, not replace, expert review and evidence.

Contemporary planning increasingly uses integrated digital tools: version-controlled requirements, issue trackers, automated builds, dashboards, and cloud cost monitoring. Tools improve traceability but do not solve unclear accountability. A dashboard can display a green status while critical assumptions remain untested.

11. Limitations and best practices

This illustrative plan has limitations. Effort estimates are judgmental, the schedule uses simplified dependencies, the budget does not model inflation or procurement delay, and qualitative risk ratings do not provide a probabilistic completion forecast. Real projects should use organizational historical data, validated calendars, procurement advice, security specialists, and appropriate quantitative analysis when the decision value justifies it.

Best practices include:

• baseline only after scope and acceptance criteria are sufficiently understood;
• document assumptions with an owner and review date;
• estimate from the WBS rather than from an attractive target date;
• separate effort, duration, and availability;
• schedule quality and governance work explicitly;
• maintain a live risk and decision register;
• measure outcomes and quality, not only activity;
• control changes through impact analysis; and
• close the project by transferring knowledge, unresolved risks, and operational ownership.

Chapter Summary

Integrated software project planning links scope, WBS, activities, estimates, dependencies, schedule, resources, cost, risk, governance, metrics, and change control. The Campus Service Request Portal case demonstrates how a clear scope boundary supports decomposition and how bottom-up and three-point estimates can expose uncertainty. Effort is distinct from elapsed duration, and a logical critical path may require adjustment when resources are limited. A credible budget identifies its cost basis and distinguishes the cost baseline from contingency and total funding authority. Governance assigns decision rights, while metrics provide evidence for corrective action. Finally, change control protects the approved objectives without pretending that change can be eliminated. A strong plan is therefore both a delivery map and a defensible management argument.

Key Terms

Activity: A scheduled unit of work that consumes time and resources.

Assumption: A condition treated as true for planning purposes.

Baseline: An approved reference version used to measure performance.

Contingency reserve: Budget or time for identified risks and estimation uncertainty within scope.

Constraint: A restriction on project choices, such as date, budget, or regulation.

Critical path: The longest dependency path determining the earliest completion under stated assumptions.

Deliverable: A verifiable product, service, or result.

Earned value: Budgeted value of work actually completed.

Float: Schedule flexibility available to an activity without violating a defined constraint.

Governance: Structures and processes for authority, decisions, accountability, and oversight.

Issue: A problem that has already occurred or is currently occurring.

Milestone: A significant zero-duration event or decision point.

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

RACI: A responsibility model identifying responsible, accountable, consulted, and informed parties.

Scope statement: A description of included and excluded work and its boundaries.

Three-point estimate: An estimate based on optimistic, most likely, and pessimistic values.

Work package: A manageable WBS component used for estimating and control.

WBS: A hierarchical decomposition of the project’s total approved scope.

Review Questions

Short Answer Questions

1. Why must scope, the WBS, estimates, and the schedule be linked?
2. Distinguish effort from duration and give one reason they may differ.
3. What is the purpose of a WBS dictionary?
4. Differentiate a risk from an issue.
5. Why should a change request include schedule and cost impact analysis?

Long Answer Questions

1. Explain how the Campus Service Request Portal could be planned from its scope statement through its cost baseline.
2. Discuss the advantages and limitations of analogous, bottom-up, and three-point estimating.
3. Explain how governance roles and milestone gates support accountable decision-making.
4. Describe how quality, privacy, accessibility, and security should be integrated into a software plan.
5. Discuss why a logically feasible schedule may become infeasible after resource availability is considered.

Analytical / Application Questions

1. A work package has optimistic, most likely, and pessimistic estimates of 6, 10, and 18 person-days. Calculate its three-point expected estimate and approximate dispersion, and explain how you would use the result.
2. A sponsor requests a new mobile application during week 4. Describe the impact-analysis and approval steps you would follow before committing the team.
3. The project has PV = £30,000, EV = £27,000, and AC = £25,000 at the status date. Calculate SV, CV, SPI, and CPI, then interpret the results cautiously.

Multiple Choice Questions with Answers

Question 1

Which sequence best represents integrated project planning?

A. Budget → staffing → scope → testing

B. Scope → WBS → activities → estimates → schedule and cost

C. Risks → deployment → scope → requirements

D. Schedule → marketing → procurement → WBS

Correct Answer: B. Scope → WBS → activities → estimates → schedule and cost

Question 2

Using the three-point estimate E = (O + 4M + P) ÷ 6, what is the expected estimate when O = 6, M = 10, and P = 18 person-days?

A. 9 person-days

B. 10 person-days

C. 10.7 person-days

D. 12 person-days

Correct Answer: C. 10.7 person-days

Question 3

Two people are available for four working days at 0.75 capacity each. What effort is available?

A. 4 person-days

B. 6 person-days

C. 8 person-days

D. 10 person-days

Correct Answer: B. 6 person-days

Question 4

Which item is most appropriately included in a WBS dictionary?

A. An employee’s personal preference

B. A work package’s acceptance criteria and assumptions

C. An unrelated department’s annual budget

D. A social media announcement

Correct Answer: B. A work package’s acceptance criteria and assumptions

Question 5

What does a positive schedule variance defined as actual finish date minus baseline finish date indicate?

A. The work finished early

B. The work finished late

C. The budget was reduced

D. The scope was automatically accepted

Correct Answer: B. The work finished late

Question 6

Which statement correctly distinguishes a contingency reserve from a management reserve?

A. Contingency is for identified uncertainty within scope; management reserve is controlled for unforeseen in-scope work

B. Contingency is always outside the project budget; management reserve is always spent immediately

C. They are identical terms with no governance distinction

D. Management reserve is assigned directly to every activity

Correct Answer: A. Contingency is for identified uncertainty within scope; management reserve is controlled for unforeseen in-scope work

Question 7

At a status date, PV is £30,000, EV is £27,000, and AC is £25,000. What is the CPI?

A. 0.83

B. 0.90

C. 1.08

D. 1.20

Correct Answer: C. 1.08

Question 8

Who normally accepts defined product deliverables in the illustrative governance model?

A. The product owner

B. The cloud supplier

C. The facilities receptionist

D. The external auditor only

Correct Answer: A. The product owner

Question 9

What is the most appropriate first response to an out-of-scope feature request?

A. Implement it immediately if a developer has spare time

B. Delete the original requirement

C. Log it and assess its impacts before authorization

D. Ignore it permanently without recording the request

Correct Answer: C. Log it and assess its impacts before authorization

Question 10

Which practice best integrates quality into software planning?

A. Postponing all testing until after deployment

B. Defining acceptance criteria, reviews, security checks, and test evidence during planning

C. Counting hours worked as proof of quality

D. Removing defect tracking to protect morale

Correct Answer: B. Defining acceptance criteria, reviews, security checks, and test evidence during planning