Project Specifications

Once more unto the breach, dear friends, once more.

Many years ago, when dirt was still clean, powdered wigs were the fashion, people were polite and I was working in IT, the question of project specification arose regularly. Meetings were held. Notes were taken. Lines were drawn and armies mustered.

The developers would raid the company stationery cupboard, gathering notebooks, cardboard boxes and staplers with which to build and arm the Fortress of Impenetrable Logic. They would barricade themselves behind the reasonable, while an assortment of clients and managers bombarded them with hundreds of ridiculous requests, diminishing delivery timelines and out-of-date doughnuts.

Carnage ensued, as minor skirmishes over the definition of words escalated into full-scale trench warfare. Both sides would dig in, refusing to budge from their positions, guarding their time and ideas stubbornly. Eventually, an armistice would be signed, usually after the demise of at least one individual’s reputation, general unhappiness in the clientèle and the waste of a lot of time and effort – not to mention money and mouldy snacks.

Like most of the idiocies of modern business, that reaction to a simple process was unnecessarily confrontational.

Writing specs is not the easiest of tasks – mostly because it’s hard to be sufficiently precise – but it is an essential skill for any freelancer. If you don’t get the spec right, you can end up working endlessly, running in circles and not being paid for it. Worse, you might deliver something the client doesn’t want.

What questions do you need to ask yourself when planning your project? Here’s a few to be going on with:

1. What’s the point?

Exactly what is the end product of the job? This has to be precise: for example, a document of a certain number of words on a particular subject (rather than “a document”). A book of at least 30 pages, help files for the customer information entry process in a specific application, three different web site home page designs, twelve illustrations in black and white: these are all reasonable. The intricate details will follow.

- The job description must be clear and have a definite end.

2. If that’s where I’m going, how do I get there?

Once you know what the job is, you can look at what that entails. Is research needed? Perhaps you can do each of the three new page designs in turn, presenting them to the client as they are done. Do all twelve illustrations need to be sent in a batch? The client might want to read the book as it appears, rather than at the end.

- Break the job into steps – or ”milestones”, if you want the management-speak term.

3. What do I need to see on the way?

Once you have a list of requirements from the client, it is absolutely essential to make sure they are achievable. It’s all very fine and good to say that you will produce “a new site design”, for example, but what if the client thinks that includes an up-to-date list of all the telephone numbers in Timbuktu? Unless you can come up with a way to siphon those numbers out of a database somewhere, it’s not going to be possible.

Plot your critical path – the things that are absolutely essential for the client to be satisfied with the job – and make sure you can supply what they want.

4. What would it be nice to visit?

Since you’re headed in a particular direction, wouldn’t it be nice to see some of the sights on the way? I mean, if you’re creating twelve illustrations, having one of them in colour would be really cool. Pretty, blue skies and white, fluffy clouds. Yes, that’d be great. Only if you have the time, of course. Unfortunately, these optional elements can lead to “scope creep”, especially if the client thinks they’re essential (and you think they aren’t).

- Make a list of the “nice to have” elements of the project.

5. Is there public transport?

Many projects are short and simple, but some are great big things that go on for ages. In those cases, it may be worth looking for ways to get to the end quicker: is there a short-cut, a virtual bus or train you can use to cut down the man-hours? Perhaps you have something you’ve worked on before that can be revamped? Any way to reduce the time needed is an advantage since projects always overrun their deadlines!

- Consider ways to reduce the amount of time or work needed to provide the same end.

6. Egad! Look at all those words!

“Language is a virus,” as Laurie Anderson would say. It’s frightening how easy it is to misunderstand a common word: I have very vivid memories of an hour-long discussion in a global conference call over the definition of “should” – does that mean “must” or “might”? When you’ve put together your project spec, it’s worth re-reading it (or asking someone else to) so that any vague words are removed. Be definite. Be harsh. Be precise.

- Re-read your spec and make sure the language is clear, blunt and accurate.

Those more familiar with management will have spotted similarities between the suggestions here and the “SMART” process of defining metrics. It’s deliberate. Writing a job or project spec is just like deciding how to measure progress: everything must be Specific, Measurable, Accurate, Reliable and Timely. If you have those five points covered when you’re setting your waypoints, the rest is just a case of fuelling up and putting your foot on the accelerator.

Do you have a specific method of defining your project deliverables? I’d love to hear it.