Skip to main content

What’s Governance Got to Do with Effective Software Development?

Article

What’s Governance Got to Do with Effective Software Development?

Article by Graham Oakes | Comments: (0) | Tue, 07/03/2012 - 8:15am
Summary:

Governance doesn't have to end in bureaucracy. Learn to maintain and refine your governance structures, and you'll reap the rewards of improved decision-making processes.

What springs to mind when you hear the word “governance”? For many people, it’s bureaucracy. They see a thick manual of policies and checklists, a central committee that delays decisions, or an endless round of audits and compliance checks. The next thing that comes to mind is skunkworks—how do we go underground to avoid the governance police?

It doesn’t have to be like that. Governance isn’t about compliance. It's about making good decisions in an efficient way.

What Is Governance?

My preferred definition comes from the Institute on Governance. They’ve defined governance as “the process whereby societies or organizations make important decisions, determine whom they involve and how they render account.” This identifies four key aspects to governance:

  1. Defining which decisions are important. Some decisions have a large impact on whether we achieve our goals. Most don’t. Good governance ensures we focus our energy on the important decisions.
  2. Defining who makes these decisions. How much time have you seen wasted on demarcation disputes? How many decisions have you seen fall through the cracks because no one took responsibility for them? Good governance ensures that lines of authority are clear.
  3. Defining “due process.” If the decision-making process is clear, we don't need to spend time making it up as we go along. We can focus our energy on analyzing our options and balancing trade-offs. If people can see that we’ve followed the agreed process, then they’re less likely to challenge the resulting decision and we won't waste time revisiting old decisions.
  4. Accounting for outcomes. Accountability is not the same as blame. Good governance builds in feedback loops. It ensures that we track the outcomes of decisions and, hence, refine those decisions as we learn more. Equally, it ensures that we monitor and refine the decision-making process itself.

Software development is knowledge work. It’s all about decisions—which features to prioritize and which to delay, which design trade-offs to emphasize, where to allocate our effort, and so on. Good governance ensures that we make these decisions as effectively as possible. We involve the right people in the right way, and we learn and refine as we go along.

Conversely, poor governance leads to poor decision making. We waste time on trivial decisions. We involve people who lack the necessary expertise and understanding. We define bespoke processes for every decision. We get bogged down in politicking and infighting as people argue about decision rights. And, at the end of all this, we’re left with decisions that don't stick, either because they lack legitimacy in the eyes of key stakeholders or because they aren’t grounded in solid evidence and analysis.

The sad fact is that organizations that don’t address governance end up spending a lot of time on it. They discuss it afresh for each decision as they design the decision-making process and argue about decision rights. They’re then left with little time to gather data, analyze options, and make the decision, so they make bad decisions.

Central or Devolved?

How is it that governance often turns into bureaucracy? This tends to happen when people equate governance with centralized control. They reason that centrally enforced policies, priorities, and standards make it easier to ensure that everyone acts in a way that aligns to corporate goals. Further, they reckon that centralization builds consistency, making it easier to coordinate distributed teams and move work or people between teams.

There’s some truth in this, but there are also countervailing pressures. For example, devolving decision making to individuals and teams ensures that decisions will be more closely attuned to local circumstances. It also shortens the chain of command, allowing people to make decisions more rapidly. Such speed and situational awareness are often key requirements for good decision making.

Many executives find devolved decision making scary. Things move quickly and not always in the direction they expect, but this may just reflect the realities of software development. Local nuances can have a large impact on the effectiveness of a team or the validity of a solution. In such circumstances, centralization merely gives the illusion of control.

Defining appropriate governance structures, then, is about balance. We need to balance the benefits of centralized and devolved control. Here are some factors to consider when doing this:

  • Consistency—Is it important to make consistent decisions across multiple teams? Centralized governance mechanisms make this easier. Thus, for example, a central body might set standards for user interface design.
  • Alignment—Do you want to ensure that everyone is focused on common priorities and objectives? Again, centralized decision making can make this easier. So, you might set up a central portfolio management office to decide which projects to prioritize.
  • Expertise—Do you need specialist expertise to make certain decisions or to carry them out? If that expertise is rare, then you might put people into a central pool where you can manage their utilization carefully. This is common for groups like legal teams and things like specialist equipment and tools.
  • Speed—If decisions need to be made quickly, then you want to reduce the length of the chain of command. So, devolved governance mechanisms make a lot of sense.
  • Situational awareness—Many decisions are influenced by context—different customers need different types of support, different teams have different strengths and weaknesses, etc. People who are close to the situation are better able to weigh the factors and make appropriate decisions. This favors devolved governance.
  • Scope for consultation and guidance—It doesn’t have to be all or nothing, central or devolved. You can create intermediate structures by centralizing some aspects of a decision and devolving others. For example, people may make decisions locally but use centrally defined guidelines. Or, an organization might decide centrally after consulting with teams and individuals locally.

The balance point will vary from organization to organization, as factors such as culture, market environment, and the mix of products and technologies come into play. It will also vary from decision to decision within a single organization. Good governance builds a range of decision-making mechanisms, each tuned to different circumstances.

The balance point might also be dynamic. For example, if you’re experimenting with a new technology, then it probably makes sense to devolve decisions initially while teams learn how to handle it. But, as understanding grows, you might want to centralize some decisions in order to ensure consistent application of your newfound knowledge.

It can even make sense to rotate between the two poles. This can help transfer knowledge. People bring local knowledge from the field and share it more widely when they centralize. They then build specialist skills to take back into the field when they next decentralize. I haven’t seen many organizations that are smart enough to do this consciously, but it might be the main benefit they get from their regular reorganizations.

Other Decision Attributes

This trade-off between central and devolved control is at the heart of good governance. However, it’s also worth considering some other attributes of your decisions:

  • Routine versus one-off. Routine decisions benefit from clear policies and guidance. You want to make them as efficiently as possible. On the other hand, trying to write policies that cover every possible one-off decision and exceptional case is a fool’s errand. It’s unlikely that you can accurately predict every possible circumstance, and the weighty policies will just bog down routine decision making. When an exception arises, set up a specialist team to deal with it.
  • Complex versus complicated. Complicated decisions are amenable to analysis. It might take time, but a team of experts can eventually think through the situation and decide. Complex decisions arise when everything is so interconnected that such analysis simply isn't tractable. In such cases, you need to experiment to learn what works, so your governance structures must support experimentation and phased decision making.
  • Reversibility. If decisions can be reversed easily, then controls can be made more lightweight. Thus, for example, you can make the decision within a devolved team and then review it centrally later. This may incur added costs when you reverse a decision, but the benefit of rapid decision making often outweighs this (provided that the devolved team gets it right most of the time).

The important thing is to think clearly about your situation and the decision-making mechanisms that fit it. If you only start thinking about decision making when in the midst of a crisis, then you’re unlikely to make good decisions.

And remember the fourth aspect from my definition of governance, accounting for outcomes. Monitor the effectiveness of your decision making, and work to improve it as you learn more. 

Governance is an ongoing process, not a one-off. If we don’t look after our governance structures, then they tend to degenerate, either towards anarchy or towards bureaucracy. Conversely, if we maintain them carefully, refining them as we learn, then we’ll be rewarded with flexible decision-making processes that consider all the important factors and win the buy-in of all key stakeholders. The price of good governance is eternal vigilance.

About The Author: Graham Oakes

Graham Oakes helps people untangle complex technology, relationships, processes and governance. He can be contacted through www.grahamoakes.co.uk or at graham@grahamoakes.co.uk. His book Project Reviews, Assurance and Governance is published by Gower.