Project Management Terms

Early in my career, when I was getting into “project management”, I often felt confused and intimidated by all the terminology I heard people throwing around. I wished there was something simple to explain each term and how they fit together. This is my attempt to write such a thing. I’ve intentionally avoided “agile” specific words (for now) to focus on more general concepts. UPDATE: Check out my introduction to agile terminology.

Reflecting and planning

Work is the process of turning resources into outcomes.

Right NOW is where the work happens but you’re constantly looking back at what you did in the past. Sometimes looking back is called tracking, reporting, reviewing, reflecting, or retrospecting. The reason we look back is usually to help predict the future. Predicting the future is called planning. When we try to figure out how long a thing will take (AKA the timeline or lead time), or how much it will cost (the budget), we might call that an estimate.

An estimate is just a guess. Nothing more.

Both resources and outcomes will need to be tracked and planned, together.

Plans (and estimates) are just guesses and nothing more but the act of planning is still useful. It can protect us from optimism bias, help us to understand the challenges we’ll face, and encourage us to think through how we can respond to them. Dwight D. Eisenhower once said “plans are useless but planning is indispensable”.

The more often you reflect on the past, the easier it becomes to look forward, and the more quickly and accurately you can both predict future outcomes and respond to change in the present.

Resources (People & Things)

When it comes to resources, it’s better to talk about “investment" than “expenses”. It will change your mindset as you look at using resources to create valuable outcomes. Creating value is sometimes called “Return on Investment” or ROI. Good ROI is usually the goal. Predicting ROI helps people decide whether they want to bother doing something or not. You can predict ROI at any scale… Years, months, days, hours, minutes. It’s helpful to think about what you want to get from any investment no matter how small so that you can decide whether everything you do is a worthwhile use of your time and energy.

The past is evidence, the future is potential, the present is the work.

Resources are typically split into people (or “human resources”) and non-people (or “other costs”) a better word for “non-people” is “things”.

People are typically split into permanent staff who are expected to stay with an organisation for years and interim staff (or contractors) who are expected to stick around for days, weeks, or months (but sometimes stay much longer). Permanent staff should help you solve long term problems like bringing a product to market and supporting it indefinitely. Contractors are useful in solving specific short-term problems where it’s impractical or inefficient to hire in those specialised skills permanently.

Things are varied and could include anything from software licenses, to doughnuts, rent, training, chairs, legal fees, post-it notes, or web hosting. People investment involves on-boarding, off-boarding, recruitment, re-deployment, training, communities of practice, pensions, other benefits, and career development.

By “outcomes” we mean how the world will be different at some specific point in the future (sometimes called a “deadline” or “delivery date”) because of what we’re doing and planning now. We can plan and report on outcomes in various ways using, for example, Objectives & Key Results (OKRs), milestones, or Key Performance Indicators (KPIs). If an outcome is difficult to measure, it won’t help us much to determine if our actions are effective.

The cadence (or frequency) of your planning, reporting, and delivery will depend on how heavy your process is and how rapidly your organisation and environment change.

“Plans are useless but planning is indispensable.” — Dwight D. Eisenhower

Risks & Issues

A risk is a thing that might happen and prevent us from delivering our target outcome (or realising our ROI). If some event happens then your outcomes will be affected in some specific way. You might write them down in a risk register which is really just a list of risks, how likely they are, how much damage they could do, and some ideas for mitigating this risk. Risk mitigation simply means making a risk less likely to happen or reducing the impact if it does happen.

When weighing mitigation strategies, it’s helpful to figure out how much each option might cost, how much additional risk each option might bring, and how much it will improve your confidence in reaching your goal. Risks should be associated to an outcome. Otherwise, don’t bother.

Issues are like risks but describe problems which have already happened or, we believe, are guaranteed to happen. We can try mitigating them in the same way that we do risks, but usually with slightly more urgency.

If we can’t solve an issue or mitigate a risk on our own, then we need to escalate it. This usually means taking it to someone more senior with more power, autonomy, influence, or information than we have who would be able to do different things to help.

Dependencies & Critical Path

When your success depends on something happening outside the team, you’d call these “dependencies”. This might be an external vendor agreement getting signed (or expiring), a new system being installed elsewhere in the organisation, a 3rd party patch being released, a new policy being implemented… whatever. Correctly identifying, associating, and chasing up dependencies is one of the most important factors in helping a team to deliver. A critical part of this is knowing which things the team controls, which things the team can influence, and which things are outside of the team’s control. There’s a great game to help you do this called Circles and Soup.

You’ll sometimes hear the terms “finish start” (or FS) dependencies meaning one task must finish before the next can start or “start finish” (SF) meaning one thing must start before the other task finishes. There’s also “start start” (SS) where two things need to begin at the same time and “finish finish” (FF) where two things must end together. You can read more about these here.

If you’re making an old-skool project plan that includes all the activities, timings, dependencies, and deliverables you think you’ll need (and you also live in a world where these things can be reliably predicted ahead of time and remain fixed for the duration of the project) then the critical path is the shortest pathway that meets all the dependencies (in the order they need to be done). Even if you’re using agile methods to deliver a project/programme, sooner or later, it’s helpful to think about the critical path.

Conclusion

This is a non-exhaustive list but should get you started. What other words and phrases are you hearing that haven’t been included here? What things would you explain to someone just starting in the world of project, programme, portfolio delivery? Let me know and I’ll edit this post to make it more useful. Thanks for reading!