Over the past few weeks, I've looked a number of the ways that I've seen IT governance initiatives fail, in particular when they deal with Enterprise Architecture. Failings such as insufficient stakeholder management, lack of a communication plan, failing to line up some allies and unclear review criteria can all work to neuter the rollout of governance initiatives. In this final post, I'm going to look at another way that an organization can inadvertently torpedo such an initiative – through having ‘woolly’ principles for governance.
Before going any further, it would be useful to clarify exactly what we mean by a ‘principle’ in this context. TOGAF differentiates between two types:
Enterprise principles provide a basis for decision-making throughout an enterprise, and inform how the organization sets about fulfilling its mission. Such principles are commonly found as a means of harmonizing decision-making across an organization. In particular, they are a key element in a successful architecture governance strategy.
Architecture principles are a set of principles that relate to architecture work. They reflect a level of consensus across the enterprise, and embody the spirit and thinking of existing enterprise principles. Architecture principles govern the architecture process, affecting the development, maintenance, and use of the enterprise architecture.
In general then, principles are an inherent part of governance – they are necessary to provide guidelines to the decisions that must be made as part of any governance situation. Unfortunately, it's not enough to just have principles – they must be actionable to be able to provide guidance, and this is where having principles that are ‘woolly’ comes to end up crippling their use in supporting governance.
So what makes a principle ‘woolly’? A woolly principle is one that can't ever be wrong; a lovely idea that is vague enough that no-one could ever dispute but which for that very reason isn't something that's usable to help in forming a decision point.
For example, I once saw an architectural principle that stated “projects must deliver real value to the enterprise”. Now, I'm not going to argue with that as an idea, but is that saying that previously the organization knowingly undertook projects that it didn't expect would deliver real value to the enterprise? I would certainly hope not. The problem is, how can you prove that a project fails this, given that every organization that I've seen includes some level of business case or business justification before it even gets to the governance stage?
For another example, how about the principle “projects should use industry standard tools and technologies”. Again, not something that I'm going to dispute, but unless the organization plans to maintain an official list of tools and technologies, any debate on compliance risks being a case of “yes it is!”, “no it isn't!”
I can't help suspecting that often, when you see principles like this they've been added to pad the number of principles in order to make the overall set look more substantive. But unfortunately this is a counter-productive thing to do, because the woolier principles end up diluting the impact of the better ones. In such a case, less is definitely more. Woolly principles diminish the credibility of any program that they're part of.