Over the last 18 months we’ve been investigating a number of web-based products which are complementary to the services we offer. One of these is in development and will, touch wood, be launched later in the year.

Whether or not the products turn into profitable businesses is for later but, if nothing else, the process has been massively educational; we advise clients on buying technology but you get a whole new perspective when you’re doing the buying yourself. We thought we should share some of what we’ve learnt.  This post is about some of the things we’ve learned about specs. In his post  Mark tells us what we should have done. Needless to say, we didn’t exactly do that.

A little less conversation…You can spend forever talking about concepts but it’s not until you write things down that you can actually get proper clarity and definition. We started talking to potential developers before we’d done any sort of spec. It would have been better to have had the spec prepared earlier. That would have provided focus to all those conversations and we would have got more value from them.

The essence of the thing…What Mark says (in his post) about this is spot on – you need to convey the essence succinctly and clearly. This is not something that comes naturally to a group of lawyers – we’re used to the detail but summarising concepts was not something that came easily.  In the development stage the aim must be to build something that showcases the essential elements of the concept. The detail is important but it can come later.

Less of the how… A spec must state what you want built and why. Unless you come from a technical background you’re not the best person to decide how it’s actually built. Understanding the ‘how’ is important but our spec contained details about the database and how documents should be organised – neither of which actually helped to describe the essence. The result? We spent too much time and energy on these items.

Go back to it…It’s too easy to concentrate on where  you are in the build process. At every stage you should check back against the spec so that decisions are aligned to your initial aims. You are then more likely to end up with a product that captures the essence of what you wanted to achieve.

If you want to make a change, ensure it’s an informed decision…Even a detailed, tight spec isn’t going to be perfect. We followed an agile process, so the result was always going to be different from what was envisaged in the initial spec. If you do change it during the build then make it a definite and informed decision rather than allow the build to diverge from the original spec by default through inconsistent decision-making.