Following on from my post last week about the need for a ‘regulatory compliance framework’, I will now examine the importance of taking a more holistic view of this challenge. We are now in a much better position to bring intelligent design and technology to bear in solving this problem and it’s vital that we should. However, the basic building blocks of the systems development life cycle (SDLC) process chain still stay the same:

1. Document assessment: Starting at the beginning of the project we have the documents from all of the appropriate regulators (not only financial regulators – there are potentially 12 or so additional regulators who hold purview over institutions regulated by the national financial authority). These documents may include thousands of pages, many cross referencing each other, meaning that deciphering the specific deliverable for each subject matter out of each document and bringing it all together is a herculean task.
2. Organisational impact assessment: Determining which banking division it will affect, which office and which business function, and  how many people, and stems will be affected, and how it will change the operating model is the another mammoth task.
3. Planning the change: Then comes the task of planning for all of the changes to technology and systems, people, and processes (the classic Programme Plan), and the proposed critical path, bearing in mind any interdependencies with other in-flight projects.
4. Change programme staff: Staffing these large programmes of change (often on a limited budget) is another major headache. This means balancing the requirement for subject matter experts (SMEs), internal and external staff (and whether they are located onshore, nearshore or offshore), management overhead and logistics.
5. The engineering component: Establishing the best approach is a prized craft of our profession, which comes with a degree of risk. Whether to enhance old or build new systems, and deciding on whether waterfall or agile methodologies are used, through to the acceptance testing regime across multiple technology stacks, and interfacing the data flows seamlessly are all of critical importance.
6. Measurement dashboard: Building the end-to-end performance measurement dashboard for the ‘Business as Usual Operating Model’ is normally compulsory these days.
7. Communications: It is crucial to ensure that internal and external stakeholders, staff, suppliers, and customers are engaged and understand what progress is being made – which involves a well thought through communications plan (timings, content and dissemination mediums).
8. Education plan: Typically left until too late (if not forgotten), the education plan is essential for bringing all staff to the required level of understanding, be that general subject matter and programme awareness, job specific responsibilities, and managerial and SME responsibilities.

So the concept of an end-to-end unified programme plan, which combines every one of these SDLC disciplines can be a minefield, especially when the wild horses seem to be going faster and faster.

No matter, it is important to move quickly with the times. The priority must be to build the detail of the programme plan and target operating model, along with estimation tools with embedded risk factors, accelerators to streamline desktop development into production environments, end-to-end tracking and performance measurement while implementing the programme plan, and finally the business-as-usual operating model dashboard.

With all this in mind, we also need to remember the ultimate goal of the regulatory compliance framework – to provide a governance environment to simplify the implementation of every regulation, and in so doing, map every regulatory requirement to the right technology, process or staff; and therefore be able to measure and monitor the performance of those staff, technology, and processes against every regulatory requirement.

Now wouldn’t a regulatory compliance framework of this nature be a wonderful outcome?