In my last article, I discussed the types of project stakeholders from outside the IT organization that I have found most useful in
setting goals and driving a project forward. These folks can come from the
business division sponsoring the project, a key partner, or even an external
client that relies heavily on the system being impacted by the project.

Folks from inside the IT organization also have a
stake in ensuring a project comes in on deadline and more-or-less accomplishes
its stated purpose. In this article, I’ll discuss the mix of roles from inside tech
that you should shoot for in building a stakeholders team, and what you can
expect them to contribute along the way.

A minor caveat

By and large, I have found that
it is best to err on the side of economy when developing the IT stakeholders group. Remember, the main purpose of stakeholders is to help set the business
goals and overall parameters of the project, and then to review iterative
deliverables to make sure those goals are being made.

It’s important to get feedback from the various IT
disciplines at this stage, but you don’t want your stakeholders
bogging down the business requirements process by haggling over coding models, etc. That can
come later deep inside the project team, which is not necessarily (and often,
best not) a direct reflection of the stakeholders.

Get IT insight on your stakeholders team

Here are four basic models for IT folks
you want in your stakeholders group.

1: The manager of the
development team that will handle most of the coding on the project. Notice that I
did not suggest a developer be involved at this stage. You want
someone who ultimately does have some skin in the game, but who will not
immediately leap to specifics of the build. That comes later.

2: Someone from infrastructure
/ networking. This seems like a no-brainer, but I have seen this key
component overlooked entirely, or (even worse) assumed to be something the
developer can just handle in the requirements phase. No, they can’t. Hardware
and throughput requirements should be the most solid component of your
requirements document, so get the needed input upfront.

3: A ground-zero member
of the team(s) that will have primary support responsibility for the system.
Nobody has better insight into how something really ought to work than the
folks who are charged with fixing it when the thing breaks. In addition to
technical issues, support teams typically also have unpleasant (and therefore,
indelible) skinny on how users tend to bungle systems. While your business-side
operators will have valuable aspirational input about how great it would be if
a system worked a certain way, support will provide sage warnings about
fault-checking and other user-proofing you need to include in the biz rec for a
major system overhaul.

4: An engineer who will
NOT be involved hands-on with the project. IT types tend to rathole,
either in agreement with each other or when they want to squabble over code
(see warning above). I have always found that perspective from an engineer that
won’t be building out the ultimate solution is a great asset in the scope /
requirement phase. The level of detachment that comes from knowing that they
won’t have to write the thing incites these folks to think a little more
creatively, it seems. But they are still engineers, so their ideas tend to be
at least tethered to practical reality, and their opinions carry a little more
weight with tech types.