Process: Managing the Technical Work of the Project

Exam weight: the largest domain — roughly half of all scored questions.

Process is the craft of turning objectives into delivered value. It is the biggest domain on the exam because it is the biggest part of the job: choosing how you will deliver, then planning and controlling integration, scope, schedule, cost, quality, risk, procurement, and communications until the work is done and accepted. The exam does not reward reciting definitions. It rewards judgment — given a specific situation, what does a disciplined project manager do to keep the work aligned to value while absorbing change without chaos? This chapter builds that judgment topic by topic, and it slows down on the two places where the exam actually makes you calculate: the schedule (critical path and float) and cost (earned value). Learn those cold and you convert a cluster of guaranteed questions into guaranteed points.

1.1 Selecting and Tailoring the Delivery Approach

Before you plan a single task, you make a strategic choice: how will this project be delivered? Picture a continuum. At one end sits predictive (plan-driven, sometimes called waterfall) delivery, where you define scope up front, plan thoroughly, and execute the plan. At the other end sits adaptive (agile) delivery, where requirements emerge, work happens in short iterations, and fast feedback steers the product. In between sits hybrid, which deliberately mixes the two.

The choice is driven by the nature of the work, not by fashion:

• Predictive fits stability. When the scope is well understood, requirements can be locked early, and change is expensive or dangerous, predictive wins. Think construction, regulated hardware, or a data-center migration. You would not "iterate" a bridge.
• Adaptive fits uncertainty. When requirements are unclear, the market is moving, and frequent feedback reduces risk, adaptive wins. Think a new consumer app or a product still searching for its customer. Iterating is how you discover the right scope.
• Hybrid fits mixed reality. Real programs are often part-stable, part-uncertain: build the physical device predictively against fixed regulatory dates, while developing its software in sprints. Hybrid lets each part use the cadence that suits it.

The deciding factors are the degree of uncertainty, the expected frequency of change, how available stakeholders are to give feedback, regulatory constraints, and team experience with each approach.

Tailoring is the second half of this skill. No framework is applied by the book. Tailoring means keeping the ceremonies and artifacts that add value for this project and dropping the ones that only add overhead. A two-person, two-week effort does not need a formal change control board; a fifty-person regulated program does. The goal is always to deliver value — never to be "pure Scrum" or "pure PMBOK" for its own sake.

Common trap. The exam often dangles the "purist" answer — "enforce all Scrum ceremonies exactly" or "follow the full process regardless of project size." That is almost always wrong. Tailoring to context beats orthodoxy every time.

What should the PM do NEXT / BEST? When a scenario describes shifting requirements, an uncertain market, or a need for frequent stakeholder feedback, lean adaptive. When it describes fixed scope, heavy regulation, and costly change, lean predictive. When it describes both, choose hybrid — and never pick the answer that forces one rigid framework onto a project that does not fit it.

1.2 Integration and Integrated Change Control

Integration is the one job that is uniquely the project manager's. Team members own their specialties; only the PM unifies scope, schedule, cost, quality, risk, and stakeholders into a single coherent whole. Integration begins with the project charter — the document that formally authorizes the project and names the project manager, giving them authority to apply resources. It continues through directing and managing the work, managing project knowledge, and monitoring performance against the plan.

The beating heart of integration — and a reliable source of exam questions — is integrated change control. The rule is absolute: every requested change is captured, evaluated for its impact on all baselines (scope, schedule, cost, and more), and formally approved or rejected before it is implemented. A project manager never quietly absorbs a change, never says "sure, I'll just squeeze it in," and never lets a stakeholder's hallway request bypass the process.

Walk the sequence, because the exam tests each step:

1. A change is requested (by anyone — sponsor, customer, team, regulator).
2. The PM assesses the impact on every baseline and on the project's objectives.
3. The change goes to the appropriate authority — often a Change Control Board (CCB) — for approval or rejection.
4. If approved, the PM updates the plan and baselines and communicates the change.
5. If rejected, the decision and its rationale are documented and the requester is informed.

