- Guerrilla Project Management
- Kenneth T. Hanley
- 729字
- 2022-09-02 18:11:28
CHAPTER 2 A NEED TO KNOW WHY
When dealing with people, remember you are not dealing with creatures of logic, but with creatures of emotion, creatures bristling with prejudice and motivated by pride and vanity.
—Dale Carnegie
As far as I can tell, there are two inviolable truths about people and projects:
1.There’s a reason behind everything that everyone does on, to, for, with, or against a project. No one does anything without a reason.
2.In a stakeholder’s mind, no matter what they are doing on, to, for, with, or against a project, it makes complete sense to them.
The key skill for a PM then, is figuring out: where are these project stakeholders coming from, and most important, why are they acting the way they are? (“Because he’s an idiot!” is never the right answer.) The thinking PM asks “Why?” all the time, guided by two principles:
1.He never allows himself to think that someone is doing something “just because he’s stupid.”
2.He never treats anyone as an “enemy” of the project but, rather, as a potential ally he just hasn’t figured out yet.
This approach makes a broad assumption about the intent of the project stakeholder community: It’s very rare that a stakeholder is really out to kill a project, even if it feels that way sometimes.
Asking “Why?”—over and over and over again—should take the PM back to root causes. Without an understanding of the root causes of a stakeholder’s behavior and their attitude toward a project, the PM probably won’t be able to put an effective stakeholder management plan in place.
Getting to Root Causes: The Fishbone Diagram
The fishbone diagram, also known as an Ishikawa diagram or a cause-and-effect diagram, came out of the Japanese quality management push in the 1960s. Although it’s more often used to analyze the root cause of product defects, it’s also very helpful to PMs in understanding their stakeholders.
Wikipedia offers this example of root cause thinking
:
“My car won’t start”.
“Why?”
“Because the battery’s dead.”
“Why?”
“Because the alternator isn’t working.”
“Why?”
“Because the alternator belt is broken.”
“Why?”
“Because the belt was well beyond its service life—it’s never been replaced.”
“Why?”
“Because I guess I haven’t been maintaining my car according to the recommended service schedule.”
And that’s the root cause (although you could keep going to figure out why he isn’t maintaining his car, but you get the idea). So how would a root-cause analysis work with a difficult project stakeholder?
Project Business Lead (PBL): “We’ve invited Bob Miller to the inventory management process redesign sessions a number of times, but he just isn’t attending, and that’s a problem—Bob’s got a lot of influence with the VP of manufacturing.”
PM: “Why do we think Bob’s not participating?”
PBL: “He says that the way we’re tackling process optimization is stupid.”
PM: “Stupid how?”
PBL: “He says that we haven’t fully considered how things work in his plant.”
PM: “Why does he think that?”
PBL: “Because we don’t have his warehouse manager on the inventory management redesign team.”
PM: “Why not?”
PBL: “Because the COO—our sponsor—chose a warehouse manager from another plant.”
PM: “So?”
PBL: “So Bob’s warehouse manager had put his name in the hat for that role on the team.”
PM: “And …?”
PBL: “And Bob and his guys are convinced that the next set of promotions will only go to people who are on the project team.”
Now we’re getting somewhere. Now we’re at the root cause, and we have information the PM can act on—something he can take up with the sponsor.