Client Onboarding Documents

Scoping & Quality Assurance

Handover & Client Testing

Flexible logic and scope extensions

Bugs & issues

Our Prioritisation Logic

Explore

Scoping & Quality Assurance

How we'll define what to build and agree it has been built.

Welcome

Hi. You have probably found a link to this page in an email from us or from our agile development onboarding document. In this doc we have outlined some important contextual info before defining and outlining our Scoping & QA protocol.

Click here to read about our agile development services for complex projects.

⁠

Read Now

⁠

Our Mission

Before diving into the ‘how’, please make sure you understand the ‘why’ of what we do. This is our company mission:

To build transformative business systems, harnessing the best of people and technology, that form scaleable and resilient platforms upon which our clients thrive.

Important Context

Your BusinessOS

There isn’t a business owner alive that does not want a highly automated business that runs with maximum efficiency, makes informed and ‘data-driven’ decisions based on highly accurate data and that doesn’t have the financial or emotional turmoil of people-problems.

There remain few areas of business that one cannot improve with technology. Each and every system that you implement within your business can (should) be linked to the others. Ultimately, the goal is a single, comprehensively integrated Business Operating System - this is your BusinessOS.

When we work with you on one project, we (and we suspect you too) will treat it as the beginning of the construction of your BusinessOS.

BusinessOS & Scope Creep

The natural tendency is therefore to maximise the extent to which singular technology projects can propel the whole business towards this end state of technological nirvana.

There are five ways this leads to scope-creep in a given project as it is underway:

New integration opportunities emerge

New business logic is created or revealed

Business processes change

Apps are replaced or updated

Project stakeholder opinions change

We try and solve for this pressure by reducing large projects into smaller ones and large ‘all-in-one’ systems into modules and phases. We then deliver this according to an agile methodology - whose primary aim is the ‘continuous delivery of value’. I.e. Finishes in a month , not two years!

Scope Specification

In this context we define a scope as:

A sufficiently detailed explanation of all of the human and computerised inputs, processes and outputs your system must be able to achieve at the end of the project that it currently does not and the full extent of the boundaries of this system.

We have two scope specifications. A simple scope for Simple projects and a detailed scope for Complex ones. Here we differentiate between Simple and Complex projects and then outline our required specification.

We have three scope specifications: Bugs, Simple Projects, Complex Projects

Here we differentiate between Bugs, Simple and Complex projects and then outline our required specification.

Bug

We define a bug as any issue that meets the following criteria:

Where a systems output deviates from the developer’s intentions

The developers intended system design did not fulfil a common or reasonable user expectation.

Genuine mistake by one of our team members within your applications and systems.

What is not a bug

Upstream or downstream third-party app failures (e.g. the CRM fails to fire a webhook reliably) due to internal error or configuration changes (accidental or deliberate) by a third-party which break a dependency that your system relied on.

An output that does not comply with unexpressed client requirements (i.e. we weren’t told it should do X)

A system that operates as expected, but did not include certain business logic (decisions, variables, organisational data lookups)

Changes to scope, even if the client didn’t know what they wanted until they saw something developed.

All third-party permissions and connectivity issues

Any issue caused by data errors or data-mismatch between multiple apps across your system - Garbage In Garbage Out

Simple Project Definition

A New workflow request or improvement that meets following criteria:

A to B workflow

One way flow of data

Instinctively feels like under one day’s work for one developer

Does not feature custom API integration

Does not feature flagged app

Client has all access and permissions unlocked and in 1Password

Note regarding financial logic

If the workflow request contains financial logic - this can still be treated as a simple project definition if the following are true:

The exact logic has been documented in writing and ratified by the client’s accountant.

Every variable is known and any calculations written out

One example of ‘a perfect job’ is available, showing input/output pairings for each potential scenario.

If not, the project will be treated as complex and go through a full scoping exercise OR be undertaken solely on a best effort basis, since accurate estimation is not feasible.

Complex Project Definition

Anything that is not a simple project or bug

Scope Specification

Has clear explanation of the issue and definition of done persona walkthroughs (Loom / Annotated Screens) of all:

Errors which meet bug criteria

and

Inputs

Processes / Logic / Data Transformations

Outputs

Scope Specification

Has definition of done persona walkthroughs (Loom / Annotated Screens) of all:

Inputs

Processes / Logic / Data Transformations

Outputs

Scope Specification

Has defined requirements and acceptance criteria

Has known Data Model

Has System Schematic demonstrating workflows and business logic

Has definition of done persona walkthroughs (Loom / Annotated Screens of all:

Inputs

Processes / Logic

Outputs

Has defined modules and deliverables

Has identified likely risks and mitigations

There are no rows in this table

⁠

Scoping Protocol

Here is how we approach project scoping:

Simple Project Scoping Protocol

Clients remain responsible for providing a detailed brief covering the full scope. All development work will be based on explicitly stated logic and no assumptions will be made on our part.

Complex Projects Scoping Protocol

If clients have a scope to the required specification, our development team can provide an estimate (not fixed quote) for delivery.

R&D: For complex projects we typically also recommend the pairing of estimation with a one-off small R&D task to help us explore and understand any complexities and potential risks. This small investment can highlight any unknowns to improve the estimate.

If clients do not have a scope for their project to the defined specification, they may engage our consulting team to take them through our discovery process and construct their scope to the required standard.

Due to initial unknowns and the evolving nature of business logic, our consulting services are offered on an adhoc basis unless the client instructs us to conduct the discovery process within their first sprint itself - depending on their confidence level in the project feasibility within their resource constraints.

The output of the discovery process is a scope to the defined standard.

The discovery process consists of an appropriate blend of:

Systems exploration (going under the bonnet)

Stakeholder identification and interviews - recorded

Iterative development of the above defined artefacts

Gathering of client feedback from various stakeholders

Final output and presentation of the finalised scope including potential risks and mitigation strategies.

QA & Sign Off Protocol

Our approach to quality assurance is simple and is aimed to maximise the early and continuous delivery of working software and business value to our clients, here is our protocol:

We will limit development activity to only that which has been scoped to avoid mission creep and maximise efficiency. All incoming change requests will be logged for future development unless the client or a project manager requests a ‘pause and rescope’ due to emerging risk.

An item under client-QA will be deemed delivered when signed off by the client’s defined project decision makers - identified near start of the project.

Once a project deliverable is developed and tested by our team internally, responsibility will pass to the client’s defined project decision makers to test the deliverable and sign it off as delivered.

The standard to which the client’s defined project decision makers will sign off a deliverable is defined in the scoping stage by attaching business requirements with linked acceptance criteria. These criteria give all parties a shared understanding of what ‘done’ looks like in plain language.

Clarifications

If anything is not clear in this doc, please reach out to us for clarification.

Want to print your doc?
This is not the way.

Try clicking the ⋯ next to your doc name or using a keyboard shortcut (

CtrlP

) instead.