Fifty shades of governance

This talk, which followed my article ‘Bringing sexy back to governance‘, was presented at the 2012 BA Development Day conference, and covers what we mean by governance, what the fifty shades are, and what we can all do about it – in short, this is a call to action for lean governance.

Background

I worked on many early agile projects and introduced agile practices at several organisations during the ‘90s and ’00s, and we always struggled against serial stage-gate governance processes. I had a moment of inspiration to turn the problem on its head, to throw out unproductive processes, and focus on key decisions; to have leadership trust the professionals to do their jobs without specifying every step they have to take; to overcome this obsession with process, freeing projects from the maze of endless reviews and gate meetings; and to enable stakeholders to review a project at any point in the delivery cycle.

Do we ‘need’ governance?

Governance is the term we use to describe the act of running our countries, organisations, and projects to a set of policies and processes that we have agreed … and holding ourselves accountable to behaving that way … but, do we need these?

Without a framework within which people know how to act there will be chaos, savagery, and mutiny (try reading ‘Lord of the Flies’ by William Golding).

In terms of projects, governance seeks to balance the delegation of authority with the assurance that it is being wielded wisely.

This is important, to ensure that we don’t end up with projects with a high burn rate that don’t deliver; to ensure that we select the right projects to run in the first place; to allocate scarce resources between projects; and even to stop one project in favour of another.

If we accept that some commonly agreed governance is necessary; what makes it ineffective?

What can go wrong?

The ‘shades’ mentioned in the title slyly refer to ‘visitors from the underworld’ in ancient mythology (ghosts or spirits, to you and me), and in this context, I used this to mean the problems that beset our projects, sucking the life and value out of them. This covers problem areas like bad scope definition and scope creep; too much or too little monitoring and authorisation; how we approve and intervene in projects; and the culture and capability of our people.

Many of us could draw up a long list of such problems, and we created such a list on the whiteboard at the conference. In preparing for the conference, I am indebted to Jed Simms, of Totally Optimized Projects, and his paper on ‘The TOP 26 Dimensions of Project Governance‘ in which he lists 95 problems that destroy value on projects. I compared that to my list and drew up a list of 50 common problems, solely to meet the constraints and artifice of my chosen title. This worked as an exercise in marketing; using the phrase ’50 shades’ in the session’s title guaranteed high attendance.

While governance should be about ensuring that money and time is being spent on the right things at the right time, through behaviours of aggravated risk aversion, governance processes have become more about ‘covering your arse’ than about making strong decisions to invest well in the right things.

Unchecked, governance processes can grow and become an anchor that slows us down until we are uncompetitive, rather than a simple way of confirming what we want to do and when. Designed and operated well, lean governance can act as the grease in the wheels of a well-operating business, providing a balance of delegated authority and oversight.

What can we do about it?

As I have worked on projects, as well as consulting on governance, new product development (NPD), and system development lifecycle (SDLC) frameworks across a number of organisations, I have been able to develop, trial, and prove a lean governance approach

Our experience of lean and agile practices has shown us the importance of eliminating waste, improving flow, and reducing burden. By applying these insights, we can approach a leaner form of governance.

Lean governance is about making sound decisions, trusting people to do what they said, and agreeing when they will check back on progress. It strips change governance back to the bones, and focuses on the following six questions, when we are faced with a decision about investing in an idea:

• Do we want to do it (i.e., is it desirable)?
• How well can we deliver it (i.e., is it feasible)?
• Having delivered it, how well can we operate it, what impact will it have, will it be profitable (i.e., is it viable)?
• How will we resource or fund it?
• Will we be able to complete it in a timeline that makes it worthwhile?
• Given everything else that’s going on, does it make sense to do it now (i.e. prioritisation)?

Getting the idea’s owner to pitch it to a decision-making body, we can seek to answer these questions in a single brief session. To make this possible, those making the decision need oversight of all potential changes and those currently in-flight (i.e., the portfolio).

As well as selecting the right things on which to work, governance should also be about intervention when required – whether bringing something back to its scope; pausing it because the resources are needed urgently on something with a higher priority; or cancelling it completely because it no longer makes sense (i.e., it subsequently fails some of those six questions). This should be considered irrespective of which stage a project has reached.

Traditionally, however, after ideas have been approved as projects, there is very little governance oversight until the pre-launch decision. Most projects, however, have some form of regular stakeholder review: on projects following agile practices these would be at the end of each sprint, while on waterfall projects there are normally regular project management reviews. Whichever form these take, they should be asking the same set of questions as above.

My strong recommendation is that these reviews should be held in the same session as new ideas being considered, so that interventions can be timed right and prioritisation can be based on the latest live information. One of my clients recently referred this as a ‘super-scrum’ meeting (i.e., higher than a scrum of scrums); that works for me.

As you will see from the presentation itself, the way I illustrated this led to the appearance of an Argyle pattern, and hence I derived the acronym ARGYLE for the six questions. It’s a stretch to make that fit, so that won’t necessarily continue as a name.