A Fixed-Price Portal and the 'It's Already in Scope' Request

Not in scope on the evidence given. Three tests:

1. Size against the baseline. The baseline is 180 points and the request is estimated at 34 - nearly 19% of the whole project. Work of that magnitude is not a clarification of an existing line item.
2. Specificity of the SOW. 'Marketing content' and 'member communications' describe a category, not a real-time promotions engine or a second language. A vague category name does not transfer 34 points of new build to a fixed-price vendor.
3. Contract mechanism. The contract has a written change-control clause and priced change orders. Absorbing the work outside that clause sets a precedent and erodes protection for every later request.

Process to apply: log the request in the change-control system, perform an impact analysis (effort, cost, schedule, risk, quality), and take it to the change board and the client's authorised representative for a written decision. Even if the answer is 'do it,' it must be a priced, signed change order that moves the baseline and the contract value.

If the client genuinely believes it is in scope, resolve that through the contract's ambiguity or dispute step - not through silent absorption by the delivery team.

Capacity check first.

• Remaining work at end of sprint 6: 112 points, including 10 of carryover.
• Sprints remaining: 6. At the demonstrated 18 points/sprint the team can deliver ~108 points - already about 4 points short of the outstanding work.
• Sprints 9–10 lose two senior developers, so a realistic velocity for those sprints is closer to 12–14. Blended velocity over the remaining six sprints is more like 16.

Adding 34 points takes remaining work to 146 points. At ~16 points/sprint that is about 9 sprints - roughly 3 sprints (6 weeks) late, before allowing for further vacation effects.

Options to table:

1. Change order with a 3-sprint extension - priced at the team's run rate plus the 34 points of build; protects quality and the date commitment elsewhere.
2. Change order with a scope swap - trade ~34 points of lower-value baseline features for the banner and Spanish support, keeping the date. Requires the client to rank its backlog in writing.
3. Phased delivery - banner in the current release, Spanish support in a separately funded follow-on release.
4. Absorb - not recommended: the team has no spare capacity, so the realistic outcome is overtime, defects, and a late date anyway.

Recommend option 2 or 3 and let the client choose. The PM's job is to make the trade-off explicit and priced, not to absorb it.

Hold the line, but make yes easy.

• Put the facts in writing. A short note: 34 points, ~6 weeks of schedule at current velocity, 10 points of carryover already, two senior developers on leave in sprints 9–10. Attach the number to the decision, not the relationship.
• Do not let work start without a disposition. Unauthorised build is scope creep; once started, the vendor loses the leverage to price it and the date commitment moves silently.
• Escalate internally, not at the client. The account manager is making a commercial promise delivery cannot keep - that is a line-management issue. Frame it as: 'We can absorb this only if you also accept the date slip or the scope swap. Which do you authorise?'
• Offer a face-saving route: a paid discovery spike, a fixed-price change order at modest margin, or the phased release, so the client gets a visible win without 34 unfunded points.
• Document the risk. Record the instruction and your objection in the risk register and decision log. If the account manager overrides in writing, that becomes an accepted risk with a named owner and a stated consequence.
• Check the contract's escalation clause. Many fixed-price contracts define a dispute path that protects both parties and cools the commercial pressure.

The PM protects the baseline and team capacity; the account manager protects the relationship. Resolve the conflict above both roles, with data.