Select Page

“Inconceivable!” exclaimed Vizzini.

“You keep using that word,” said Inigo. “I do not think it means what you think it means.”

Have you ever thought that during a meeting when someone is rattling off engineering jargon? Yeah, me too. And as hilarious as I find the exchange between Vizzini and Inigo in The Princess Bride, living through that is not as much fun.

Let’s take a look at a few of my favorite misused terms.

Project Plan

According to the Project Management Institute (PMI), a project plan covers how a project will be executed, monitored, and controlled. Basically, the facets which are required to ensure a successful rollout.

However, most people would tell you that a project plan is a Gantt chart, probably created in Microsoft Project, which details every task, resource, and dependency necessary to deliver the project. No, no … that’s a project schedule. 

Project plans concern themselves with budgeting, quality, scope, communications, etc. They remain valid for the life of a project. 

Microsoft Project documents (aka, project schedules) are highly detailed documents which require continual work and provide continual frustration. Also, they are usually obsolete on about day 3 of the project, hence the continual work and frustration.

Because of this confusion, some engineering firms call these Project Execution Plans now instead of just Project Plans.

Risks and Issues

I would love to blame this confusion on RAID logs where risks, assumptions, issues, and dependencies get lumped into a single list and reviewed together. However, to be fair, these terms were confused long before I received my first RAID log and had to Google the acronym to figure out what I was about to view.

A risk is an event (or condition) which might occur and would probably have a negative effect on the project’s on-time delivery or budget. Hurricane Dorian (currently raging in the Atlantic as I write this) is a risk to many engineering projects on the East Coast of the United States. A potential summer fuel increase or a concrete shortage due to a massive interstate project is a risk to your project’s budget.

An issue is an event (or condition) which already occurred and, if left unresolved, will negatively impact one or more of the success criteria (deadline, budget, etc) of the project. A breached sewer line, a stranded delivery truck, and a massive bug in the data import would all be issues.

Something I find interesting is that the Project Management Institute defines a risk as something that could have a negative or positive impact on the project. While this is the definition, I never think of a risk having a positive outcome. 

“I need to let you know there’s a risk that we’ll come in under budget and ahead of schedule.” 

Yeah, the word risk just doesn’t quite fit in that sentence.

Move Fast and Break Things

Mark Zuckerberg at the F8 conference in 2014

Facebook founder Mark Zuckerberg famously said, “Unless you are breaking stuff, you aren’t moving fast enough.” The phrase “move fast and break things” became synonymous with rapid innovation and the natural consequence of mistakes or failure in the pursuit of successful development.

Sadly, I’ve heard too many engineers and entrepreneurs use it to mean, “Screw it, I’m tired of dealing with this. Just ship what we have.”

  • “The budget is due tomorrow!” – “Ugh, let’s just send what we have. It’s close enough. Move fast and break things!”
  • “The new reporting module is still broken and it’s due tomorrow!” – “Ugh, let’s just send what we have. By the time they get around to running a report, we’ll have it fixed and they’ll never know. Move fast and break things!”
  • “The chicken isn’t cooked all the way and our dinner guests are here!” – “Ugh, let’s plate it and dim the lights. Slightly pink chicken never hurt anyone. Move fast and break things!”

That last one might break someone’s digestive system for a couple of days.

No thanks, I’ll just have a nice mutton, lettuce, and tomato sandwich.

Proclaim this motto when you try new things, prototype, and innovate. Don’t proclaim it as an excuse for sloppy work or undercooked chicken.

 Agile

Agile often gets a bad rap from management and even some engineering teams. However, I think most of the problems occur because people mistake what agile means.

Being agile doesn’t mean …

  • you can change your project’s directions on a moment’s notice without any negative consequences
  • you will suddenly increase your delivery speed
  • you can skip the documentation
  • you plan will reveal itself up as you go along
  • you will be a better swordsman than Inigo Montoya

So, what is it? Personally, I like the definition at Capterra:

“[Agile] is an iterative development methodology that values human communication and feedback, adapting to change, and producing working results.”

Defining agile and what it means to your team is a lot more complicated than a simple sentence, though. That will take some work. Contact me if you have questions.

The Final Takeaway

We misuse words and phrases all the time.

For example, I used to say that I ate fairly healthy meals. Since then, my doctor has informed me that just because a bacon, egg, and cheese burrito with salsa technically addresses all four food groups, that doesn’t mean it’s “fairly healthy.”

Goodbye breakfast burritos, hello oatmeal. What are the phrases people misuse at your office? Send me a list. I’m already working on a sequel to this article. I just hope no one is working on a sequel to The Princess Bride.


Author: Tracy Thomason

Agile project manager by day, craft beer drinker by night, and avid reader anytime I can get 5 minutes alone with my Kindle.

More posts by Tracy

Featured photo from The Princess Bride, copyright by 20th Century Fox
Photo of Mark Zuckerberg CC BY 2.0