Meeting Intent

Making sure that governance processes meet the underlying intent of a requirement seems like an obvious objective. Most audits begin by laying out the requirements under review, often with a short statement or discussion regarding the intent of each requirement. This makes it easy to then compare how well any mechanisms meet the intent.

Consider, for example, the intent of checking on the return on an IT investment. The best way to measure this would be to check if, and how well, the target outcomes were achieved, although some find measuring outcomes hard to do or imprecise. A common shortcut is to instead use a proxy measure like function points or story points delivered. Unfortunately, such measures do little to tell you whether the actual intent was achieved. To demonstrate this, I once showed two implementations of the same service, one with more function points than the other. The one with fewer function points was faster, more stable, and did a far superior job in delivering what was required; however, by just measuring function points, the poorer implementation with more function points would be considered a better investment.

Intent misinterpretations, disconnects, and measurement errors can occur even more frequently when trying to handle regulatory and legal requirements. Assume that your organization must fulfill a separation of duties requirement. These requirements are designed as a check to make sure someone cannot put in a change without the full knowledge and approval of the organization and participation of separate organizational parties. This limits the potential for fraud, theft, sabotage, and error.

To implement the separation of duties principle, most organizations separate the development team that builds the software from the operations team that deploys and runs it. An approval process with a governance board whose members are suitably accountable sits in the middle to review any changes.

This might look great from the outside, but how effectively do the processes meet the intent behind the requirement of minimizing the risk for potential fraud, theft, sabotage, or error?

Understanding the contents of any changes and the reasons behind them helps determine whether there is a risk. Facilitating this understanding is usually done by presenting the board with a summary of the changes, along with any detailed requirements documentation, test results showing any known service behavior changes, release notes, deployment procedures, and an overview.

While this approach appears sound, there are a number of troublesome flaws. The first is that it assumes the details presented are complete and adequately capture any risks. Anyone knowingly trying to violate the intent is unlikely to document it. This means that you need some other mechanism to find and present any potential risks. While there is a possibility the testing processes might stumble across a hidden risk, the only means to confidently do so would be by going through the actual code and configuration implementations directly. Unfortunately, it is extremely rare that anyone outside of the development team ever does this.

This leads to the second challenge. While governance board members might be suitably accountable, they often lack the skills, time, and even situational awareness necessary to parse all the documentation and relevant technical details provided to make a sufficiently informed decision. This means that actual governance is left to a mix of the following:

• Trust that anything potentially prohibited was eliminated by those doing the work

• Dumb luck that any risk is so visible and obvious that it immediately comes out of the data presented

The final flaw of this approach is that it assumes that all the deployment activities performed by the operations team align perfectly with the deployment procedures presented. This can happen, but more often than not there are some differences. Sometimes these differences might be caused by a minor mistake such as a miskeying or misordering of steps. Other times there are errors or gaps in the instructions themselves that require unplanned (and frequently uncaptured) work. These errors/gaps might manifest in a tweak to a configuration file, a file permission change, or some other activity needed to get everything working properly.

While it is unlikely that an operations person would knowingly commit sabotage, fraud, or error, few bother to capture what actions they performed, let alone check whether those actions align with the deployment procedures presented. This creates potential unknowns that can introduce hidden risks into the ecosystem.

If you are lucky, you can still avoid undermining your own efforts with such flaws. However, you must also be aware that many of the traditional fixes put in place to fill such gaps, such as increasing the amount of documentation or bringing in even more senior people to the governance board, do little to help.

No Target Outcome Interference

Not meeting intent effectively is far from the only problem with any governance and reporting mechanisms you might put in place. They can also interfere with the second factor, your efforts to achieve your larger service delivery target outcomes.

Being able to achieve target outcomes is obviously important. As you might expect, governance mechanisms usually introduce a level of delivery friction through the combination of extra work, handoffs, and approval gates required to meet it. Such friction will inevitably have some impact on your delivery capabilities that can and should be actively managed to minimize its effect. There are many ways this can be done through some combination of regular monitoring and streamlining of processes, intelligent tooling, and other improvements.

