The Secret of Successful IT Projects
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”
We sat in a room, three of us, discussing the requirements of a client. They wanted to migrate their email 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.
What could possibly go wrong?
We just needed to know what domain the server should receive mail for. Or maybe “domains”. Oh, and should users be able to access email only from within the company premises, or from outside as well? 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” would be contested.
The Requirements Document
These days, we start with a Requirements Document. The goals of this document are to:
- take into account the client’s wishes
- incorporate relevant 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
The Requirements Document defines what is needed. It does not discuss how the requirements will be met.
We’ll look at each of those goals in a moment, but first let’s consider how we’re going to do this.
Who’s Going To Write It?
The obvious answer is “the client”, but that’s the wrong answer. The IT Project Manager will have more experience and knows what questions to ask. Often, previous experience will help. The Requirements Document for the database server built last year may be a good starting point for this mail server.
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:
The server will accept mail for the following domains:
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 such that they lead towards a particular solution. Here are some real-life examples:
“We need two servers for redundancy”
What is the requirement here? It is almost certainly not that we use two servers, regardless. This 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”. Keep doing that until you unearth the real tequirement:
“Two server will be needed for redundancy”
“Because we don’t want a single point of failure”
“Because for every minute the server is down, we lose £1000”
“So is the requirement, ‘Better than 99.99% availability’?”
“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. Clients are often surprised by the amount of detail that goes into that document, although few question the amount of detail.
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:
- “Access to mail will only be via the secure protocols SMTPS and IMAPS.”
- “Offsite backups of all user data and system configuration data will be taken nightly”.
- “Two factor authentication must be mandated for interactive logins to the server”
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.
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.
This is where experience from previous projects is invaluable. Ensure that any questions that were asked last time are already answered in the Requirements Document.
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.”. Well, if that’s 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?
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. If you want people to be proud of the work they do, don’t tell them that you don’t need it or you’ve changed your mind once they’ve started.
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.
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 the following domains:
Mail for any other domain will be rejected.
We can turn this into a 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
Putting the Requirements Document together is hard work, but it is worthwhile. Failing to define the requirements in advance leads to questions during implementation. Those questions:
- interrupts the implementation process
- interrupts the client
- may delay the project schedule
It’s also demoralising. Time set aside to implement something ideally ends with the “something” implemented rather than waiting around for answers.
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 excuse to blame people for any mistakes made. Rather, 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.
- 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.
Could This Article Be Improved?
Let us know in the comments below.