We’ve written elsewhere in this series about service architecture, building flatter organisations and a capability-based ecosystem approach both to organisations and service provision across organisations. In this article we address the governance implications for banks in general and the service-aligned ecosystem in particular.
What is decision architecture?
Decision logic is a commonly used concept, which has been widely used in technology design, and particularly interface design for customer facing applications – you encounter it every time you phone up a VCR and are invited to “key 1 for an existing order, 2 for a new order”. The concept of decision architecture has also been used in some instances, to streamline the logic for these applications, so that instead of going through a tree structure, you have more of a network with logical outcomes being anticipated based on early inputs. We apply a similar approach to designing organisational governance, by anticipating the decisions that an organisation will need to make and building these into an architecture that can be applied to an organisation’s capabilities. The advantage of doing this is that we can then design the governance decision making bodies – committees and so forth, around the decisions they need to make, rather than trying to find existing committees to make a decision or, more commonly, create a new one every time new decisions come up.
The problem with governance
Appropriate governance is critical to balancing an organisation’s ability to control outcomes with its ability to innovate and respond to changing circumstances. A rigid governance structure, with no flexibility and all decisions flowing up a hierarchy, paralyses decision making and prevents organisations from evolving. Too fluid a governance, and it’s impossible to understand who’s responsible for making decisions, which leads to no decisions being made. Most organisations fall somewhere in the middle. The problem is, that governance is often the last thing to be designed holistically, with an organisation’s outcomes in full view. There’s a good reason for this; governance bodies are closely aligned to accountability, and, as with hierarchical organisation structures, where accountability for decisions rests, the committee naturally sits. This makes sense where organisational design is closely aligned to organisational outcomes but, as we’ve discussed elsewhere, this is rarely the case.
Making decisions with courage and conviction
Organisations are usually organised around function, and decisions flow up the hierarchy to bodies composed of increasingly broader collections of function, until they reach the executive committee, and decisions are made based on information passed up the organisation through this hierarchy. The bigger the decision, the further it goes up the tree; smaller decisions are made “lower down” in the organisation, by bodies composed of a subset of functions. This creates the following characteristic outcomes:
- Big decisions take a long time to make, because they’re passed through successive governance bodies to get to the top of the tree
- Big decisions are usually made with partial, highly filtered information, that has been doctored as it moves up the tree, meaning decision makers don’t have access to relevant information that would influence the outcome
- Smaller decisions (often quite big) are often made by decision making bodies with an organisational skew based on their representation; for example, decisions about technology which impact end customers are likely to be made in the absence of any customer facing representatives
- Decisions are more likely to be made by bodies where the person requesting a particular outcome has a reporting relationship, than by bodies with specific subject matter expertise relevant to the decision
- Because decision makers are partially informed and often generalists, rather than skilled in the subject matter under review, the outcome of their decision is likely to be influenced by personal relationships and the position of the person requesting a particular outcome, rather than by the content
- Similarly, decisions can be subject to “group-think”, where even if individuals have doubts or contrary opinions, they are less confident because of the limited information available, and likely to go with the majority or the most influential person’s opinion
- Once made, decisions may be communicated in a high-level and unclear fashion, not specifying who is accountable for implementing them, resulting in slow or no response – even where the decision’s clear, without clearly communicated accountability, the implementation becomes “somebody else’s problem”
All of this leads to many wrong decisions being made, in good faith, by people who are very smart, committed to making the right decision, and fully prepared to be accountable for the outcome of that decision. Obviously, that doesn’t mean alldecisions are the wrong decision, because the decision makers do have a broad range of experience and often are the right people to be making those decisions, but in too many cases, in our experience, the above points apply.
But, I hear you argue, that’s what leaders are for! Being able to make decisions with partial information defines the job! To which, our response is yes, that’s true. That’s what we have learned as we have progressed through traditional organisations to take up leadership roles, and it’s absolutely true. In many cases, leaders have to be there on the front line, making educated guesses with courage and conviction, and taking the associated risks.
But what if they’re taking educated guesses with courage and conviction, when the information and expertise to make the right decision is freely available, within their organisation or within reach? Far from demonstrating leadership, that’s allowing bad governance to lead them astray. And too often, the structure of our organisations and our decision making bodies forces us into that bad governance and making the wrong decisions.
A question of trust
In the absence of sufficient relevant information or expertise, organisational hierarchies effectively delegate decisions down the tree, even when that decision is officially taken by the highest body. It’s what we call “Fred in the carpark” syndrome. It goes like this: Fred in the carpark wants a decision made, but it’s more expensive/impactful than his mandate allows, so he passes it to his manager. His manager reckons it must be ok because she trusts Fred, but it’s too big for her, so she passes it up the tree, and so on. Eventually it lands with Group Executive Management, and because everyone in the tree, from Fred’s boss upwards, trusts the person recommending the decision to them, the decision is made. So effectively, the executive committee has delegated the decision making to Fred, who’s probably the person with the right expertise anyway, so that’s all good.
Of course, it could be derailed if Fred’s manager, or her manager, or someone else up the tree, has another point of view. While their point of view may well be valid because of their broader viewpoint, it may just be that they don’t like Fred’s manager, because they have some vested interest or because it conflicts with something completely unrelated that they want to do instead. So Fred’s need could be derailed, but he’s unlikely to be involved in the discussion about the decision if it’s happening two or three layers up the hierarchy; Fred’s manager’s manager may be in there arguing his case, but without Fred’s direct experience and with information that’s probably been filtered already, all he really has to support his case is how much he trusts Fred’s manager, which won’t always win. Again, depending on his relationships and the status of the person with the counter-argument, Fred’s need could be dismissed for a variety of other reasons.
And whatever the outcome, all of this takes a lot of time and investment of effort from all the people throughout the hierarchy who’ve been involved in decision making. In Fred’s case, that’s a straight lineage through the management hierarchy, but as we know, that decision making usually doesn’t happen in isolation; it’s probably gone through several committees, where a number of highly-paid individuals have reviewed the material in advance, then had a bit of a discussion about Fred’s need, in committee. We’ve got some numbers around this as an example: in a global bank, there was a technology investment signoff process for any expenditure over $25,000. So any expenditure went through the same process, whether it was for $25,000 or $25,000,000. When we reviewed the process, it turned out to be a hugely expensive process to run – 55 mandatory approvers, five committees, various documents that needed to be originated, lots of negotiations. The whole process was costing around $8,000 in people time every time it was run, as well as injecting nearly two months into the process of actually buying something. And of all the requests that had been put through in a period of six months, not one had been rejected. So the cost to the organisation of signing off a $25,000 investment was about a third again of that expenditure, and more importantly, a two month delay in time to market. We weren’t able to measure the cost of chasing the process, but we’d expect this to have taken up plenty of man hours as well.
Let’s look at the reasons we use for passing the decisions up the tree:
- Somebody up the hierarchy may be better informed than Fred
- Somebody up the hierarchy will have a more holistic perspective than Fred
- Somebody up the hierarchy has more authority to spend money than Fred
- Somebody up the hierarchy has more authority to change supplier than Fred
- Somebody up the hierarchy has a cousin who owns a car park surfacing company
Only two of these are good reasons (clue: the first two). It’s absolutely true that Fred’s perspective may make him underqualified to make the decision, if the implications are beyond his sphere of visibility. But why should his position be linked to his spending ability? We take it as natural that junior people in the organisation shouldn’t be allowed to fritter away our P&L, but why not? If there’s a decision that falls within Fred’s area of expertise and he has the budget and all the information he needs to make that decision, passing it up the tree does nothing but inject cost and time into the process of making the decision.
Good governance gives decision rights to the people or bodies most suited to making the decision, and this is where decision architecture comes in. We wouldn’t want Fred to make a decision about customer strategy, or design the menus for the canteen, but he might be the perfect person to choose the surface when we’re rebuilding the car park and a budget has been allocated. What value will an executive committee bring to that decision? Of course, Fred probably won’t make that decision in isolation, but the people who need to help him are not his manager and the hierarchy; they might be materials engineers, architects, someone who understands vendor management and maybe whoever’s allocated the overall budget for the refurbishment; the people with expertise to inform the decision making process.
But don’t be preposterous, we can’t let Fred make a decision which costs us $40,000! Or can’t we? What is the difference between Fred making this decision, and Fred passing this decision up the tree? If he’s involved the right expertise in making that decision, passing it up the tree will just inject time and cost to the process. You could also argue that we shouldn’t put Fred on the spot and take the risk, by giving him the rights over such an important decision. But if Fred knows his matter, what is the risk? Take a little time to think about this; it’s a shift to how we normally make decisions.
Another argument, of course, is that Fred may be incompetent, or be in cahoots with the supplier of the car park surface. This comes back to the trust issue. If we’ve hired Fred to do the job, we have to assume he’s competent to do it. Anyone, at any level of hierarchy or pay, can be incompetent to do a particular task, or be dishonest, and it’s up to the organisation to prevent this happening, rather than restricting their ability to perform their roles.
…within formalised structure
But we’re not advocating delegating all decisions to the lowest level; this puts us at the risk of entrusting too many decisions, the wrong decisions or too high a volume of decisions to Fred. Trust works both ways and Fred needs the support of the organisation to be able to successfully implement them. Devolving too many decisions to the lower level also risks those decisions being hampered by the consensus building that typically happens at lower levels. This consensus building is driven by a lack of experience, lack of confidence or lack of mandate, and if there’s extensive consensus building going on, it’s a symptom that you are giving Fred the wrong decisions, the wrong mandate or the wrong information. If Fred’s going to make an informed and confident decision about the car park surface, he needs to know the boundaries of that decision – that it’s in the budget, for example, and criteria for quality; he needs to feel confident that his leadership will support his decision – as they would if they were representing it up the tree, in fact. And he needs to have a clear mandate, telling him who to involve (and who not to involve) to avoid the paralysis of consensus decision making.
Let’s say Fred is now asked to make some additional decisions, say about the opening hours of the car park, how frequently it’s cleaned, or who can use the car park. These decisions, which may have a much lower cost implication for the organisation than the car park surface, are not encapsulated in the same way; they may depend on a lot of different factors beyond Fred’s sphere of experience, although he needs to be consulted. In these decisions, Fred becomes a subject matter expert, but the decision rights, as they affect other individuals not in Fred’s organisational capability, need to be taken by someone with a more holistic viewpoint, probably responsible for wider building management, who in turn will need to involve relevant people in the decision making.
So at any level, without clear alignment of expertise and roles to decisions and to different types of decisions, we’re likely to be making some of the wrong decisions.
Strategic (direction setting) and Execution (operational) decisions
We hope you don’t imagine that a bank’s executive committee is regularly making decisions about car park surfacing or opening hours, but when we compare some of the decisions that bubble up to senior governance and to executive teams, they’re comparable, especially when the decision involves a lot of money; we confuse the strategic decision to spend the money with the execution decision about what to spend the money on. Of course, strategy and execution don’t just involve decisions about money; they can be about scope, technology or people, for example, and it’s sometimes difficult to clearly understand the difference between strategic and execution, so we’ve created some definitions which we hope will explain how we see the difference.
Strategic (direction-setting) decisions are likely to need endorsement from a capability independent committee such as a governance body to ensure strategic fit
- The level at which decisions are made is based on agreed criteria, usually detailed in the governance of the organisation or charters of the decision making bodies
- Decisions should be targeted at one decision committee only for each decision, rather than a stack of committees
- Example: a decision to expand into a new customer segment
Execution, operational or delivery-focused decisions should be de-centralised where possible for timeliness
- Guidelines are needed for decision ownership and decision level
- Use a simple scorecard to identify decisions requiring committee-level endorsement; capability teams may act as guides were in doubt
- Interested parties are kept in the loop by an exception-based process (consent is assumed if not advised otherwise within pre-defined period)
- Example: a decision to agree metrics for sales staff in a new customer segment
Clarity
These guidelines will work in most cases; the art and science of decision architecture is more complex and we find that in many cases where decisions are going to the wrong, or too many, decision making bodies, the problem is not so much that those decision making bodies want to micromanage, but that there’s a confusion about what’s strategic, versus what’s executional or operational. We’ve seen senior committees arguing about, approving and ultimately endorsing, details of reporting processes, while their strategic decisions are being made out of sight by Solution Architecture. SteerCo members dive into the details of how requirements are being built. This isn’t usually the fault of the governance committee alone; it takes a whole organisation to build good, or bad, governance. But committees also need to be proactive in not accepting the wrong decisions being brought to their attention, and to do this, they need clarity on what those decisions should be.
You could argue that a strong governance committee would be composed of members that are capable of calling this; but even strong committees are controlled by their governance, and if that governance says they have to sign off decisions pertaining to the subject, with no distinction between strategic and execution decisions, especially in organisations where there’s a history of people being penalised for making the wrong decisions, these will continue to bubble up.
So clarity is an answer; it’s not the only answer, of course; structure should precede clarity, but clarity in itself is a pretty good start. Most governance bodies have a charter of some sort, detailing the role and scope of the committee and its members, but few detail what they mean by the decisions this committee should be taking. Even capturing the decisions that the committee should be making today can help a lot (see below for some tips on this) and when this is built into a clear decision architecture, it’s also much easier to see where these decisions are reaching the right, or the wrong, decision making body.
Roles and encapsulation
In addition to the right governance bodies making the right decisions, strong decision governance also needs clarity of which roles are responsible for making which decisions (see the chapters on capabilities and communities of practice for more on this). It’s not enough just to tell people they should be making decisions, without telling them which decisions, what information they should gather before making that decision, and who should be consulted about the decision.
So decision architecture has very close ties with strategic workforce planning, as well as with capability design. Capabilities and communities of practice encapsulate roles, which in turn will have decision rights assigned to them. In most cases, broad decision architecture (where the bigger, strategic decisions are made) can be designed around the organisation’s capability map, while lower level decision design associated with roles can be done within capabilities, through co-creation by capability communities. Necessarily, there will be a continuous dialogue between these two “layers”, which together form the decision architecture of the organisation.
Because many decisions, associated with roles within capabilities, can be made independently of the broader governance structure, it’s also possible and, indeed, desirable, to encapsulate these decisions within the capability’s governance, rather than exposing this level of decision architecture to the broader organisational decision architecture. As with all other encapsulation, at some point a need may arise to expose the results of these decisions to the wider organisation, and it’s therefore important for the organisation to understand that these decisions are made within the capability, but unimportant to understand the details of how that decision is made, or who’s making it.
We discuss role design in more detail elsewhere, for the sake of decision architecture it’s important to know that role design is an essential part of this architecture, and equally that, in most cases, it’s a part that is hidden from the broader decision architecture design at organisational level.
Decision design, then governance design
As described above, most governance isn’t really designed. It grows as the need for decision bodies arises, sometimes through omission being identified rather than through design but more often, as business units, programmes or initiatives are created by an organisation. Every organisational unit needs a governance board to make decisions for it, or to ratify decisions. These decision boards are almost always tightly aligned to the organisational hierarchy of the units concerned, with senior people or their representatives on the boards. While this works pretty well in a small, functionally structured organisation, it almost always translates as extremely complex, bureaucratic layers of governance in larger organisations, where units have responsibility both for their own governance, and towards the wider organisation. It gets worse when those organisations are managing any kind of matrix arrangement, with boards representing both organisational and policy/strategic alignment for different disciplines.
Add to this change programmes, and the matrix gets more complex. One of the fundamental challenges of implementing strategic change is attracting sufficient attention from sponsoring units at a senior level, but effectively what that means is that any organisation in transformation, as most are today, requires its senior managers to sit both on management and transformational bodies, absorbing significant amounts of their time. It also means that decisions are more likely to be passed through layers of decision fora, as accountabilities are unclear and often budget allocation requires authorisation by multiple units. In parallel, senior managers are likely to delegate responsibility for attending these fora to layers within their organisation, effectively removing the senior attention that was needed in the first place and again creating layers of decision making.
Radical though it might sound, we’re proposing designing decision fora based on the decisions that need to be made, rather than on the organisational hierarchy. Our experience shows that this is likely to meet with some resistance, but in practice creates a more positive experience for the forum members, while expediting decision making. Of course, it sounds logical but it’s not commonly practiced, and there are pitfalls – you may find that some of your most significant decision bodies are meeting too frequently, if there’s not enough material that really needs their attention; we find that agendas tend to get filled for the time available, rather than because of the relevance of the content, where meetings are too frequent, and the removal of irrelevant material may leave the committees with not enough decisions to make. Conversely, you’re likely to identify the need for fora which didn’t previously exist, where concentrations of decisions are clustering in a decision forum vacuum.
The beauty of analysing decisions prior to designing your decision fora is that you don’t have to break anything; unfortunately, real life isn’t usually like that, so you’re almost always working with an existing set of decision making bodies, with entrenched behaviours and preconceptions. This is where landing change can be challenging, but having a body of evidence generated by your decision analysis is useful to support delivery of the change.
Service aligned decision architecture
When we describe service architecture for service aligned organisations, it looks complicated. As discussed elsewhere, this isn’t because it’s any more complicated than in any other type of organisation – in fact, usually the reverse, but because we’ve stripped out the hierarchical view, there’s a set of commonly used reference points that’s entirely absent, and so the organisation needs to be described in terms of capabilities, services and decisions, rather than hierarchies and processes. Of course, those capabilities, services and decisions also exist in traditional organisations, but we generally don’t try to capture them schematically because we have the hierarchies and processes to point to; services, decisions and capabilities are sometimes bolted onto the hierarchy or process diagram (typically a side box to a leader for a governance forum) but usually not captured separately as decision or service architecture, as outlined here and elsewhere in this series.
Decision architecture, like service architecture, for service aligned organisations, doesn’t have a hierarchy to pin it to, which can make it harder to know where to start; without a hierarchy, you’re unlikely to have the same formalised top-down governance fora already in place. But it’s usually easier to see the flow of decisions if you base them on service architecture, rather than hierarchies, so it’s actually easier to get it right, without the baggage of a hierarchical organisation influencing your thinking.
In the absence of a hierarchy, decision architecture becomes more critical to understanding your organisation and the flow of control within it. It also means that you’re more able to identify where the most important decisions are being made, and to ensure that the right people are in the right roles to make these decisions.
Decision architecture in the ecosystem
As with services, for organisations operating as part of an ecosystem in the connected economy, decision architecture will persist beyond the boundaries of any individual organisation, and be closely associated with the services they support. This means extending decision rights over your organisation to groups and individuals who may be based in other organisations, which can at first look challenging, until we consider that many of the decisions made about our organisations are already being made outside our control; obvious ones like tax and regulation, but also less obvious ones such as how our services are positioned in relation to others by third party agents, how our competitors position themselves, educational and social norms in the countries in which we operate, and so on. An ecosystem in which your organisation is an active participant is a microcosm of a competitive environment in which you have more, not less control, over how your potential competitors (partners) are interacting with your customers, and therefore it is in your interest, and theirs, to ensure the decisions are taking place in an agile, decentralised way.
Like multi-entity computing, this means that you won’t have full visibility of the decision making process for decisions made outside your organisation, and your governance needs to be robust to ensure that all parties are comfortable with the way decisions are being made and who’s making them for this to work effectively. In general, the closer the decision is to your organisation and the more impact it has on your organisation, the more likely you are to want to be involved with the decision, but this isn’t always the right answer; often third parties in your ecosystem, especially those with a closer customer relationship for the service in question, will be both better informed and more able to make effective decisions without your direct input. You may want to establish a right of veto over certain decisions, and just as important is for agreement upfront on which decisions over which you will not have a right of veto. See below for the mechanisms for agreeing this upfront.
Components of decision architecture
To understand decision architecture, you first need to identify the decisions your organisation is making. That should start with identifying which decisions fit into various categories, which isn’t that easy, so we’ve presented some criteria here to help. First, what is a decision?
A decision is a point in time conversion of input into certain output, based on the criteria and parameters input. The output of a decision represents a change in state to an entity, which is usually enacted after the fact. For example, a decision to approve a loan will be based on the validation of the applicant, their credit-worthiness, the size of loan requested and the repayment terms. All of these are input parameters, while the entity is the loan request, and the output is a change of state from “requested” to “approved” or “rejected”. Once that decision has been made, no change of state is possible without a further decision. Alternatively, a decision may be to approve a document such as a charter; the entity is the document’s status (proposed vs baselined/rejected) and the parameters will be more complicated than that of the loan, usually assessed by a number of experts. While there may be several iterations of the document before it’s approved, these iterations represent adjustments to the parameters to reach an acceptable benchmark for it to be approved, and pass through the decision from “proposed” to “baselined” status.
The reason it’s important to apply these criteria when deciding whether something’s a decision or not, is that often activities which appear to be decisions are not actually decisions; they may be ratification of a decision that’s already been made (as with Fred’s car park surface) or, frequently, committees discuss matter without actually making a decision at all; the “decision” is to pass the decision to another body, but this doesn’t change the state of the entity in question. Or, conversely, some entities are brought to committee and receive no outcome at all – no decision, and no referral. These items are often referred to as “for information”, and in some cases it may be appropriate to inform the committee of the outcome of a different decision making process, especially when it impacts the whole audience, but this should not be confused with the purpose of a governance committee, which is to make decisions. Unless these items are of a nature that requires technical explanation and addresses a roughly equal knowledge gap in all committee members, there’s almost always a better way of conveying “for information” items than a full-blown presentation – usually a paper submitted before committee, with Q&A invited to clarify any uncertainty.
In addition to decisions brought to committee, there are usually a lot of decisions being made in the organisation that don’t come to committee, and sometimes these are the decisions that should be receiving strategic attention; while other decisions brought to committee should be made by skilled technical resources instead. To clarify the distinction, these can be divided into Strategic, or direction-setting decisions, and Operational/execution, or delivery-focused decisions. As we don’t want to create a megalithic decision architecture detailing every input, output and parameter for every decision made in an organisation, drawing this line early on is important; both to expose the strategic decisions and to encapsulate the operational ones.
It’s critical not to confuse “important” decisions with “strategic” decisions. Some important decisions are operational and should be made within expert capabilities, such as Fred’s car park surface decision. The sales staff metrics are also important, but this is a very good example of where you should leave the design to the experts and not allow governance committees to tamper with the details! The governance committee in this case, should be concerned with ensuring the right experts are in position to make the right decisions, by hiring those smart people we talk about a lot.
Most strategic decisions will also be important; here you need to ensure they reach the right level (not too high) of governance, and once only. Any strategic decision that’s being referred by one committee to the next level up is at the wrong level. But to get decisions to the right level, it’s essential to ensure the right subject matter experts are involved in the decision, and that there’s an effective exception-based consent process to keep interested parties in the loop is essential. Say, for example, I’m asking for €40 million to fund a major change programme. Rather than going through a load of small committees before reaching the executive committee’s table, we’d need to ensure the right people – subject matter experts and those familiar with the organisation’s strategy – are involved in developing the request, before presenting it to the senior committee.
In effect, stacks of committees in many organisations fulfil this role of refining proposals, rather than asking the proposal submitter to create a robust proposal in the first place. This may mean many of the right people get involved in the process of refinement, but it’s not efficient and takes up time which could be used by those committees for making more relevant decisions. By putting the onus on the submitter to come to the right committee first time, decision architecture also ensures the submitter is applying sufficient focus to getting the right people involved and creating a proposal that holds water for the more senior committee, rather than using the stack of committees as a testing ground.
Filtering decisions then becomes more important, because the task of filtering is taken away from the lower-level committees. You would normally expect some of those individuals who sit on some of those committees to be involved both in developing the proposal and in filtering prior to submission to an executive committee, but the timescales will be shorter and, if managed on an exception basis, decisions can be expedited much more quickly, while also saving the committees’ time.
When designing decision architecture, all of this means it’s important not just to understand the size of the decision and which committee it should go to, but which expertise needs to be involved to create the proposal. To some extent, it’s turning the traditional stacked committee pyramid on its head, identifying individuals for their capabilities, rather than which committee they sit on, to participate in the development and filtering of ideas, before they’re presented for a decision.
Building Decision Architecture
So for each decision you need to understand the type of decision, which expertise needs to contribute to it, the size of the decision and who should make that decision. As mentioned above, many decisions will be encapsulated in capabilities, but even these will need clarity about these criteria for the decision making process to be effective – as noted in the first section, if you give someone the authority to make a decision without the right support, they will either be forced into making the wrong decisions or over-consult, which leads in one case to a lack of confidence in the governance, and secondly to paralysing the decision making process.
So the structure of decision architecture needs to persist, even where those decisions are encapsulated in capabilities. However from a macro perspective, all that’s important is the decision interaction between capabilities and the governance fora that support the decision making process. Rather than starting with governance fora, however, it’s almost always easier to start with the decisions, and the knowledge about those decisions is held by the people in your organisation who need conclusions; they may be scattered around the organisation but it’s usually pretty straightforward to identify the key people; they will also help you to find other decision stakeholders.
When gathering data, doing so with an outline structure helps you to focus and find the needed information.
- Is it a decision?
- What type of decision is it?
- Strategic
- Operational
- How big is it? (i.e. which level of committee should it go to)
- How big is the customer impact of the outcome?
- Who/how many people/functions will be impacted by the outcome?
- How much money will move buckets as the result of the decision?
- To what extent is strategy impacted by the outcome?
- Which expertise is needed as an input?
- Which expertise is needed to evaluate it?
- Which capability should own it?
- Which capability will be most impacted by it?
- Which capability has the most “skin in the game”?
Deciding where decisions are anchored (owned) and who’s impacted by the outcome are useful exercises in themselves and will lead towards the answers to some of the other questions. Examining decisions in this way will often (hopefully) lead to the expected results, but it is also likely to uncover some decisions that are being made in absence of the correct expertise, or being evaluated by the wrong bodies. Even so, it’s wise not to rush into assigning decisions to existing decision making bodies until you’ve gathered all the key decisions.
Following a first pass exercise, you should have a fairly good idea of the key decisions and be able to divide them into operational vs strategic decisions; park the operational decisions for now. It’s then possible to plot them into a matrix based on where the decisions are made.
In this way, the decisions can be plotted to existing committees and at the same time, any missing decision making bodies will be identified. As you plot the decisions, consider whether the decision making body has the right characteristics to make the decision:
- Are they at the right level of seniority (e.g. to sign off strategy/cost decisions)?
- Do they have the right level of expertise?
- Is the decision body agenda relevant to the decision under consideration?
It may be that none of the existing decision bodies is relevant, or that their agendas do not cover the scope of the decisions needed. If that’s the case, it’s worth considering whether you need a new decision making body. It may also transpire that some of your existing decision making bodies aren’t needed for as long, or as frequently as they currently meet, or in some cases, aren’t needed at all! It’s likely there will be a need to compromise to some extent, but this exercise is useful in identifying where you have concentrations of decisions to be made by the same, or similar, sets of people. The programme governance example above is pretty clear-cut but the same applies to most organisational decision making structures.
In addition, guidance is needed for the people making the decisions, both in governance forums and in the line. This is achieved by:
- Embedding decision rights in governance charters for governance meetings
- Embedding decision rights in role descriptions
- Providing guidelines/checklists for employees and governance forums
Conclusion
Through decision architecture we can ensure the right decisions are being made by the right people, with the right information and in a timely fashion. That’s not the only thing that makes an organisation run effectively, but well designed decision architecture can
- significantly reduce management overhead
- reduce risk by ensuring correct expertise is available for decision making
- reduce time to make decisions
- clarify output of decisions
- reduce confusion in managing governance forums
- reduce frequency and length of management meetings
Although the concept may be unfamiliar to many, the principles are simple and easy to apply. We hope this how-to guide has given you enough insight to apply them to your organisation.