evolt.org Workers of the Web, Evolt!

Introduction

"But you were supposed to..." "But I wanted..." "But I thought..." "But that's not what I said..." "Can you just..." How often have you heard these from clients, suppliers or colleagues? They're frighteningly common, but they share 2 common characteristics:

1. They're caused by failures in managing project requirements
2. They're 100% avoidable.

Without a doubt, the most significant thing you can get wrong in running a web development is to mess up the requirements. Get this wrong, and every thing you do after that is doomed. Without the right effort in gathering, documenting, agreeing and keeping to requirements, you won't deliver the thing that the client wants, and in many cases, you either won't get paid this time, or you'll never be hired again by the client.

This article will teach you how to avoid this poison chalice and be on the first step of the road towards consistently delivering effective projects.

Web Development is a Project Management Discipline.

What is a project?

To clarify why this matters for our industry, let's think about what a project is and isn't. First off, it's not just a thing done with large clients, budgets and suppliers. It doesn't necessarily have to involve money changing hands, or separate client and supplier bodies: internal work has the same characteristics. That said, I'm going to be concentrating on client/supplier contractual type projects, assuming that you're the supplier, as there are some interestingly specific implications of getting this right in that setting.

The nature of web development is that it's nearly always temporary (not necessarily short!) pieces of work, with a beginning and an end. In that time, you do some things that give an end result that's noticeably different - and ideally better - than where you started.

Well, that's near as makes no difference to the textbook definition of a project.

What is a Project Manager?

Do you need to have a job title of Project Manager? Do you need to be doing it full time? Do you need to have staff reporting to you? No, no and no. If you have any responsibility for ensuring that the project happens to time, budget and quality, then you are a PM. And everything that follows is your responsibility too.

Goals, Objectives and Requirements (oh my)

Loosely speaking, Requirements are the things that the project must deliver. However, let's take a step back and think about this from the point of view of the project sponsor - the person who wants the project and is prepared to provide money, people, equipment and whatever else is needed to get it.

A project comes into existence to do something: to have the end result - effect the change - that we talked about above. This is nearly always expressed in the language of the sponsor's business, as web development purely for its own sake is a rare thing. So taking the US Moon Landing as an example, the desired result was not a Moon Landing in itself, or even a Space Programme, but to prove the superiority of American Technology to the world. Similarly, the result of a web development project might be to increase sales, or to enable employees to self-book holiday time. We call these Project Goals, and meeting the Goals is the job of the Sponsor.

The project exists to do stuff that achieves these Goals. The stuff in question we call Objectives. These are the things that the project directly produces: A Man on the Moon; an eCommerce site; a web-enabled vacation application. Meeting the Objectives to time, budget and quality is your job as PM. If you do that, and it doesn't achieve the Goals, its Not Your Problem (tm).

So what are Requirements? Requirements are the necessary characteristics of the Objectives that are likely to fulfill the Goals - and that the Project therefore must deliver. So if I'm the Sponsor, and my Goal is to develop online sales, the eCommerce site must be highly usable, support customers browsing products, adding them to a cart and paying for them. These would be (some - but by no means all - of) the Requirements.

To put it another way, Requirements are the detailed view of the Objectives. They are the answer to the question "What exactly do you mean when you say you want an eCommerce site?" Because Requirements are the things that the Project must deliver, they are the absolute definition of whether the project has achieved its Objectives. Meet all the Requirements in full, and you've done the job. Fail to meet any element of any of them, and you haven't.

Naturally, Requirements are contractually binding. And in many jurisdictions - English Law for one - where a contract is vague, the customer can interpret it exactly as she likes. So fail to get your requirements right, and you're setting yourself up for the most mighty of reamings.

Gathering Requirements

When to Gather Requirements

As meeting the Requirements is the definition of success, they're the basis for all your plans: task list, estimates of time and cost, test plans, the lot. So you need to have them before you can accurately do any planning. So you need them as early as you possibly can, in as much detail as you can. You most definitely need them before you can submit a quote, as otherwise, how will you know whether you can do the work for the price you've submitted?

So now you've got the work, you need to check them again, in much finer detail than you've been able to do before. You can now revise your plans and estimates accordingly - hopefully with more accuracy! Any change at this stage will likely involve a contractual variation, but hopefully it's just a level of detail thing.

The third essential point to gather requirements is whenever you join the project. With luck, this will just confirm what you've been told before you joined, but I wouldn't bet the farm on it. Failing to do this is a fairly major assumption on your part, which is A Bad Thing to do when you have the opportunity to confirm the actual state of affairs.

Gathering Requirements

Step 1: Context Is Everything

