Main Page Content
A Project Management Glossary
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:
- The business requests a change, defining detailed changes to the functional spec and perceived benefits resulting from the change.
- The technical team analyses the detailed changes and conducts an Impact Analysis, highlighting the expected changes in costs and risks.
- The business weigh the change's costs/risks against its benefits and decides whether or not to go ahead and accept the change.
- 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:
- End to Start, where I can't start my work until you've finished yours.
- 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 inThe 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.
- Process
- 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
orHigh impact with medium or strong likelihood
. Green meansLow 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
isIs 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 sayIt'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 (answerWhen 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:
- Educate the sponsor to supporting the users' goals (this is the ideal outcome)
- Support the sponsors goals (and get paid)
- 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.
