Like most disciplines, project management has its own set of tools and processes. Those tools and processes have names. To those in the practice, those names have meaning. But to others, it’s just jargon. And jargon is bad. Especially in an informal project management environment (“Cottage PM”). You can go a long way to demystifying project management in your teams and organizations by avoiding jargon and using natural language instead.
Why is jargon bad?
I’m sure there’s plenty of research and other writing on the topic of jargon. When I worked closely with support engineers, removing jargon was one of the training topics for improving soft skills. It’s just as valid for you and me.
Jargon alienates. It separates the “knows” from the “know nots.” That flies in the face of everything else that you’re doing to build communication and trust across your project team and stakeholders.
Jargon confuses. If the words have no meaning, then your communication stalls out. You neither get understanding nor input nor buy-in.
Jargon is me-centered. Consultants fall into this trap all the time. The more jargon you use, the less I think that you understand my needs, my organization, my project, my constraints, my concerns. It makes me feel like you’re just trying to “process me.”
Jargon can damage credibility. While some people may be impressed as you throw around your jargon, I’d bet most people are put off. Use of jargon is a rookie behavior. It says to me that you may know your processes and your job, but you may not be able to apply it effectively in my organization or to my problem. Jargon says “cookie cutter,” and that’s a put-off. After all, I’m completely unique and special as your customer, aren’t I?
Here’s an example. One of my mentors used to be a marriage counselor. That’s his education and training. One day, I was in his office and we were talking through a problem. I was having a bad day. He threw a jargon-like idea at me, some platitude from the positive thinking arena, and I simply said to him, “I don’t need you to shrink me; I just need you to think through this with me.” To his credit, he wasn’t offended, and our relationship has only improved over time. But don’t think he’s ever tried to “shrink” me since.
You risk the same kind of response if you’re using too much PM jargon.
Solution? Re-language jargon.
All you need to do is to re-language the PM terms. They are very straightforward ideas, really, and you should be able to express them that way. In some environments, it may suffice to define the term up front, just as you would when using an acronym in writing. You may then be able to proceed with the term. But often, it can be more helpful to use the natural language first, build trust, and then if you wish, begin labeling those ideas with the PM terms.
Here are some examples of risky terms, and some possible ways to restate them.
| Term / Function | Jargon usage | Natural language |
|---|---|---|
| Scope | We need to define the scope of the project. | Let’s figure out and define what we are and are not going to do on this project. |
| Stakeholders | We need to identify your stakeholders. | Who (else) will be impacted by the project? Who all is going to use it [the output]? Who could help us get approval / budget? Who could cause problems for the project? |
| WBS | Let’s meet to build the project WBS. | We need to get a solid feel for all the work that has to be done on the project. If we map it out, it’s easy to see what we’ve left out. It’ll also help us to assign it and track progress later. |
| Risk Register | …That’s a real risk to our project. Let’s put it on the risk register. |
…That’s a real risk to our project. Let’s figure out how we’ll know when it becomes a real threat and what we’ll do about it. I’ll keep that written down for reference. |
| Objectives | Let’s identify the project objectives. | Let’s identify the key things you want to accomplish on the project. |
| Vision | Let’s capture the project vision. | What does “done” look like? How will you know when it’s done? |
| Charter | We need a project charter. | Before we get too far down the line, we ought to jot down a really high level view of the project, what we’re going to do, who’s going to do it, what you’re willing to spend on it, etc. That’ll help us steer the project team through the detailed planning discussions and keep us focused. |
This kind of re-languaging can overcome a lot of weaknesses of jargon. You show understanding. You build relationships instead of alienating people. You build clarity instead of confusion. It’s easier to identify the benefits of a given process and get better input and buy-off. You bring clarity instead of confusion. You build credibility. You become more effective.
And all just because you changed the words you use.
No related posts.
Category: 
Max, I just found your blog (from Josh Nankivel’s status update on LI), and I just want to tell you this article is great. It really meshes nicely with my basic PM belief that project management needs to be more clear to the business people who benefit from it. I like the professionalism of the field, but when we’re working with customers, we need to speak in a language they understand and assures them we know what we’re doing and how it will benefit them. I recommended your article to a couple groups and will explore the site some more. Meanwhile, good article and I look forward to reading more.
[Reply]
Max Walker Reply:
December 15th, 2009 at 17:55
@Brian Mossing, Thanks for the feedback, Brian, and glad to meet you! This barrier of jagon was a huge barrier for me when I was just starting with PM as a stakeholder and later as a PM student.
[Reply]
Great post Max! This is really great advice for the area you are writing for, the “cottage PM” environments.
In major aerospace projects jargon is critical to know because that’s what the customer speaks too! The primary lesson here is to speak on the terms of your customer, whoever they may be.
Josh Nankivel
[Reply]
Max Walker Reply:
December 15th, 2009 at 17:56
@Josh Nankivel, I completely agree. The general principle is to speak common language as a means of building common understanding. Using too little jargon in the wrong setting could kill credibility just as quickly as using too much.
[Reply]
Awesome!
However, I’m wondering how the more words fit into a presentation which should not be full of text slides.
I keep saying the words on the right while presenting, but also keep writing the ones on the left.
Thanks!
[Reply]
Max Walker Reply:
December 16th, 2009 at 10:58
@Rolf Goetz, Hi, Rolf, thanks for commenting! It’s a good point. When scheduling meetings or preparing presentations, or possibly even while outlining a progress report, you need clear labels for these activities. Your approach would probably work in a lot of environments: use the proper jargon, but speak regular English. In other words, explain the jargon simply as you move through the presentation.
In other environments, even that could be off-putting. In those cases, try to find plain-English labels. “WBS” could be rendered simply as “The Work,” or “Summary of Work,” or “Project Work.”
As Josh pointed out above, the key is to use whatever languaging will build credibility and common understanding as you move through the process.
[Reply]
Good article. Too much jargon just comes in way of 2 way communications…
[Reply]
Max Walker Reply:
December 22nd, 2009 at 08:33
@Priyanka D, Thanks for the comment, Priyanka!
[Reply]