PM Best Practices – Dealing with customers and clients

Yesterday I was talking with a friend—actually I was only listening as she ranted about her experience with an insurance company after a minor car accident. To put it mildly, she was angry. She was spitting nails and plotting cyber-revenge via Twitter and Facebook. As she discussed how the insurance company made her feel and why, I wondered—to myself since I could not get in more than a sympathetic “um-hmm”—if there was any wisdom to be gained from her experience for project managers  dealing with customers or clients.

I think there is.

Here is a summary of her complaints:

  • The claims people were paper-pushers. They only wanted to fill out forms—they had no interest in what happened unless it fit a blank on their form.
  • It took forever to get through the automated phone system to a real person. My time is valuable, too.
  • They acted as if I was stupid or I had done something wrong.
  • Every action was for their convenience and my inconvenience.
  • No matter the evidence, they took way too long to accept responsibility.
  • They did not care that I was without a vehicle because of their insured’s mistake.
  • Their attitude was “it was my problem” and if I did not like the way they were handling it, I could sue them.

Take-aways for project managers

  • Be available. As project manager, you personally cannot always be available. But, it is important to have a person designated to answer calls during business hours and a way to reach someone after-hours.  “Leave a message and we’ll get back to you” is not enough.
  • Listen first. When a customer or a client is having a problem, they want and need your understanding of the impact on their business. Clients may not tell you in tech-savvy words what is wrong. They may be angry or frustrated. You do not improve the situation by cutting off their story and trying to get them to rationally describe the problem.
  • Do not blame the client for the problem. It’s true that the client may have done something wrong, but pointing that out will only lead to more anger and defensiveness.
  • Apologize. Even if you have done nothing wrong, you can respond sympathetically to the client’s situation. “I am sorry you are having this problem.”
  • Confirm that you will solve the problem. How you will solve the problem and when are details. But you should first allay their fears and assure them that the problem will be solved.
  • Give them a timeline. People are less anxious and angry when they know what to expect. Be realistic about the steps you can take and when you will take them.
  • Do what you promise.
  • Give the client or customer feedback along the way. Contact the client by phone with updates on your actions and the status of the problem solving. Be proactive; do not wait for them to call you.
  • Thank the client. Let them know you appreciate their business.

If you have had success in dealing with upset clients, share your tips and tricks in the comments section.



Why doesn’t anyone listen to the customer?

The tired cliché about the customer always being right does not always sit well with IT professionals, software developers, or even project managers. In private meetings, I have heard many contentious thoughts expressed:

“The customer does not know what he wants.”

“The customer does not understand what he’s asking.”

“The client is stupid.”

“This client is a flake.”

Wow! What’s going on here? Part of the explanation for this “failure to communicate” probably stems from the way that requirements are often generated – especially in projects. The customer begins with a problem, a need, or an itch to be scratched by a new software solution. He presents his challenge to—usually— marketing or business development professionals who assure him that XYZ Company can make his pain go away.

I can’t help but think of the classic picture of the “Tire Swing Cartoon” that depicts the mis-communication of requirements.  How the initial requirements are created depends on who is in the room while dream and reality crash together. In all likelihood, the company bidding for the project will include project management staff in putting their bid together to provide creativity and a dose of reality—although this is often done under the duress of a fixed cost and delivery schedule.

Eventually agreement is reached on basic deliverables, schedule, and cost among these parties (with emphasis on the soon forgotten “basic” word). In the pleasure of the moment, future problems are expected to be resolved through requirements management by the PM.

The customer’s role is not over when the contract is signed, however. Most good projects call for concept demonstrations, prototypes, and beta-test versions of the software before the customer accepts delivery and the contract terms are fulfilled. It is in these feedback sessions between the users and the developers that frustrations may manifest and charges fly: why doesn’t anyone listen to the customer?

Now, don’t get me wrong, I believe the stepped process in developing, refining, and final acceptance is an essential best practice in creating software for good project management. But as the proposed solution begins to emerge and be displayed, it is typical that users will want more and want it differently. Because users are not coders or system architects, they will express their desires in ways that do not appreciate the level of effort required or the implications of what they are asking. Nor do they understand the effect on cost and schedule to comply with their requests.  Even with new software methods like Agile development, a customer is not going to understand software problems any better than they do in a traditionl project management methodology.

That’s the PM’s job. It is also the PM’s opportunity to work with the users to better understand their needs and to explain in non-technical terms how the user can get what he wants, what the changes and additions will cost, and how they impact the schedule, cost, and quality/scope (see the Project Triangle)

“Good project managers recognize that every decision has opportunity costs. If you decide to add more features, quality must drop, or the schedule must slip. If you decide to cut the schedule, features must be drop or quality must drop. There is no way around the natural tradeoffs of resources, time and quality.”  – Scott Berkun in The List of Reasons Ease of Use Doesn’t Happen (November 2002)

The PM must also be adept at translating the user’s world to the developers. He or she must listen to the customer and try to discern what is really meant by, “can I download this on-line data to a database on my notebook?”

One effective technique to gain a handle on real customer requirements is to create a “Concept of Operations” or use- scenario before a line of code is written. This user-centric step helps the customer understand what they will be getting and provides feedback to developers when the cost of change is much lower – as opposed to later in the development process. You can read Karen’s paper on “The Performance-Centered Design & Development Methodology” for more information.  Company XYZ may also find that it is very helpful in this early part of the process to call in an outside professional to facilitate the dialogue between the end-users and the developer and PM staff.

If you have any tricks or techniques that facilitate listening to the customer, please share them via your comments.  Everyone benefits from sharing good ideas.


The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management


Pushing the Edges Out ...


Just another site