Why did I mention Goals above? Because if you don't understand these, you won't get to the Objectives (and therefore Requirements) that the Sponsor actually needs. Take the Moon Landing project. The Goal was "Convince the World of the Superiority of American Technology." Just landing on the Moon wasn't enough - the Project also had to convince the World that it had happened (leaving aside Conspiracy Theorists for now). So a key requirement of the project was to ensure global publicity, including live television broadcast.

So step 1 is really Understand the Goals. How do you do that? With luck, it'll be documented for you (and if it's not, the old PM rule of If it's not documented, it's a rumour holds true), but unless you enjoy working on assumptions, you talk to the Sponsor and other key stakeholders (i.e. people who have an interest in the outcome of the project). Useful questions to ask include:

• Why are we doing this?
• If we're successful, what would be the outcome for you?
• What would happen if we didn't do this project?

Note that these are all Open questions designed to get the other person talking...

Step 2: What do you Need?

Now you've got a feeling for the context, you can start asking questions (open ones, ideally) that will drive out what it is that the sponsor needs. You'll also need to talk to anyone who's affected by the project, or at least a representative of each group to produce Needs for every major stakeholder. You'll need some standard information for almost any project, such as:

• Why do you think we're doing this project?
• What's your role in the project and in the business?
• How will what we're doing affect your role?
• What functionality do you need?
• What would success look like for you?
• How do you define project completion?

You'll also need some more specific questions probing the capability and functionality needed. So for a web-enabled vacation tool, you might include questions like:

• Which staff should have access to it?
• What hours must it be operational?
• How is an employee's vacation allowance calculated?
• How will we know if an employee leaves?
• What happens if an employee doesn't use all their allowance?

You should also be reading all project documentation - contracts, proposals, statements of work etc - as these nearly always contain strong hints of what stakeholders are expecting.

Step 3: Do We Really Need the Moon on a Stick?

In any exercise in gathering Needs, you're going to end up with a mixture of must-haves, some should-haves, and some nice-to-haves. You now need to split those three categories into two: Requirements and Exclusions. Or alternatively, must-haves and everything else. Every Requirement will be delivered in the project; everything else will either be entirely rejected - either because it's not technically feasible or the client won't pay for it - or deferred to a later project or release.

Here's the Acid Test for which box each Need should go into:

1. Is the Need part of the original intent of the project? An example of an Exclusion on this basis might be reporting sick days using the vacation tool.
2. Was the cost of delivering the need included in the original estimate? Assuming that this has already been produced of course.

The Sponsor should have a lot of input into answering these questions, not least because she will have to agree with your definition, and you'll save a lot of trouble the earlier you do this.

Documenting Requirements

If you remember, the final Requirements will be the basis of every single piece of planning you will do for the project. So getting them definitively agreed and not subject to interpretation by clients is essential. You must produce documentation that is clear and concise, using graphics, models and other visuals if it helps clarify what you mean. Your documentation must also be detailed enough for anyone else to plan or start work on delivering the Requirements.

This should be insultingly obvious, but it's worryingly commonly missed: Document everything in writing.

Validating Requirements

Once you've gathered and documented the Project Requirements, you need to check that you've truly understood them and that they accurately reflect the understanding of your main stakeholders. You go about this by effectively locking yourself in a room with those people, and staying there until you've got a common understanding of every single one of the Requirements, and an agreement on your Exclusions.

Requirements Baseline

This is a Requirements Document that has been approved by the Sponsor and is supported by stakeholders and main members of the project team. It is the formal, contractual definition of what the Sponsor wants, and that the project team has agreed to deliver (remember Contract Law 101: contract=offer + acceptance). It must not be changed without a formal approval to do so.

What you must do to establish the baseline is take the written output of the Requirements Validation, put it in front of the Sponsor, and get her to sign it. You sign it too. As of that moment, the only place Requirements are documented is in the Requirements Baseline. Every member of the team needs to understand this; that any changes to it will affect the project's cost or schedule, or both and that it is the heart of your contract with the client. Failing to understand this will inevitably lead to scope creep, and that is the death of your project. This means that any proposed changes can only be implemented following the formal approval of the Sponsor, which only you can seek. Therefore, all proposed changes have to come to you, in writing.

Wrap-up

The result of all this is that you'll have Requirements that:

1. Are understood by everyone
2. Are agreed to by everyone
3. Are documented such that there is no room for arguments
4. Are the basis for accurate planning of work and budget
5. Are capable of being strongly defended against the "This week's wizard wheeze" type of request

Nothing magical, no rocket science required. Just a simple process to follow, and the biggest dragon responsible for project death is slain. And you get to be a hero, which is nice.