IT projects have a reputation for being late and over budget. At Tiger Computing, we’ve evolved a simple process that has helped us avoid those two problems.

As well as reducing the time it takes us to get new systems live, it’s also made us more efficient and helped us “get it right the first time”.

Just to be clear, we’re talking about everyday projects that take no more than a couple of months from inception to implementation rather than multi-year, multi-location projects.

Common agreement

We had a client that wanted to migrate their email back from Google Mail to an in-house server, and had asked us if we could help. Their requirements were simple: build us a mail server.

Easy.

What could possibly go wrong?

We just needed to know what domain the server should receive mail for. Or maybe “domains”. Of course we would need to consider the security policies for the mail server. And whether the client wanted to have shared mail folders. And if they did, who should have access to them? Is that read or write access? If someone reads a new mail in a shared folder, is it marked “read” for everyone or just them? What about backups?

It seems quite a lot could go wrong.

What’s the problem?

Each of us in the room would have answers to most of those questions, but:

our answers may not be the same
the client may have different answers still
there may be other questions that we’ve not yet considered

At this point, the chances of success are slim. Even the definition of “success” isn’t clear.

The Requirements Document

Today when we implement IT projects, we always start with a Requirements Document. The goals of this document are to:

take into account the client’s wishes
incorporate our experience
define what the end result is able to do
avoid mission creep
be complete, such that someone who has not previously worked on this project could implement it
be definitive

A critical point is that the Requirements Document defines what is needed. It does not discuss how the requirements will be met.

This is much harder to achieve in practice than it appears.

We’ll look at each of those goals in a moment, but first let’s consider some practicalities.

Who’s going to write it?

The obvious answer might be “the client”, but that’s the wrong answer. The IT Project Manager will have more experience and knows what questions to ask. The Requirements Document for the database server built last year may be a good starting point for this mail server.

Making assumptions

We’re often told what the word “assume” does, but there are times when making assumptions is a sensible thing to do. Writing the first draft of the Requirements Document is one such occasion. We can make a good first-pass guess at what’s needed, and then refine it with the client.

We need to make it clear that we have made assumptions, and invite the requester to challenge or correct anything.

We can make life much easier for the requester by using headings for each area with the assumed answers below:

Mail Domains

The server will accept mail for the following domains:

- example.com
- example.co.uk

Mail for any other domain will be rejected.

The non-goal: how will the requirements be met?

This is one of the hardest traps to avoid.

It’s all too easy to couch the requirements in terms that lead towards a particular solution. Here are some real-life examples:

“We need two servers for redundancy”

What is the real requirement here? It is almost certainly not that we simply use two servers. That requirement says nothing about the relationship between the two servers. Will we keep one in a box on the shelf “just in case”?

Better to question the requirements with “why?”, and keep doing so until you reach the real requirement:

“Two server will be needed for redundancy”
“Why?”
“Because we don’t want a single point of failure”
“Why?”
“Because for every minute the server is down, we lose £1000”
“So is the requirement, ‘Better than 99.99% availability’?”
“Oh. Yes.”
“Is that availability of the server, or of the service it provides?”
“Ah. Good question…”

“The solution must be hosted on Amazon Web Services”

This isn’t a requirement: it’s a constraint. It may be corporate policy to host services on AWS or to buy Dell servers or to use Red Hat Linux, but they are implementation details. If they’re cast in stone, list them as constraints and detail any implications.

Step by step

Let’s look at the Requirements Documents goals one by one.

Take into account the client’s wishes

This is a given (of course), but it’s likely that the client’s expressed wishes will form a small part of the Requirements Document.

Incorporate Relevant Experience

The role of the IT Department should be to add value rather than implement blindly. They will have seen it, done it, and may even have the T-shirt from before. They should also be familiar with industry best practices, and how those practices evolve.

The IT Department will be aware of elements that the client is less likely to think of. For example:

The information security risks this project presents
What a sensible backup policy for this service might look like
The trade-off between features and costs

Define what the end result is able to do

This is the heart of the Requirements Document. This definition must be clear; words such as ‘preferable’, ‘ideally’ and ‘should’ have no place.

Be complete

The goal is to implement without having to ask further questions. If questions arise – for example, “when do you need this by?” – either the Requirements Document wasn’t read or it is deficient.

Avoid mission creep

The bane of projects everywhere. “If we’re doing X, it would be very simple to do Y at the same time.”. If Y is a requirement, document it in the Requirements Document. If it’s a suggestion, a thought, an idea, then add it to the list of “Unanswered Questions” in the appendix to the Requirements Document. Answer all such questions before starting of implementation.

We take a leaf from Fergus O’Connell’s book, “Simply Brilliant“, and answer the following questions at the start of the Requirements document:

How will we know when we’re finished?
What point in time constitutes the end point?
What will the deliverables be?
How will the quality of the deliverables be determined?
What things are definitely part of this?
What things are definitely not part of this?

Be definitive

During the development of the Requirements Document, either party may make changes. When all parties agree, the Requirements Document is complete. It is then signed off by both the client and the project team.

Any further changes are expensive. They are expensive in the literal sense that work effort will almost certainly have been wasted. They are also expensive in the emotional sense. When people are proud of the work they do, it’s upsetting to hear that you don’t need that work or you’ve changed your mind once they’ve started.

Implementation

There is a second, optional, document that may follow the Requirements Document: the Implementation Plan. In our experience, it’s a helpful document, but not as important as the Requirements Document. It also tends to be an internal document: the client is often not interested in how it is done, only when it will be done. The Implementation Plan may be little more than a list of actions and owners; for larger projects, a more formal project plan may be needed.

Pre-delivery check

Once the Requirements Document is complete, it is easy to turn it into a pre-delivery checklist. For example, the requirement might be that the server will accept mail for only the following domains:

example.com
example.co.uk

We can turn this into a checklist:

Checklist:

[ ] Server accepts mail for example.com
[ ] Server accepts mail for example.co.uk
[ ] Server rejects mail for example.net
[ ] Server rejects mail for tiger-computing.co.uk

Do the hard work first to make the rest easy

Putting the Requirements Document together is hard work, but it is worthwhile. Failing to define the requirements in advance leads to questions during implementation which:

interrupt the implementation process
interrupt the client
may delay the project schedule

In short, putting the hard work into the Requirements Document makes the implementation much easier.

Post project review

A post-project review is not an exercise in blaming people for any mistakes made. It’s the mechanism by which the next project will be more successful. It’s a good opportunity to improve the quality of Requirements Documents over time. Here are a few questions worth asking:

what did we do well?
what did we do badly?
what was missing from the Requirements Document?
what’s the one thing you would change in hindsight?

Here’s how to ask them: gather all related parties together, and issue them with Post-It pads. As you ask the questions, each person should write any answers they have on separate Post-Its. When all questions have been asked, collect the Post-Its in and group them by common concerns. A pattern will almost always emerge, and that’s the feedback for the next project.

Finally, write a short document that sits alongside the archive of the Requirements Document and lists the changes you would make next time.

Summary

Write the Requirements Document first.
Avoid “should”. This is requirements, not suggestions.
No implementation details.
No unanswered questions before the project starts.
“No blame” post project review findings must be written up.

The Secret of Successful IT Projects