Welcome to part 2 of our website scoping series. We previously looked at some of the benefits of scoping a website project and how to prepare teams for what could quite easily be considered a project before the project!
Now that we understand why we are scoping the website I suppose we better get on with it. In this article we will be tackling the main bulk of ‘how to scope a website project’. We’ll be covering the following main points:
- Non-development items
- Preparing information
- Project objectives
- Sitemaps, user flows & sales funnels
- Specific functionality
- Must-haves and nice-to-haves
- Reiterating the process
- Finalising the agreement
It isn’t all about functionality
The likelihood is that website functionality is going to make up the lion’s share of your scope. It’s just the reality of the situation and for good reason, development is often where a lot of issues start to come out of the woodwork.
A website project isn’t just about functionality though, is it?
There are multiple factors in play here and for you to have a really tight scope of work, they should all be included. We’ll be discussing why the design process should be integral to the scope in the next article but we would also include items such as timeframes for deliverables and feedback, hosting & domain management, post live warrantee and content creation/upload. We need to look at all facets of a project, not just those that take the limelight.
Finally, the scope is there to document what will be completed by the agency, and what will not. It’s very important to define what is not included in the scope. More on this later. Essentially, the scope must include any area where there is a risk of different expectations between the agency and the client.
Prepare examples & inspiration
As we touched upon at the end of part one, it’s good to warm everybody up for the first meeting. There’s nothing worse than when the answer is always “we’ll have to think about that one”. Both parties want to go into the first meeting with a general idea of what they want to achieve, but should also be flexible and welcome new ideas.
A few ways to prepare:
- Illustrate the client’s options by preparing different examples of specific functionality
- Research competitors, what they do well and how they could improve
- Create a questionnaire for the client to complete prior to the meeting. This can be distributed internally in advance.
- Provide the agency with access to any key collateral or analytics, i.e GA, Search Console, Key Messaging, Imagery or Video.
- Identify websites that you particularly like or think could be applicable to your website project.
- If you are unsure over a particular idea, it’s worth checking with the agency prior to the meeting so that it can be researched if necessary.
Send over an example scope so that the client understands the format and what you are doing.
Hopefully you’ve already got some objectives defined for the project. If you don’t, now is the time to get some. If you need some guidance we would advise starting with SMART goals, the SMART standing for specific, measurable, achievable, relevant and time-bound.
As a client, your goals will allow you to give better guidance to the agency. They can also help you define your budget and whether the project is viable.
As an agency, knowing your client’s objectives will provide structure to the project, keeping both parties focussed on what you are looking to achieve.
Sitemaps, User Flows & Sales Funnels
You don’t see artists starting with the minutiae of a painting before sketching out an outline and general structure, do you? Without a sitemap and general user flow, you can find yourself going round in circles, rehashing pieces of functionality over and over again.
Work to define how a user will navigate your site, key items to explore include:
What we mean by this is that it’s likely a significant portion of traffic will start on your homepage. This might be due to your marketing campaigns linking to the homepage or simply branded search. Regardless, your homepage is a critical first step for your users. In an ideal world, which page(s) would be the most logical next step?
Can you map out your marketing campaigns? What will the key messages be within these campaigns? Your sitemap and user flow should support your marketing campaigns, not work against them!
User acquisition / Inbound funnel
First of all, does your sitemap support your SEO strategy. We’re biased but we would always recommend ensuring that your sitemap can support an SEO campaign either immediately or in the future.
Furthermore, we can’t just rely on the homepage as the starting point for all users. For example, product/service specific marketing campaigns may send users directly to inner pages. A comprehensive content marketing campaign may result in large amounts of traffic originating on blog articles.
We live in a multi device world, adding another level of complexity to user flows. How will behaviour differ between someone searching on a desktop and someone using a smartphone? Will their experience need to be different depending on the device and, dare I say it, dependent on the product/service they are viewing?
This is what most people think of when a website scope is mentioned. The process of getting down to the real nuts and bolts of the project. Most people prefer to tackle the really large pieces of functionality (such as a database or member’s area) first. We won’t argue with you here, it’s really a matter of preference so why not get the big ones out of the way whilst you’re feeling fresh?
The key thing to note here is that it is the agency’s responsibility to ask the right questions. They should be more experienced than the client when it comes to scoping a website project. As such, they should know that a brief description ain’t gonna cut it.
“We need a member’s area where people can access member only documents”
We’re going to have to dive a little deeper than that. How are these documents uploaded? Do members get push notifications for new docs? Can some members see documents that others can’t? What about editing member profiles?
These are just a few examples of overarching questions. These should then lead you to explore each piece of functionality within the members area.
Don’t breeze over anything. It’s far better to have too much detail than to not have enough.
Must-haves and nice-to-haves
Once you’ve got a comprehensive list of functionality, it’s time to go through and start labelling them. If you’re happy with a binary system you can use “must-haves” and “want-to-haves”. Alternatively, you might have a traffic light or more complex grading system.
Whatever you side with, this is your opportunity to dust off those objectives, sitemaps and user flows we discussed previously and start comparing. Additional functionality can be expensive so put your CFO hat on and figure out what truly contributes to the objectives and what are might be a spur of the moment techie idea. It doesn’t mean that you can’t include the ideas that don’t directly contribute to the objectives, it just means you are categorising them in case the powers that be don’t agree with the final price.
Reiterate the Process
Probably the most important outcome of a website scope is a clear view on the cost of a project. It allows an agency to break down a website into component parts, assigning a cost to each and providing a total that both parties can agree on.
Don’t forget that not all agency processes are the same. In fact, far from it. Your own design & development process will have an accompanying time and skill requirement which translates to……you guessed it……a specific cost. If one agency offers no proof stages and a junior designer, but another offers 3 proof stages and a senior designer, their costs are likely to be very different.
This is information that needs to be relayed to the client more than once. After all, it is going to affect the price that they pay. Furthermore, scope creep does not just relate to functionality. Feedback stages are part of the agreement so any deviation or extension of these could legitimately be considered scope creep.
Also, timeframes are important. There should be limits set on feedback loops, just like there should be timeframes for the agency deliverables.
I don’t think we need to flog a dead horse here. Make sure that the project process is communicated and included in the scope of work.
Be Realistic with costs
Both parties are trying to achieve a breakdown of time and costs that give clarity to the project. A client wants to make sure that the price is reasonable and justifiable. An agency wants to make sure that the project is not undersold and remains profitable.
There’s not much that a client can do at this stage, it’s all on the agency to tally everything up. Here’s a few things to bear in mind as an agency:
Be realistic, or add buffer, or both.
It always takes longer than you think it will. It’s like painting a house. In theory, it should take x amount of hours, but that’s because you’re only taking into account the painting part (which you’ve probably underestimated anyway). What about all the prep, the touching up, cutting in, extra coats?
Remember that you will be assigning time/costs to component parts of a project. As such, a small miscalculation on every item will add up to a rather large sum as a whole. Before you know it, you could be staring down the barrel of a loss making project, whilst thinking that you’ve scoped it perfectly to be profitable.
Factor in communication
This can be heinously difficult to do precisely, but we would advise that you do the best you can! If you time track comms as a separate line, you’ll be fully aware how much time it involves over the lifespan of a project. If you don’t feel confident factoring in communication, at least factor in time spent for meetings and the personnel involved. You’ll be unpleasantly surprised at the amount of man hours a single meeting can take up. They are of course often essential, but they should still be factored into the costs.
Start with the original price
Even if you’re going to match a price or give a discount, as an agency you should price the project up internally to start with. This way you will have a real consideration of how much this project is going to cost you. We’ve all been there, matching a price because, well, revenue is revenue. Only for the project to drag on, lose momentum and take longer than expected. Suddenly what started out as a deal has become a loss-making project. It’s tough to maintain enthusiasm at this point.
Start with the original price. You will then be anchored to that price and be able to view any discount with a much clearer view of the situation.
Discounts should be shown
To be clear, we’re not advocating the dishing out of discounts. Far from it. However, we also run a small business and understand that sometimes a deal has to be made.
This came up in an Agency Summit discussion last year. If you are going to offer a discount, you should always display the original price on the quote given to the client. From here you can then show the discount and give reasoning. I’ll be honest, we hadn’t done this before and from the amount of agency owners that brought this point up, it was a little embarrassing! There are some very important reasons why you should show the original price:
- It supposedly softens the blow of ‘cheapening the brand’ (although I buy into this less than the other points).
- It highlights the additional value that you are offering the client and allows you to justify the discount.
- It manages expectations for any future deals between the two entities.
The unfortunate fact is that unless you make it explicit that the client is getting a deal on this project, no-one remembers. How could they remember something that they didn’t see? Finally, and on a bit of a side note, don’t expect discounts to win you favours in the future. It’s not like the movies.
Finalising an agreement
We should be getting pretty darn close to an agreement here. The documentation that you now have will give both parties clear insights into the belly of the beast, so to speak. The agency and the client have worked together to isolate and detail every piece of functionality and the associated costs. There are just a few more items that we would highly recommend you including in the scope of work/contract:
What’s not included.
By this stage you’ll have been laser focussed on scoping the functionality and processes that are included within the project. However, you also need to agree on what isn’t included. These items could range from pieces of functionality that have been mentioned in passing, to proof stages, uploading of content, migration or even additional meetings.
As an agency you’ll want to prevent scope creep so these should be documented, but as a client you may want to know what your options are. We would therefore advise that these ‘not included’ items are also priced up so that both parties are clear on the costs should they have to be included at some point during the project.
Time is money, as they say. The scope should also include a realistic project plan. If the documents are there to provide clarity on the project then it makes sense that everyone is also clear on what needs to be delivered at what time. Timeframes focus teams.
Cool. In part three we’re going to backtrack slightly and look at some of the key items to scope for both design and development, hopefully highlighting the importance of including more than just development functionality in the SoW. Then finally in part four we’ll look at how to use the scope during the project!