This discipline is exactly what prevents scope creep and keeps the plan credible: after an approved change, you measure future performance against the updated baseline, not an outdated one.

Common trap. A stakeholder asks for "just a small addition." The wrong answers are "implement it because it's small" and "refuse it outright." The right answer is almost always assess the impact and run it through change control. Small changes still consume schedule and budget; the process is how you find out by how much.

What should the PM do NEXT / BEST? Faced with any requested change, the exam-correct first move is to evaluate its impact and submit a change request — not to say yes, not to say no, and never to implement it silently. "Update the baseline" comes after approval, never before.

1.3 Managing Scope

Scope management answers a deceptively simple question: what is, and is not, part of this project? Get it wrong in either direction — missing work or unrequested extras — and the project suffers.

In predictive work the flow is orderly. The team collects requirements from stakeholders, writes a scope statement, and then decomposes the deliverables into a Work Breakdown Structure (WBS) — a hierarchical, exhaustive breakdown of everything the project will produce. Learn this vocabulary precisely, because the exam tests it:

• The lowest level of the WBS is a work package.
• The smallest unit of planned work overall — what you schedule and assign — is an activity (work packages are decomposed into activities in the schedule).
• The WBS is deliverable-oriented and covers 100% of the scope: if it is not in the WBS, it is not in the project.

The WBS creates a shared, complete picture that prevents both gaps (work everyone assumed someone else owned) and gold-plating (adding features nobody asked for, which is a defect, not a gift). Requirements are validated with stakeholders, and finished deliverables are formally accepted through Validate Scope — which is about customer acceptance. Do not confuse it with Control Quality, which is about correctness / meeting specifications. The clean distinction: Control Quality checks that the deliverable is right; Validate Scope gets the customer to sign off on it. On the exam, Control Quality typically comes first (verify it works), then Validate Scope (get it accepted).

In adaptive work, scope lives in a prioritized product backlog that is continuously refined. The variables flip: time and cost become fixed (a fixed-length sprint, a fixed team), and scope flexes — you deliver the highest-value items that fit and defer the rest.

Scope creep is uncontrolled, unapproved change to scope. The countermeasure is not simply telling stakeholders "no." It is a clear baseline plus change control: legitimate new needs are welcome — through the process, where their impact is assessed and the baseline updated if approved.

Common trap. "Add the extra feature to delight the customer" is gold-plating and is wrong even when well-intentioned. Deliver what was agreed; route new ideas through change control.

What should the PM do NEXT / BEST? When the deliverable is finished, the sequence is Control Quality → Validate Scope — confirm it is correct, then get formal customer acceptance. When scope pressure appears, protect the baseline and use change control, not a flat refusal.

1.4 Managing the Schedule: Critical Path and Float

Scheduling turns a list of activities into a model that predicts the finish date, and it is one of the two places the exam makes you calculate. Master two ideas — the critical path and float — and you own this topic.

The critical path is the longest path of dependent activities through the network. That length determines the shortest possible project duration: you cannot finish faster than your longest chain of must-happen-in-order work. Any delay to an activity on the critical path delays the whole project.

Float (also called slack) is how much an activity can slip before it causes a problem:

• Total float — how long an activity can slip without delaying the project finish.
• Free float — how long it can slip without delaying its immediate successor.
• Activities on the critical path have zero total float — that is what makes them critical.

Worked example — find the critical path and the float. A tiny network:

