A beginner’s guide to project management jargon

Entering the world of project management isn’t easy: you need to familiarize yourself with the team’s current process, and you have to decide what your own style is going to be. Plus, you’ve probably heard a few sobering statistics, like how only 2.5% of companies complete 100% of projects they begin. Whether you’re stepping into a new project management role or diving into the corporate world for the first time after college, you’ll likely encounter some new terminology at work.

The business world often gets so caught up in shiny expressions that it struggles to actually convey meaning. To avoid feeling confused or sounding like a robot to your team, learn common project management terms and ways that you can best communicate as you move through the project management process.

1. Project management jargon in the initiation and planning phases

As you and your team begin to outline a project, some of the first phrases you hear will probably have to do with the project management methodology your team is using. Whether your team uses Kanban, Scrum, Waterfall, or another methodology, be sure you understand what that methodology actually means to your team to start projects off on the right note. The Kanban method you followed at an old role or in business school may not be applied the same way at your new company.

Look out for these phrases during the early phases of a project. (To learn more about specific project management methodologies, check out this article.)

Swimlane: In a project management context, boundaries of responsibility within a project. Once you delineate responsibilities, track who owns which tasks using a Lucidchart template.

Sprints: Smaller phases of a project (often a two-week period) during which an agreed-upon amount of work is completed. It’s a particularly common term in the Scrum methodology.

Deliverables: Just a fancy word for the goods or services provided at the completion of a project. If your company is working with a client, the deliverable is what you present to a client to prove that you did the work you were hired for. Before you start a project, everyone should understand the deliverables they’ll create. You can build a Lucidchart document that outlines your project as a whole so that the entire team is aware of the project’s overall goals, not just their individual responsibilities.  

At this point in a project, ensuring every member of your team actually understands their roles, the boundaries of those roles, and the work they are expected to contribute at each point in the project is the most important part of your job. Jargon aside, communicate these expectations clearly, and you’ll have a good chance of success later on.  

2. Project management jargon in the execution phase

As you work through the project, all the changing requests and unexpected challenges will usher in a whole new portion of project management vocabulary. Here’s a translation of some phrases you’ll probably hear.

Velocity: The speed at which your team members complete work, usually calculated in hours. Ask your team, “How long will it take you to complete this and other projects like it?”

Bandwidth: The energy or mental capacity required to complete a project. Asking a team member if they have bandwidth to do something is exactly the same as asking them if they have time to do another task for you.

Roadblocks: Any obstacles to completing a project. Double-checking with your team to see whether there are impediments to their work and whether you can resolve those roadblocks is a valuable step, especially at this point in the project.

Action item: Simply tasks to be accomplished. For example, saying “I’ll take that as an action item” means “I’ll make sure that gets done.”

Scope creep: Expression that refers to the tendency for large projects to expand beyond original parameters as they move forward, whether due to changing expectations from executives or from clients. If this phrase makes you imagine something amorphous slinking around in the shadows of your office, you’re not alone. Like that large green blob you’re imagining, scope creep is best avoided. Define your projects with clear boundaries and put a plan in place in case you do need to redefine your scope.

By the middle phases of a project, your concerns shift to making sure your team has what they need, managing expectations from team members and other stakeholders, and communicating the project’s process clearly. Skip the jargon if you have doubts about its efficacy.

3. Project management jargon in the closure and delivery phases

You’re almost there. Team members are completing work, you’re on schedule, and the project’s end date is beckoning. Don’t be tripped up by a web of jargon after you’ve made it this far.

Get one’s ducks in a row: To get your affairs in order, such as collecting the files, gathering documents, and running through a final round of edits. However you need to say it, make sure you stay organized before the project’s completion date. Update your Lucidchart document to clearly show your team where you’re at and what you need to do to complete the project.

Backlog: The languishing list of to-do’s that your team has to finish before your project can officially be declared complete.

Status: The position of a project at a particular time, as in “What’s the status on the CTA button?” You’ll hear about status a lot as a project moves towards completion. If you tire of it, just ask your team members whether their parts of the project are done yet—it might sound less diplomatic to some, but it asks the same question.

By this point, everyone (yourself included) has invested a lot of time and energy into your project’s success, and you’re all ready to send the project on its way into the world. Don’t let communication mishaps slow down your progress or cause you to miss a deadline. Check for clarity at every step to be sure every team member knows exactly what stands in the way of officially declaring a project complete.

4. Project management jargon in the refining phase

Most project managers carve out some time to look back at a project after its completion to learn what they could do better next time. Use these phrases to describe the ways of refining projects.

Process improvement: A plan to avoid the same mistakes or work better as a team on the next project you tackle.

Scalable: The ability to adapt your project to a larger or smaller scale. Company leadership might bring up this term to understand whether your team can handle additional work in the future. So, when you hear the question “Is this scalable?” you can assume management isn’t referring to fences or trees.

Retrospective: The act of looking back on previous projects. If you receive an invitation to a meeting with this word in the title, you’ll be discussing what went well and what you could do better on your next project—so don’t panic.

After a project is over, it’s tempting to sigh with relief, throw out your checklist, and then look ahead on the calendar to the next awaiting task. However, taking time to talk to your team about how the project went is worth the extra time. Strive to foster meaningful conversation in team meetings, with or without jargon, to gain insight into how the project went from the perspectives of different team members and departments.

Let Lucidchart simplify the jargon

Learning common office jargon can make your first few months as a new project manager much easier, especially if it’s a big part of the culture at your new company. However, if you notice that your team stares blankly as you use these phrases, change them. Up to 30% of projects fail as a result of poor communication, and it’s your job as a project manager to communicate in a way that keeps your projects from becoming part of that 30%.

Instead of relying on language your whole team may not understand, use visuals in Lucidchart to speak to your team in language they don’t have to decode.