Project Manaverse

Top Sixteen Project Manager Terms 

The project world comes with a lot of ‘jargon’ that you need to be familiar with.  It won’t be long before you hear these terms and to be fair, you will naturally pick them up as you go. However, it is certainly worth spending ten minutes to learn the most common terms, so that you are not on the back foot when you hear them!  In this blog, I’ll share what I believe to be the sixteen most common project manager terms.  Let’s dive in!

• Project Scope

The project scope tells us, at a high level, what the project is ‘doing’ or delivering. All of it. Most projects have one overarching goal that is easy to grasp, for example, ‘build a house’ or ‘upgrade a system’.  The scope will include this goal, but will also include a few more high level specifics.  Using the ‘upgrade a system’ example, the high level scope could look something like – 

• Upgrade Accounting Tool to v2.0
• Build a Test environment 
• Migrate the system database to the Cloud 

The project scope will not include the low level requirements or details.

See my blog https://projectmanaverse.com/2022/04/13/what-is-scope/ for a guide to writing the project scope.

• The Design

You can think of the Design as the blueprint for the thing your project is building.  It covers the exact details and specifications of the scope, leaving no room for ambiguity.  If you were building a house, then the design would likely be the blueprint for the house, along with a reference to the exact building materials (not that I know anything about building houses!).  In my world of IT project management, the design is typically a technical diagram of the system ‘architecture’.  It includes all the systems specs and configuration, the infrastructure the systems sits on, any feeds in or out of the system, and any upstream or downstream systems.  Of course, the diagram is just a summary to bring it all together, you will also have pages and pages covering the technical specifics.  It is crucial that the Design is agreed and approved before you start building.  If it isn’t, then you are at risk of building the wrong thing…which leads us to term number three…

• Change Request (CR)

A change request is required if you want to change something on the project.  If you want to add to the scope, you need a CR.  If you want to change a requirement, you need a CR.  If you want to move some of your key milestone dates, you need a CR. If you want to change some of your code in a Pre-Prod or Production environment, you need a CR. To complete a CR, you will typically need to fill out an online form or excel document.  The CR will then go through some kind of governance where it will be reviewed and (hopefully) approved by the approvers.  CRs are a great way to keep the project under control. 

• Project Plan

The project plan, in my opinion, is the most important tool for a project manager.  A project plan can  refer to a collection of documents used to manage the project (e.g roles and responsibilities, scope, Gantt chart, risk log, critical success factors etc), but more commonly it just refers to the ‘actual plan’.  That is, a list of activities required to achieve the project outcome, plotted against a timeline (sometimes called a Gantt chart).  Project managers tend to have a very detailed plan which can consist of hundreds of rows of tasks.  They also tend to have a high level plan which includes only the key tasks.  This high level plan can fit on one page and provides a holistic view.  Very handy.  We call this a Plan on a Page or POAP.

• Milestones

Project managers love to hit milestones!  A milestone represents a significant event or outcome on your project plan.  For example, the Design approval, the end of Testing or the Project Go Live date.  Once a milestone has been formally agreed, we usually say it has been ‘baselined’.  Once baselined, you cannot change it without a CR.  Your plan on a page will be the best place to get a quick view of all the key milestone, as it will mostly consist of these.  As a project manager, it is your responsibility to ensure the milestones are achieved.  If any are at risk, you should communicate that appropriately.  

• Critical Path

Critical path is a tricky one to explain.  All experienced project managers have a great sense of what it is, but have a hard time trying to describe it (or maybe it’s just me!).  It basically highlights all the key project milestones (and activities needed to complete those milestones) that must be done sequentially to achieve the final project delivery date.  You cannot complete these activities in parallel, or in any other order.  Therefore, if a critical path milestone is late, it will cause all the subsequent critical path milestones to be late, and ultimately mean you won’t achieve your final planned project delivery date.  

• Requirements

The requirements describe the ‘needs’ that are driving the project.  You have high level requirements, and you have detailed requirements.  Examples of high level requirements could be, 

‘I need a bigger place to live’

‘I need to spend less time to achieve my accounting outcomes’ 

There are many ways these requirements could be met, and it’s important to remember that, strictly speaking, a requirement should not take the form of a solution e.g. ‘I need to build a new house’ or ‘I need to hire an assistant’.  These are not really requirements, these are solutions.  

Low level or detailed requirements are typically written after the broader solution has been agreed.  For example, if the solution is to build a new house, a low level requirement might be to ‘have a room big enough for my book collection’ or ‘I want my feet to be warm when I walk around the kitchen’.  The Solution document or Design will show exactly how all the requirements will be met (e.g. library blueprint, heated flooring specs).  

The requirements should stick to the customer need.  If an agreed solution to the accounting example were to build an accounting system, the requirements would describe all the things the customer wanted to use the accounting system for. Each requirement would be associated to a customer need.

Every detailed requirement should be tested to ensure the desired outcomes have been delivered.  

• RAG Status 

