Running a successful development project – the five documents you really need

As outlined in my previous article “Documentation: boring – yes, essential – absolutely!”, documentation, although unexciting, forms a key part of any project. It helps to keep things on track and protects both you and your client. In this article I’ll look at the five documents you need to run a successful development project from start to finish.

Document 1 – Statement of Work

The statement of work is your kick-off document. It’s purpose is to get a high-level agreement on what you are going to deliver prior to the main work beginning. As a minimum, your statement of work should define the key deliverables and your terms of engagement (your rates, where you will work, what expenses you will charge for, whether you are working alone or bringing in additional resource). Ideally, it should also include some protection for your work, setting out compensation rates should the project be scrapped prior to completion and payment milestones (i.e. development tasks that trigger payments). By getting agreement on these, you can start work confident in the knowledge that both you and the client are working to the same agenda.

Document 2 – Wireframes

Wireframes aren’t usually seen as an essential document, but they make my list for a simple reason: clients aren’t usually technical people. The functional specification, as we shall see, is the more important document for development, but most clients simply can’t read them without falling asleep. That’s why wireframes are so useful, they are a visual representation of the deliverable that can be produced quickly and without the need for coding (what do you mean you’ve started coding before knowing the full specification – shame on you 😉 ). They are also useful for helping the developer to understand the user journeys involved in the system. There are lots of tools available online to help you create wireframes, but you can sketch them if you feel more confident. Once you’ve got your wireframes in place, run through them with the client and get them to sign-off on the concept; it’s the big document next and you don’t want any changes half way through.

Document 3 – Functional Specification

For the developer, working alone or in a team, this is the main document. A good functional specification is worth its weight in gold, as it contains the single source of guidance for the project. Within a functional specification, each piece of functionality required for the successful build of the system must be fully defined without any ambiguity. Using the wireframes as a reference, the functional specification will describe the workings of each screen, from input validation to login procedures and error handling. Writing a functional specification is not easy, and can be onerous, but is essential. It provides the basis for successful testing and acceptance and can stop ‘scope-creep’ in its tracks. If you can, try to go through the functional specification with the client, especially if there are any logical calculations or data processing that is represented in the wireframes. This won’t be easy, but it does help a project to run smoothly – pick out the main areas they need to look at or provide a client-facing “executive summary” up front to help them through.

Document 4 – Project Plan

The Project Plan defines the delivery schedule for the project. Although this will focus mainly on development milestones, such as the end of development, testing and go-live, it should also include payment milestones if these have not already been included in the Statement of Work. Project plans serve a dual purpose, they define timescales, but they also allow you to show the impact of changes on the project delivery date. The Project Plan is all about setting expectations for the client and protecting your time.

Document 5 – Project sign-off

This document is often missed from a project, but it’s important as it forms a clean break between development and production. The document itself is simple, you just need the client’s signature and a reference to the original Statement of Work, but its impact is greater. With a project sign-off document in place, there is no argument over charging for work, as anything post-signing is chargeable work (unless you decide otherwise) – a good situation to be in.

These five documents provide a complete overview of the project, both from the perspective of the developer and the client. They provide clarity around the deliverables and the timescales, and protect from the dreaded ‘scope-creep’ (I haven’t covered Change Management in this article, that’s for another time). They also engender trust, as a professional approach to a project gives the right impression to existing and potential clients.

Just one more?

Of course, there is one document that isn’t on the list that most freelancers would say is the most important: the invoice. It’s the one document we’re always happy to create and to submit to the client. Hopefully, with this set of documents by your side, submitting your invoice will be the easiest thing you have to do all project and there will be very little issue about getting it paid!

What documents do you use in your projects? Do you have a different set of essential documents? What’s the most important document in your armoury? Do you agree with our list? Let us know in the comments.

Why documentation could save your project (or even your business)

Ah! Documentation! It’s everybody’s least favourite activity. We all like to be creative, whether you’re a web designer creating great sites, a writer penning brilliant copy, or even a consultant electrifying the room with your ideas and wisdom. And that’s fine, that is the most exciting and satisfying part of a project, it’s what keeps us doing the things we do (that and money of course). But without documentation, boring old documentation, we’re all heading for a fall.

But what do we mean by documentation? That’s a good question. Documentation takes many forms, from invoices to functional specifications, creative briefs to project timelines – and they’re all important. Documentation is the backbone of any project for two crucial reasons:

1. It sets the limits on a project

When you come out of a creative session, or a briefing, your head is usually buzzing with ideas. As is the clients. At this point in the project, the end product is rather nebulous and probably looks different in your head than it does in theirs. Good documentation helps you to distil this creativity into a deliverable. By taking a step away from the creativity for a moment, you can clearly define what you will deliver – be it 300 words or a website design – in terms that are unequivocal. It should also define how you will deal with changes, which we all know and accept are part of the process. How many rounds of amends will you allow; are they free or paid? And finally, having set out the deliverables, it should also say when you will be paid – be it 100% on completion , 100% after the initial delivery, or 50% up front and 50% on delivery. You must set the terms of engagement, so that the limits are clear, both positively (what you will do) and negatively (what you won’t do). By doing this, the client understands what they are getting and if they overstep the limits, you have the power to push back or charge more.

2. It sets expectations

So you’ve set the limits on the project and the client knows exactly what they are getting. The next step is to set expectations. Expectations are different from limits. Limits define the deliverables for a project, whilst expectations set the times and costs. A good documentation set will tell the client when you will deliver and how much it will cost them. It allows you to set out your terms, and the client to benchmark your demands in an open and transparent manner. For me, in my career in digital agencies, setting expectations has always been the key to a good client relationship. By being honest about costs and times, you can create trust, and trust will get you a long way. Setting expectations means you can beat them, and meet them. Conversely, it empowers your client and makes them feel in control. It also stops you from being hassled when you need to work (”is it ready yet?”) and buys you time to do a good job.

If you don’t provide documentation around a project, you’re opening yourself up to risk, and as a freelancer risk is the one thing you don’t want. In big companies, if a project starts to wander off-course, they can throw additional resource or budget at it without causing too much of a dent in the bottom line – I’ve seen it happen. For you, that’s just not possible, or it might be, but at your expense – you’re either going to be putting in a lot of long days and late nights, or reaching into your bank account to pay people to help you. It’s in your interest to stop this from happening and it’s here, in the dark times, that documentation is your friend.

So next time you start a project, for a new client or an existing one, make sure you’ve got your documentation in order. It’s boring, yes, but one day it might just save your project, or your business.

In the next post, I’ll look at some of the key document you should use to control your projects – from briefs to project plans.