To recap we’ve now explored how to prep both teams for the scoping project and also covered the main structure of how to scope a website. Before we move on to using a SoW during the project we just wanted to pump the brakes slightly.
As we’ve mentioned before, we can’t just focus on the development side of life so running with that piece of advice we’ve split this article into design and development. We’re going to be looking at some of the larger items that you will want to cover in your scope and also some common pitfalls to look out for!
Everyone tends to be laser focussed on scoping the development of the project. This is rational, development can become a horror story and everyone has heard of a project which barely gets off the ground because of technical issues. Perhaps it is because the majority of people lack technical knowledge, so it feels a bit like the unknown. Seems fair.
However, the effect is a tendency to breeze over what would appear to be more ‘obvious’ parts of the project. Hopefully this becomes obvious below as we discuss design and content.
This is often an area that tends to be glossed over somewhat, as both parties are keen to cover the real meaty parts of the project. From experience though, this is another area where there is a risk of different expectations. The concept stage (along with most of the points in the article) is about defining the process. Key items to cover include:
- How many wireframes will be created and for which page templates?
- How many concepts will be created and for which page templates?
- Define how fleshed out the concepts will be.
- How will the concept be delivered?
- How many amendment stages will be included and what will those amendments look like?
- Set the ground rules for amendments. For example, if there are three rounds of amendments, the client may not be allowed to make major structural changes/complete revamps in the third stage.
Pro tip: both sides need to be aware of the potential risks for the other party. For an agency, the risk is a client that fails to be decisive or wants to make endless changes. For a client, what if they don’t like any of the concepts? The latter is somewhat mitigated by a thorough research and preparation process (see part one).
Ahh content. It comes in all shapes and sizes which, of course, means varying expectations. It isn’t just about the quantity or type of content either, we also need to define the labour involved with making this content visible. For example, you might agree on who is producing the content but fail to specify who is responsible for uploading it to the site.
We know what you’re thinking – content is the easy part. That might be true for some projects but from experience, when it goes wrong it’s often the content that is to blame! It’s viewed as an afterthought, perhaps because everyone is so concerned with the design and development of the project. Our advice would be to view it as a major part of the project and to scope it fully.
Content Creation & Type
By now you’re probably quite au fait with the types of questions that need to be asked when scoping. In essence we are looking to set the guidelines on ‘who is doing what’ in relation to the content. If the agency is producing the content, they need to specify how much content is going to be produced, when, and almost more importantly, what type of content is going to be produced? A full page infographic will take substantially longer than sourcing a stock image.
Much like development functionality we need to be specific about the process of producing content. Trust us, on a previous project it took more man hours to create and upload the content than to design and develop the entire website, all because we had not been specific with the type of content! We won’t be making that mistake again…
It’s reasonable that a client would expect a website to be delivered with content uploaded, regardless of who had created the content. It’s also reasonable that an agency would be hesitant to spend a considerable amount of time uploading content if it was not part of the original agreement (it’s also not a job that requires agency level skillsets).
Neither side is wrong, and both are working towards having a live site. As with most items within a scope, the responsibility lies with the agency to define the process. They should find a cost effective way to upload content and include this in the quote. Failing this, the content upload process should be clearly stated.
The above also applies to content migration when redesigning a website.
Producing content will almost always take you longer than you think. Factor this in, not only for the agency’s quote but also to both party’s expectations of a go live date.
Timeframes could arguably be part of the contract, rather than the scope of work. We would argue that they are almost one and the same. The scope is outlining everything that needs to occur in order for the project to be successful, of which timeframes are critical.
Both the agency and the client should be held to specific timeframes relating to the creation, delivery and feedback on content.
- If the agency is creating textual content, especially for new businesses, are they also responsible for developing the messaging?
- If the agency is sourcing imagery:
- Will there need to be any editing of the images?
- Does the client have a clear brief of the type of imagery?
- How many proof stages does the client have? What happens if the client does not like the imagery?
- Is there a sign off process prior to uploading?
- If the agency is uploading content:
- Are there rules for the format in which the client delivers imagery?
- Who is responsible for making sure the imagery is web ready?
- Will text based content be delivered/signed off in the correct format or does the agency need to format it on each page?
It is very important that the process is defined in terms of how content will be created, delivered and uploaded. Furthermore, approach it from a worst case scenario. What happens if content is produced but needs amending? What if it is rejected? There needs to be clear proof stages and an agreement if these proof stages are exceeded.
Designing the Site
The process oriented items of design are reasonably easy to scope. You want to make sure that you include the amount of page templates that will be designed and indeed if multiple pages will be mocked up using the same template.
You’ll also want to define the amount of proof stages that are included in the price as well as the price of any future proof stages. These are all standard parts of scoping the project that you will hopefully be confident with (after having me bang on about them for 3 articles).
So where can stuff go wrong?
Believe it or not, agencies and clients can have very different views on how designs will be received and how feedback will be given. Some agencies will present designs in person, others will send over PDFs, whilst others may have clickable prototypes. Some clients want to be able to feedback using hotspots on the designs whereas others insist on printing out designs, scribbling on them and scanning/sending them back.
The client and the agency need to agree on how designs will be delivered to the client, how feedback will be received and in what timeframe. Once again, this seems like it is tertiary to the main bulk of the project but in reality can be one of the areas in which the most time is lost/largest delays occur.
This is a difficult one to put into words and just as difficult to put into a scope/enforce. Note that if the agency in particular does not attempt to clarify the intended design style, it makes it impossible for them to keep a client within the guidelines they had in their heads!
The long and the short of it is that certain design styles require significantly longer than others. It links in to agreeing on content/imagery. Creating bespoke icons or infographics for every single page can add scary multiples to the time required from the agency to complete the designs.
It should also protect the client. They may believe that for a certain price, that a certain level of design is to be delivered. Portfolios are incredibly misleading as well – you’re unlikely to know the price paid for each website in the agency’s portfolio.
So how do you go about including design style in the SoW?
The good news is that the functionality included in the scope will serve as the wider parameters of the design, especially if you go through this page by page.
But that’s not enough. We would advise that the agency presents examples of design styles for the website as a whole, along with major pieces of functionality. Furthermore, that they ask (and understand) what the client’s expectations are. Do they require a snazzy design filled with interactions? How will various elements be layered?
If you can have these conversations early on and get them in writing, it can help both parties avoid butting heads during the design process.
As the title of this article suggests, we’re not here to point out the obvious. We’re here to identify common pitfalls, the ones that you might not think of or would not expect to be an issue. Of course the scope is going to cover the major pieces of functionality, these are your marquee items and will attract the most attention. But what about the underlying ones? You know, the ones that rear their head when you’re 98% complete, only to show that you are 60% complete (perhaps exaggerated for effect)?
Seems like a very silly one. You have to factor in time for testing and fixing. This is mainly for the agencies but if you are a project manager and ask your developer how long something will take, bear in mind that it’s unlikely they have factored in testing.
We’ve already covered adding buffer so let’s move on.
Flipping over to the client’s side, they should receive QA documentation from the agency. How would they know that it has been completed otherwise – apart from going through every element on the site and essentially completing the QA on behalf of the agency? By the way, the responsibility of user acceptance testing and QA sit squarely on the agency.
Clarify the difference between a bug and a change.
This one is fiendishly difficult to define if the spec is loose. The nuts and bolts of the scope (in terms of development functionality) is the basis on which you will be able to decide on whether it is a bug or a change. In actual fact, this is one of the main reasons why you want to scope out all of the functionality.
Who is in charge of the domain and hosting?
This might have already been covered off when setting up the development site. However, if it hasn’t, you’ll want to. Not only can it further delay the website being pushed live but depending on the size of the site (and the traffic it attracts), the hosting can be an unforeseen ongoing cost.
I know, if you’re reading this from an agency (and probably a lot of you that are client side), you may be furrowing your brow somewhat. Who wouldn’t take into account hosting expenses? Where did they think the website would sit?
There are actually a number of reasons why this might be unforeseen, over and above pure lack of knowledge. For example, the client may have previously not paid a lot of attention to the website and its hosting. As such, whilst the website clearly had a host it was a relatively cheap one. The new website and marketing campaigns may require a much higher spec server which had not been taken into account when budgeting for the project.
Again, something that seems pretty straight forward. Agree on the amount of time that the warranty lasts for and voila. Again, for a lot of projects this will be sufficient. Just like with a lot of projects an overarching scope will work. The issue is that when it goes wrong, it tends to be amplified and costs a lot of time, resources and money. Let’s look at a couple of examples:
What happens if a certain function needs to be constantly fixed, and the warranty period runs out? I think it is reasonable that the agency will need to ensure that this particular piece of functionality is working correctly, even if the warranty has run out. What needs to be agreed is the time period after it has been fixed (for good). Just because there has been a history of issues does not mean that the client is entitled to lifetime maintenance, much like the agency isn’t entitled to walk away just because the warranty period has come to an end.
Finally, what happens if the client’s internal tech team has been tampering with the website and subsequently broken something? Is the agency expected to investigate and then notify the client of their error for free? Seems like that could create a lot of wasted time for the agency.
Ongoing Maintenance, Support and Crisis Management
Both the warranty period and any ongoing maintenance need water tight SLAs. We’re not talking about response times or a scale for prioritisation of issues. We’re talking about responsibility splits. This is especially important if there are separate teams such as the client’s internal technical team, the agency’s development team and perhaps a third party host. How do all three parties react to crises? Who decides whose responsibility it is to make the fix?
We’ve covered off a lot of points and a lot of potential questions to ask. It may seem a little daunting but you’ll find that a number of them will be naturally discussed if you have a structured process to the scoping. In part four we’ll finish with how to execute the scope and manage expectations throughout the project.