Have you ever thought you were doing exactly what your customer wanted and he still wasn't happy? Mike, a software manager, had an experience like that. At the start of a project, his customer, Kyle, requested a weekly written status report. Fine, no problem, thought Mike. But as the project progressed, Mike noticed his status reports piling up in Kyle's inbox. And Kyle frequently asked questions about matters that Mike had covered in the status reports. Hmmm.
After the project concluded (on time, within budget, and to spec, and you know how rare that is), Kyle filled out a customer satisfaction questionnaire—and complained that he never knew the status of the project! Mike was mighty miffed.
What might Mike have done differently to avoid this outcome? And what might you do to avoid a similar situation? The following suggestions may help.
1. Guard against conflicting interpretations.
Mike was so familiar with status reports that it never occurred to him to clarify what Kyle meant when he asked for one. But in absolute certainty lies danger. Though the words we use sound like everyday English, we—any two of us—speak different languages. Kyle's idea of a status report may have been very different from Mike’s.
Now, in theory, you can avoid conflicting interpretations by clarifying every word either of you uses ("And by 'the,' I mean..."). A more practical approach would be to become conscientious about the potential for differing interpretations. If you're not positive you understand what customers or others mean, ask clarifying questions.
For example, Mike might have asked:
2. Don't jump to conclusions.
Well, of course Kyle never knew the status of the project; he never read the reports! At least, that was Mike's conclusion. But maybe Kyle asked all those questions because he couldn't understand the reports, or because he found them too detailed, or because he was allergic to the cryptic little symbols he saw in them. And perhaps he left the status reports in his in-box because that's where he kept important information...or because he hated filing? (I keep most everything in my in-box. Doesn't everybody?)
It's so easy to leap to conclusions, and such leaping often takes you in precisely the wrong direction. Leap not. Accept what you observe as data, and seek other information to support you in forming conclusions.
3. Gather feedback early and often.
Post-project feedback that reveals surprises is evidence of a feedback process that failed. Mike seemed unaware that feedback gathering is a process, not an isolated event. By holding periodic conversations with Kyle about what was working and what wasn't, he could have identified and resolved Kyle’s concern early in the project.
To provide a context for feedback gathering, Mike might have explained to Kyle that in any project, concerns surface on both sides, and they can trap those concerns by periodically meeting and discussing them. By setting the stage in this way, they would have laid the foundation for feedback as a routine part of their working relationship. Discussing feedback gathering right up front is an example of communicating about how you're going to communicate and is a key contributor to successful projects.
Of course, every time Kyle asked a question about a matter that had already been addressed in the status report, he was giving Mike feedback about his state of mind. Mike wasn't astute enough to recognize that everything a customer says is a form of feedback
4. Examine your rules for commenting.
As kids, we translated our caregivers' behavior and advice into rules about what's appropriate to say and what's not. Things like "Say please and thank you." And "Don’t ask so many questions." We internalized some of these rules for commenting, and retained them into adulthood. And at times, some of them interfere with our ability to do our job effectively.
Kyle and Mike may both have been influenced by rules for commenting—Kyle's rules keeping him from telling Mike that he didn’t understand the reports, and Mike’s rules keeping him from asking about the reports in Kyle's in-box. In addition, both may have been held hostage to a prevalent rule that stifles open and honest discussion: "If you can't say something nice, don't say anything at all."
Reflecting on your rules for commenting is a worthwhile exercise, one that you can do privately for your personal rules and as a team for your organizational rules. By developing awareness of your rules and acknowledging their impact, you can begin to choose when to honor them and when to set them aside.
5. Conduct congruent questioning.
Let’s face it: there are better ways and worse ways to ask questions if you like having successful projects. Tempting though it might have been, Mike was wise not to ask Kyle "you're a-jerk" questions such as, "So how come you're not reading the status reports?" or "Whatsamatter, don'tcha get it?" He could, however, have asked some non-blaming, face-saving questions, such as:
6. Find out what's important to your customers.
The software development process typically focuses on project expectations but not process expectations. Process expectations concern how people want to be treated, such as not being kept waiting indefinitely, having calls returned in a reasonable amount of time, being kept informed about important matters, being listened to, and being treated with respect. One of Kyle's process expectations was knowing the status of the project, but Mike may not have been aware of the importance of paying attention to these expectations.
You can get an idea of your customers' process expectations by asking questions early in the project such as:
Ask the right questions and ask the questions right, and you'll avoid having an experience like Mike's. Any questions?