A Fractional COO Scope Change Review: Decide What a Project Can Absorb
Evaluate new project requests against the agreed baseline, expose delivery tradeoffs, and record approval before changing commitments.
A project can appear on schedule while its true commitment changes every week. A customer asks for another deliverable, an internal sponsor adds a reporting requirement, and a manager agrees to a small adjustment without checking dependencies. Individually, the requests look manageable. Together, they change what the team must deliver and when.
A fractional COO can establish a lightweight scope change review that makes those decisions visible. The aim is to evaluate useful changes without hiding their cost in an already approved plan. This guide addresses project commitments and delivery tradeoffs; it does not prescribe contractual terms or replace specialist approval for regulated work.
Establish the baseline people will compare against
Start with an agreed description of the project's purpose, included deliverables, exclusions, acceptance criteria, schedule, and assigned resources. Record the version and approval date. Without that baseline, the team cannot distinguish a new requirement from unfinished work that was always included.
Ask whether the current plan is actually understood by the delivery team and sponsor. A sales proposal, project brief, and working task list may describe different commitments. Resolve material inconsistencies before introducing a new approval form. Otherwise, every discussion becomes an argument about what someone remembers promising.
Atlassian's change control guide describes a process for documenting, assessing, and approving changes to scope, schedule, or resources before implementation. That principle supports the review below. A small business can apply it through a short shared record rather than copying a large organization's committee structure.
Separate clarification, correction, and new work
Classify the request before estimating it. A clarification explains an existing requirement. A correction fixes work that fails an agreed acceptance criterion. A scope change adds, removes, or alters an approved commitment. These categories can require different decisions and commercial handling.
Do not automatically treat every correction as additional customer-funded work. Equally, do not assume a genuinely new requirement is free because it was raised during a review. The relevant owners need to examine the facts and existing agreement. The COO can coordinate that assessment without inventing a legal interpretation.
Capture why the change is being requested now. A new business need, an overlooked dependency, and a preference discovered during delivery are different explanations. The reason helps management evaluate whether to act, defer, or investigate further.
Where classification is uncertain, record the uncertainty and identify who will resolve it. A disputed label should not quietly become an instruction to the delivery team.
Capture one request in one usable record
Use a short request with a unique reference, requester, date, affected deliverable, current baseline, proposed difference, and business reason. Attach supporting material where needed. Avoid long forms that make people return to informal chat approvals.
Describe the proposed result in terms a recipient can verify. “Improve reporting” is too broad. “Add a weekly location-level utilization report using the existing approved data source” identifies something the team can assess, while still leaving technical questions to investigation.
Keep the requested date separate from an approved delivery date. A requester may have an important deadline, but putting it into a tracker does not create capacity. Likewise, an estimate is not permission to begin work. The record should distinguish submitted, under assessment, decided, implemented, and closed states.
Name one person responsible for maintaining the request through the process. That person can coordinate input without owning every technical or commercial decision.
Assess the complete delivery impact
Ask the delivery owner to identify affected tasks, skills, dependencies, acceptance checks, and operational handover. Include work outside the visible deliverable: preparation, review, testing, documentation, training, and coordination can all change the effort required.
Use ranges and assumptions when the estimate is uncertain. A precise number with no supporting analysis is not more useful than a credible range. If a supplier must respond or a data source must be examined, state that dependency and when an updated assessment will be available.
Review effects on other commitments. A change may be small within one project but displace the same specialist from another approved assignment. The professional services capacity guide explains how to keep those shared constraints visible.
Also consider removing work. A proposed addition may be accommodated by dropping a lower-priority deliverable, provided the sponsor understands the tradeoff. Present that as a revised scope, not as evidence that the addition had no cost.
Compare realistic options
A useful assessment gives management alternatives rather than a single urgent request. Options might include retaining the baseline, substituting one deliverable, adding capacity, extending the schedule, or running a limited discovery task before deciding.
| Illustrative option | What changes | Question for the sponsor |
|---|---|---|
| Keep the approved baseline | New request is deferred | Is the original outcome still useful? |
| Substitute a deliverable | One item is added and another removed | Does the revised outcome meet the business need? |
| Extend the schedule | Scope grows with additional delivery time | Can the downstream commitment move? |
| Add qualified capacity | Resources increase with coordination needs | Is suitable capacity actually available? |
These are illustrative options, not a recommendation for every project. Adding people may require onboarding and supervision and should not be assumed to recover time immediately.
For an invented example, imagine a six-week reporting project with one analyst shared across two clients. A request for a new data source requires discovery before anyone can assess the reporting effort. Management could approve only that bounded investigation, keep the original delivery plan, and review the resulting estimate later. That separates learning from a commitment to deliver an unknown scope.
Route the decision to the right authority
Agree which changes the project lead can approve and which need sponsor, finance, customer, or specialist approval. The route should follow the effect of the request, not just the requester's seniority. A seemingly small change can still affect a sensitive dependency or an external commitment.
Set a response expectation and identify a backup approver. Do not interpret silence as approval unless that is explicitly part of an appropriate, agreed process. A request waiting for authority should remain visible so the delivery team knows which plan governs its work.
Where commercial terms need amendment, the authorized commercial owner should handle that process. Internal approval of extra effort does not by itself establish a customer's acceptance of a new fee or deadline. Record the relevant confirmation before updating external commitments.
Approve a specific version and update the plan
The decision should identify the request version, chosen option, approved scope, schedule and resource effects, conditions, and approver. If the proposal changes after approval, reassess the material differences rather than treating the old decision as an open-ended authorization.
Update the working baseline and notify affected owners. A change can be approved correctly yet fail in delivery because only the requester knows about it. Make the active plan easy to identify, while retaining the previous version for the decision history.
Check that task assignments, acceptance criteria, and downstream communications reflect the decision. If a request is rejected or deferred, record the reason and any trigger for reconsideration. That prevents the same proposal from resurfacing as a fresh instruction a week later.
Close the change with evidence
Confirm that the approved change was delivered and accepted through the relevant process. Compare the actual impact with the original assessment and explain meaningful differences. This is a learning opportunity for estimating and coordination, not a reason to rewrite the original record.
Review repeated sources of changes. If many requests arise from the same missing requirement, improve the initial discovery process. If approvals repeatedly stall, examine the authority map. Do not assume every change indicates poor planning; business needs can legitimately evolve.
Read what a fractional COO does, explore fractional COO providers, or find an executive with a recent project and its change history. A concrete engagement should leave a usable baseline, a proportionate decision route, and an internal owner who can maintain it.
Turn perspective into a shortlist.
Explore executive partners by expertise, industry, and business stage.
Explore the directory