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.
1. Should
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.
2. Simple
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.
3. Quick
This is a bit of a piggyback on no.1 and no.2; the use case for quick is a little different. I 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 an expectation in the requesters mind as to about 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?
5. Broken
All too often a site feature (or the entire site itself) will be flagged as broken or buggy or wonky. I have no idea what it means when a site is broken, since it can mean too many things. To put it another way, “The window is broken” can mean many things. Did the glass pane break? Will it 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.
6. Out-of-the-box
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, 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?” to lift the decision off of the group’s shoulders and onto some mysterious outside arbiter to choose. This dodge towards “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.