Building dynamic websites for small businesses presents unique challenges. Andrew Betts explains how to maintain standards through a process-led approach.
If I ran a massive multinational, and wanted a new... asset management tool say - I'd probably draw up an invitation to tender, describe my requirements, and go out to the market for proposals. I'd expect this to take some time, and cost a lot of money, but in the end there would be a clearly defined set of hoops through which the winning bidder would gladly jump in order to ensure that the system was properly delivered.
On the other hand, if I were at the helm of something considerably smaller, say a single independent bakery in Watford, I would probably use Excel to do the same job. It makes sense because it's a tool that's proportionate to the task. There's no point in spending tens of thousands on custom built software when I can buy something that does 80% of what I need for £100.
The problem with websites is that they fly in the face of this established principle, because although they are essentially highly bespoke software applications, every Tom Dick and Harry wants one.
This, obviously, has led to web development agencies springing up who specialise in the SME market, but it's something of a wild west of unregulated inexperience and bad practice. In a quest to cut costs and delivery times, processes that are absolutely vital to the project's success are often overlooked entirely. In the planning stages, a specification of some kind ought to be produced, but often isn't. The actual development itself should follow coding guidelines laid down by the agency for all its developers to follow, but often doesn't. It ought to be documented as it progresses, but again, often isn't. Some people don't even get a user guide. And above all, there should always be a process in place for the testing and review of every part of the system, to bring it as close as possible to the standard of 'off the shelf' software.
The competence and time required to deliver a solution properly comes at a price which won't belong to the lowest bidder. As the director of an SME you might well take the view that if one of your co-directors knows a bloke whose son is quite good with this web stuff, why not let him have a crack at it for pocket money? At the heart of this thought process lies a misunderstanding of the real prerequisites for a decent web application.
Think about it like this. Assume you have a ten year old who is absolutely brilliant at building tree houses, and you have a perfect old sprawling walnut tree in your back garden in which they've impressively crafted a retreat using bits of driftwood and railway sleepers. You wouldn't commission them to build you a four bedroom family home, would you?
Bespoke is for dreamers
One of the biggest problems with web development is the idea that when you commission a piece of software to fit your exact requirements, it should be built for you from the ground up, and that when it's finished you should own it outright.
Even huge software companies that develop things like the new multi-billion pound NHS IT system don't develop things from scratch. They strike deals with other companies that already have products that do part of what's required, and then they sew it all up into a single finished product. The result is that the code is never entirely owned by the customer, but is instead licensed to them in an agreement drawn up when the project begins.
This applies equally to small businesses. You don't need to own the software that you have developed for you. By allowing software producers to reuse modules that they've previously developed, or buy in components from elsewhere, you get the cost benefit of off-the-shelf software along with the customisation benefits of bespoke, and the development time is greatly reduced. Then the only parts of a project that need to be developed from scratch are those that are truly unique to your particular requirements.
Website development process
It's possible that, having looked carefully at the products available, you may not need to do much development work at all, in fact you may simply need to get someone to configure a number of products to work together. However, bringing all these elements together with the various skills and disciplines involved in the creation of a website still needs to be well managed.
We break the process down into stages that describe the complete workflow - sometimes we are responsible for the whole thing, while in other projects we're brought in for specialist advice on just one area. Our basic web development workflow is shown below:
- Requirements gathering
In multinationals this is usually an internal process, but SMEs often lack the capability of internally defining their own requirements, so it's important to acknowledge that this is the responsibility of the developer.
- Proposal
Again an unnecessary step for larger organisations, but where the requirements are essentially defined by the developer, it's important that the SME really understands what they are signing up to. It can be difficult to digest this in a formal functional specification, so we'll often prepare a friendlier proposal to describe in less detail what we feel is required, which allows the customer to make the connection between those requirements and their potential business benefits.
- Specification
All projects involving bespoke development require a specification - a document that describes exactly what the system will do, and therefore defines the scope of the developer's remit.
- Contract
When all parties have agreed the specification, the contract is signed. It sets out the developer's responsibilities, the licence terms of the software, and the provisions for services such as technical support. The signing marks the start date of the project.
- Design
Any interface design that is required is usually done first. The scope of this discipline within Assanka is very narrow, and extends only as far as creating a graphical mock-up of the interface. This allows the designers to concentrate on one discipline rather than having to cross over into rendering as well. The design stage is where issues of usability should be considered.
- Rendering
Often grouped together with design, rendering is actually a very distinct discipline, where the design is applied to the software using whatever mechanism is appropriate to the technology. On the web this is usually XHTML and CSS. It is here that accessibility is considered.
- Development
Doing the actual development work, although often considered the entirety of the project, is only one stage on our workflow. Of course it is, in fact, a workflow in itself, and significant development projects should employ a development methodology to enforce a structure to the development process. This is where we bring in any off the shelf or pre-existing components that we are using in a project.
- Documentation
The post-project documentation should include at the very least user documentation, and a review of inline code documentation to ensure that it meets the developer's standards.
- Testing
This is the one element of a software project that everyone regrets not doing! Less testing means more support requests, and that's something that everyone wants to avoid. Testing comes in many different flavours, but the developer should be able to put an appropriately comprehensive test plan in place.
- Acceptance
Often it's difficult to actually pick a moment in time and say "it's finished". The purpose of acceptance is to put a specific end date on the development phase of the project so that the system can start to be used and the developer can move into a support role.
- Operation
Finally, the developer needs to have plans in place for supporting the system that they've developed. We have a range of four standard support packages that each define service levels for things like backup, technical support, advice and other assistance. The customer must know that the developer has a continuing interest in supporting their system, particularly if the system is critical to the customer's core business.
Before you take on a new website project for your SME, consider the workflow above and make sure you go through all the necessary stages. There are a few telltale signs of a developer that is not following a comprehensive process-led approach:
- No service contract containing response times and support mechanism
- No development contract
- No provision for backup of code and data
- No user documentation (user guides, quick reference cards)
- No functional specification
- No confirmed delivery date
- No penalties for overrunning
- No internal coding standards
- Claim that all code will be original and that you will own the Intellectual Property
The SME may be a relative newcomer as a customer to the bespoke software industry, but this is no reason to drop standards as an excuse to deliver more quickly, and cut development costs. If you pay for a tree house built by a ten year old, that's exactly what you'll get.
With a proven track record in the SME market, a structured development process and a range of our own customisable components, Assanka is the ideal choice for businesses who want to take the internet seriously.