Define a Scope

The benefits of Scoping

With any website or app development, we always ensure that any project has a full detailed Scope / SOW (Statement of Work) created, reviewed, tweaked and finally signed-off. You will be able to get a better idea of whether your budget matches your scope, so you can narrow deliverables as needed. Sprint cycles and iterations allow for deliverables to be rolled out incrementally. Here we take a look at what a Scoping / SOW document involves and why.

Day one

Your development has just been given the green-light to go-ahead. All systems go. Get the kick-off meetings underway, designers creating assets, developers coding away, then launch it for the world to see right?! 

As much as it is tempting to do that, a Scoping / SOW document needs to be created. Always stemming from the defined goals of your users, this is a document at its simplest form, outlining the following:

What you want the website to do - from a frontend and backend point of view.

From this there will be additions of resources, design, environments, integrations and technologies.

For technical eyes only?

There is a common misconception that a Scoping / SOW document will be purely technical and therefore full of lots of technical jargon. This could not be further from the truth. The Scoping / SOW document will be collaborated on by the project manager, the client, designers, developers to ensure all are on the same page. Whilst it will contain technical information for any development, this will sit alongside other information relating to the development in a clear and concise manner.

Better together

So the Scoping / SOW document has been written, can we launch already? Not quite yet. This needs to be reviewed and signed-off by the entire project team and client - together. We like to sit down together with the client (or on a Google Meet) and go through each section of the scope with a fine tooth comb, chatting about the why of certain features and making tweaks - ideally over a coffee or two and some cracking biscuits. 

Going through changes

Once the scope has been signed-off, this isn’t the end of the document. As we progress through the project, there may be agreed slight tweaks to the document. This is handy for the entire project team:

Designers can see any new screens and assets required

Developers can refer to the technical architecture and any new pages required

Client and Project manager can see the latest brief and therefore discuss any timing and cost implications. 

The project bible

Once your development has launched, the scope should still be seen as an integral part of the project - effectively the Project bible to refer to. 

Taking a day from the project timeline to sit down together and create this document is invaluable. A solid scope that removes unnecessary fluff is time saving in the long term. A well thought-out Scoping / SOW document will ensure all requirements, updates and user goals have been addressed, with no element overlooked and resulting in a successful delivered project.

Contact us today about starting your development project and kickstarting your Scoping / SOW document.