Unfortunately, few organizations bother to do much more than nibble around the edges of the problem. In one organization, I was brought in to try to optimize an 18-month-long delivery cycle. What I discovered was that all the technical aspects, including architectural designs, coding, testing, and deployment, made up at most 6 weeks of the 18-month period. The remaining time was spent in all the governance approval processes surrounding it.

While few organizations are quite that dysfunctional, many still find themselves pressed between an urgent need to deliver changes to meet customer demands and the slow grind to work their way through governance processes. This is not helped by the fact that governance processes usually require valuable time from important people who are often short of it, resulting in further delays and frustration. Not only are such delays wasteful, anyone who has been caught between a governance process and an impatient customer knows that they often look ridiculously incompetent to those on the outside.

All of this can be incredibly frustrating to many of those being pushed hard to deliver. This can build to the point where delivery people look for ways to work around the governance procedures. The least subversive method is to simply batch up all changes into one large delivery, meaning that governance processes only have to be done once. Such large batching also means that only bigger changes will get noticed, allowing other ones to slip through. Other organizations simply try to avoid or actively thwart governance altogether through emergency patches or backchannel activities to achieve objectives on the sly.

None of these actions do much to both achieve governance intent and progress toward target outcomes.

Maintain Situational Awareness and Learning

It might seem odd to have to consider the effect of governance on situational awareness and learning. Governance processes should, if anything, be mechanisms that capture and bring to light the ecosystem dynamics you need to know about and learn from. Yet it is surprisingly common for governance to be implemented in ways that both directly and indirectly hinder the sorts of information flow and understanding critical to maintain them.

Poor Requirement Drafting and Understanding

The vast majority of the requirements that determine the shape of many governance processes are ultimately defined by the lawyers who write the regulations and contracts that contain them. Unfortunately, not everyone is well versed in all the technical nuances of the spaces for which they are writing regulations and contracts. Legal language also has a tendency to be written in ways that are incomprehensible for the technical teams to interpret and follow.

Legal contracts that companies enter into are the biggest source of these sorts of headaches. Not all organizations have their own in-house legal counsel, and even when they do, they interface primarily with management and teams such as Sales and Vendor Management. This limited exposure to the technical delivery side makes it that much less likely that contracts and other legal agreements will be drafted and agreed to in a way that avoids causing big technical implementation problems.

The best way to avoid these sorts of quandaries is for technical teams to get to know Legal staff early and build strong relationships with them. By introducing what your team does and articulating your desire to avoid unnecessary grief befalling you and the rest of the organization, you can create a bridge that can help everyone. Legal is usually staffed by smart people who themselves want to be seen as working in the best interest of the company. They know the contracts that have been signed and can help you understand their conditions as well as the legal terms and intent behind them. They can also help do the same with any regulations you need to follow, possibly even pointing out potential pitfalls and loopholes that are useful to be aware of. This can help you both highlight their impacts and find effective ways to abide by them.

By being a known friendly contact, Legal staff are also far more likely to seek you out whenever there is a contract being negotiated. They might ask for help to interpret technical details and proactively avoid creating problems. They can also provide insights into negotiations, giving you some advanced warning of their dynamics and sticking points, which is very useful in improving situational awareness.

Being even a supporting part of negotiations can help you locate awareness gaps within your organization. For instance, Sales and Marketing team members may misunderstand a key capability, or the risk associated with certain commitments. Negotiations also provide useful insights into likely target outcomes of potential customers, as well as point out possible problem areas to watch out for from your suppliers.

Using Off-the-Shelf Governance Frameworks

Not having a say in shaping a regulation or contract is far from the only problem technical teams face. A lot of the time we aren’t even made aware that one is coming until we are confronted by a demand to find a way to comply with it as soon as possible. When we ask for details, we often get hit with documents full of impenetrable legal language. With such an immediate need, what options are available?

One solution is to find a consultancy or out-of-the-box solution that can take the problem out of our hands. There is no shortage of providers claiming to deliver everything you might need. Many themselves take a shortcut by adapting a preexisting practices framework to do so. Those looking for a more IT-centric bent may be presented something like ITIL or COBIT that include modules for incident handling, service design, security, and change management. Those wanting more project and program management might see Prince2 or PMI that stress planning, risk assessment, business case, and portfolio management.

