Compliance, Wicked Problems, and Checklists: Needs, Issues and Solutions.

Agile Compliance

Before we dive into the details of the Agile methodology, we should begin by understanding that Compliance is a project. It is a project that requires a practical, effective and efficient methodology to understand and implement requirements of a regulatory regime or any other type of project for that matter. Resources to address compliance include time, money and people, all of which are scarce, yet are required to get the work done. And this is a key reason why compliance projects can be costly.

Agile Compliance originated from software development efforts. It provides an iterative approach to projects, whether software related or not. When I first began projects in technology years ago, most software projects were managed with a costly Waterfall methodology which was later found to be inadequate due to its inflexible approach and costly approach to problem-solving. The Waterfall project methodology, in contrast to the Agile methodology, mandated a step-by-step approach where each step is a complete deliverable without dedicated time or for review and revisions as the project proceeded. Waterfall projects generally enabled do-overs at the end of the initial project when all the work was completed review or testing began. Hence, projects often took far longer than what was originally estimated due to the fact that work had to be revised and reviewed once again. There are simply no cook-book Manifestos, no maps, no videos, no webinars, no conferences, no software and certainly no checklists that can provide an efficient and practical step-by-step approach for solving all the organizational problems that surround Compliance.

Many in the software industry were elated to be given another approach to achieve work product. Agile was this other approach. In contrast to Waterfall methods, an Agile methodology is an iterative process where each piece of the project is developed, reviewed, and subsequently revised as needed. You don’t have to wait until the project is over to solve problems that were identified in the beginning. Considering Agile’s incremental approach, it’s not surprising that changes made incrementally can have a positive long-range effect on other pieces of the plan further down the road that can be addressed in advance, without the negative impact of costly time delays. 

Let’s take the example of a HIPAA Risk Assessment. As I work with clients, we understand requirements can be overwhelming and the work effort can be daunting. We also understand there are cross-functional team members who have specific knowledge about various aspects of the regulations and therefore, they are an important part of the organizational solution. Agile Methodology for Compliance enables rapid iterations throughout the work effort because Compliance is not a once-and-done project. Compliance is a 24/7 365 regulatory set of processes. If changes to the plan are rapidly identified, decisions can be targeted, tested, and implemented quickly. Notice that we didn’t say by making the “right” decisions. Even making wrong educated decisions sooner rather than later is a better alternative.

Agile Compliance and wicked problems are joined at the hip never to be separated. Wicked problems, such as regulatory Compliance, can only be solved using an Agile methodology. Although the organizational challenges of wicked problems are predominant, that does not mean that the technical challenges can, or should be, trivialized.

Wicked Problems

Every compliance regime is a wicked problem that contains an order of magnitude more organizational complexity than technical complexity; however, the latter is ever-present and almost always non-trivial.

So, what is a Wicked Problem? Well, it’s not something that is evil, although people may claim that compliance projects contain evil amounts of work. 

In our context, a Wicked Problem includes the following axioms:

1. You don’t understand the problem until you have started developing the solution… 
2. There’s No stopping rule…since there is no definitive “problem” there can be no definitive “solution” … 
3. Solutions are not right or wrong…just “better” than others, or “worse” or “good enough” … 
4. Every wicked problem is “unique and novel” … 
5. Every solution is a “one-shot operation” … 
6. A wicked problem is one that possesses more “social/organizational complexity” than technical complexity… 

 The original thinking around wicked problems came out of the urban planning space and then went on to entirely dominate the software development space. The central idea that underpins Agile (i.e. iterative problem solving) is now permeating almost every existing knowledge-based industry.

Checklists

There’s a great book by Atul Gawande, entitled “The Checklist Manifesto – How to get things right.” I highly recommend it. He discussed how the nature of complexity has in many cases, exceeded our ability as individuals to succeed. He touts the use of checklists as making what may seem like an impossible task, one that can be achieved using a checklist to identify, improve, and manage the range of complexities we face.

A checklist is a way to attack a problem or issue. Checklists are used across industries aviation, medicine, and other industries and are a key part of knowing how well your compliance initiative is working. A Checklist, from our perspective, is most useful when an organization is confronting a difficult problem that is either entirely new or for some reason has taken on additional complexity or has never really been solved to a stakeholders’ satisfaction (e.g. the problem continues to be plagued with repeatable errors). 

Checklists provide guidance on how to think through and solve a problem, based upon the experience of others, and provides a verification tool to be used repeatedly over time to ensure that important details are not missed in an evolving and complex regulatory environment. Checklists are comprised of Checklist items including policies regarding the compliance regulation a definition of the processes that underpin the policy and ultimately a tracking mechanism to capture process results. In this manner we can, as Atul suggested, use the checklist to identify, improve, and manage the range of complexities in the compliance realm.

It is no small feat to create Checklist Items for each Requirement of a Regime. That is where the focus should lie. Why? Because you must comply at the granularity level of a Requirement. And a Requirement can only be satisfied if it has the aforementioned attributes associated with it: (1) a Policy; (2) a set of Processes that underpin the Policy; and (3) mechanisms for tracking Process Results.