F.U.D: the sources of way too many of the motivations that drive the players on your project. Yes, you can defend yourself and your project: like the swarthy man in the gangster movie says: keep your friends close and your enemies closer.
Here’s how I ‘out’ the FUDs on a project: through a formal and disciplined analysis of all the project stakeholders, and what it is they’re looking for from the project.
This type of stakeholder analysis cannot be done in isolation – the stakeholder community (or people who can speak for each stakeholder) have to be in the room when you’re doing this work.
“But that takes so much time,” they’ll say. “We’re busy people,” they’ll say.
To which you’ll reply: “Look, is this an important project or not? The organization is telling us that this is one of the most important projects we’ve ever done, but you don’t have half a day to spend with us to ensure that we clearly understand and plan to meet your expectations?”
Once you’ve “logiced” them into the room, the fun begins.
Stakeholder analysis: I didn’t say “formal” and “disciplined” lightly – I want to see:
A list of every stakeholder for the project (using a broad definition, a stakeholder is anyone and everyone, group or individual, who can affect or be affected by the outcome of the project). There are always more stakeholders out there than you think at first, and a project team ignores them at its peril. If you intend to ignore a stakeholder, that decision should be made explicitly and with full knowledge and support of the project sponsor.
Documentation on what every one of those stakeholders or stakeholder groups is expecting as a result of the project. This part can be eye opening: in all likelihood, there are expectations of your project that you didn’t anticipate, and likely expectations that you don’t have the (desire, time, money) to address. Missed expectations are going to hit you in the head later on if you don’t deal with them now. For expectations that you intend to address, go to step 3. For expectations you don’t intend to address, get the support of the project sponsor as above.
The deliverables the project has to produce to meet these expectations – Here’s where the stakeholder rubber hits the scheduling road: listing all the project deliverables that are necessary to meet the expectations of the project stakeholder community.
If you do it right, you’ll end up with a (significant) list of deliverables that explicitly address the expectations of a formally identified stakeholder community.
And then these deliverables plug right into your project schedule. Voila – the powerful connection between your stakeholder analysis and your schedule – in fact, a schedule that is primarily and explicitly driven by the expectations of the stakeholder community, rather than by technical considerations.
You’re on a roll, but you’re not finished – here’s where the fear, uncertainty and doubt part comes in:
“So tell us what you’re really looking for from the project,” you’ll ask your assembled stakeholders. Appeal to their better natures and you’ll get most of the expectations of the table.
“I expect minimal disturbance to our current processes.”
“I expect a significant reduction in my chargeback to use this system.”
“I expect to see evidence that our call handling times are dropping significantly.”
We can work with these expectations, laying out specific deliverables to meet each expectation, or taking the expectations off the table (and out of the scope of the project – always remember to document your assumptions).
Then turn to the dark side, Luke. What is it that people are worried about, uncertain of, fearful of that will result from your project? Will someone be losing position, power, influence or even his or her job as a result of the project?
Will this project make one vendor look better than another? Will this project turn up some embarrassing shortcomings in someone’s processes?
Is there anyone in the stakeholder community who (in their heart of hearts) really wants this project to fail?
Do the work that anticipates the FUD-driven expectations – if you’re brave, you’ll take them head on in your planning. Llike my mentor Dr. Francis Hartman says: “Eat your crow when its young and tender, rather than when its old and tough.”
If you’re not so brave i.e. you don’t want to show these negative or unpleasant expectations publicly, you can still defend the project team: have every stakeholder sign off on their explicit and documented expectations: “We want to ensure that we’ve captured all your expectations and that we’re planning for deliverables that explicitly address them – please sign here to confirm that we’ve captured everything you expect from the project. Any expectations that you have that don’t appear here will not be addressed by this project, and any expectations that you articulate later will be addressed by change control – hey, we love you guys, but nothin’ comes for free.”
Forgive my cynicism (it lives deep in my little black heart), but I know that if a stakeholder won’t confess to their FUD-driven expectations, at least these expectations can be explicitly excluded with their signature.
Hanley is an IS professional in Calgary. He can be reached at isguerrilla@hotmail.com.
