Scope + Approval

Delivering exceptional outcomes on time and on budget requires a formal process for approving work at major milestones, and agreement on what will and will not make it into the final product. By agreeing on how to handle unexpected changes up front, we can avoid uncertainty and maintain momentum through the project.

Project Scope

The scope of a project is the combined set of functionality and deliverables that we agree to produce for a project. A project’s scope may include – for example – any or all of the following:

  • Number and complexity of pages to be included
  • Number of unique page templates that will be designed
  • Specific functionality requested, such as social sharing, forms, filtering or search
  • Unique animations or interactive details
  • Number of iterations or revisions allowed during design

The precise scope of your project will typically be defined in the project proposal. Throughout the project, if adjustments to the project scope are agreed upon, we’ll clearly outline the new scope adjustments in writing and create a budget addendum if neccessary.

Scope Creep

It’s common and natural to make discoveries throughout a process that challenge our expectations and require minor adjustments to the direction of the project. That's how the best outcomes are created. However, certain types of adjustments to scope – such as requests for additional functionality or changes to previously-approved content or organization – can add up over time and threaten to derail the timeline or budget for the project. This incremental balooning of project scope over time is called scope creep and its one of the biggest threats to project budgets and timelines.

We’ll do our best throughout the project to help keep scoop creep to a minimum, and appreciate your effort in helping us do so. If you request a change to scope that isn't clearly defined in the project proposal and will require considerable additional time or effort, we may suggest an addendum to the budget to address your request.

Approvals

Each milestone in an interactive project directly influences and ladders up to the step following it. Any time we’re asked to revisit previous phases of the project – revisting information architecture during art direction for example – it means redoing existing work and inevitably affects the project’s timeline and budget.

To ensure that this type of rework rarely occurs, we’ll ask for formal, written approval at the end of each of the following phases of the project:

  • Sitemap
  • Wireframes
  • Art Direction
  • Design

Approval means that everyone within your organization whose opinion is important to the success of the project has reviewed and approves of the deliverable. After receiving approval we’re free to move on to the next stage of the process, and any updates to previously-approved deliverables will be considered out of scope.

Consolidating Feedback

Although we ask you to designate person as the Project Owner for your organization, it’s not uncommon for a project to involve many people within your organization whose input is important. With so many voices involved, it’s important that the feedback we receive from your organization is consolidated before being presented to us, and that any conflicting opinions have been resolved internally before sharing with our team. This helps ensure that the feedback we hear and address accurately reflects the goals of your organization.

Bugs vs. Features

In the later stages of an interactive product, when we’re reviewing a working website or application and not static designs, feedback can usually be broken down into two types: features or bugs.

Bugs occur when the product is clearly not working the way that we originally agreed it would. Bugs will inevitably occur and be resolved many times throughout the creation of a digital product, and we will address bugs at any time, including after the initial launch of the site.

Feature feedback means that a piece of functionality is working the way that we originally agreed that it would, but now that we’re seeing it in action it seems that there are pieces of functionality missing or incomplete. These kind of changes to functionality will need to be reviewed on an individual basis. Sometimes that adjustments will be small enough that we can work them into the existing scope, and sometimes they may require adjustments to the timeline or budget.