How to Complete a Feasibility Study

5 Terms Every Project Manager Should Know

June 26, 2013

Have you ever sat in a meeting and wondered what on earth was going on? When you are new to project management it can be difficult to get your head around all the new terminology, as, let’s face it, project management has a language all to itself. The jargon can make you feel as if you’ll never make any progress, and what’s worse is that you won’t find it easy to get your hands on a glossary of terms. Many project managers who have been working in the field for a long time have forgotten that once upon a time they didn’t know what any of these words meant either!

Here we try to demystify 5 of the most common project management terms – things you’ll hear every day when you are a project manager.

1. Baseline

A baseline is a snapshot in time. It’s usually used to refer to a project plan, so it captures the plan at any given moment. Baselines are important because project plans usually change, so what you think you’ll do today may not be the case in a couple of weeks. With a baseline, you can compare what you thought you’d do then to what you think you’ll do now.

They can be particularly helpful at the end of a project as you can go back and see how the plan evolved. This can be useful when you next come to work on a project – you’ll have an idea of how things changed last time and this will help you plan more accurately for any future work.

You can also have baselines for budgets. These capture the original financial position and you can use them to compare how much you actually spent against how much you planned to spend when the project started. That can be illuminating!

2. Risk

We use the term ‘risk’ in project management much like we do in everyday conversation, so this one isn’t as new to you as you might think. A project risk is something that may have an impact on the project but it hasn’t yet happened. An example could be poor weather threatening the company’s summer barbecue, for example. There’s a risk that it could rain, but you don’t know for definite yet. And you won’t until it actually happens (or doesn’t happen at all).

Risks are important on projects because we try to minimize the amount of things that could go wrong. While we don’t know if a risk will happen or not, we still work to reduce the chances of it happening, although you can’t do much about rain. In that case, you can try to mitigate the impact that the risk will have, so for the barbecue you could organize a marquee. That way, if it does rain, the impact will be a lot less as everyone will have somewhere dry to go. The work around the risk is documented in the form of an action plan, so that everyone knows what is being done to try to avoid the risk from having an impact on the project.

3. Issue

‘Issues’ on projects have a more defined meaning than in everyday conversation. A project issue is something that will impact the project. It is different from a risk because it has already happened. The impact of an issue can be massive (like a supplier going bankrupt and leaving you in the lurch) or tiny (like the photocopier being broken on the day that you need to make 10 copies of your report for the Project Board).

An issue may arise completely unexpectedly, or you may have already predicted that it might happen, in which case it will be on your risk log. When a risk becomes real – when it happens – we call it an issue.

We record all meaningful issues on projects and document the action plan to try to solve them. It might not be possible to fix them all, but project managers try! However, you don’t need to resolve them all yourself. Issues have owners – a person who is responsible for co-ordinating all the work (and probably doing some of it) to fix the problem and get the project back on track.

4. Change

A change on a project is exactly that: something that changes. It usually refers to a change in requirements, which happens when someone changes their mind about what they want your project to do. A change could be including new functionality in the software you are building, extending the project to cover an additional department or something simple like changing the colour of the product you are designing.

Changes normally arise when you show a prototype to the end user, or when they start thinking more about what they have asked you to do. They can also come up during testing, when you find something that really doesn’t work the way it should.

Whatever the change, they are all managed in the same way. The project team should evaluate the impact of the change and make a recommendation to the project sponsor about whether or not to do it. (Remember, you don’t have to make every change – if you did, your project would never get finished!)

5. Resources

‘Resources’ is a fancy term for stuff, but it is also a rather impersonal way of talking about people. Your project team members are ‘resources’ but so are money, office space, delivery vans, computers and anything else you need to get your project done.

Resources are important because if you don’t have the right ones you can’t finish your project. It’s not just getting them that is essential: it’s also getting them at the right time. People, for example, might be tied up working on another project at just the moment that you need them for yours, so it’s the project manager’s job to plan when everyone and everything is required. It can be difficult to sort out resource clashes but normally you can work with the other individuals involved to find a schedule that suits everyone. That’s why you need to plan what you need at the same time as what you are going to do, as if you can’t get that critical piece of equipment at exactly the right time then your project tasks are going to be delayed.

While these 5 terms might be new to you when you first start working on projects, you’ll soon get the hang of using them in everyday conversation. You’ll be surprised at how quickly you pick up the jargon and start slotting it into the way you communicate. Soon you will speak ‘project management’ like a pro!