In my day-to-day consulting, I try to steer clear of phone calls, especially conference calls, but I occasionally have to do one like everyone else. Today was an uncommon bit of hell, as I had two different conference calls. Both of them were with potential clients, and just due to my role on these projects, both phone calls had other developers on the line who are handling some of the actual development. My role on both projects is advisory.
The purpose of the calls was discovery; we had a number of questions about the project to better understand the client’s needs and how the project should be built.
At some point on each call, we were discussing a particular piece of potential functionality for the project in question, and I heard a developer say the worst words you can say in terms of client expectations management:
“Oh, that should be easy.”
face-palm
Now, I used to say things like this. And sometimes I still want to.
As a group, developers seem to think that saying something is “easy” makes us sound like brilliant rockstar coders. I think it makes us sound like amateurs.
I get it though; it’s very unsatisfying to hedge and demure when a client asks how long something will take, how hard it will be, and how much it will cost.
But answering those questions right away is almost always ego-driven, not in the service of the client or your relationship.
Now, just to be clear, I’m not talking about changing the color of a button or adding a field to a database (both of which can have their own kinds of complications, btw). These were major pieces of functionality, involving a lot of modification on both client and server for applications that were currently being widely used by customers (with real, live customer data) out in the field.
You’re absolutely insane if you think that’s going to be a quick, easy fix. Hell, you’re insane if you think you can possibly even know off the top of your head how difficult it might be! You just heard about this ten seconds ago!
Over the course of my career, I’ve worked with a lot of very experienced, very professional engineers. And their defining characteristic from what I can tell is thoughtfulness. Anytime they were asked about a potential issue, they wouldn’t answer right away. They would spend time thinking about it, researching, discussing internally, and then get back to you with an answer.
That kind of approach takes more discipline, but it’s so refreshing. Having someone pop off an answer immediately that has an 80% chance of being wrong is actually not as helpful as you might think.
This also goes along with my mantra about calls with clients:
”Never give out a project price over the phone.”
80% of the time when I talk to a potential client on the phone for the first time, they describe the project in high-level terms and then they say something like this:
“So, we know this is really rough, and we won’t hold you to this, but do you have any idea how long this will take and how much this would cost?”
Yeah, right. The most I’ll give them is an order of magnitude idea of the time involved, and 90% of the time, I basically just say:
“Well, this isn’t such a simple project that it can be built in a few days or weeks. You’re likely talking about months, but probably not years.”
I’m pretty comfortable with telling a client that it’s going to be in the range of 2-12 months to complete their project 🙂
The worst part about the anecdotes above about the developers I was on the phone with is that in both cases: they weren’t the ones who would be building that particular piece of functionality.
So not only are they probably being wildly optimistic with their estimates and ruining the client expectations, but they’re going to throw some other poor schmuck under the bus in the process.
In a few weeks the client is going to want to dig into that work that “should just take a couple days”, and some poor developer is going to have to say “actually, this is going to take 10x as long as that, and here are some other side effects as well that you may not have thought of.”
That’s going to be terrible for everyone involved. All because a developer on the phone couldn’t say:
“I think I understand what you’re looking for. Let me go through it with my team and get back to you with some options.”
That’s it.
I have never, ever lost a client because I wouldn’t give an estimate over the phone two minutes after hearing some high-level overview about the project.
In closing, the purpose of discovery calls is to discover! It’s to gather facts for a decision-making process. It’s not to make decisions.
Do not give time or cost estimates over the phone!
And if you just can’t help yourself, don’t say things “should be easy”. Instead, try saying:
“Oh, that should be surprisingly complicated, difficult, and expensive.”
You’ll be surprised how often you’re right.