When anyone thinks about developing a new Website, or revamping their old site, they understandably come at it from the perspective of a Website user – from the ‘front end’, so to speak. Even if they have administered a Website in the past, they have usually experienced that administration through a ‘back end’ user-interface that was created for them, allowing them to do what they needed to do. So, when it is time to create the brief for their new Website, almost always, the brief tends to be written almost as if written by one of their visitors, offering opinion, advice and feedback.
‘Easy to use’, ‘professional look and feel’ and ‘must have feature X or Y’ are common requests in a Web design brief. Business considerations usually cover aspects like ‘must be search engine friendly for this list of keywords’ and ‘competitor sites A and B have such and such a feature and we want our site to have the same feature but better’.
Often the solution has already been decided upon, perhaps on the suggestion of another developer that the business owner may have already received advice from and quite often a budget has already been set. If a budget has not been set, then the typical request is to build the site with price as a major consideration.
Rarely does a potential client come to us with a platform-independent functional specification, that lays out the exact requirements of how the Website will work, what processes will be needed and specific details of the way the site will be, programmed, managed, integrated with the rest of the business (including the marketing strategy) and how a visitor will actually use the site. The supplied brief is almost always a high level overview of the kind of site it needs to be in terms of quality and style, but the technical details are left to the Web developer to simply make happen when they build it.
This leads to some potentially risky and costly problems:
- It places all the responsibility of many of the strategic business outcomes on an external service provider who may not be experienced in anything more that design and programming
- It ignores the potentially disastrous issues that might arise if the Website project is undertaken on the requested platform that turns out to be unsuitable for the business requirements
- It assumes that a price and scope can be determined before the price and scope can possibly be determined
- It leads to the business owner being provided with totally disparate proposals as each provider bidding for the project tries to second-guess the business requirements and budget in order to secure the contract
- It leads to providers under-quoting in order to get the job or over-quoting to cover themselves for the huge risk of scope creep and cost blow-outs that will inevitably happen as the true scope of the project is realised through the development process.
This does not serve the business owner or the service provider well. Business owners, who are understandably none the wiser when they prepare their brief, expect quotes and proposals for Website development just like they might expect for printing or other production services. Web service providers are caught out either agreeing to take on a project at a price they can’t support or not getting the job at all, because of the under-quoting firms who convince the business owner that they can develop the Website cheaply.
It is difficult for a Web developer to risk losing the lead and throwing cold water on the business owner’s plans by suggesting that perhaps the brief is not enough information to provide a quote, when other firms are providing quotes. It is equally difficult to find a diplomatic way to suggest that perhaps the business owner is ill-informed, or simply doesn’t understand what they might be getting themselves into.
Business owners often believe that they don’t need to know the gory, technical details, as that is the job of the Web developer to take care of and deliver a user-friendly solution. To leave that responsibility in the hands of the developer and expect them to do it well, is the difference between hiring a builder to build your house, or an architect to design it and oversee the building process. When the brief is going straight to builders and implying that they also need to be the architect, without allowing for that process in the cost, or assessing the builder’s capability to do such a thing, the risk of disastrous outcomes is great.
The only way to ensure a Website – particularly a complex one, such as an eCommerce site – will be developed successfully in line with all of the business and technical requirements, is to start with a functional specification. Don’t go straight from an overview brief to a quoting process and straight into development by a successful proposal writer. Take the brief to someone who can develop a full specification that takes into account every aspect of a Website: How it will work, how it will be marketed, how every little detail will function, from form fields to product variations, postage and fulfillment.
Once you are certain that the functional brief addresses and considers all aspects of workflow, ongoing site maintenance, customer experience and any other consideration, then and only then should you take that detailed brief to potential developers to offer solutions and estimate costs. It is the only way to ensure the right technical solution, the right business outcomes and a realistic quote for the work that will be specifically and explicitly stated as being required.
Even if it is impossible to develop a completely detailed functional specification, because maybe some of the details cannot be determined until the project is developed iteratively, still one ought to do one’s utmost to detail as much as possible in order to ensure the best outcomes for the project and that as little as possible is left to chance.
Comments