Such an offering can be quite compelling. Taking the ready-made approach opens up a whole range of value-added processes with prebuilt examples that can be used to structure, record, and govern any delivery and operational activities you might have. Not only does this seem cost effective for everything you get, it has the added bonus of following widely recognized standards. These come complete with their own training curriculums, certification levels, and skilled practitioner communities that can be drawn upon. Many contracts and regulations will even reference them directly or point to them as examples to follow. Who wants to reinvent the wheel when there is no need to?

As you might expect, such an approach comes with some serious challenges that few fail to consider.

The first is that these sorts of external solutions emphasize process adherence over outcome delivery. In fact, you might argue that process adherence is the target outcome of these solutions. That isn’t to say they ignore what is delivered, just that the emphasis is toward checking the process boxes.

Part of the reason for this is that most are grounded in method-driven management approaches. They assume delivering outcomes can be assured through controlling how work is performed and by whom. In such a world, policing process adherence is a good way to maintain this control. It also happens to align with how many view the role of governance, especially in cases where the organization must ensure it meets any legal or regulatory requirements.

The problem is that most modern service delivery ecosystems are complex domains where it is difficult for management to tightly detail and choreograph every task in advance, especially when this information is requested weeks or months in advance of actual implementation.

All of this makes the processes themselves too brittle and slow to deal effectively with the unknown and unforeseen. With new requirements emerging all the time, a process-driven framework forces managers with two bad choices. Either become a bottleneck by trying to micromanage everything, knowing you will become overwhelmed and miss important details, or hire knowledgeable and situationally aware people who know what is necessary to meet target outcomes and force them to navigate the processes.

Process-heavy governance frameworks also impose a lot of extra friction in the form of extra up-front planning, documentation, and approvals, all of which result in the added pressure of time and effort. Reviewers get put under intense pressure to push through anything that is proposed without enough time to build a sufficiently deep understanding of the details to do so effectively.

This results in a terrible result for everyone. Those outside see an organization that is dangerously slow to deliver and yet still blind to how reliably it can adhere to its legal and regulatory requirements. Those on the inside face a sea of dysfunction, with those trying to deliver finding most of their time and effort being wasted on seemingly useless work, while those responsible for governing sensing they are one decision away from disaster.

Out-of-the-Box Process Tooling and Workflows

I am always reticent to recommend specific tooling solutions without a detailed understanding of the ecosystem in which they will be deployed. Tooling choices can have a big impact on whether you achieve the intent behind a set of legal or regulatory requirements. In many cases a tooling choice can provide the very documentation, controls, and tracking that are needed.

Some organizations go a step further and use tooling as a means of enforcing a set of processes in order to effectively govern artifacts and activities that can exist within a delivery ecosystem. This can be extremely helpful. I have myself used tooling to prevent everything from manual environment configuration changes, to check-ins, to software repositories that are not associated with a specific task.

However, governance through tooling can be tricky. Once tooling becomes firmly embedded in your delivery ecosystem, it can be difficult to extract. For that reason, and in order to avoid creating chaos and dysfunction, you have to make sure whatever is being enforced fits your ecosystem neatly, clearly meets the intent you are trying to achieve in a way that is obvious to most, and is flexible enough to adjust as conditions change.

Unfortunately, just as with processes, it is extremely tempting for organizations to put in place a ready-made governance-through-tooling solution. Some see built-in “best practice” process workflows as a compelling feature of an out-of-the-box tool, or are lured into it as a value-add as part of an off-the-shelf governance process framework adoption. Others simply stumble across them in whatever ticketing tool they have. This “insta-process” approach is appealing. They are easy to implement and are officially recognized.

You might be lucky and find a set of workflows that work for you; however, their one-size-fits-all approach tends to force process flows, gates, dependencies, and completion criteria that might not fit the realities of your ecosystem.

With process workflows, what might suit the masses might not suit your individual needs. In service delivery, such mismatches can cause massive amounts of friction and frustration that constrain the service delivery process, making it far more difficult for those in it to know what is going on to do their job effectively.

