Engage Stakeholders Early and Often — Project Success Tips from Project Failure Blog

I’m commenting on the project success checklist at Michael Krigsman’s Project Failure Blog.. My comments are scattered among his notes (excerpted below). I’d love to hear your comments on the details behind some of these factors as we go …

2. Engage stakeholders early and often — Enterprise IT projects usually involve three groups : the IT department, business and financial stakeholders, and end-users. While the project is being planned, ensure that:

My first comment is that order in checklists is everything, and I’d switch the order. Also, we’ve found that stakeholder and communication management practices shorten risk event duration and impact. One of the most successful practices was to consistently link stakeholder analysis, communications planning, and plan execution. Just another variant on the “6P” formula, applied to the “soft stuff”

The financial and business folks are convinced the project is worthwhile

This aligns strongly with the business case, so what I’ve suggested here applies. In particular, our project debrief analysis found that successful project and program managers carefully reviewed the contract with the customer and account team to gain a common understanding of all assumptions. This doesn’t sound like stakeholder management, but it is a very concrete and “natural” introduction into the stakeholders’ way of thinking.

End-users agree the project meets their needs…

Getting and staying close to the end-users can be critical, though the project or program manager must take care not to get drawn back into the fray. Many of us have development or configuration backgrounds, so sometimes our comfort zone is still code, tables, etc. I try to strike a balance between sitting in enough development or process meetings to get a feel for how the various players fit in the project, who will raise appropriate or inappropriate red flags, and who is dying to steer the project in the wrong direction.

This last point — about steer in the wrong direction — can be subtle. Users, particularly power users, sit side by side with configurers and developers. Have you ever found your key “fill-in-the-blank” resource has just spend two weeks on a new screen… for a process that isn’t in scope. Oops.

It is better if you prevent the core team from going native by regularly validating scope vs. work — via scrums, change control boards, etc.

The technical aspects are approved by IT

It has been a while, but I’ve seen this happen at small firms — the CEO/founder gets a wild hair from something he saw in an airline magazine and he/she’s off to the races. I’ve also seen when a department buys something on its own and wants to plug it in to a SOX-controlled environment…next weekend. Of course, the last case often happens when IT isn’t as plugged or as responsive as it should, say like a department ran by this guy…

Advertisements

One Response

  1. […] is to project success.   A compelling story can build strong sponsorship and sustain stakeholder commitment, even in the most challenging of circumstances (also see Michael Krigsman’s project success […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: