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.
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:
- explaining the project to new team members
- rework caused by mismatches between design, UX and the technical approach
- rework caused when reasonable but incompatible approaches are used by different team members
- revisiting old discussions because the outcomes and decisions were not properly captured and understood
- lengthy ‘catch-ups’.
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:
An executive summary of the project. It’s aim is to provide context for the rest of the scoping document. This includes:
- a brief introduction about who the project is for and what they do
- the background that led to this project and the business case for the work
- relevant previous work
- the expected business outcomes
- any key deadlines/dates and the reasons behind them.
I try to keep this to a single page.
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.
- KPIs and objectives (or a link to a separate document)
- user profiles, usually a link to a set of personas
- content structure, usually a link to a sitemap for a website and/or workflow diagrams for a app
- a diagram showing the tools used and their relationships (often the digital platform)
- details of the technical platform(s) / tools and why they’ve been selected
- an explanation of how the project has been broken down into deliverables
- any other information that’s helpful to know before presenting the specific deliverables
Approach chapters are around two-three pages long.
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.
The clarifications chapter captures decisions that don’t result in specific deliverables. These include:
- Non-functional requirements, such as browser support and responsibility for backups. (This is something other agile approaches such as user stories can struggle with)
- Requirements addressed by other means, such as manual processes, existing systems or as part of other deliverables
- Requirements placed out of scope
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:
- Limiting work in progress (which accelerates delivery, provides agility and lowers costs)
- Links to supporting project management tools and documents, such as the project Kanban board and budget tracker (details below)
- Reconfirming invoicing schedules
- A high-level project plan showing the expected sequence of events over time. This is not a detailed Gantt chart of all the deliverables; rather a visualisation of any significant dependencies and likely duration.
This is usually about 3 pages long, including the plan.
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.
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.
In an agile world, delivery often means adding, removing and changing work items as we progress.
- Visualised workflow. It’s easy for anyone to see and understand the current status of the project.
- Limited work in progress. By only working on a few items at a time, the majority of deliverables are either ready to start or done. This makes it far easier to adjust the plans with minimal impact. It also ensure any issues that come up are addressed immediately, and not left until the end of the project.
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).