Jan 28, 2010
3 comments
“That’s Not What I Wanted!”
A client came to us asking why he never got what he wanted from his project team.
Here’s The Replay of every project he requested.
- Before a project began he would carefully explain the deliverable to the project manager. He would go into great details on all the intricacies that he’d worked out from months of thinking about the project.
- The project manager would take notes and send him a specification detailing the whole project.
- The client would think about the project some more then give the pm the green light to go ahead.
- The project manager would set-up a schedule and deliver on time.
- The client would take one look at the final product and inevitably be disappointed. Then frustrated. Then downright angry.
- “That’s not what I wanted!” he would exclaim. Every time. Months of thinking about the new deliverable wasted. All his plans for using it, gone.
Needless to say, he was frustrated.
The Investigation
I went in and investigated. The process sounded alright. No glaring holes in a typical waterfall approach.
The client had a well-defined goal. The project manager was listening and delivered on time. So that’s not where the break down was.
I could recommend that the client check in every once in a while to see the actual deliverables themselves while they’re being produced. But I know he’s not that kind of manager. Besides, it wasn’t the details that were off in the final product. It was the whole thing.
I started asking the client different, seemingly obvious questions. Then, I found my answer.
“Did you read the specification the project manager sent?”
“No,” was the answer. And that was the answer.
He said it was a big, detailed document that looked thorough enough.
Gauging by the weight of the spec he was sure the project manager had the right idea.
“Besides,” he continued, “I explained it well enough for anyone to understand what I was talking about.”
In his mind, the idea was so clear and well formed that with a careful explanation it should’ve be obvious. The problem was that it was only clear in his head. He’d been the one living with it for months. He’d been the one who saw every detail. But someone it didn’t translate. A critical component of the communication in the requirements gathering phase was missing.
Communication is more than getting out everything you want to say about something (which is what he did). Communication is about making sure the other person understands.
The Core of the Problem
To come up with a solution we needed to get to the core of the problem. Knowing the people involved, the solution wasn’t simply to tell him to read the spec. It would never happen. He needed a solution where he could get what he wanted but without having him
a) do something he’ll never do or
b) change the way projects are done (e.g. adopting agile or requiring more interaction with the project team).
The core of the issue was that the specification was the wrong tool for the project manager and the client to use for their communications.
In general, a specification is the right tool for the project manager to use with his team. The project team needs a detailed blue-print. It also helps the project manager m think through the specific requirements of the project.
But it is the wrong tool to use with the client, particularly this one.
The Answer
I recommended that the project manager give the client a bullet point list of the general features. Keep it to one page whenever possible. This could even be a milestone view of the project schedule with all the sub-tasks rolled up.
If it’s too general, the client will ask questions. And it’s exactly the questions that you want to encourage. Sparking communication is one of the main goals of this approach.
A bullet-point spec is easily digested and easily scanned. It keeps the client engaged. It makes the project manager look like an efficient problem solver and good communicator. Whereas a big specification document can create the impression in the client’s mind that the project manager needs 30 pages to say what the client can envision clearly in a single image or a short conversation.
They tried it. It worked.
It didn’t happen overnight. But, it did work.
Moving to a bullet-point specification set-up a process of iterative conversations that resulted in the client and project manager connecting better and connecting more often.
This resulted in the client getting more of what he wanted, every time.
The requirements phase became a valuable, two-way conversation, rather than a hand-off of responsibility which left the client hoping he’d get what he wanted.
