A Question of Scope

Any project, regardless of its nature revolves around one key element – scope. That is, what is done as part of the project, and what is left out, or delayed for later stage of work. Scope underpins the interaction between project cost, timescale and budget.

Being so fundamental to a project, scope is often the hardest thing to define, and this is especially true in digital projects. Why? Because it is so fluid and people’s understanding of a project and what’s needed to make it a success will usually evolve along the way. Scope is also rarely defined by a client – for sure, requirements are set in a brief, but its usually left to us to set the scope and share this with someone who doesn’t talk our language every day. Almost inevitably, differences will appear.

This week I raised the question of scope on a current project. We’d stressed the importance of having great content on the site, and as a result, were receiving more and more documents with carefully researched copy, image references and links to related pages. This content is ultimately the raison d’etre for the site, and without doubt it will enhance the value and experience the site offers its visitors. But it was clearly felt that adding all this content was included within the scope.

To a certain extent, it was. We specialise in building websites with content management systems, but a CMS is just a place to store and manage content. You can’t match the page templates to a CMS without content, or properly test the site ahead of its launch. But equally, a CMS doesn’t limit the amount of content that can be added – so where does the axe fall and who’s responsibility is it to ‘own’ a given task? If I commission a carpenter to build me a bespoke wardrobe, I wouldn’t expect him to fill it with my clothes when its finished – only to meet the requirements I gave in the brief. Yet the expectation with aspects of a website is usually the exact opposite.

We could say we’ll add in your core content (in fact, our contract does state this clearly). But what exactly is this? A collection of blog posts could be considered ‘core’, especially if they’re being imported from an existing site. The trouble is, as a web project starts, does anyone understand the scope? We’ve all started things that turned out to be much bigger tasks than we anticipated, even if it was just building the dining table bought from Ikea, or tidying out the garage.

The main problem with scope on a web project is that it can leave the end result as a bit of an unknown. Buyers of any service naturally what to know what they’re going to get for their money, and fixing the budget but not the scope, means the end result can’t easily be predicted. Even if the end result can be clearly defined, the route to get there might not.

It could be possible to fix the budget and the scope, but I don’t believe this is at all feasible – or helpful. Almost every project I’ve ever worked on has revealed something new along the way – be it a better technical approach to take, or new product or service that needs factoring in to the end result. Digital projects frequently explore different avenues, consider different audiences and objectives, and the final direction is rarely known until part way through the project. Fixing the scope but not the budget isn’t likely to be a popular choice either.

The best analogy to project scope I can think of is being blindfolded and asked to jump into a swimming pool. We’ve no knowledge of what lies in that pool; it could be deep, shallow; hot or cold. Ok, strictly speaking, we’re not exactly blindfolded, but rarely can we see the bottom before we jump in. With the growth of software as a service (SaaS) apps, more often than not a website needs to ‘talk’ to a third party system. This often means having to do things for the first time, and we’ve no idea of the gotchas that could pop up along the way. Yet, we’re web developers – we work with these things all the time, so how hard can it be?

This obviously presents a problem, especially when it comes to estimating work. This has knock on effects on pricing, resource planning and ultimately profit. Scope is important, but it too, has a cost. Writing out a detailed scope document takes time, and in my experience, still doesn’t necessarily solve the problem. Things will still change along the way. Formal change requests could reduce scope creep, but such changes can be quite discreet, and they still need to be based on an accurate scope document to being with.

Of course a lot of managing scope depends on the financial value and impact of the project. A £100k website project will give much more opportunity for defining scope over a £5k project. Its all relative, but for many typical ‘mid-range’ projects we do, there’s little room to define scope to the n-th degree, but it still needs managing.

The only realistic approach has to be to leave both scope and budget open. Clearly something needs to be defined before the project starts, but more and more, fixed price projects just don’t work and can quickly place unreasonable demands on the project team.

I like the idea of the minimal viable product, or MVP. Setting a baseline for what will be delivered, so there is a reasonable expectation of what will be produced and at what price. Anything else becomes a bonus, if budget or time allows.

Regardless of how you approach scope, the key to achieving success comes down to setting a realistic expectation, followed by continued communication. Whether that’s providing a time sheet, weekly budget update or keeping a Trello board to maintain the focus on the must-haves and the nice-to-haves, conversations and visual indicators like this can help to visualise what most buyers don’t (and often can’t) see. Unfortunately, as an industry, we’re usually too busy thinking about how our clients could/should communicate, we fail to communicate effectively ourselves – definitely a focus of ours to work harder at and improve on.