Learn how to get just enough IT insight on your project stakeholder team.
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.