Introducing Project Requirements

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.