Why do we define a scope?

What is a scope? We always ensure that any project has a full detailed Scope / SOW (Statement of Work) created, reviewed, tweaked and finally signed-off. Here we take a look at what a scoping / SOW document involves.

Why do we define a scope?

With a scope in place you will be able to get a better idea of whether your budget matches the work involved, so you can narrow deliverables as needed. Sprint cycles and iterations allow for deliverables to be rolled out incrementally. So what is the process?


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 in 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, and 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 clearly and concisely.  


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 on 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.

  • The 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 successfully delivered project.


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