It is not rocket science! 8 steps to regulatory compliance

Repeated conversations are usually an indicator that something is not well understood and not working well. In this case, I have had a number of conversations in the last couple of years around the production and sign-off of “business requirements ” in regulatory change. Business requirements are a key step in almost ant change methodology. They articulate what needs to be delivered for a change to happen. They are the physical manifestation of my old headmaster’s advice that “if you can’t write it down you don’t understand it.” They provide a checkpoint on understanding, a rallying point for stakeholder understanding, and they document and compromises. Traditionally they are signed off by the future users and beneficiaries of the change. So why does there seem to be an issue with regulatory change? I think the answer is that business leadership forgets the large amount of preliminary work and thinking that precedes a normal business change. They don’t understand their own contribution well and expect project teams to work with the published regulations and “just sort it out”. In this article, I have drawn out the eight-step process to successful regulatory change and compared it with the “normal” BAU process.

Before I look at the eight steps in more detail, I would like to point out a few things. Firstly, business requirements are quite a long way into the business change process at Step 7. In my discussions around regulatory change, it seems that there is often a belief that one can go straight from Step 2 to Step 7; this is the source if many problems as the links (and traceability) between rules and deliverables are lost and assurance is eroded. Secondly, in normal business change, senior management will have already invested significant effort in Steps 3 and 4. They will already have an understanding of why things are being done before they are asked to review and sign off on the eventual business requirements. This is often missing or very late in regulatory change. Thirdly, I have deliberately simplified Step 8 into a singular delivery point. The reason is that the method of delivery is not “one-size-fits-all”, but should be optimised to the requirements. Let’s look at the eight steps. Step 1: Collect and Collate This is a key foundation. Without the confidence that you are working with all the right texts and rules, how can you assure anyone of eventual compliance? Unfortunately, this is rarely a simple task as there are usually a number of texts involved, ranging from the official legal text to notes on required standards (technical and business) as well guidance. This is an evolving body of information that needs to be managed and disseminated. Increasing clarity will inform the change effort and may require in-flight adjustments. You have to expect this and be ready to cope with it. Step 2: Interpret The rules tend to be written by lawyers, using a language that suits legal discussion but is not always easily understood by the business. This step looks at the collected texts, piece by piece, and asks, “do you understand the rules?” If not, then now is the time to seek clarification or at least document your corporate understanding of each piece. Again developments, both internal and external, may lead to changes in interpretation as the effort progresses. These changes need to be embraced and allowed to flow through the subsequent steps. Step 3: Articulate the rules This is a key step and driven off the interpreted texts. It is where each requirement contained in the rules is identified and articulated. It does not prejudge any existing solutions or business shape. It will be in a form something like this, “a firm that operates with authorisation XXXXX and performs activity YYYYYY is required to do ZZZZZZ”. This is a key stage and is a pure analysis of the regulatory text. It could be and is maybe better performed away from the day to day business in order to avoid any assumptions. It should cover the entirety of the texts, even if it is something that the business does not currently perform. Irrelevant aspects will be discounted in the next step. Step 4: Gap Analysis This is an analysis of how well current practices meet the new requirements. There are three main options:- 1. Current practices and existing capabilities meet the new regulatory requirements. In this case, ratifying and documenting the fact is valuable. 2. Existing practices need to be changed, or new/enhanced capabilities are required. These form the basis for the rest of the work 3. The business does not need to comply with a specific requirement. Documenting this with appropriate sign off is key NOTES: 1. This analysis needs to be done against the correct business framework. Most business rules are aimed at legal entities and require a separate analysis against each entity. There may also be a “line of business” overlay in which case a further level of detail is required. If the Steps 2 and 3 have been performed well, then the nature of the gap analysis should be apparent. Uncertainty should prompt a revisit to the previous work. 2. One needs to be of other developments impacting the business as these may add or subtract capabilities and thus affect the identified gaps. This needs to be factored in. In the case of updated regulations, I stress “current practices” rather than any change from previous regulations. Time has a tendency to erode and confuse memories and practices. Unless one can be absolutely certain that current compliance is beyond question, it is best to review requirements against practices, not just the documented changes to the regulation. Step 5: Change Requirements The gap analysis will have highlighted where the business needs to deliver change or build capacity. Essentially it is a summarised extraction of the gaps, but with full traceability back to the relevant rule(s). This is a chance to contextualise the requirement as well as consolidate aspects in order to make the next steps easier, e.g. bring all the data requirements together. Step 6: Solution Design This is where the business decides how it will address the requirements. It is likely that a single solution could address a number of gaps and this is where that discussion takes place. Generally, it is not at a level of deep detail, but rather principles and organisational considerations, i.e. who is going to be responsible, how will it fit in, etc.? This is an opportunity to realign/reshape the organisation's effort to better reflect its needs. The people/teams that undertook the interpretation and analysis may not be best positioned to take matters forward. Step 7: Solution Requirements Having established how you will address the gaps, this is where the business defines what is specifically required – these are what would otherwise be seen as business requirements. As the details are worked out, there may be some iteration back to the solution design. Step 8: Delivery This is where the traditional project work really kicks in. It can because of the quality of thinking in the previous steps. Depending on the nature of the solutions, delivery can and will likely take a number of shapes. The organisation should determine who is best to deliver the various aspects and eventual deliverables verified back against identified requirements. The combination of existing capabilities and delivered change will ensure compliance with the identified regulatory requirements. Of course, life is not simple, and the parts and players keep moving, but an approach like this allows developments to be embraced at the right point and the downstream implications assessed and addressed. As I said it is not rocket science, as the comparable “business as usual” change flow shows. There are 8 Steps there albeit with slightly different names. There is often months of effort and considerable management input invested before there is attempt to draw up business requirements. No project team is expected to manage all eight steps. The problems regarding business requirements for regulatory change are I believe down to three main factors:- 1. Senior management attempts to over delegate responsibility when they should be heavily involved in at least Steps 3, 4 and 6. 2. Confusion between Regulatory Requirements and Solution/Business requirements 3. A rush to lock down business requirements without a structured path and often missing key steps – the gap analysis seems to be most commonly missed. I hope this illustration will help readers structure their regulatory change effort and enable stronger communication and engagement with senior management.