Clear Communication: Saying No

I find that so many of my clients have a hard time saying “no”, which often leads to difficulties finishing a project. I find, however, that while saying “no” sounds hard, it actually leads to an easier time working with the client and finishing the project. Do you guys have any tips/stories on times you had to tell a client “no” and it actually resulted in something great? I’m sharing some of my tips in my latest blog post:

the more I tell my PMs no, the better off the project is. Clients rarely do I have to tell no to. When I do they are on board with it and understand (90+% of the time). PMs almost never understand. Or least in my experience.


[quote=376250:@scott boss]the more I tell my PMs no, the better off the project is. Clients rarely do I have to tell no to. When I do they are on board with it and understand (90+% of the time). PMs almost never understand. Or least in my experience.


You do a great job of setting expectations then, probably starting in your sales process. That is not the norm, so kudos to you!

I say no to everything, and then “capitulate” on the things that are actually achievable :slight_smile:

Not really, but that’s what my project team thinks.

[quote=376256:@Tim Jones]I say no to everything, and then “capitulate” on the things that are actually achievable :slight_smile:

Not really, but that’s what my project team thinks.[/quote]

This forum needs a laughing “like” choice. That’s awesome @Tim Jones

I find myself telling the client, “That’s a great idea! Let’s put that into the next phase.”

PERFECT! That’s the very best way to handle it. (And you’re already building your next project with the client, so longer-term income.)

I have long ago stopped doing custom development, but you would not believe the number of end users who request modifications of commercial software.

Especially with Check Writer III+ and Check Print’R+, I regularly get people on the phone asking for new features. Or reporting bugs, but that is another story.

There are two categories of users : the ones that ask for irrealistic stuff, like that guy who wanted literally a clone of Versacheck, and others, who ask for useful features.

In both cases, I cannot say no outright, so i general, I very politely tell them the request is noted, and it may be implemented in a coming version. For the sensible requests, I make sure to take their email, in order to get them posted.

The person I have trouble saying no to is myself. I spent a considerable time last year trying to get Xojo iOS to do things it was never conceived to do, and had at one point to kill the project, and start over with XCode. If I had said no to myself in the first place, I would have saved months of aggravation and waste of time.

More generally, every time I said yes to a business decision and was not sure, I should have said No.

It is all about communication.

Of course, one important thing for me is to be as clear, precise and honest as possible, right from the first meeting, which includes contracts with clear definition of the goal, the finishing line, the time frame and the consequences for both when those are not met.

Even more important is how I communicate directly with a client. This actually does not differ from how I communicate in private, with my wife or our children, my friends and family.

First of all I try to understand the good reasons why something is asked or requested. If the client asks for more features, what is he/she trying to get fulfilled? Maybe I am asked to do something or to add something which from my experience will lead us into a disaster, but before I start arguing about the suggested strategies, I try to clarify the needs behind it and to make sure that my client is convinced that I have heard his good reasons.

Maybe I suspect that my client is worrying, because he thinks that the success of our project is crucial for his career and right now he is not convinced that the solution we are developing will be good enough. So I will express such thoughts and ask him if that could be the case, somthing like: “I see that this project is very important for you and that you really would like to lead it to success, but maybe you have some doubts right now whether our solution is powerful enough? Is it like that?”

The wording may be different of course, but you get the idea.

This process may take for a while and to whatever is said by my client, I will first try to understand his good reasons, his needs. i will try to put myself in his situation and ask back to make clear I have understood what is really worrying or moving him.

After some time we will reach a point where he remains silent and no longer responds by putting a but(t) in my face. It may not be necessary, but I still can ask then: “Sir, do you think I have understood what is important for you?”

Only after we have reached this point , then I try to make sure my client is willing to hear my own good reasons, my own needs.
(Like to finish a project in a orderly manner and make a decent living from my work and not to do unpaid work or constant night-shifts…)

If I am convinced that saying No is the best solution, I will say No and make clear that my No is actually a Yes to a successful project where the defined goals are reached within the defined timeframes. And inside, in my own thinking, I will not surrender to disaster phantasies and rather be ready to stop the project right now (without getting the final payment) than let my fears drive me into uncontrolled actions. To familiarise with a worst-case scenario, to get mentally prepared, helps me a lot to stay clear and actually to be able to say No.

Then I will demonstrate my willingness to help my client to reach his goals, for instance by showing my readiness to add new features in the frame of a new project, a follow-up.

Or in short, as Tim puts it: “That’s a great idea! Let’s put that into the next phase.”

I just will not immediately say such a thing, but first express what I have understood about the needs of my client.

EDIT: And of course, I will avoid the usage of the word “need”. My client is not needy, he is in charge …

I say no, a lot, with version 1.0 projects. Clients tend to think of new things to add very late in the process and I have to tell them, “That’s a great idea, but let’s get it out the door first so we can find out what the customers really want.” Subsequent versions don’t have the same level of scope creep.

I wear this hat to my dev meetings:

@Oliver Osswald and @Bob Keeney - good insights. Communication is definitely the key - EARLY communication. The end is always a challenge and setting those expectations early in a project can save you at the end.

@Kimball Larsen - I need your cap. Ha ha!

The most difficult “no” is when a client/customer asks for a change to an application that results in no meaningful functionality, but makes things clearer for some users. Often times, I really like the change and wish it would have been implemented in that way initially, but changing midstream (so to speak) would be confusing to users who have already adapted to the current implementation. I’ve made that mistake a couple of times only to get beat back by users who complain that “change for the sake of change” is not necessarily a good thing unless there is some functional reason for it.

You’re damned if you do and damned if you don’t. Words to live by in the programming world.

@John Fatte - that is a very common situation. Why and what are the consequences are always good things to investigate before making what seems like a quick change. Keeping that note for a future upgrade though could make the change more valuable when there is time to completely think through it.

I just said no to a lead last week. While we could have taken the work, they wanted to develop a vertical market app using FileMaker. I explained how the licensing would be an issue long-term and explained how a Xojo Web App would solve those issues. They had some FileMaker development experience and no Xojo experience, they wanted to use FileMaker so they would be comfortable.

It felt good doing the right thing by saying ‘no’. :slight_smile:

when you can say no like that, it is a good thing for all parties.

You did a service to the client, to yourself and to your future clients by saying no that early! That situation was ripe with challenges and it would have ended up being a mess. Meanwhile, you’ve left capacity for you to work with people you CAN serve in a mutually beneficial way. Really awesome!

I have two comments on the subject.

  1. Scope Creep / add-in items can easily be dealt with early on by having a really good statement of work or project charter for the project that defines what is in and out of scope as well as how the project will proceed. I have seen a lot of situations where scope items are very loosely define and can lead to misinterpretations of what is to be done / delivered.

  2. The word No. Often times, we fine our selves not wanting to say no because we worry of the impact it may have for the current project or future work. No doesn’t have to be viewed as a negative but rather a point in time to educate the audience of what the choices are and impact from these choices. I think Hal’s example above demonstrations a very well informed way of handling a customer request.

Thank you for sharing Susan… I enjoy reading your topics in how it relates to projects.

@Rich Hatfield - ??

That was easy.