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.