Background image

Scoping documents: the agile statement of work

Tall Projects’ scoping documents are concise yet comprehensive, delivery is transparent and organised, communication is clear and in a language that I understand.

In short Ed has become a trusted partner in my businesses. He understands me and I rely upon him. Chris Hansen, Owner and Founder, Buy Any Part

All projects need a plan. As the saying goes, if you fail to plan you plan to fail.

Traditional fields such as civil engineering can use detailed up-front plans. This works because once the planning is done there is little variability in the execution.

Digital projects are different. The technology is constantly changing. New information comes to light every day. There are many ways to deliver each constituent part. Traditional waterfall methods with a single prescriptive specification phase are inefficient at best and often result in significant problems due to their inability to adapt.

Agile methods are now widely understood to be a better option for delivering digital projects. Unfortunately not all agile projects are well structured. Poor planning will always cause problems.

It doesn’t help that the agile manifesto values ‘working software over comprehensive documentation’, which some have misinterpreted as ‘documentation has no value’.

The value of a documented plan

The value of a documented plan lies in the cost savings it delivers. These cost savings are more than just financial.

Cost savings from an agile plan
A good plan means financial, opportunity and social cost savings. The value of the social costs savings is the most important.

Direct cost savings

The direct financial cost savings from a good plan are the most obvious.

Without a shared understanding projects cost more. This is because extra time is needed for:

Further money may also be wasted paying for unnecessary products and services.

Opportunity cost savings

A clear understanding of the goals and approach enable better projects to be delivered faster. This allows everyone to move on the next project sooner.

An agile plan lets us quickly understand the impacts and practicalities of pivoting as new opportunities emerge.

When projects can’t adapt and take longer to complete, other opportunities may be missed.

Social cost savings

Projects are complex. People need structure to manage complex things.

Without a shared plan projects quickly get out of control. And when things get out of control this brings considerable emotional costs.

People will react in different ways. Some may hold back, afraid of what their actions may bring. Others may try and take control, but success is impossible without going back and creating the plan that should have been there in the first place.

This results in tense conversations, strained relationships, stress, anxiety and uncertainty.

A well structured plan with an agreed approach for how any challenges will be addressed keeps the uncertainty and stress under control.

To me this is by far the most important point.

What is a scoping document?

The scoping document is the master plan I use when delivering projects. It’s what others may call a statement of work or agile specification.

It pulls together all the information that’s littered in emails, comment threads and long-forgotten conversations into a single coherent reference source. I think of it as the ‘table of contents’ for the project.

I fully embraced scoping documents back in 2010. Each project brings new learnings (continuous improvement) but the format described below has been stable for about four years now. It has been proven on large, complex projects such as the University of Oxford website.

I judge a scoping document to be a success if someone new to the team can sit down with their favourite beverage and get a full understanding of the project in under 30 mins.

Scoping documents are typically around 25-30 pages long. While they’re predominantly text documents I use diagrams whenever possible to enhance understanding.

Enough preamble. Here’s the format. I use the following chapters:

Table of contents
Scoping documents act as the table of contents for the whole project.

Introduction

An executive summary of the project. It’s aim is to provide context for the rest of the scoping document. This includes:

I try to keep this to a single page.

Approach

The approach chapter summarises what will be delivered along with supporting background information.

It is not a list of requirements. It is a high-level description of the planned solution that satisfies the requirements.

This includes:

Approach chapters are around two-three pages long.

Deliverables

This chapter lists the items of work to be delivered. It uses concepts from both product breakdown structure and work breakdown structure tools.

Each item includes a title and a brief description of the function(s) and the outcomes it will provide. Dependencies on other deliverables are also noted. I do not go into excessive detail here; it’s not a technical specification.

The aim is to capture the information we have available at the time of scoping and note any expected approaches or exclusions.

All the features/deliverables are considered together so that we know they’re able to provide the required end result.

As a guide, each item should need between 2-5 days (15-40 hours) of effort to complete in its entirety. This includes related calls, emails, demos, system setups and project management as well as design and development work. Smaller deliverables are grouped together and larger ones broken down into smaller components.

Breaking the project down into these separate elements dramatically simplifies the costing and delivery project management. And by limiting work-in-progress (WIP) it’s easy to add/remove/reorder deliverables as the project progresses. Truly agile.

The deliverables chapter forms the bulk of the scoping document. It is usually about 8-12 pages long.

Clarifications

The clarifications chapter captures decisions that don’t result in specific deliverables. These include:

The value of this chapter cannot be understated. It ensures we have a documented response to all requirements and ideas related to the project. Capturing them all in a single location is the key to shared understandings for a smooth and efficient delivery.

This chapter is typically 5-10 pages long.

Getting the job done

This confirms how we’ll manage the project delivery so there are no misunderstandings.

It covers items including:

This is usually about 3 pages long, including the plan.

Change log

Scoping documents are created in parallel with other discovery tasks. This means they often end up having a few versions. The change log notes the date of each issue and a brief summary of changes from the previous version.

This makes it quick and easy for everyone to know what’s changed when reading a new version.

Supporting tools and processes

The scoping document doesn’t work in isolation. It consolidates information from various sources, and uses it all to determine the deliverables. This plan is then the foundation for delivery.

Scoping document (agile statement of work) inputs and outputs
The scoping document uses all available information, research and opinion. This is used to plan the approach and deliverables.

Inputs

User-centred design (i.e. meeting the real needs of our users) underpins all successful projects.

This often involves user research tasks such as stakeholder consultations, interviews and surveys. The findings of this research – documented as personas – guide the solution planned through the scoping document process.

The importance of the full team in the scoping process cannot be understated.

While I create the scoping document as the project manager, this is done in regular consultation with designers, developers and any other partners involved in the project.

Involving these key people in the scoping stage means they’re able to help shape and validate the plans. This results in a more engaged team and one that’s better equipped to deliver the project.

I maintain a master checklist of items I consider for every digital project to ensure nothing is missed out. This currently includes over 90 items and as you’d expect, is constantly being improved.

Delivery processes

In an agile world, delivery often means adding, removing and changing work items as we progress.

I prefer the Kanban method to manage the delivery. Deliverables are tracked on a shared Trello board. The method includes a number of general practices. I find two provide the greatest impact:

Knowledge transfer on how systems work and why is critical to long term success. I use process diagrams, short documents and videos to explain how things work. These are then added to the corresponding Trello card, providing a rich set of lasting documentation.

If the project is costed on a per-deliverable basis, I use a shared budget tracking spreadsheet. This transparently shows the cost for each work item, and enables me to keep a clear picture of the overall budget. Should anything drift, this is quickly visible allowing for appropriate actions to be taken before it’s too late.

All these processes are of course described in the scoping document. This provides the shared understanding from the outset making everything so much more achievable. (And making process policies explicit is one of the other general practices of the Kanban method).

Comments