I have been in many organizations that have adopted such tools and workflows, only to deeply regret doing so only after it was too hard and time consuming to extract them from the delivery ecosystem. Inevitably people work around them, either by performing and tracking work using other means outside the tool, double-keying when necessary, or simply not tracking anything formally at all. This creates the worst of all scenarios, which is having a set of governance processes and tools that does not capture and govern all the activities in the ecosystem effectively.

It is also worthwhile to point out that you should not be fooled into thinking that using a tool or set of workflows that is a poor fit is okay as long as the process methodology followed is a more iterative Agile one. I have seen many tooling and workflow monstrosities with “Agile” monikers that enforce such heavyweight dependencies and completion criteria that they create terrible organizational dysfunction. In more than one case I have seen some of the most mild-mannered Agilists in the industry curse in frustration and refuse to use them.

Understand Governance Intent

Understanding the intent of any governance or legal/regulatory requirement is critical. Most delivery teams get hit with demands for good governance, or worse, get told they have to implement some horrible process, with no explanation as to why. Few teams bother to ask for any details behind the outcomes or underlying intent desired. Occasionally, it is possible to figure out the intent even if the mechanisms proposed are clunky or outright bad, such as with a return on investment or quality review. Other times the reasons are unclear or wrapped in impenetrable legalese. Sometimes, the entire requirement gets enveloped in a fog of mostly false rumors, as so often happens with Sarbanes-Oxley compliance reporting.

When things are unclear, ask nicely for clarification of the underlying intent. If the intent is to implement internal policies, try to find out where they came from and the history behind them by seeking out a friendly manager for guidance.

For legal and regulatory matters, you might want to try reaching out to the Legal or Compliance team for some help. Ask for any details on what the legal or regulatory requirements are and who they are for, as well as clarification on what they might mean.

I have done this a number of times, with HIPAA, Sarbanes Oxley, and GDPR being the most common legal/regulatory hobgoblins. Consulting the Legal or Compliance team will help you find that there are important nuances relevant to your ecosystem that you might not have considered. You might need to ask a number of questions to tease these nuances out, so be sure to remain friendly. Your goal is to understand the intent behind the legal and regulatory requirements so that you can achieve them in the best way possible.

Make It Visible

There are times when no one can really explain the intent behind governance processes coherently. Sometimes, the person or group demanding that the processes be followed will insist upon equating performing the processes themselves as the intent. This lack of a clear understanding of what is being governed not only results in shoddy governance, but can also have a larger impact on overall service delivery.

A great way of solving this issue is to make what the process accomplishes, and its impact on service delivery, visible. It is a must for any new process, but it can also be done to review existing ones.

I usually start by building a value stream map that shows the various steps, who performs them, and the amount of time it takes and/or is available to perform them. On this map I also lay out what is done and try to detail the assumed intent behind the work.

Along the way I note any known or potential areas for failure. For existing processes, these might include missed or misunderstood details, the use of a low-quality proxy measurement, or some process element or detail that might violate the intent behind a requirement.

It is also worthwhile to look at the efficacy of the processes themselves and the various artifacts within them. For instance, what material evidence is collected, what is it used for, and does it create sufficient situational awareness to make an informed decision or to learn from? Are the people who are part of the process sufficiently equipped to perform their duties and make effective decisions? Can they do this on their own, or do they need support from someone/somewhere? If external support is required, does the process help with securing it?

Finally, I look for any review mechanisms for the process that allow for problems to be spotted and improvements to be put in place. If these review mechanisms exist, who runs them, how often, and how is the efficacy of the process and any improvements determined?

Making the process visible is always an eye-opening experience, especially for management and those leading governance. Just as in the earlier story of the 18-month approval process, most simply do not realize the level of dysfunction, instead directing their attention to more tangible activities like code creation and deployment.

Propose Reasonable Solutions

Identifying a problem and collecting evidence is great. But anyone who has run a team or project knows that rather than just point out or complain about a problem, the most valuable thing someone can do is propose a reasonable solution to the problem. This is especially important in a situation where governance is causing delivery problems or is ineffective at fulfilling its intended purpose. Better still is when a proposal is a group effort, or at least has strong buy-in from others.

