By Glen Johnson.
There are many common misconceptions when it comes to selecting an online partner to establish your web presence. There are also many common mistakes being made by individuals in everyday organisations at various levels.
The purpose of this mock-interview is to attempt to extract key aspects of long-term solutions and how one may identify a provider capable of consistently delivering a solution geared for longevity.
Q: I've decided that I want to upgrade my website as it has been sitting static for the last few years and it does nothing for me. How do I know what my website should do, and how do I plan for something that will last?
Answer: Well you've probably had people asking you for certain things to be online; regularly used bits of information like contact details, product information, prices, employment opportunities etc. These consistently form the basis of a sitemap. But the really interesting stuff is when you think about what parts of an organisation or business could actually be serviced online. For some clients that's as simple as having online contact form-email generators or a searchable support database. For others it will be something highly functional like interacting with a core business database to maintain customer information or process online transactions. A good method of defining what you want your website to do is to first make sure that you have compiled a list of all information that people regularly require from you, and then secondly decide on what aspects of your business can be integrated with your website or substituted by the website.
Q: How do I communicate my requirements to others?
Answer: You're talking about a brief document or a request for tender (RFT). Basically you need to detail what your idea of the sitemap will be, what functional components you'd like, whether there are any similar developments you can use as a reference, describe your branding requirements, detail the stakeholders and if possible the target audience, try and define a way of measuring the outcome of the project, set a budget, and if you've got an IT division you may want to note any specific requirements that they come up with. It is advisable to present such a document in person to your chosen range of tenderers as it will give you an opportunity to verbally expand on the ideas and requirements noted in your paperwork. A good solutions provider would consider it mandatory that they meet with you prior to responding to your document for similar reasons.
The document need not be any more than 3 or 4 pages.
When we read a brief we like to see an introduction that details what the organisation is about and why they're looking at a new development. This allows us to get a feel for how to come up with measurable outcomes. It also allows us to decide on appropriate styles for branding and interface design.
Next your brief should detail the actual content structure of the development. This is typically done in a sitemap which need not be anything more than a list of section names (navigation items) and the lists of associated pages that fall within them. At this point it is prudent to include notes about any specific content requirements (such as forms) or inclusion of functional items (such as search systems or interfaces to other systems). They can be detailed in full in the next section.
Functional requirements are typically something that you cannot document effectively yourself at this stage unless you utilise the services of a consultant to help you prepare technical specifications for each module you require. If you have to write requirements for your functional aspects yourself consider writing a few paragraphs about what a functional module should do for you or your customers, and then where possible provide details of the sort of technology the website may have to connect to i.e. a database or a customer management application, or a bank in the case of e-commerce. If you are unable to provide much information surrounding your functional requirements make sure you state the details of someone in your organisation that can provide further information on request.
It helps minimise risk in the quotation if you can tie down a few examples of relevant material or sites that you want to use as benchmarks. This will allow you to revert back to original notes later on if you find that things are not in line with your original expectation.
Following this it is beneficial for all parties if you establish fairly clearly who the stakeholders are i.e. who's your boss, and who's the one that ultimately has to approve the quote. This is particularly relevant when a board makes the final decision as your tenderer may have to provide the quotation in a different format or structure to address key individuals.
You may wish to seek references from the tenderer to prove their capabilities.
More often than not people don't provide a budget for their projects. Given the variations possible in every online solution it is possible to really overshoot the mark by layering in all sorts of niceties and extras in the design stage. If the tenderer gets the wrong impression of your financial reserves they may automatically assume that you want all the bells and whistles and quote at a figure much higher than you can afford. This is not beneficial to you if that particular tenderer was in fact the most qualified for the job but overestimated your budget.
Ongoing costs form a substantial component of maintaining your website. If you have limited ongoing funds you should also state what your ideal budget would be. You should always clearly request an indication of ongoing costs stated in dollars per annum. Depending on the technologies and products utilised you may have substantial ongoing costs and you need to be prepared for them. Ask your tenderer to provide a simple cost-benefits analysis in their tender response.
Please download the PDF (link below) to read the full article.
(.pdf 156Kb)
