Governance - Strategy as a key Constraint on Delivery

I often hear the term "we need better governance of project XXX" or "they don't understand the value of good governance" from project managers, members of the PMO (Project Management Office) and the such like. While it's easy to assume that the people saying such things are striving for administrative excellence as opposed to technical excellence (thanks to Jim Highsmith for that wording), I do believe there is a role for good governance. The real question is: what the hell is governance?

Somewhat unusually for a member of a software development team, I also have experience on the board of a couple of different organisations - ranging from an alcoholic beverages company to a non-profit organisation. This makes my take on governance slightly different to the usual "project is meeting cost, time, and quality constraints".

Imagine, for a second if you are responsible to the shareholders of an organisation for performance of a company and the shareholders (or the market analysts) asked you how the company was performing. If you said "We're on track to meet cost, quality, and time constraints" you'd quite rightly be fired. It's a bad way to govern an organisation - and an equally bad way to govern projects.

Governance, for me anyway, is about defining the minimum set of constraints so that the organisation can deliver value. However, that just raises two different questions: what are constraints and what is value. Value is easy to define - it's usually money except in the non-profit sector (better called the "not for loss" sector") where it is some non-financial outcome. Value is generally pretty well defined by the organisation - and if value is not well defined then the organisations governing body knows where to focus first!

From a constraint perspective, I can think of four types of constraints:

1. Strategy, 
2. Risk Mitigation, 
3. Cost, and 
4. Timeframe. 

It might seem slightly odd that strategy is a constraint - but it makes sense (to me anyway). Richard Rumelt wrote in "good strategy bad strategy" that the kernel of a strategy has three things. First, a description of what is going on in organisations environment. Second, a set of guiding principles for the organisation to track a path through the environment. Third, a set of coherent actions the organisation will perform. Those three things provide a set of constraints that govern what the organisation will do without defining how the organisation will do it.

Even Ross, Weill, and Robertson's architecture for governing technology can be considered a set of constraints on how we integrate data and standardise processes as we implement new business systems.

Anyway, once an organisation has clearly defined the constraints on performance then governance becomes a straightforward exercise (but not easy). We just need to keep asking these questions:

1. Are we getting the right information to determine if the organisation is adhering to the constraints?
2. Is the organisation adhering to the constraints - and why not?
3. Are the constraints still valid?

It's also worth repeating Jim Highsmith's words here: we prefer delivering value over meeting constraints. If we are not delivering value then we should not be in business (well, we won't be in business for much longer anyway). If we have to break constraints along the way then that is a worthy conversation with the board (or the project steering committee) as to the validity of the constraints - or the validity of the business model.