The Feature Request That Arrives Without a Change Request

Do not implement, and do not refuse. Both are failures of the process.

1. Log it. Open a change request in the change log with the requester, date, description, and the requester's stated justification. A request that exists only in an inbox cannot be managed.
2. Acknowledge in writing. Confirm to the VP that the request is received and is being assessed - this buys credibility without conceding scope.
3. Run an impact analysis now, not in nine days. Scope, schedule, cost, risk, quality, and resources. In this case the headline finding is unavoidable: four weeks of build against five weeks to go-live, on the same codebase being stabilised, means either the date moves or scope comes out.
4. Notify the sponsor. The sponsor is the COO, not the VP of Sales. The sponsor needs to know before the VP escalates, and needs the impact analysis, not the raw request.
5. Ask the CCB chair whether an out-of-cycle review can be convened. Nine days is not acceptable if the answer might be "do it."

The key judgement: the VP's claim of budget authority is a claim about funding, not about scope authority. The project charter and the change control section of the project management plan define who can approve a change to the baseline. Until those documents say the VP is a CCB approver, her approval is an input, not a decision.

If the charter gives the sponsor baseline-change authority, the sponsor has made a legitimate decision - but a legitimate decision still has to be a documented decision.

• Convert the verbal instruction into a formal decision in the change log: approved by (sponsor), date, and the impact that was presented.
• Present the impact before recording the approval. The sponsor said "just do it" without seeing that four weeks of work lands inside a five-week runway. Show the three real options: move go-live, de-scope something of comparable size, or accept a compressed test window with the associated defect risk. A sponsor who still says "do it" after seeing this has genuinely accepted the trade-off; one who has not seen it is being allowed to make an uninformed call.
• Update the baselines. Scope baseline, schedule baseline, and cost baseline all change. A change that is invisible in the baselines will reappear as an unexplained variance in month three.
• Protect the process, not the paperwork. The failure mode here is not a missed form; it is a change absorbed silently into the team's workload, discovered at go-live.

Also notify marketing that the announced date is at risk, or confirm it is now protected by cutting scope. Someone outside the project has already made a public commitment.

Approval settles whether the work happens; it does not settle how the rest of the project survives it.

Assess:

• Schedule: the four weeks cannot simply be appended. Something in the existing build must move, be deferred, or be done in parallel. Name it explicitly.
• Test window: compressing QA on the same codebase being stabilised is the highest-risk element. State the defect-escape risk in terms of a business consequence (loan applications failing), not a percentage.
• Dependencies: interfaces, training, data migration, and any regulatory or audit checks tied to the portal.
• Quality and technical debt: what gets built quickly now and reworked after launch, and who pays for that.

Communicate:

• A revised schedule forecast to the sponsor and marketing, with the announcement date flagged.
• A de-scoping recommendation with the project manager's own opinion - sponsors make better decisions when given a recommendation and a consequence.
• An updated change log, risk register, and baselines, plus a planned review point at which the new feature's progress is checked.

The judgement being tested: a good project manager does not treat "approved" as "absorbed." An approved change that is not re-planned is just an overrun waiting to be blamed on the project manager.