Project Managers - can't live with 'em, can't lock 'em in a filing cabinet

in a disused basement toilet with a sign on the door saying 'Beware of the

Leopard'.

Project Managers have a large part to play in what work you'll have to

do, when you'll have to do it by, and whether you get paid. So it's

pretty useful to gain credibility with them - and other stakeholders

you meet - by understanding their language, and even using it on occasion.

What follows is a guide to the common terms used by Project Managers and

other people within a project. Like most jargon, it seems pointless until

you start working with it, at which point it becomes a very useful way

of describing the many people, situations and processes which almost every

development project will involve.

Many of the terms have a commercial tone to them, as if the only possible

application is in pursuit of cash. Leaving aside the question of

'so what?',

it's worth bearing in mind that a project is a project, whether money

changes hands or not, and whether the end goal is profit [insert

dot-com joke of your choice here - Ed.] or not.

Accountable

The accountable person in a team may or may not be the one who actually

does the work in question, but she would be the one whose job

it is to make sure it gets done, and would be the contact person

for the clients and/or project manager. The person actually doing

the coding is responsible for that bit of code - if a

team is dividing up the work between them, different bits of code

will have different responsible team members, but there's only

one team member who is accountable for it all.

 

Aligned

People and plans are said to be aligned when they're in agreement.

If the plan says that the developers should have completed

a certain bit of work by now, and they have, then the work is

aligned with the plan. If the project sponsor's goals are the

same as the business users' goals, then they are also in

alignment.
 

Business User

The people within the client who will own and/or operate the system

or site you're producing. Note that the client doesn't have

to be an external one (you could work for the same people),

or be a profit-making organisation.
 

Business Requirements

The tasks which the stakeholders need the system/site to

perform, to fulfil business needs. This will start off at a

high level, and iteratively drive down in increasing levels of

detail until you have a functional spec. Again, 'business'

is a slightly misleading term - they don't have to be profit-making

requirements.
 

Buy-in

If you introduce new ways of doing things to anyone, particularly

if they don't have much choice about it (such as part of their job),

it's only fair that you work with Business Users or other stakeholders

to make sure they're happy with the new way of the world.

Part of this

is sensible User Centred Design, part is validation that you're meeting

their needs, and part is simple communication so that they know what

you're doing and why, before it's all set in stone. The worst possible

outcome is that the first they know about it is at the post-build

testing phase - unless you like dealing with outright rebellion or

sneaky subversion.

Change Request Process (aka CYA for developers)

Once you have a tightly defined scope, and you've signed up to

delivering that scope within a specific time and/or budget, the

last thing you want is for the scope to change, either by adding

new things in, or by redefining the requirements. A Change Request

process is a sensible, ordered approach to making sure that

the build team don't get blamed for over-runs caused by this kind

of change. The basic process goes like this:

1. The business requests a change, defining detailed changes to the
   functional spec and perceived benefits resulting from the change.

2. The technical team analyses the detailed changes and conducts an
   Impact Analysis, highlighting the expected changes in costs and risks.

3. The business weigh the change's costs/risks against its benefits and
   decides whether or not to go ahead and accept the change.

4. If the change is accepted, the project has a new scope, costs,
   timescales and risks, and the development team is no longer expected
   to meet the old ones.
    

Communications Plan (aka Comms Plan)

Your project is changing the world - fantastic! But hadn't you better

tell people about it? Like all good things, this will take planning.
 

Constraints

The business can (and often does) ask for the moon on a stick. But it's

important that you make them aware of the limitations of time, budget,

technical strategy etc you're working under. After all, is it realistic

to support multi-thousand simultaneous users of a banking system if all

you have is a single Win95 machine running Access and Personal Web

Server?
 

Deliverable

The output of what you're doing. It should be something obvious

and tangible - for IAs, this might be wireframes or a site structure.

For a CMS developer, it might be workflows. For the project manager,

it might be the project plan.

 

Dependency

Something one tasks needs from another task before it can

complete. So before you can cut up the site into templates in a content

management system, you'll need the HTML templates, which will need

the visual design, which will need the branding, which will need

the marketing strategy etc.

Dependencies come in two major flavours:

1. End to Start, where I can't start my
   work until you've finished yours.

2. End to End/Start to Start, where you dripfeed
   your deliverables to me as you get them done, so I can get on
   with my work. An example would be where I can get started on
   producing HTML templates from your visual designs as soon as
   you start passing them over.
    

