This Annex forms part of the Web Development Master Services Agreement and describes the scope, responsibilities and limitations relating to the Change Control Process.

1. What counts as a change?

  1. A “Change” is anything that alters:
    • the agreed scope, features or requirements;
    • designs that have already been signed off;
    • assumptions or constraints identified during discovery; or
    • delivery timescales or dependencies in a material way.
  2. Examples include:
    • adding new features or user journeys not in the original scope;
    • significant redesigns or rebranding mid-project;
    • changes to core integrations or platforms; and
    • new regulatory or compliance requirements introduced after work has started.

2. Requesting a Change

  1. Either you or we may raise a potential Change.
  2. We will normally:
    • capture the request in writing; and
    • ask clarifying questions where needed.

3. Impact assessment

  1. For each proposed Change, we may assess:
    • impact on scope and complexity;
    • impact on timelines and milestones;
    • impact on cost; and
    • technical or risk implications.
  2. We will share a summary of this assessment with you before proceeding.

4. Approval

  1. If you wish to go ahead with the Change, we will:
    • agree any adjustments to price and timescales; and
    • record the Change in an updated Order, Statement of Work or change log.
  2. We are not obliged to implement a Change until it has been agreed in this way.

5. Emergency or minor changes

  1. Very small changes or urgent fixes may sometimes be handled informally (for example under a retainer) where the impact is clearly low and both parties agree.
  2. Where an emergency change is required to address a serious production issue, we may implement it promptly and document the change afterwards.