How do I write a scoping document?

So you finally have your great online idea. It could be an app, a web page, a development strategy and so on. Whatever it is, it seems to crystal clear in your head, and your team’s head.
Or is it?

Scoping is so important. It removes assumptions, the killer of any project, by providing a way of having key details aligned in your own, your team and the development team’s mind. Tying together these commercial and technical aspects is critical in setting expectations as well as keeping timelines and budgets in check.

Regardless of the document’s length or title items, it should effectively present the project in an organised and detailed fashion for the project team. The best kind of scoping documents are helpful in ironing out kinks which help to make your idea even better in the first place.

On a conflicting note, once established they provide the team with wriggle room to optimise details which may offer more efficient solutions. The scoping document ends up being a living organism. It evolves as new data or requirements are revealed.

Setting the scene

Before you even begin putting together the scoping document ask yourself the following questions:

1. What’s the project goal? A one liner which sets out your purpose. For example “A user friendly mobile app which tells users what’s going on in their area.” This gives us a brief summary which gives us the what, how and where, including design credentials that are required.
2. What’s the scope of the project? Different to the scoping document, this is a brief list of items required in the project. For a web page or app it could be a list of menu items, with sub menus included. It provides a guideline to how deep and wide the project is looking.
3. What are the project’s requirements? Think of the live version of your online project. Where do you want people to use it (i.e types of devices and platforms)? Does it require a separate mobile version? How should it look? Does the finished project need to align to certain business guidelines? Is ongoing tracking and reporting required? And so on. These kinds of questions create more clarity in your own mind about how big this project can be.
4. Who is responsible for what? Front end, back end all have their own requirements that need to link up. Make sure on your own team and your development team has all these bases covered. Putting a list together before things get messy will help clear things in your head of where responsibility will be aligned and who does what.

Putting together the scoping document

Once the above questions are answered it is easier to put the scoping document together for your development team. The best scoping documents include the following elements.

Brief/Elevator Pitch: What is it that the app does? Explain in top level what the app needs to do and how it works. Use your project goal here and elaborate.

Use Cases: This is probably the most important aspect of a scoping document. Provide as many scenarios of how the app works and its rules of engagement in each and every configuration of how you envision the app. Use diagrams and pictures based on the scope elements that were outlined in 2 and 3 above. These cases should account for how the online project is used and where, restrictions and exceptions, online and offline access. Include differences if any exist between web and mobile.
Get creative to allow other people to understand the vision and operation of elements that are in your mind.

App architecture: Using 2 above provide an initial map of the project’s basic configuration.

Design and assets: Include any design requirements and inclusions that already exist as listed in 3 above. Specify whether there is a pre-existing logo and design guidelines and where to find them. Or alternatively, outline what is missing and what needs to be done.

API: Using 3 above, is there existing internal tech that needs to be included. Is there tech that you know about that you want included?

Measurement and analytics: Include the types of reporting and tracking required. If your business is aligned to particular targets include those here. This is guided by 3 above and will help dev teams to provide the best options for measurement if none are already selected.

Deadlines and budgets: Provide realistic allocations for your project. You can’t ask for the world on a shoestring budget in 3 days. Give guidelines around what you’re looking to spend in terms of resources so your development team can accurately assess what’s doable, useful and can be parked for the next update.

Post scope

Once you provide such a document to a development team they should sit down with you and ask a lot of questions. Elements may be need to be cleared up, but this should be a pretty well rounded scoping document that gives you and them the bare bones to set up a scope of work.

They should also be able to spot any gaps, shortcuts or issues, so make sure you talk to your team and understand their approach on the scope you’ve provided. With all this in hand they should be able to provide you with a good estimate of time and cost.

Sources:

Phuse, Herron M, October 16, 2013, How to Write a Scope Document for a Web Project

Six Revisions, St Pierre D, July 8 2013, Improve Your Web Design Projects with a Good Project Scope

Swarm, Jacek, June 19 2015, Example Mobile Spec Sheet / Scope of Work

Waracle, Romilly D, April 2 2013, How to write top-notch mobile app development proposal

Taking the next step

If you’d like an initial chat to better understand how your app can be a reality, get in touch with us via our contact form.

Image credit: by rawpixel on Unsplash