Evaluate a requested change before authorizing work

ReasonSpan™. Project Management Professional. Change impact and authorization.

A predictive customer-portal project has an approved scope and a release date six weeks away. The sponsor requests an audit-export feature. In this project, the change control board must approve changes to the scope baseline. The sponsor asks the team to begin tomorrow. A request from the sponsor is important, but it is not the approval required by this project's governance.

The project manager clarifies the feature's acceptance criteria and expected business value with the sponsor. The team estimates eight thousand dollars for development, four thousand for security review, and three thousand for testing. These work-package estimates total fifteen thousand dollars. A proposed two-thousand-dollar risk response brings the requested one-time funding to seventeen thousand dollars. That response is planned work, not an unexplained contingency percentage. The assessment also identifies two working days of release delay and twelve hundred dollars a month in ongoing support. Keep one-time project funding separate from recurring operating cost.

The project manager has verified these impacts with the team. The review package compares adding the feature now, deferring it to a later release, and exchanging lower-value scope through the same approval process. It states assumptions, uncertainty, acceptance criteria, expected benefit, and the consequences of each option. The sponsor's urgency is a reason to arrange timely review. It is not a reason to omit security testing or promise a date the team has not supported.

The impact assessment is complete, and the change is not yet approved. What should the project manager do next? Start development because the sponsor requested it? Submit the documented options and recommendation to the change control board? Use available reserve without seeking approval for the scope change? Or reject the request solely because the baseline already exists?

Submit the documented assessment through the agreed change process. This lets the authorized decision makers evaluate value, cost, schedule, quality, and risk together. Starting work would bypass the stated authority. Available funds do not authorize new scope. Automatically rejecting the request would skip a legitimate business decision. The correct action depends on the project's stated governance, not a rule that every project uses a change control board.

If the change is approved, update the affected baselines, funding authorization, plans, and change record, then communicate the decision before directing the approved work. If it is deferred or rejected, record and communicate that outcome. After implementation, verify the agreed acceptance criteria and review whether the intended benefit is being achieved. The project manager connects evidence, authority, and value. A cost estimate informs that decision; it does not make the decision by itself.

Support the product owner in clarifying value and acceptance criteria and ordering the backlog with the team's estimates, dependencies and capacity in view. Do not impose the predictive case's change control board on every backlog decision, and do not insert the item into an active iteration unilaterally. If it affects an external commitment or exceeds delegated scope, budget or compliance authority, use the applicable governance and escalation path. The method transfers as informed prioritization and respect for explicit decision rights.