Nine Destructive Project Manager Behaviours: Part 5 of 9

I’m going to preface this behaviour type with an easy-to-relate-to, very simple case study. This case study is real, and while the project was a video (and so had a producer rather than a project manager), the principles I’m about to discuss are the same, so I’ve swapped titles for simplicity.

client: I need to make a recruitment video.

project manager: No problem I’ll get right on it.

Six weeks later with no dialogue between the client or PM…

project manager: Here you go!

client: I don’t like it. It’s too…corporate. Here, change this and this and this and this and this and this and this and this and this and let’s see it again.

project manager: Okay.

editor (a smart person who was in the elevator with the client one day): What exactly are you trying to accomplish?

client: I want to show fresh grads the city and how exciting it is. I want them to feel that if they work with us they’ll be able to live like someone off of “Friends“.

editor: So you don’t want a recruitment video. You want a lifestyle video.

client: ZOMG YAH!

editor: Give me one hour.

5. The Premature Solutioner.

So what happened? Well, first of all, the PM didn’t really talk to the client. Many PMs would claim that’s unrealistic; there’s normally dialogue between the PM and the client all the time. That’s true, but here’s the catch embedded in the dialogue: the client said she wanted a “recruitment video”. She used a specific phase that resonated with the PM in a specific way, and rather than ignoring that phrase to go after higher level details, the PM pursued it to create something the client didn’t want. Because the PM developed a solution prematurely, he felt he was justified moving the project straight into execution. In other words, he jumped to conclusions.

The PM also assumed that the client was capable of articulating their wants. That assumption kills projects all the time. When a project sponsor initiates a project, they’re generally (we hope) looking not just for a monkey to follow instructions, but for an arsenal of intelligence that’s capable of looking beyond words, into the heart of the business need.

Consequences:

Premature Solutioners make others crazy. It’s not just the clients who suffer. Everyone on the project team who has done any work on a solution that is inappropriate has to claw everything back and try to build a new solution based on whatever Frankenstein parts are left. The work has already been paid for, and now must be paid again. It doesn’t matter what type of contract exists… somebody, somewhere is paying for the rework.

Dysfunction Junction

When a project team develops improper solutions, the resulting wasted expenditures inevitably turn to finger pointing. “You gave me bad requirements.” “No, you weren’t listening to what I wanted.” My response in these situations (when I have the luxury of being an outside observer) is, “stop, Doublemint Twins, you’re both right! Now fix it! /imperious glower”

In the face of the “he said / she said” argument over who’s at fault, I will invariably side with the sponsor (unless there was deliberate deception but that’s a different problem). The sponsor has approached the PM to build a new product or service. That doesn’t mean that the sponsor understands the nature of the work about to be undertaken, only that the work is relevant to the sponsor in some way. As such the sponsor will use language that makes sense to them, but may not make sense in the context of the project. I firmly believe it’s the PMs job to uncover the truth before work begins, and only then build a solution around the problems he or she discovers.

I’ve rated Premature Solutioners as Serious, because rework is a budget killer. You’ve paid for work once, that work was no good, so now you have to pay for it again. If that happens too often on a project, the costs will soar out of control. The project will either be very late, or truckloads of scope will have to be mercilessly ripped out. Project quality can’t stand up to that kind of decimation.

Prevention:

The extant behaviour here is an impulsive tendency to jump to conclusions. In the case study I’ve used at the top, I’ve chosen a really fundamental example that may have been caught at the charter stage (no, the producer in question didn’t make one…d’oh). We don’t need a high level scope statement to keep us from jumping to conclusions, though. When a staff member comes to us with a problem in the cafeteria, or finance brings us a problem after a meeting…there are countless points during the course of our projects that a PM who tends towards this kind of behaviour could derail their project. It’s true that a PM needs to be able to envision and articulate solutions quickly, but the solutions need to be right.

Premature Solutioners need to avoid the temptation to run with the first idea that jumps into their heads, and they need to ask lots of questions and probe for problems that lie beneath the language they hear. The following is a table of resources that may help with both active listening and maintaining objectivity that you may find useful refreshers on how to avoid this very dangerous habit.

Resources on Maintaining Objectivity	Resources on Active Listening
The Ladder of Inference Individuals Cannot Avoid Jumping to Conclusions How to Avoid Jumping to Conclusions How to Be Objective – American Scientist	Active Listening Skills Active Listening: A man’s silence is wonderful to listen to. Active Listening: Hear What People Are Really Saying 10 Tips to Effective and Active Listening Skills

Up next: The Terrier

Related articles by Zemanta

• Achievements System for Projects? (edge.papercutpm.com)
• eXtreme Project Management. Both Brilliant and Dangerous. (edge.papercutpm.com)
• Garbage In, Garbage Out. Haven’t We Learned That Yet? (edge.papercutpm.com)
• Project Management Training Brochure Release : 1.01/0408 (slideshare.net)
• How to Create an Effective Project Management Process (businesspundit.com)