Getting work done in government IT takes more people than ever before. The average employee must now collaborate with 10 or more individuals to accomplish day-to-day work. High-level cross-silo government initiatives, such as FITARA in the federal government and consolidation in state-level IT, mean that more decision makers are involved in approving IT projects and expenses.
For example, one US federal agency recently told CEB that an audit identified 121 different governance committees across their organization. Additionally, the trend of business-led IT means that IT leaders are entering projects at later phases and with less control.
Simply put, government IT teams must navigate a highly complex and growing network of stakeholders to get almost anything done. But the most common approaches to identifying and managing all these stakeholders all hail from an earlier, simpler time and don’t work too well in this new environment.
What’s Wrong with Traditional Stakeholder Management
Traditional stakeholder management often focuses on engaging the explicit decision-makers in intra- and inter-agency hierarchies. Functional teams will draw up “stakeholder maps” of who these stakeholders are and where they reside in the organization but these maps typically focus only on the operational silo of the initiative in question.
This approach was useful when the projects were completed within a traditional silo with a few people making decisions. But with more workers involved in projects, more people making decisions, more diverse funding sources, and a mandate for shared information, IT’s approach needs to be updated.
To break the focus on seniority and silos, IT leaders need to focus on stakeholders’ ability to influence others in the network. And influence, which is the capacity or power to be a motivating force on the actions, behaviors, or opinions of others, is a vital currency for IT’s success in enabling business objectives.
In today’s environment, seniority does not equal importance, and how centrally someone sits in a particular operational silo does not equal influence. Rather, some nodes in the network, by virtue of their location, connectedness, or willingness to help, are more capable of exerting influence than others.
This modified approach naturally leads to some questions for IT leaders:
How do I identify who is influential in my project?: Channels of influence in the organization run not just through hierarchies, but instead vary by the business objective. Take the time to map out potential influencers, keeping the business objective as the map’s focal point, not IT.
Criteria that affect how influential someone is include not just the stakeholder’s explicit role, but also the level of the existing relationship with IT, their perception of IT, and their receptivity to the required change. Most likely, this map will look significantly different than one that starts with an org chart.
How do I gain stakeholder support?: For stakeholder management to be efficient as well as effective, IT should exert the bulk of its efforts on the stakeholders that are both the most relevant and the most resistant.
Communications with these highly relevant resistors should emphasize calls to action, reduce the stakeholder’s engagement burden, and avoid over-communication that will do more to annoy them than inspire them to action.
Stakeholder management is certainly not a new activity. But IT’s increasingly networked environment means that improving existing stakeholder identification and engagement processes may be just what you need for government IT initiatives to succeed.