Important: The information in this article is over 12 months old, and may be out of date or no longer relevant.
But hey, you're here anyway, so give it a read see if it still applies to you.
I like to plan. I like lists. And while writing scoping documentation for a web dev project is not my favourite task (I much prefer the coding side of things), through years of experience, I also know the immense value and critical importance of a detailed, thorough and documented scope.
Immense value. Critical importance. Thorough. Have you understood just how vital the scope is? Even a simple job needs a scope – after all, this is how we know what is considered in and out of scope.
At the initial stage of a project – be that a new project, or an extension to an existing one – that discussion with the client is very high level, and very much in business-based terms. What are the core features, ideas and points that this needs to cover. And this is an ideal starting point. But this could be written as a few bullet points – what about the intricacies of each point? Have we captured enough data? Are we following the expected workflow?
I then spend time evolving these ideas and planning how it will actually be built in terms of the code base. This is where the scope balloons in to such fine detail – dotting the i’s and crossing the t’s. Side note, grammatically those apostrophes look wrong, but apparently are correct. Anyway, scoping. Detail. Fine detail.
I’ve had scoping documents grow into the hundreds-of-pages range – and while that is a lot of work, a lot of words and so much to take in – it also meant that when the build for the project came, the critical decisions had been considered and finalised – workflows, validation, data types, interface elements, business rules.
As other developers work on the project too, the scope document can explain and detail exactly what needs to happen from a business perspective. While they do include programmer-specific details like data dictionaries, wireframes and object models, they are really aimed at the customer too. The scope document is a tool that talks about the business, their requirements, and how the project will work – through all aspects – to achieve these goals and using language that both developers and the client can understand. It is a crucial document for all involved to help explain and illustrate the scale, inclusions and functionality that is being quoted.
Over the years, I’ve been involved in projects that didn’t have this level of detail put in to the scoping stage. And it led to a troublesome, stressful, sporadic and inconsistent build – especially when the project’s goal posts kept being moved and shifted because ideas weren’t planned. In my eyes as a developer, the difference on working on a project with a light (or absent) scope vs a heavily scoped project is huge. And I’ve worked with clients who want the world for as little cost as possible. But I stand by the quality of the work I produce – and to build reliable, scalable and quality projects requires planning and dedication from both the developer side, as well as the customer’s commitment to the project.
So now, I insist.
Every dev job needs a scope.
Me as the developer, as well as the customer, need to know what we’re going to produce – what’s included, what functionality will be delivered, what business and validation rules are being considered (and the logic they require) not to mention, how long it will take and what will it cost. This reduces the chance for scope creep, for shifting goal posts and for uncertainties during the build process, and helps deliver projects on time, on budget and to the calibre of coding that I demand of my team.
And this makes me a much happier and productive developer. And we all like a happy and productive Marty.