Due Diligence

Before you sign up a supplier, you'll want to follow

up their references, look at their previous work, check

their financial records (to make sure they'll still be around

to finish their work) and generally do some asking around. This

is known as due diligence.

 

Elapsed days/time

The number of hours/days/weeks from start to finish of a piece

of work. Elapsed days can't be compressed by throwing more people

at the work. An example would be obtaining a Merchant ID to accept

credit cards. The bank will take the same number of days to do

their due diligence, and there's nothing you can do about it.

Alternatively, if you put several people on a job measured in

man-days, elapsed days is the actual amount of time taken to

do the work.

Expectation Management

Here's the situation: I expect you to deliver the moon on a stick,

because that's what was in your pitch. If I still believe that that's

what I'm getting when it's delivered, and it's not, you've got a problem

because I think you've failed me. However, if you'd told me much earlier

We can't find a stick long enough, guv'nor, so we can't do that.

But we can get you a large balloon on a stick if that's

OK, then when I get a balloon on a stick, I'm not disappointed.

Expectation management is another hard job for project managers (and their

expectations need managing too), and they appreciate all the help they

can get.

 

Functional Spec

A description of how the system will behave to a level of detail which

lets the stakeholders (and in particular, the sponsor and other people

with sign-off authority) decide whether it specifies a system which

meets the business requirements.

 

Impact Analysis

No doubt your project will change the way things are done,

and the costs incurred in doing it. Working out what

the difference will be is impact analysis.

 

Learnings

What you learn from designing, building and launching

this project. And yes, it is grammatically stupid.
 

Man days

Producing wireframe layouts for a site will take a certain

amount of effort. If you put two people (of either gender) on

it, they'll split the work between them and the elapsed time

involved will be reduced.

The simplistic theory is that man

days are fixed and are simply divisible by the number of people

involved to find the elapsed time. In projects where communication

is a major factor (as it is in nearly all IT projects), this

doesn't quite work - in particularly complex projects, adding

people to a job may actually slow it down. This realisation was

documented by Fred Brooks in The Mythical Man Month.

Milestone

Milestone planning is a fantastically useful planning method

for when you don't have all the timescales required for the plan.

It's solely based on dependencies, and allows you to set out a

plan's skeleton around the arrival of dependencies. Here's

an example of a milestone plan for usability testing:

Milestone:	Dependencies: "When we have..."
Paper prototype Heuristic Inspection	Finalised wireframes available Heuristics standards available Heuristics inspectors available
Paper prototype user testing	Paper prototype heuristics inspection completed, changes agreed and implemented Finalised wireframes available Testers recruited Facilities requirements (ie testing environment) in place
HTML prototype heuristics inspection	HTML templates available Paper prototype testing completed, changes agreed and implemented Facilities requirements (ie testing environment) in place
HTML template prototype user testing	HTML prototype heuristics inspection completed, changes agreed and implemented Testers recruited (NB different testers from paper prototypes) Facilities requirements (ie testing environment) in place
Functional system prototype heuristics inspection	Areas of functionality available HTML prototype testing completed, changes agreed and implemented Facilities requirements (ie testing environment) in place
Functional system prototype user testing	Functional system prototype heuristics inspection completed, changes agreed and implemented Testers recruited (NB different testers from paper or HTML prototypes) Facilities requirements (ie testing environment) in place

 

Over-run

So we've agreed that the wireframes for this site will take five

days elapsed time, and cost £3000. If they don't arrive in

five days time, you have caused a time over-run, which will

throw the rest of the plan out. If they also cost over £3000,

you've caused a cost over-run which will break the budget.

And be sure of this - unless you've managed to negotiate otherwise,

your over-runs are your responsibility, not mine.

 

Phases

Discovery Phase

Is there a situation which needs a project at all?

This is where you find out by conducting a needs

analysis of the current situation (do people want

nasally fitted fire), and finding out

if there's a possibility of getting the resources you

might need.
 

Initiation Phase

This is the phase of the project where you do the initial

planning, get go-ahead and (most importantly) get the

budget to allow you to actually run the rest of the

project.
 

Design Phase

This is when you analyse the current situation, define

the end situation, and decide on solutions to get you

there. Surprising though it may seem, this is usually the

hardest phase, and certainly the one which takes most

creative thought.

In almost all projects, the business (via the stakeholders)

would first define its requirements, to clearly state what