The best proposals start with outlining the intent of the governance process. You can do this either to put forward a new governance proposal when it is needed or to fix an existing one. You do not need to lay out all of the detail, but be sure to do your homework in case you are asked any questions about it.

If you are pointing out an existing governance problem, highlight the elements that are problematic or are being missed. Give an overview of the current problem, whether it is with governance, the friction caused, meeting outcomes, or situational awareness and learning. Give some examples but try to be brief.

Then lay out some ideas of ways to solve the issue. How does your proposal address it, and how does it maintain or improve overall governance efficacy? Be sure that you have covered your bases on the governance intent side.

Whenever I do this, I never do it alone or in a bubble. I always try to find others who either feel the problem themselves or have a strong interest in the efficacy of the process to work with. This helps build buy-in and will likely strengthen the proposal and ultimately the efficacy of whatever is proposed.

One example of this is the vicious change management–automated deployment struggle. I frequently see companies that automate deployments before establishing environment or configuration hygiene, resulting in unexpected failures and unknown states as changes are deployed into production. A common reaction to this is to put in place an even stricter change management approval process with more steps, documents, and approvers. These do little to solve the underlying problem (deploying what I often call “random bits onto shifting sand”). Instead, I uncover the problem of the unknowns and their effects, as well as show how the added process does little to solve it. I then build a step-by-step approach for resolving the underlying problems (make the underlying infrastructure and configurations both known and automatedly re-creatable from scratch, make packaging and configuration atomic, etc.), as well as reforming the change approval process to be more useful.

Sometimes your proposal might not be accepted at first. That is okay. Try to find out where any problems exist in what you put forward and see if there are ways you can address them.

Automation and Compliance

While tooling can certainly cause problems, it can also really help with governance and requirements compliance. Processes will inevitably need to evolve over time, so it doesn’t make sense for tooling to be only an enforcement mechanism with little value to the person doing the work. Instead, I try to shape automation to be flexible and helpful, collecting details and driving transparency that can also be used to aid the person doing the work at the same time. By using automation as a flexible aid that makes people’s lives easier while helping them complete tasks the correct way, the tooling is far more likely to remain used rather than worked around.

For instance, forcing people to tack on a task ID to a code check-in might sound annoying at first; however, it can save a great deal of time and effort when you try to figure out what code you changed for a given piece of work, or why you changed it the way you did. If you have heavyweight compliance requirements, intense security reviews, or are being audited for some reason, task IDs can also prove to be an extremely handy way to automatically generate all the documentation and reports about what was done, what tests were run against it and their results, and what packages were created and when they were released.

Another instance of useful automation tooling comes from the deployment side. When done well, fully automated deployments allow you to know exactly what was released and what changes were made where, all without worrying about potential variations, missed steps, or untracked extra work being performed by human hands. Delivery pipelines can also be configured to allow for change thresholds to be set so that higher-risk and requirement-dependent work gets reviewed by the right parties with the right information to make a sensible decision, while lower-risk and unregulated changes can be rolled out with fewer controls.

Be Flexible and Always Ready to Improve

Whether you are an individual contributor, a manager, or an executive responsible for maintaining good governance, it is important to remember that achieving the three critical factors for good governance is more important than the means you use to do so. There are many ways to achieve them. It is your job to work with the rest of your organization to find the means that are best for you. As the people, services, customers, and their target outcomes change, the means will likely also likely need to change and adjust over time to compensate.

To do this, you will need to be flexible. Regularly review your governance commitments, how well you meet them, and how much the mechanisms you use to manage them affect the organization’s responsiveness and awareness in achieving and improving the means you use to meet the target outcomes. To improve your ability to meet them, you might need to experiment from time to time or rip out a trusted tool or process and replace it with a new one.

Finally, there will be times that you might want to put in a new tool or way of doing things that seems to actively conflict with a governance requirement. For instance, the one team DevOps approach often falls afoul of separation of duties requirements. Look at the intent of the requirement alongside your own objective. Most who want to use the one team DevOps model hope to reduce delivery friction while maintaining awareness, responsiveness, and ownership of the running service by those developing it. While you might not be able to have everyone doing everything at the same time, there are a number of creative ways that you can use tooling and create organizational structures that can still achieve both the desire and requirement intent.