• Start → A takes 4 days, then A → C takes 3 days.
• Start → B takes 2 days, then B → C takes 0 (B feeds directly into C's start along its own path).

Two paths reach the end through C:

• Path A → C = 4 + 3 = 7 days.
• Path B → C = 2 + 3 = 5 days (B, then the same 3-day C).

The longer path is A → C at 7 days, so that is the critical path and the project's shortest duration is 7 days. Activity B sits on the shorter path, so it has total float = 7 − 5 = 2 days: B can slip up to 2 days before it starts pushing the project's finish. A, on the critical path, has zero float — slip A by a day and the whole project slips a day.

Recovering a slipping schedule. Two classic techniques, and the exam loves making you choose between them:

• Crashing — add resources to critical activities to shorten them. It usually costs more money (overtime, extra people) and can hit diminishing returns.
• Fast-tracking — run activities in parallel that were planned in sequence. It usually adds risk (rework if the parallel work has to change) but does not cost extra money.

The decision rule is clean: fast-track when you cannot spend more money; crash when you cannot accept more risk. Both are compression techniques applied to the critical path — compressing a non-critical activity does nothing for the finish date.

Common trap. Candidates "fix" the schedule by speeding up an activity that has float. Wasted effort — only compressing the critical path moves the finish date. Also: crashing does not always work and it is never "free"; it trades money for time.

What should the PM do NEXT / BEST? Schedule is late and budget is fixed → fast-track (accept risk). Schedule is late and risk must stay low → crash (spend money). Either way, act on the critical path, and re-baseline only through change control if the target date itself moves.

1.5 Managing Cost and Earned Value (EVM)

Cost management estimates, budgets, and controls spending against a cost baseline, and Earned Value Management (EVM) is how the exam measures — in one integrated set of numbers — whether you are on budget and on schedule at once. This is the highest-yield math on the exam. Learn the three inputs and the pattern, and every EVM question becomes plug-and-chug.

The three inputs:

• PV — Planned Value: the budgeted cost of the work you planned to have done by now.
• EV — Earned Value: the budgeted cost of the work you actually completed (budget × percent complete).
• AC — Actual Cost: what you truly spent to do that work.

Plus BAC — Budget At Completion: the total budget for the whole project.

Worked example. A project has BAC = $100,000. At the checkpoint:

• You planned to be 50% done → PV = 0.50 × 100,000 = $50,000.
• You are actually 40% done → EV = 0.40 × 100,000 = $40,000.
• You have spent AC = $45,000.

Now the four core measures. Variances are subtractions with EV first; negative is bad. Indexes are divisions with EV on top; below 1.0 is bad.

• Cost Variance: CV = EV − AC = 40,000 − 45,000 = −$5,000. Negative → over budget.
• Schedule Variance: SV = EV − PV = 40,000 − 50,000 = −$10,000. Negative → behind schedule.
• Cost Performance Index: CPI = EV ÷ AC = 40,000 ÷ 45,000 = 0.89. Below 1.0 → getting 89 cents of value per dollar spent (over budget).
• Schedule Performance Index: SPI = EV ÷ PV = 40,000 ÷ 50,000 = 0.80. Below 1.0 → doing 80% of the planned pace (behind schedule).

Forecasting the finish. If current cost efficiency will continue:

• Estimate At Completion: EAC = BAC ÷ CPI = 100,000 ÷ 0.89 ≈ $112,360. At this efficiency the project will cost about $112k, not $100k.
• Estimate To Complete: ETC = EAC − AC = 112,360 − 45,000 ≈ $67,360 — the money still needed to finish.
• Variance At Completion: VAC = BAC − EAC = 100,000 − 112,360 = −$12,360 — the projected overrun.

Reading the signs at a glance: for CV and SV, positive = good, negative = bad, zero = on plan. For CPI and SPI, above 1.0 = good, below 1.0 = bad, exactly 1.0 = on plan. Our project is over budget and behind schedule — bad on all four.

Memorize the pattern, not a table of formulas: Variance = subtraction, EV first, negative is bad. Index = division, EV on top, under 1.0 is bad. From that one sentence you can rebuild CV, SV, CPI, and SPI under pressure.

Common trap. Sign and direction errors. If a question says "CPI = 1.2," that is good (getting $1.20 of value per dollar). If "SV = −$4,000," that is behind schedule, not over budget — SV is a schedule signal even though it is in dollars.

What should the PM do NEXT / BEST? Asked whether the project is healthy, compute CPI and SPI: both ≥ 1.0 is good, either below 1.0 flags a problem to explain and address. Asked what the project will finally cost at current efficiency, use EAC = BAC ÷ CPI. Do not confuse EV (value earned) with AC (money spent) — that swap is the single most common EVM mistake.