Read about the types of stakeholders from outside the traditional IT organization whose participation with your project team might be the most valuable.
You can find an enormous amount of advice across the web about the need to identify C-suite sponsors for a project as it works its way through the high-level budgeting and appropriations maze. Every bit as important, at least from a project manager's perspective, is the need to establish a stakeholder's team for review of business requirements and iterative project deliverables after the project is green-lit.
There's nothing revolutionary about the idea of stakeholders being engaged in a project. In fact, several "extreme" models for development (remember those?) eschewed specs, and project documentation in general, in favor of twice-weekly meetings between developers and deeply engaged stakeholders to review iterative builds (I would not go so far as to call them deliverables) to see how the project is going.
Agile and Lean development advocates will bristle (and to some degree, justifiably) at the description above. You can spec and project manage a project to death. But I have found that, at least for projects larger than a simple scheduling app, expecting "stakeholders" to not only invest that amount of time, but to have the required attention span, is unrealistic. So, what should you expect from stakeholders on your project, and how should you recruit them?
In this post, I will discuss the types of stakeholders from outside the traditional IT organization whose participation I have found most valuable. In a future article, I will touch on additional resources from inside IT that you may want to attach to your project.
Recruiting stakeholders from outside IT
In my experience, stakeholders from outside IT (an important distinction I will get back to in a bit) are most useful in setting business goals for a project. Note that I said goals not business requirements -- goals are the actual, measurable impact a project will have on key business metrics. "The project will cut response time to customer complaints by 20 percent," "The project will cut staff hour requirements for function X by 30 percent," and so on -- the kind of stuff that is remarkably overlooked on many projects.
You need at least one mid-level manager on your stakeholder team. If the project does have a C-level sponsor, you definitely want someone from insider that sponsor's unit as a key stakeholder, both as a source of input and as a conduit back to the sponsor.
The major caveat for all stakeholder teams is: Be sure to pick (or, more likely, strongly suggest) a mid-level manager who has the reputation for pushing back on the C-level sponsor. Seriously, do a little behind-the-scenes discovery if you have to find the name of someone in the sponsoring group's organization who has the reputation for "speaking truth to power." Odds are, the "sponsorship" of the project was greased with a few unrealistic promises, or at least insufficient reality checking when cost/benefit projections got a little too rosy. That's just politics. You will need someone on the stakeholder team who can assertively communicate issues and the inevitable compromises up the food chain.
The corollary to this is, you probably don't want a C-level person on the project team. In large organizations, this is not a worry, but in medium-sized shops you may find yourself faced with a CFO who "wants to get my hands dirty" with that new order processing flow. Executives are genuinely busy people, and most of them (including finance officers) got to where they are by being big-picture thinkers. This is a good skill for initial scope, but it's bad for everything else.
Aside from the sponsoring group manager, you will want to include:
At least two stakeholders from the team that has primary operational responsibility for the new or modified system(s). This team might live under the IT umbrella depending on how your business is organized. It's best to include a second-level manager here who has responsibility for the allocating bandwidth -- that's where you will get invaluable "we just don't have time to do that" pushback.
A stakeholder from each internal client of the new system(s). This is self-explanitory.
A stakeholder from each external client of the new system(s). This assumes your business has trusted partners who connect or otherwise rely on the system in an extended business process. For conventional customers, focus groups and other feedback loops are essential, but in this scenario I am talking about a key supplier or recipient of a regular data feed. Securing this kind of participation is a little tougher than with internal stakeholders, but the external clients should be motivated by a clear benefit for themselves from the project. Otherwise, they probably aren't really clients.