Seven Things You Can Never Say on Project Calls
The words we use communicate shades of meaning that we might not want. Here’s a list of seven words that I strive to not use when discussing a project with a client or with my team.
This is the cardinal sin of any client communication. “We should be able to get back to you midweek.” “This code should fix the issue you are seeing.” “Should” is a wishy-washy, slouching word of ill repute. It’s vague and noncommittal. You need to define the expectation you are setting with your clients clearly or how can you know if expectations have been met? “Should” does not promise anything.
Instead, replace your shoulds with affirmative verbs like can and will.
I have seen very skilled and smart engineers say to clients that a request is “simple” or “easy”. What they leave off is “for me to do”, because even the most basic project task is invariably as far from easy as you can get for me, for my clients, and for 99% of the population. Calling a task simple undersells the value and worth of the work, and the one delivering it.
Instead, use the word straightforward to describe a task that requires a low level of effort.
This is a bit of a piggyback on #1 and #2; the use case for “quick” is a little different. I’ll often hear that an issue can be remedied by a “quick fix”. This descriptor not only undercuts the skill that will go into completing, but quick is not an exact measurement of time. It’s too subjective to be valid.
Just as inexact is when you need to speak with someone and they respond that they will get back to you once they’re off this “quick call”. Again, I have no idea what a quick call is for you, so I’m left in ambiguous anxiety. Work to make your expectation-setting more clear and objective.
The close cousin of this word is “a bit”, which means nothing, so don’t use it.
4. Less than
This pet peeve is specifically about LoE estimates. Expectations being set that a given task will take “less than 1 hour” or “less than 3 hours” is deceptive. Estimates don’t need to be exact; they are setting a number in the requesters mind as to how long a task will take. 59 minutes is “less than an hour” but is basically an hour, and will likely be billed as such. Since the client is going to see an invoice for any hour, and not 59 minutes, why split hairs?
All too often a site feature (or the entire site itself) will be flagged as “broken” or “buggy” or “wonky” or some other generic term. I have no idea what it means when a site is broken, since it can mean too many things. Even a simple sentence from the real world, “The window is broken” can mean a few things. Did the glass pane break? Will it simply not lock? Perhaps it is stuck open or closed?
Getting specific with bug reports is invaluable and an exercise every member of a production team—from client to PM to dev—needs to focus on throughout a project’s lifecycle.
This hyphenated word can be replaced by “off-the-shelf” or “vanilla” and means that a solution can be plucked from a waiting pile and slapped onto your need without issue. Two things here:
- First, even a ready-made solution will need to be set up. Despite the heavy lifting in CREATING the solution already being done, wiring it up into your project’s environment takes time and effort. Be wary of the expectations “out-of-the-box” builds with clients; there will still be work to do.
- Second, unless you have a very minimal and specific need, odds are there will be some customizations necessary to get an available solution to meet all your client’s expectations. It’s a bit of a panacea in meaning, and will likely not match the reality of going this route.
7. Best practice
Another peeve of mine is “best practice”, but only in how it is often utilized. When a team is faced with a project decision, someone will often ask “What is the best practice here?” as a way to lift the decision off of the group’s shoulders and instead look to some mysterious outside arbiter to choose. This dodge towards the placebo effect of “if it’s a best practice, it must apply here” is dangerous.
Own your choices. Talk things through as a team and see what meets your goals and ideals best. Odds are your situation is unique enough to require thinking things through fully. A best practice can be a guiding point, but it’s not a solution.