// CHANGE_REQUEST_POLICY

Change Request Policy

This policy protects scope without blocking progress. It keeps changes clear, estimated, approved, and scheduled so delivery stays predictable.

This page is part of our operating system and pairs with the Method page.

How requests are submitted

Send requests through your active project channel (email thread or project workspace). Include objective, affected pages/components, requested timing, and why it matters now.

How we estimate impact

We estimate effort plus ripple effects: dependencies, QA scope, launch risk, and timeline change. Estimates are framed as impact on current commitments, not just task hours.

How we prioritize

Priority is based on business impact, urgency, and disruption to in-flight milestones. High-impact, low-risk changes move first.

When a change becomes new scope

A request is treated as new scope when it introduces net-new pages/features, major architecture shifts, or repeated revisions beyond planned review cycles.

What happens when feedback is late

If approvals or content feedback arrive after the agreed review window, timeline commitments shift by the same delay plus any rescheduling impact. We will always share the updated delivery date before work resumes.

What “approval” means

Approval means explicit written confirmation to proceed with a defined estimate, timeline, and scope boundary. Silence, partial comments, or implied agreement do not count as approval.

// FLOW

Repeatable Change Flow

No contracts to download here—just a fast, readable flow your team can reference at any time.

  1. 01

    Request

    Submit your change in writing with goal, page/feature, urgency, and any deadline constraints.

  2. 02

    Clarify

    We confirm intent, assumptions, and dependencies so there are no hidden expectations.

  3. 03

    Estimate

    We estimate impact on effort, timeline, cost, and delivery risk using current scope and capacity.

  4. 04

    Approve

    You approve the estimate and tradeoffs in writing before any change work starts.

  5. 05

    Schedule

    The approved change is placed into the next available slot based on priority and active commitments.

  6. 06

    Ship

    We implement and release the approved change within the agreed delivery window.

  7. 07

    Verify

    We confirm the change works as expected and close the request or capture follow-up actions.

// CONNECTED_SYSTEM

For delivery cadence and stage definitions, see Our Method. Change requests follow the same decision rhythm so the project stays coherent.

View Method