Traditionally, a project follows a series of design and documentation phases, each one a complex beast with reams of documentation to be produced and an endless series of sign-off points between one stage and the next.

The web is full of literature on how to create the perfect project brief, functional specification, technical specification etc. but most of this literature assumes the reader is part of a 30 strong project team working in a large corporate environment. Once upon a time I was project managing just such teams and while the ideas offered by most analysts on the web are fantastic for the teams aforementioned, they're not ideal for small to medium sized design agencies and bespoke software houses.

The inescapable fact is that most examples and methodologies floating around out there are so complex and management intensive that teams like ours would need to bring in another full time employee just to get through our self inflicted paperwork. But, there is a good reason to document a project well - not doing this can expose a project to mis-judgements and personal assumptions which can lead to a misinterpretation of the client's needs.

Going with the flow

To do a project by the book (at least, following the general flow of accepted methodologies), there are several key stages of design documentation we need to go through:

• After the inception of the project (first phone call / email / meeting etc) we're going to need a design brief. We can take this brief to the next meeting to discuss with the client and iron out their requirements more fully.
• It is after this point that we're going to need to produce our quote (cost / hours for external clients, or hours / resources for internal stakeholders – more on the quote shortly). We can't just pluck the quote from the ether though, we need to think very carefully about what the system must do and discuss the brief with our team; we must ensure the requirements are thoroughly understood and all time consumining complexity traps have been foreseen and accounted for. Once the quote has been (repeatedly amended and subsequently) accepted the real fun starts.
• We have to now produce our functional specification, which is another topic in itself and I'll cover it another time, but essentially this is where we have to clarify exactly what the system will do. The level of detail needed here will vary depending on the structure and dependability of our team but it's safe to assume that we'll need to think of every system usage scenario to at least some extent.
• Once this is complete (and signed off if required) then we'll be having conversations with our developers, building the final technical specification and getting down on paper exactly how the system will do what it's going to do, even before we write our first line of code.

With the above reams of documentation down on paper, the project manager then has to go through everything that needs doing and carefully distribute the workload as jobs to the appropriate team members (or more likely to appropriate members of various different teams). This in itself can be an arduous task if the system specifications have turned out to be very complex.

Wing it at your peril

The problem small teams face with such a thorough methodology (well, part of a methodology) is that it could take three or four times longer to generate all this paperwork than it would take for the project manager to have a chat with a designer and / or developer and for them to go off, spit out a 'fag-packet' spec for themselves and get the whole thing built.

Nobody wants to introduce the huge management overheads that creating all these documents in full would bring (we'd either have to absorb the costs ourselves, or sacrifice our competitive position in the market). Also, nobody wants to spoil a perfectly functional workflow. The thing is, not tackling these documentation issues is not healthy either, for instance...

• What if an emergency piece of work comes in and the programmer is taken off the project?
• What if the programmer gets hit by a bus (God forbid) when the project is half built?
• What if for any other reason someone else has to pick up the build work half way through?
• What if the client undergoes a systems audit at any point and calls us up for the documentation?
• What if securing our next big contract hinges on our clients approval of our stable, sound processes and best practice adherence?

We needed a solution that incorporates all the required processes and documentation.

We needed a solution that was quick, efficient, cost effective and wouldn't cause too much disruption (if any) to our current workflow and ongoing projects.

We needed to think outside the box a little...

Stay tuned for part 2.