Have you ever seen the website Clients from Hell? It’s a collection of crowd-sourced horror stories about client interactions from across the tech industry. I don’t frequent it anymore, but I have found the stories humorous in the past. To be honest, the website could just as easily be called “Self-Entitled Designers from Hell” or “A Master’s Degree in How to Be Inept At Managing Client Expectations.”
While a blog full of tropes in which two parties verbally assault one another isn’t the most helpful thing ever created, I do think it serves to highlight a reality in software product design and development: Sometimes, projects go to hell.
An All-Too Familiar Scenario
The scenario is all too familiar. As clients and makers, we start projects excited about the prospect of working together. Think about that “kick-off meeting feeling.” The butcher paper we hang on the walls gives the conference room a fresh, clean feel. The Post-its are organized by color and size in nice, neat rows. The coffee is hot, and the agenda is organized. The Sharpies are full of ink, just as our hearts are full of excitement for the prospect of starting on a new project.
Fast-forward six months to that meeting convened because the project has gone off the rails. Tufts of butcher paper are hanging from masking tape on the wall. There are so many Post-its in the trash that if you flipped over the can, its contents would preserve their Christmas tree shape. We nervously test every Sharpie in the room, looking for just one of these damned things that will make a clear mark. The coffee is old and cold, and no one knows what to expect from the meeting.
What happened? How did our project end up in hell? And more importantly: How can we get back on track?
Call the Fire Brigade
I don’t pretend to have all the answers, but there are some warning signs, problems, and solutions that I have discovered in my work as a designer and software consultant. In keeping with the “Clients From Hell” analogy, I’m going to refer to these warning signs as “Smoke,” problems as “Fire,” and solutions as “Water.” Let’s see if we can’t put out some of these infernal flames.
A Lack of Definition
SMOKE: A stakeholder or product owner starts a project without clearly defined business goals and accompanying metrics.
WATER: Don’t start spending money until you know how to define success. Sometimes, there are very clear metrics which set a finish line for a project. As software makers, we’ve traditionally looked at “Fulfilling Scope” as the finish line. At other times, the finish line is not so clear.
As makers, we need work together with stakeholders in both situations. If the finish line for a project is really well defined, we need to step up and crush features until the project is done. If the finish line is fuzzy, we need to come alongside product owners and help them think about what type of scope will meet their business goals. We shouldn’t just look to fulfill scope, but rather to create a product that will deliver real business value and return on investment. Additionally, we look for ways to measure that value and ROI. I have rarely seen a stakeholder who just wants delivery of code. They are usually looking for a way to create value and make money.
SMOKE: A stakeholder becomes overbearing and attempts to micromanage the team. This smoke is actually a signifier of…
FIRE: Your stakeholder has probably lost trust in you/and or the team.
WATER: The trust has been lost, but there are a lot of ways you can find it again. There are many variables that come into play which might inspire this behavior, such as personal insecurity, communication challenges, and disparate expectations of what the project outcome should be. But there is one specific aspect of the client/maker relationship that is usually in play in these types of situations: trust.
The first thing to do is recognize that something has gone wrong. You might say something like, “I’ve noticed that you’ve been pretty on edge in our meetings the last couple weeks. It seems like you aren’t totally satisfied with my/our performance. Is there anything you’d like to get out in the open?” More often than not, your client will have some things to share. Your client’s comments might be helpful and constructive, or they might not. That’s ok. Take note of these things because we are going to use them later.
The next thing to do is apologize. Don’t think you’re wrong? It doesn’t matter. You don’t need to believe you are wrong or even be wrong for it to be right to apologize. This isn’t just placating your client with empty apologies. Every person lives a project according to their own perspective. In your client’s world, you might be wrong.
Let’s say, in a worst-case scenario, their world is completely at odds with reality. Does it really matter? Their perspective is their perspective, and a simple apology is like building a bridge from your perspective to their perspective. When trust has been lost, the other party has a real need to hear you say that you are sorry. Apologizing is a humble, nonjudgmental and empathetic way of re-initiating trust.
The worst thing you can do in this situation is to defend your action or offer an excuse. Defending yourself de-legitimizes your client’s perspective, resulting in further loss of trust and possible anger. Offering an excuse minimizes the pain the client is feeling, which could also result in a loss of trust in your ability to empathize.
Next, let’s go back to the feedback the client shared. Use that feedback to formulate a specific plan of how you and your team will address those concerns. If the client didn’t share specific, actionable feedback, do your best to translate it into a list of concrete things that the team can do and measure over time. Track these things so that specific and measurable change can be shown to the client.
None of these things are a magic wand that will restore trust from a client. But they are all positive and proactive steps that should build trust in most situations.
FIRE: Maker team doesn’t deliver regularly or on time.
WATER: There are a lot of reasons this can happen, and they’ve been well-chronicled elsewhere on this blog. Here are a few of my favorites:
Agile + Scrum = More Effective Iteration Meetings
Transparent Project Management with Burn Up Charts
Why is Your Team Falling Behind? Ask ‘The Penny Game’
Over and above these wise words, I’d suggest first focusing on inefficiencies in your process before trying to assign blame to people. Additionally, take time to see the project from the client’s point of view. Practice the same empathy you practice with users with your client. They are probably paying a not-small amount of their allotted budget for your time and expertise. How can you drive home that you are delivering value on that budget?
Out-Of-Touch Business Model
SMOKE: As the maker team becomes more acquainted with a client’s hypothetical user base, the client’s business model is found to be wanting.
WATER: Before this turns into a roaring brushfire, throw some water on it by communicating your concerns early and often. Start by communicating amongst your team and, if necessary, with your managers. If there is consensus that this a risk to the project, bring it up with your client as soon as possible. Characterizing their business idea as “bad” isn’t what you want to do here. Show them your research findings and give them time to draw their own conclusions.
No One is from Hell
These are common scenarios that have come up many times during my career. They aren’t necessarily bad. The reality is that clients aren’t bad, designers aren’t (all) jerks, and we all make mistakes. These things happen when flawed and complex people work together. The sooner we can get beyond objectifying others as demons from hell and get back to focusing on delivering value through our work, the happier we will all be in designing, developing, and business-ing.
I’m curious to hear what challenges you’ve experienced when a project has gone to hell. What different strategies have you employed to put out the fire and restore relationships?