19-Soft-B6 Software Project Management, May 2015, Q4

Question 4 (10 marks)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Part (a) — the Four P's. Pressman frames effective project management as focused on four interdependent P's, considered roughly in this priority order:

People — recruiting, organizing, and motivating a team with the right skills; considered the single most important factor, since even a good process cannot compensate for the wrong people.
Product — establishing the objectives and scope of what is being built before planning can be meaningful; you cannot plan work you have not bounded.
Process — choosing a process model (Question 1–3) appropriate to the people, the product, and the project's constraints, and adapting it rather than following it rigidly.
Project — the actual planning, organizing, staffing, and controlling activity that ties people, product and process together into a schedule and a budget, and keeps it on track.

The focus of effective project management is getting these four right, in this dependency order — a strong process cannot rescue a poorly-scoped product, and a well-scoped product cannot be delivered without the right people executing the chosen process under active project control.

Part (b) — main project metrics.

Metric family	Examples
Size	Lines of code (LOC), function points (FP)
Effort / cost	Person-months, cost per FP or per LOC
Schedule	Planned vs. actual milestone dates, schedule variance
Productivity	FP/person-month, LOC/person-month
Quality	Defect density (defects/KLOC or defects/FP), defect removal efficiency
Progress (agile)	Velocity, burndown/burnup rate

These metrics matter because they turn "the project is going fine" into a checkable, quantitative claim: size and effort metrics feed estimation (Question 8b), schedule metrics drive the monitoring-and-control loop, and quality/defect metrics are the closest thing software has to a measured, objective indicator of product quality during development, before the customer sees the delivered system.

Part (c) — forensic project management. Forensic project management is the retrospective, evidence-based investigation of a troubled or failed software project to determine what actually happened and why, applying the same disciplined, fact-gathering rigor used in a forensic (legal/criminal) investigation rather than relying on participants' after-the-fact recollection. It typically reconstructs a timeline from project artifacts (status reports, change requests, meeting minutes, defect logs, emails), compares planned vs. actual schedule/cost/scope at each milestone, and identifies the specific decision points and root causes (not just symptoms) where the project diverged from a recoverable path. It is used both constructively, to produce lessons-learned that feed back into an organization's process improvement (Question 2b's evolutionary-model feedback loop, generalized to project management itself), and, in disputed or litigated projects, as expert-witness evidence establishing who is responsible for a failure and why.

Topic: Pressman's Four P's as the organizing focus of project management, the standard families of software project metrics, and forensic project management as retrospective, evidence-based failure analysis.

Key relations: Four P's = People → Product → Process → Project, in dependency order. Metrics = size + effort + schedule + productivity + quality (+ velocity for agile). Forensic PM = reconstruct timeline from artifacts → compare planned vs. actual → identify root cause, used for lessons-learned or litigation.

Why this works: the Four P's and the metrics table are two views of the same control loop — the P's say what must be managed, the metrics say how progress against each is actually measured; forensic project management is what happens when that loop's own record (the metrics history) becomes the evidence base for explaining why the loop failed.

Common pitfall: quoting the Four P's out of order or as an unordered checklist — the ordering matters pedagogically because it reflects a real dependency (you cannot plan a project around a product that has not been scoped, by a team that has not been assembled).

Source: Pressman, Software Engineering: A Practitioner's Approach, 9th ed., Ch. 1 (The Four P's) & Ch. 22 (Metrics for Process and Projects); SWEBOK v4, Software Engineering Management KA.

Question 4 of 8

Question 4 (10 marks)