We’ve already looked at a couple of ways that you can set up an IT governance program for failure, and both of them (lack of stakeholder management, no communication plan) are particular failings that I’ve observed in the rollouts of various architectural governance initiatives. To a large extent, this is because the kind of person who rises to lead an architecture practice finds it easier to solve problems than evangelize the solutions that they identify. Alas, this failing translates into a third way that rollouts of governance programs can fail - the failure to secure allies for the changes that are being proposed or implemented.
This problem touches on stakeholder management but it’s slightly different. It’s fine (and necessary) to perform stakeholder management by identifying stakeholders, identifying the concerns of stakeholders and then engaging with stakeholders while looking to address the concerns that stakeholder or group of stakeholders might have. But this is not the same as turning them into actual supporters. An initiative needs some actual supporters in the organization, and the specific type of failure I’m describing here is the lack of this – not the failure to engage with stakeholders, but the failure to persuade any of them that the initiative will help them accomplish their own goals.
So, given that this is the case, how do I propose that you accomplish this? In the rest of this blog post, I’m going to outline three specific groups of stakeholders and the arguments that you can use.
The obvious potential ally might seem to be the department responsible for project governance and quality gating at present. However they will have a concern about adding to the requirements for project review, increasing the overall overhead of governance. So they are not as natural an ally as might be thought at first. To gain their support, you will need to find ways that whatever review criteria you wish to introduce support the existing criteria or any overall stated goals.
A more subtle ally may be the risk management group (where this group is not responsible for governance, as I have sometimes seen). While they may have the same concern with imposing overhead, and while this feels like stating the obvious, gaining the support of the risk management department is going to depend on tying the governance measure to reducing corporate-level risk.
The third potential ally is the most surprising but also the most effective in the one case I’ve seen it used – project managers themselves. Now, at first glance project managers are more likely to be skeptical than supportive of anything that makes their projects harder to get approved. The trick is in the use of governance to de-risk at a project level.
Having been in the position of having to evangelize and having watched the process from outside, and I understand the reluctance to invest time in an activity like this. Bluntly, stakeholder management, and evangelizing an idea can feel a pain in the neck and an annoying distraction from the proper work that you are charged with. But the unfortunate truth is that not doing so is a good way to make all of the other work academic, by ensuring failure. This is just a true for governance as it is for any other initiative undertaken by an architecture department.
What have you found to be the most effective technique to garner support for your initiatives?