Transformation Checklist #5: Governance and decision making

Destructive forces, burn rates and protecting scope

There are three mistakes you can make in defining the governance structure of your functional transformation:

1. Holding too much decision making at the top of the structure
2. Pushing decision making too far down the structure
3. Failing to provide enough clarity, so people are unsure when, where and how decisions should be taken.

This is the third in our series of articles that seek to answer the question of why so many transformation initiatives fail and, more importantly, provide practical guidance for success. This week we consider programme governance and how decisions are made.

When designing your governance structure, it helps to start by answering this list of questions:

• What decisions will need to be taken?
• Will all decisions be centralised (not advised for all but the smallest organisations), or will there be several levels of decision making?
• Who is the ultimate authority for making decisions about this transformation? Is it the same person for all decisions?
• What are the parameters that will define the size, scale and complexity of decisions that can be taken at each level of the governance structure?
• Who will make decisions at each level of the structure?
• How will problems be evaluated and decisions reached (unanimous, majority, consensus, executive, default)?
• What will be the process to escalate decisions from one level to the next?

The question of who makes decisions is often a vexed one in programmes that get into trouble. A pre-requisite for successful transformation is having clearly defined process owners and design authority.

Process owners are named individuals who are accountable for the efficiency and effectiveness of a defined set of processes. They need to be empowered to make decisions about the design of your future processes and supporting technology, in accordance with your agreed design principles, to deliver the strategic objectives and ultimately your vision.

In multi-national or global environments, the structure of country, regional and global process ownership is essential to making good quality decisions quickly. Clarity on the processes in scope for each of the process owners is essential to avoid confusion and conflict further down the line.

Not all decisions have obvious solutions and sometimes competing priorities need to be balanced and judgement calls taken. Process owners deal with these challenges within the processes in their scope, but there will inevitably be tension between the needs of different processes owned by different process owners. Resolving this tension is where your design authority comes in.

Your design authority should be a small group of people (5 to 8 ideally) drawn from your Finance, HR and Procurement Leadership Teams, IT and ‘Business Operations’. Their purpose is to resolve any conflicts and make decisions that deliver the best possible outcome after considering the competing priorities and objectives. Any decisions or issues that cannot be resolved within the design authority should be escalated to the executive steering committee. These escalations should be rare, exceptional events.

Effective governance is essential to avoid the most destructive forces in any project or programme – indecision, delay, reversal and rework. The old adage that time is money was never more true than on transformation programmes with implementation of new technology within their scope. Every day of delay can be all too easily quantified by simply adding up the daily cost of software subscription fees, system integrator’s resources, contractors and people seconded onto the programme. The burn rate on Tier 1 Cloud ERP or HCM Technology projects can easily exceed £25,000 per day, more if it’s a traditional ‘on premises’ ERP implementation. Some delays can be absorbed and resources diverted onto other meaningful work, but at other times a delay awaiting a decision directly translates into a day’s cost added to the programme.

More insidious still is the cost of decisions being reversed and the subsequent rework that entails. Decisions made then reversed early in the project mean you pay twice: once to do the work, then again to redo it. Decisions reversed late on in the project or post ‘go live’ can be many times more expensive. A seemingly innocuous decision not to include contractors alongside regular employees early on in a technology project might result in a £10-20,000 saving in configuration time during the project itself. However, adding contractors post ‘go live’ could easily cost in excess of £250,000.

This can all lead to date fixation and a feeling of ‘ground rush’ as the ‘go live’ date approaches and some project teams offload scope to meet the ‘go live’ deadline. In this scenario, it’s critical that there is someone accountable (typically either the sponsor or transformation director) for ensuring that the business case and promised benefits can still be delivered before scope is ejected. A reduction in scope should always be a deliberate decision, rather than something being quietly swept under the carpet.

Next week we consider the important questions of where we’re going, what we’re delivering and how we’re going to stay on track, in our article on ‘Vision, Objectives and Design Principles’.

Can’t wait until next week? For your full 10 point Transformation Scoping Checklist click here.

This article on Programme Governance is the fifth of ten critical success factors in scoping a functional transformation programme:

• Please click here to read our first article outlining the importance of Sponsorship, Problem Definition and Preparing for Change
• Please click here to read our second article on Requirements Gathering

Read Next