Clear Communication: Saying No

By Susan Fennema

Your custom-software project is nearing its end. But, the client is already submitting bugs, tweaks, and flat-out changes. You are out of time and out of resources, but the client wants MOAR. Saying no and setting clear expectations along the way could have helped you. But, now what?

Saying no at the end seems disingenuous. It can create fear, uncertainty, and anger. But, at some point, avoiding the hard conversations will result in even more of those bad feelings.  The key is not to necessarily out and out say no. It’s to set expectations, and then to use clear communication with consequences.

So, here are some steps to manage things at the crazy end:

Regroup

Stop the madness. Take a deep breath and stop wallowing around in overwhelm. I have managed over 50 project managers in my career. The number one cause of overwhelm is not having clean, clear to-do lists. Without them, you operate in a world of urgent and emergency instead of calm and planned. You don’t know what is left to finish or the status of what’s in progress.

Set aside two hours to evaluate the situation. Decide what must happen for the project to be viable to go live. During this process, you might have to practice saying no to things that you know your client might push back on. Document that information and schedule a call with your client.

Clearly Communicate

You should have been explaining to the client throughout the process what to expect, especially at the end. (If you want some tips to share with your clients, read my post on The Scarpetta Group’s website, Navigating a Custom Development Project.) If you clearly communicated on that topic, remind the client. If you didn’t, explaining will need to be part of the regroup call.

The goal is to leave that call having a very clear, distinct path to the finish. Specifically, what is necessary to go live? That path might require saying no to some things, but it will almost always require acknowledging that you will have some known bugs at go live. Give your client some good language to clearly communicate those bugs to their users, along with a plan of when they will be fixed.

Additionally, decide what your Plan B is with your client. Think…. If this doesn’t go live on time, what will the users do instead? Is there something to revert back to? Is there a different tool or resource to use in the interim?

Address Changes

Tweaks and changes will need to hold. The only exception to this rule is if, without the change, the solution is useless to a large portion of the users. If that scenario occurs, you should be able to buy more time to make the modification.

Remember that no matter what, as soon as the other users get in, you will have bugs coming in. So, be sure to set that expectation for your client as well. Make sure he knows this is normal. And, be sure that you have people available to fix anything that causes a work stoppage on Day 1.

If the client changes the plan after you have agreed to it, then you have to communicate clearly that it will require more time and resources. (By the way, resources can be money, people, servers, testers, or any combination thereof.) And, that’s the gist of saying no. It’s not actually saying the word. It’s explaining the consequences and getting the client to start saying no.

Ship It

Nothing is perfect. Don’t try to make it that way – especially at first. Until a client is using his solution, he has received absolutely no value from your services. If you have to roll it out slowly, build that into the plan. But, practice saying no to perfection. Document what needs to change and ship it… on time. And, then fix it.

After Action Review

The military uses the term After Action Review. You might have also heard it called a Post Mortem. Whatever the term used, the goal is to schedule a meeting to review the project. You can have the meeting with your client – and you should do so if your relationship allows for it.

There is no blaming… no name calling… no rank in the meeting. Everyone has an opportunity to speak their minds and provide constructive criticism. What went right? What went wrong? When should we have communicated better? When should we have been saying no?

Document that meeting and include any lessons learned in your process for the next project. (Remember, processes are built to evolve.)

And, don’t forget the pain of not saying no and not clearly communicating. Avoidance and assumptions early on lead to anger at the end.