9.2 Structured Technical Problem-Solving for PSP Scenarios

9.2 Structured Technical Problem-Solving for PSP Scenarios

PSP scenarios combine narrative facts with planning or scheduling data. The main risk is solving the wrong problem accurately. Use a disciplined sequence that works for scope, CPM, resource, update, risk, and memo questions.

Step 1: identify the required output

Read the final sentence first. Is the question asking for an early finish, total float, a planning input, a schedule-quality defect, a forecast, or a recommendation? Circle the unit: working days, calendar days, currency, labor-hours, or an option label.

Step 2: sort the inputs

Create five quick buckets:

Do not import an unstated legal rule, software default, or calendar. If a problem supplies enough data under a simplified convention, use that convention consistently.

Step 3: sketch the model

For a network calculation, draw nodes and relationships. For a planning question, draw the flow from requirements to scope, WBS, activities, logic, durations, resources, baseline, update, and forecast. For a memo, outline issue, impact, alternatives, analysis, recommendation, and handoff.

Step 4: calculate visibly

Write intermediate values. For finish-to-start logic in a zero-day convention:

$EF = ES + D$

$ES_{successor} = max(EF_{predecessors} + lag)$

On the backward pass:

$LS = LF - D$

$LF_{predecessor} = min(LS_{successors} - lag)$

Then calculate total float as $LS - ES$ or $LF - EF$. If the question uses inclusive day numbering, adjust consistently rather than mixing conventions.

Step 5: perform a reasonableness check

Ask:

• Does a successor start before a required predecessor event?
• Did I apply the correct calendar and lag units?
• Does the path with least float actually connect to the milestone?
• Did I confuse physical percent complete with duration percent complete?
• Did I treat cost-loaded progress as proof of critical-path progress?
• Did a constraint create the negative float rather than the logic alone?

This check catches many distractors.

Step 6: separate technical and commercial conclusions

A scenario may show that an event moved a milestone ten days. That is a schedule result. Responsibility, time extension, compensation, or damages also depend on any contract facts supplied. If the prompt supplies no contract rule, choose the answer that preserves that uncertainty rather than asserting a universal entitlement.

Worked example: redundant relationship

Activity A finishes before B starts, and B finishes before C starts. A direct A-to-C finish-to-start relationship is also present. In the unchanged network, the direct tie may be mathematically redundant because the A-B-C chain already enforces A before C. The planner should test whether the tie represents a distinct physical requirement before deleting it. If it is merely transitive, removal simplifies maintenance; if B is later deleted or resequenced, the direct tie might become meaningful. “Redundant” is therefore a model diagnosis, not permission to delete a relationship without review.

Worked example: resource choice

Two eligible activities need one crane. The activity with less float may receive priority under a stated heuristic, but an operational decision may also consider access, mobilization, safety, or contractual milestones. If the question names the heuristic, apply it. If not, avoid pretending one software priority rule is universal.

Scenario triage

If a question is taking too long, preserve your work, flag it, and move on if the interface permits. Return after completing questions you can solve reliably. The current exam is organized by domains, not the obsolete three-part question counts, so use the actual interface and your remaining total time rather than waiting for a fictional part boundary.

A repeatable process improves both speed and defensibility: identify the output, normalize the facts, model visibly, calculate, test plausibility, and keep conclusions within the evidence.

Applied review: solve in a controlled sequence

Begin by identifying the required output: a date, float value, resource decision, forecast, risk interpretation, or management recommendation. Record the data date, calendar convention, units, and any missing information. Sketch the relevant network or table before calculating. When several formulas are possible, state what future-performance assumption each formula represents and choose the one consistent with the question.

After calculating, perform reasonableness checks. A finish date should follow its driving predecessor and calendar; free float should not exceed total float under the same convention; a productivity increase should reduce duration only if quantity and available resources support it; and a forecast should not be presented as certain when its assumptions are unstable. Carry sufficient precision during work, then round only at the end and label the unit.

For qualitative scenarios, separate fact, inference, and recommendation. Identify which record or stakeholder can validate uncertain input and preserve the baseline while updating current truth. The strongest answer is not always the most aggressive date; it is the response that is mathematically correct, technically feasible, traceable to evidence, and appropriately communicated.