The RAG status is a colour that represents the health of your project, or how likely it is to be successful given the current situation.  RAG is an acronym for Red, Amber, Green.  Unsurprising, Red is bad, Green is good, and Amber is somewhere in between.  An Amber or Red status will be driven by the Risks and Issues of the project.  The RAG status is an extremely efficient communication tool, because in a glance you can understand how well the project is doing.  

• The Route to Green (RTG)

The route to green (RTG) or path to green (PTG) is the plan for how a project will get out of an amber or red status, back to a green status.  An amber or red project should always have a RTG.  The RTG should be concise, with specific steps, and a target completion date for each of those steps. 

• RAID log

RAID stands for Risks, Assumptions, Issues and Dependencies.  It’s common and sensible to hold them all together in one log.  It is really important that project managers have a good understanding and handle on all of these for their project. Let’s go through each one. 

Issues

An issue is basically a problem on your project that is impacting your project’s progress, quality or cost.  Generally, the longer the issue remains open, the more damage it causes.  It is a key project manager responsibility to resolve issues as quickly as possible.  

Risks

Risks are basically issues that might happen in the future.  It is a key project manager responsibility to identify and manage risks.  Risk management means attempting to reduce the likelihood of the risk occurring, as well as planning to reduce the impact or damage of the risk if it does become an issue.   

Assumptions 

Generally, there will be more assumptions at the start of a project and none by the end. There are some things about the project that will not be known right from the get go.  However, in order to plan a project robustly, you need to know what those things are!  Rather than delay the project planning and activity, assumptions can be used to fill the gaps.  Using assumptions comes with a certain amount of risk (because they could be wrong!), so it is important that key assumptions are documented, visible to key project stakeholders, and confirmed true or false as soon as possible.  

Dependencies 

Dependencies will highlight a ‘prerequisite’ activity that needs to complete before another can start.  For example, the Testing team have a dependency on the Build team to build the computer before they can test it.  If the build is not complete, they can’t start their work.  Most dependencies in a project will be within control of the project manager and the project team, however, some dependencies will be outside of their control.  These ‘outside of our control’ dependencies are the ones that would usually go on the RAID log.  For example, I have been hired to build a house, but I can’t start doing that until the planning permission comes through.  Therefore I have a major dependency on the Local Planning Authority.  In the IT project management world, it is common to have dependencies on other projects, and these are typically the key ones for the RAID log.  

• Governance 

Project governance is project control.  It’s systems or processes used to minimise risk not only to the project, but to the entire organisation.   A project cannot be delivered any old way, it must be ‘governed’.  Governance can take many shapes and forms.  Examples of governance include approvals, approval forums, escalation pathways, document storage, peer reviews, project review meetings, checklists, deliverables, policy, etc etc.  

The project manager is usually responsible for navigating the project’s governance processes. 

• Steering Committee 

Most high profile projects will have a Steering Committee.  The Steering Committee is literally there to ‘steer’ the direction of the project.  This is where key decision will be made and captured in the RAID log.  This is also where key risks and issues will be escalated and discussed.  The Steering Committee will usually include all the ‘important’ stakeholders, like the project sponsor, the relevant heads of departments, a risk representative etc etc.  Steering Committees can be a big deal, and I’ve even heard of some project teams rehearsing them ahead of the actual event!

• Stakeholders

By ‘stakeholders’ we mean anyone who has an interest in the project.  It is critical that we keep our stakeholders well informed of the project’s progress.  Stakeholders can come from a whole variety of departments and will have varying degrees of seniority.  We need to keep our stakeholders happy but we also need to ‘keep them in line’ to some extent.  This is called stakeholder management.  Poor stakeholder management will often lead to problems on your project.

• BAU

BAU stands for ‘Business as Usual’.  The acronym is always used instead of the real words!  This tends to refer to the usual and repetitive day to day work required to run an organisation.  Project work is not BAU work.  Projects are only temporary, have specific outcomes and will end once those outcomes have completed.  BAU processes tend to run ‘forever’ or until the process is changed or no long required.  A common challenge that project managers face is that their resources often have to do BAU as well as project work, and often BAU will be the higher priority.  

• Project Implementation 

This is often referred to as the ‘Go Live’ date.  It’s more commonly used for IT projects, but you can just think of it as the ‘main event’ your project has been working towards.  For example, launching a mobile app live to the world, releasing a new clothing line, putting a house you have built on the market.  

• Project Working Group (PWG)

The PWG refers to the group of people who are involved in the project.  They usually consist of the core members of your team who are full time on the project, others from the business who are supporting on a part time basis, and various other key stakeholders who have an interest in your project and may have more of an advisory role.  If you see a meeting entitled ‘PWG’, it is usually the regular project working group meeting used to update the project status, discuss the plan and key risks and issues.  

That’s your top 16 project manager terms done!

So there we have it, those were my top 16 project management terms. Did I miss any keys ones? If so, please leave them in the comments section below, I’d love to hear from you. Thanks for visiting Project Manaverse! I’ll see you next time!