is to be built, then the technical team would define the technical

solution to those requirements (ie how it is to be built).

This order is essential to ensure that the project delivers against

the business need - the thing which gained the project resources in

the first place.

Build Phase

Now you've decided what you're going to build and how,

it's time to go and do it. For junior developers, this is

all they will see of a project, and more often than not,

all they'll care about.
 

Test Phase

Does what you built actually work? Does it

deliver against the design? Here's where you find out,

before you launch it.
 

Launch Phase

This is where you'd train any business users, communicate to

the rest of the stakeholders (including the public for Internet

projects), move the site to production and register with Search

Engines.
 

Evaluation Phase

So, you're live. The site or system performs everything which

the Functional Spec said it would. But does the system deliver

against the business need? Will you make the sales? Will your

content managers update the content within a sensible timescale?

You won't know until it's being used. Think of this as testing

for the business requirements - in many cases, this is where

the next iteration starts getting designed, with changes arising

out of the live learning being added to the list of functionalities

which didn't make it into scope for this one. The usual choices at

evaluation are:

• Kill (it doesn't work, it won't work, or it's doing damage)
• Modify (it doesn't work as planned, but could work if changed)
• Maintain (it's fine as it is)
• Invest/Expand (there's greater potential than expected and it's worth
  throwing more resources at it to add enhancements)

Production

If a system is in production, then it's live to its end users.

 

Promotion

The usual way to produce a system is to develop it in one environment,

move it to another (which replicates the production environment) to

test it, then finally move it to production. This forward movement

is known as promotion.

 

PSO

PSO is a key concept in almost all projects where IT is involved.

Based on the assumption that you'd rarely do IT stuff for its

own sake, and even in those cases, there are non-IT implications,

it says that any substantive project will have impact in three areas:

• Process
  
  Almost all IT developments require a different way of working
  for someone. If you move replying to a site's contact us form
  from freeform email to a job-based web application where admins
  take ownership of a contact and reply via a form, then this is
  a different process. Alternatively, if you're selling products
  online, you'll need to ensure that there's a process for handling
  returns.

• Systems
  
  This is the IT bit. Inexperienced developers sometimes assume
  that this is the only area touched by a systems project.

• Organisation
  
  You'll probably also need to organise your people differently.
  Introduce a new site, and it'll need updating, so you'll need
  to put some staff time into doing that, possibly by recruiting
  dedicated people. You'd work out how much staff time using an impact
  analysis, based on the new/changed processes involved.
  Alternatively, if you're selling products
  online, you'll need to be organised with someone to pack and ship
  it to the customers, and you'll need to plan and get inventory to
  whoever's going to be packing and shipping it to the customers. If
  you're dealing with products with long lead times (like flowers or
  any complex industrial product), you'll need to be organised to
  have the inventory and any production capacity and component sourcing
  correctly forecast a long way in advance.

The more complex the project, the more significant Process and

Organisation become. Systems becomes the 'easy bit' at a surprisingly

small scale.

Resources

Everything needed to complete the project, but particularly

people and cash. Normally 'people' also ends up meaning 'cash',

as they have this annoying habit of wanting to be paid.

 

Risk Register

What could go wrong with the project? What could go wrong with

the system once it's live? For each thing which could go wrong,

what would be the impact of it happening? How likely

is it? Combine all of those and you've got your register

of risks.

Normally you'd track these regularly through the life of the

project with a red/amber/green traffic light summary. Red means

that the risk is either Very likely with a medium or high

impact or High impact with medium or strong likelihood.

Green means Low impact and low likelihood. Amber is everything

in between. Naturally, new risks are added as they're discovered, but

old risks are never removed from the register - they'll just sit there

at a comforting Green.

Sales Spec

An expression of the project's deliverables expressed in a way

that the end users or customers will understand and accept. Simply put,

it's the basis of what you put in the marketing copy, the press release,

and the sales force's pitch. Best practise says that this should be

in terms of benefits to those customers, not in features (ie most

customers won't care that the site uses load balancing, but will

care that it'll be fast, and won't suddenly die because one machine

goes bang).

 

Scope

What the project has agreed to deliver. Once signed off, defend

it with your life. The approved way to tell people Get stuffed,

we didn't agree to do that, and there's no way we're going

to do it is Is this in scope?

 

Scope-creep

What happens when people have bright ideas for minor improvements

to the design. Great ideas they may be (like Hey! It'd be really

cool to separate delivery and invoice addresses to allow gifts),

but if they're not in the agreed scope, you don't do them without

a Change Request being accepted. Otherwise your work ends up being

substantially more than you agreed to, but your budget and timescales

haven't changed.

 

Sign-off (aka CYA part 2)

You've completed the build, and walked

through the system with your stakeholders. They haven't made any

complaints during the UAT, so you think you've delivered what you're

being paid to deliver. But how do you know? When you ask the sponsor

to be paid, how do they know? When in a year's time, the client starts

complaining about your work, and that you didn't deliver against their

requirements, how do you prove otherwise if they sue?

The only way you'll know is if you get a signature, or a minuted

meeting, or some other clear, unequivable record that whoever has

authority to formally accept your work has done so. Once they've

signed off on the work, they take all future responsibility for

it being fit for purpose, so any come-back will land on their heads,

not on yours.

This also applies to the design phase. Someone will have to formally

agree that what you propose is what they want. Then if there's a

complaint during build of Who asked for this? This isn't right!,

you can instantly stop the argument by pointing to the signoff and

say It's signed off. If you have a problem with that, it's

nothing to do with me.

Of course, tensions arise when inappropriate people attempt to claim

signoff rights (example - when the Technical Lead wants to sign off

content in the absence of the project director (answer When I

sign off your technical infrastructure, matey, and not a day

before), or when not all of those who need to sign off do

so (say if one member of a board gives signoff to an external

publication when the whole board needs to). But that's stakeholder

management...

SLA (aka Service Level Agreement)

A contractually enforceable agreement on the quality of service

provided. This is often used for planned uptime of a site (99.99%

(or 'four nines') is common - any unplanned downtime which exceeds

this gets you money or other goodies back from your hosting provider),

and turnaround time for support. You might also have an SLA for

turnaround time of legal signoff of site content.

The point of this is that you can make firm plans around whatever

the service level you've agreed, knowing that even if you don't

get that level of service, you're going to get compensated

(and perhaps more importantly, not blamed) for slippages.

Slippage

What you get when you start running slightly over-time or

over-budget. Too many late lunches and the project slips.

As Fred Brooks put it: How does a project get six months

late? One hour at a time.

 

Sponsor

The person (or representative of the organisation) who are paying

for the project. Designing for the sponsor rather than the users

may not end up with the best deliverable, but on the other hand,

you'll get paid. If the sponsor has different goals than the users,

you have three choices:

1. Educate the sponsor to supporting the users' goals (this is the ideal outcome)
2. Support the sponsors goals (and get paid)
3. Support the users goals (and get fired)
    

Stakeholders

Anyone with a valid interest in your project. If your

project affects someone else's work, they're a stakeholder.

Some stakeholders will have direct input into your project

- some will even have signoff - while others will simply have

a representative of their interests (a UCD specialist will

represent the users for example).

 

Stakeholder Management

Projects are hard when stakeholders have different agendas,

goals and priorities. As well as managing the project, a big

part of a Project Manager's job is keeping the stakeholders

aligned with each other and with the project team. Anything you

can do to help will be appreciated.
 

Technical Spec

The detailed definition of how the system will meet the

functional spec, down to

a code level. Assuming that the system gets developed to the

specification, it should be possible to provide ongoing support,

maintenance and development of the system from this spec.

 

TOR (aka PID)

A Terms of Reference (or Project Initiation Document) is the gospel

for the project. It contains the key parts of what, how, when

and why the project will run. In most organisations, you won't

get the go-ahead or a budget without it.
 

Validation

OK, so you have a solution to the perceived business need. But

will it work for the stakeholders? Will your security model,

incorporating a 12-character, system defined, randomly generated,

non-user-changeable password, be usable for the business users?

And will it satisfy the requirements of the security folks?

Well, why not ask them? And if they say 'No', then it's back

to the drawingboard. Every design phase should be iteratively

validated until you have something which works for the people

you're producing it for.
 

Workstreams

Most complex projects will have several things going

on at once (normally with intertwined dependencies).

Each is a workstream, and may be lead and run by separate

people. For an online store, you might have a finance

workstream, a logistics one, a creative design one, a

technical build one and a project office. The only time

representatives from all of these come together may be at

a regular project meeting.

 

For more happy-clappy Project stuff, please see

• A Terms of Reference Howto
• The Tao of Testing