Saying No

Does this sound familiar? Your custom-software project is nearing its end. But, the client is already submitting bugs, tweaks, and changes. You’re 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, that didn’t happen, so now what?

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

So, here are steps to manage projects as they come to a close.

Regroup

Stop the madness. Take a deep breath and stop wallowing around in overwhelm. The number one cause of overwhelm is not having clear to-do lists. Without clear expectations of what to do, you operate in a world of urgency 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 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 regroup call with your client.

Clearly Communicate

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

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

Additionally, decide what is Plan B 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 to the Project

Tweaks and changes will need to hold. The only exception to this rule is if, without the changes, 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 as soon as the other users get in, there will be bugs coming in to fix. 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 major problems 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.)

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.

Saying no is 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 their solution, they’ve 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 of the Project

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

In the after-action review meeting, there is no blaming… no name-calling… no rank. Everyone has an opportunity to speak their minds and provide constructive criticism.

  1. What went right and why?
  2. What went wrong and why?
  3. When should we have communicated better?
  4. When should we have been saying no?

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

Don’t forget the pain of not saying no and not clearly communicating. Avoidance and assumptions early on lead to anger in the end. Prevent problems with a plan. Then be proactive in communicating – even if that includes saying no.

If you’d like more tips to understand what successful operations looks like for your small business, see our resource guide here.

Reader Interactions

Trackbacks

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.