What Should the Project Manager Do First? A PMP Decision Guide


What Should the Project Manager Do First? A PMP Decision Guide

Work through a set of PMP practice questions and a pattern appears quickly. The difficulty is rarely that three options are obviously wrong. More often, all four are things a capable project manager does at some point on a project. Inform the sponsor. Update the risk register. Speak to the supplier. Raise a change request. Nothing in the wording of the options tells you which one belongs at the front, and candidates lose marks not because they chose a bad action but because they chose a good action too early.

The same problem exists away from the exam, in a less tidy form. You arrive at a situation that is already moving. Three or four sensible things need doing. The order in which you do them shapes how much room you still have afterwards.

The short answer is that the best first action is the one the other actions depend on. In most situations that means establishing what has actually happened, whose decision this is, and what agreement already applies. There is an important exception, covered later, where acting immediately is correct and gathering information is simply delay.

Four defensible actions and only one order

Scenario options are usually drawn from different stages of the same response. One is analysis, one is consultation, one is a decision, one is a communication or a record. Presented as a list they look like competing choices. Read as a sequence, most of them are things you will do anyway.

Consider a supplier who has told you a key delivery will be four weeks late. You could escalate to the sponsor, raise a change request, meet the supplier to understand the cause, or log the delay as an issue and update the schedule. Over the following fortnight you will probably do all four. The question is which of them is damaged by being done first.

Escalating before you understand the cause produces an escalation you cannot answer questions about, and it spends credibility you may need later for something larger. Raising a change request before you know whether the project's own float absorbs the slippage commits everyone to a position that may turn out to be unnecessary. Updating the schedule with a date the supplier has not confirmed puts a number into the project's reporting that you will have to withdraw.

A useful reframe is to stop asking which option is best and ask instead which one you would regret doing first. Actions differ in how reversible they are and in what they cost if the underlying facts turn out to be different from the report you received. First actions should generally be cheap, reversible and information-generating. Later actions can be expensive and committing, because by then you know enough to commit.

What a first action has to establish

Three things usually need to be true before any substantial response makes sense, and a well-chosen first action secures at least one of them.

The first is fact. What has happened, as distinct from what has been described to you. Reported problems arrive pre-interpreted by whoever reported them, and the interpretation is often the part that turns out to be wrong.

The second is authority. Some decisions are not yours. A change to an agreed baseline, a commercial concession, a decision to accept a defect, a decision to stop work: each of these has an owner defined somewhere in the project's governance. Taking a decision that belongs to a change authority or a sponsor is not decisiveness, and it will still need unpicking afterwards.

The third is the agreement already in place. Contracts, plans, change procedures, team working agreements, escalation thresholds. A surprising number of scenarios contain their own answer in something the project agreed months earlier, and the candidate who reaches for a general principle misses the specific arrangement that already governs the situation.

Underneath those three sits a classification question that decides the route: is this a risk, an issue, a change, a conflict, or a governance decision? Those four routes lead to different first actions, and misclassifying the situation reliably produces a plausible answer that goes to the wrong place.

Section 3.1 of The Standard for Project Management describes a project management mindset, and the principles that follow it are offered as guides for judgement rather than as a sequence of steps to be executed in order. That framing is worth holding onto here. There is no official first action waiting to be memorised. There is a set of questions that reliably identifies one in a given situation.

PMP preparation sometimes compresses this into rules of thumb: never go straight to the sponsor, always talk to the team first, never make a unilateral decision. Those are preparation conventions rather than positions PMI has published, and they are decent generalisations that fail in exactly the situations where the answer matters most.

A pumping station that went live before handover

A water utility is replacing control equipment across a series of pumping stations. Delivery is predictive, with staged commissioning and a signed handover to operations at each site. The project manager arrives at the third station for a planned commissioning visit and finds the new panel already running in service. It has been running for about a fortnight. The acceptance tests are not complete and the handover certificate has not been signed. The shift technician explains that the old panel failed, the new one was installed and available, and the site team switched across.

Four responses are available to her. Instruct the site to revert to the previous arrangement. Raise a change request to bring handover forward. Escalate to the sponsor. Log an issue and inform the operations manager.

What she does first is none of them. She establishes, at the panel, with the technician and the responsible engineer, whether the equipment running in service creates a live safety or regulatory exposure. That is not a consultative courtesy. It is the only way to know whether the panel is operating on tested logic or on a temporary configuration, and whether the site has been running outside the terms of its safety case. Everything downstream changes on that answer.

If there is no live exposure, this is a governance and record problem rather than an emergency. She logs it, confirms the position with the operations manager, completes the outstanding tests and brings the handover forward through the agreed process. If there is exposure, the priority inverts. Isolating or reverting, and notifying the duty engineer, becomes the correct first act, and the paperwork follows.

Notice what her first action did. It cost almost nothing, it committed her to no position, and it served every route she might subsequently take. That is what a good first action looks like.

When waiting is the wrong answer

Analysis before action is a sound default, not a rule. Where there is live harm, a safety exposure, a regulatory breach, an ethical concern or an active security incident, the correct first action is the one that stops the exposure. In those situations, choosing to gather more information is not caution. It is delay, and on a real project it can be negligence.

Escalation works the same way. Going to the sponsor first is correct where the matter genuinely exceeds your authority, where a defined threshold has been breached, or where the decision was never yours to make. The habit of treating escalation as a last resort serves candidates well most of the time and misleads them in precisely the cases where governance exists to be used.

The development approach changes the route more than it changes the reasoning. Having established the facts, a predictive project takes the item into its configured change process. An adaptive team is more likely to bring it into the next planning or prioritisation conversation, where reordering the work is a normal act rather than an exception. On a hybrid project the first question after the facts is which part of the project the item belongs to, because the two halves have different rules. Candidates who reason well and then apply the wrong route lose the mark for the second half of the answer. If you want to practise that judgement in a structured, instructor-led setting, PMP® Exam Preparation works through it across the full delivery cycle rather than one topic at a time.

For a PMP candidate, the exam-relevant point is that the current examination content outline builds part of the exam around detailed case and scenario material, with a series of questions drawn from one situation, and it is explicit that candidates are expected to apply project management concepts and their own experience to on-the-job situations. That is a test of sequencing under realistic conditions, which is a different skill from recognising a definition.

On a live project, nobody hands you four options. What this habit gives you is a way of arriving at a problem with a question rather than a conclusion, which is usually the difference between a project manager who is trusted with difficult situations and one who is told about them late.

Andre Malowney

Interested in going further?

Choosing a first action well is a habit that has to be built across many different situations, because the cues that identify it change with the domain, the development approach and the governance in place. PMP® Exam Preparation works through that sequencing judgement in realistic scenarios, including the cases where the usual defaults are the wrong call.

The PMBOK® Guide Eighth Edition sets out the mindset and principles behind these decisions in more depth, including how they interact across the performance domains.

Ad · Amazon affiliate link.