What adding people changes
Extra people raise output. On a fixed-date project that has scored above 30, output is not the thing that has gone wrong. Adding a developer or working the weekend gets more of the current plan built, and the current plan is where the risk is sitting. Nobody you add has the standing to change what the project sold, or to settle what the customer will accept as finished. So the extra output lands against decisions that were already made, and the new hands bring their own coordination cost on top.
The clearest version of this shows up at acceptance. Work that got finished faster still fails on the day if the thing it delivers is not the thing the customer was waiting for, and no amount of pace closes that particular gap. The faster you build, the sooner you commit to the wrong target.
The two decisions
Two decisions on a fixed-date project need the customer's authority. What ships on the date, and what the customer will accept as complete. The team has other moves it can make on its own, resequencing the work or dropping a dependency, and those are re-plans too. These two are the ones you cannot take from inside the delivery team, and they are the two a score above 30 is usually pointing at. Testing whether either can still move is the two-lever test: can you change the scope you ship, or the done the customer has agreed to.
Adding people changes neither. That is the whole reason pace is the wrong tool here. It is aimed at output when the problem is a decision nobody in the room is in a position to take.
Running the review
Put the right people in a room for half an hour. You need someone who can commit the customer commercially, and the person running delivery. Open two documents: the scope the customer signed, and the most recent thing the customer actually saw about what "done" looks like. Then ask two questions.
Can we ship less and have the customer accept it? If someone in the room can make that call, set the choice out plainly: the current commitment, the smallest version that still delivers the outcome that was agreed, and the date and cost attached to each. Sometimes that is a formal change request. Sometimes it is phased acceptance with no change in price. If the honest answer is that the full scope was sold and changing it means escalating to a committee that meets next month, the decision is blocked, and you sort that authority out before you touch the schedule.
Is there a written "done" the customer has agreed to? Not the ticket system, not the internal spec. The version the customer is holding about what they get on the day. Where the only record is internal and the customer is picturing something else, that mismatch does not show on a green status report, and it surfaces at acceptance. Document what was actually agreed, put it back in front of the customer, and if they are expecting more than that, treat the difference as a scope change with named concessions and a sign-off. Do not quietly move the acceptance line to protect the date. That is how the surprise grows.
Take a fixed-date install that is green on every internal measure: cabling in, screens up, software on the rack. The customer is expecting the meeting rooms to greet visitors by name, and nobody wrote that into the acceptance document, because to the team it was always a phase-two idea. The owner of that gap is whoever can commit the customer. The deadline to catch it is the next milestone meeting. The cost of missing it is that it lands at handover, where there is no decision left to make. The review exists to catch exactly this while a decision is still available.
When adding people is the right call
A clean answer to both questions is not a shortage of hands. If scope and acceptance are already settled, the customer has agreed what "done" means and it matches what the team is building, then you have ruled out the two problems pace cannot fix. If either still needs to change, that change is the re-plan, and it comes before any new hands. Only once both are settled is it worth asking whether capacity is the real constraint, and you answer that with a work breakdown that shows the remaining tasks are understood, splittable across people, and not waiting on something else. Where that holds, add the people.
The score is filled in from inside the project, and the questions about what the customer will accept are the ones people inside answer too generously, because everything they can see says green. That is why a high total is worth an outside read even when the team is sure of it.
When the decision is blocked from inside
Some projects reach a point where neither decision can be taken internally. Nobody has the standing to renegotiate scope, and the conversation that would realign the customer keeps getting deferred. This is the risk-register band moving toward rescue.
What tips it is the cost of leaving the decision blocked. Every week it stays blocked, the team keeps building against a scope the customer has not re-agreed, so the repair gets larger while the delivery clock keeps running. At some point that combined bill is larger than paying someone whose only job is to land it. Reaching this point is not a reflection on the team; it is what happens when the same people are asked to deliver and repair at once.
An outside reviewer earns their place by doing the part the team cannot do from inside: reconstruct the scope that was actually agreed, set it against what is being built and what the customer now expects, name the decision that is blocked and who owns it, and prepare the choice the customer has to make. Above 30, that is the work, and it is the part more people cannot do for you.