Regulatory and Compliance Obligations – A Different Challenge

The world is currently facing a pandemic crisis unique in our lifetimes.  But human disasters of a more ‘local’ nature happen regularly…

In January 1986, the Challenger Space Shuttle exploded shortly after launch killing all seven crew members and ultimately delaying NASA’s Space Program by 3 years. There were two major investigations of the Challenger Disaster – the Rogers Commission (instigated by President Ronald Reagan) and the U.S House Committee in Science and Technology hearings. While the Rogers Committee emphasised breakdowns in communications between the technical experts and senior management as a contributing cause, both the Rogers Committee and the House Committee agreed that the failure of the O-ring seals on the rocket booster (designed and built by Morton-Thiokol) was the critical technical cause. What both investigations also revealed was that the flaw and potential failure of the O-rings (especially in low temperatures) was identified as a critical risk in 1977. Despite evidence of flame-outs in previous shuttle launches, the cost and delays in fixing the O-rings was seen by NASA and Thiokol executives as more “risky” than the risks of continuing with the existing booster design … “an acceptable flight risk.”

Putting this in a broader context, there is a major risk that has been known by technical people for many years but, for a number of complex reasons, the organisation delays its response … often until too late.

While clearly not as dramatic and devastating as the CoVID-19 Pandemic or the Challenger disaster, many organisations, faced with constrained project budgets and increasing demands for innovation projects to meet the competition, have struggled to give the increasing number of regulatory and compliance projects appropriate attention and focus.

Companies have always had compliance obligations.  Historically (excepting workplace safety breaches), there has been an attitude of acceptance of a risk-based approach to compliance breaches. There is a corollary here with the Challenger disaster – known technical breaches that have persisted over time, expensive and complex to fix, with the “payback” for remediation much lower than the cost to fix.   And so we end up with examples such as fees being charged by banks for no service.

Compliance program funding has typically come from the same pool as other investments, these alternatives often have strong projected financial or customer satisfaction returns, making it tempting for an Investment Committee to approve them.  This means “kicking the can down the road” on the compliance or regulatory project and accepting risk for a longer period of time.  If the company also cuts BAU investment in the risk and compliance functions in pursuit of a cost target linked to executive bonuses the risks just escalate.

Trust in institutions generally has eroded significantly – banks, religious institutions, insurance companies, government, law enforcement agencies, energy, Telcos.   Regulator attitudes and public opinion has dramatically changed, probably irreversibly.  This has raised pressure on companies to successfully and rapidly deliver on their compliance obligations.  These obligations can be explicit, in terms of hard requirements, but also implicit, in terms of a recognition of the need to regain customer trust.  One major financial institution has adopted a policy of “if it’s grey, we pay”.  This is a long way from “we’ll pay what we’re legally obliged to” view of the world.

What does this mean for your organization’s compliance programs?  Based on our considerable experience in compliance projects, Seven Consulting would like to offer some thoughts and observations about how to plan and execute regulatory and compliance programs to reduce the likelihood of them not delivering.

First, Regulatory and Compliance projects have a very important but often ignored “image problem” within project management and delivery communities:

• They are perceived by many people as having no real benefits;
• They are generally exposed to higher levels of change and uncertainty as regulators refine their legislation;
• They typically involve working with old, poorly maintained “legacy” systems;
• They are not seen as important as some “cool” new customer-facing projects;
• They rarely involve leading-edge or innovative technology;
• They are often seen by senior management as a burden rather than an opportunity;
• They are not perceived as great career-building opportunities.

These perceptions add an additional layer of organisational and people-related complexity to already complex projects. No wonder so many organisations struggle with these types of projects.

Most projects look at success via the “iron triangle” of time, cost and scope.  Our view is that this is a limited view of success, and in fact focus on these items alone can increase delivery risk.  As an example, a single-minded focus on delivering scope on time and on budget can mean huge pressure to go live with an unacceptable number of defects in production, leading to BAU failures and unacceptable maintenance costs.  Alternatively, the team could burn out through overwork, leading to key people resigning.

Our preference is to look at success through 7 lenses:

1. Have an engaged group of stakeholders
2. Meet the project’s objectives / requirements
3. Meet an agreed budget
4. Deliver the project on time
5. Add value for the organisation
6. Meet quality standards
7. Have a sense of professional satisfaction for the team

It is not possible to meet all these all the time with an acceptable risk profile.  So, trade-offs need to be made.  If you are supplying the seats to the main stadium for the Sydney Olympics and they need to be there for the Opening Ceremony, you won’t worry about the cost.  If you are launching the D-Day invasion and an attack date has been decided, you will defer if the weather is bad and people’s lives are at risk.

So, let’s look at Reg and Compliance projects using these success criteria as a structure – we’ll use Seven’s experience over a range of these projects to make some observations on what looks like what will work vs what we have experienced does work.  As legendary Yankees Coach Yogi Berra said “in theory, theory and practice are the same thing, in practice they are not”

1. Have an engaged group of stakeholders

On the face of it, determining which group of stakeholders needs to be engaged and have buy in and decision rights look straightforward – reg projects just have to be delivered, so, with the CEO or senior sponsor’s blessing it’s easy to think a Project Manager can charge off and bludgeon people into delivery, demanding prioritization above all else.  And to an extent this is true.  The issue is the consequences of failure are high, and so lots of stakeholders will want to be engaged and will most likely take a very risk averse view.  People will be nervous about being asked “why didn’t you speak up earlier” if things go wrong.  So, allow lots of flex in your plan for keeping stakeholders such as Operations, Risk, Legal, Regulatory, Customer facing teams, Media, Security informed and engaged.  If they think they have decision rights, they probably do, it’s a brave sponsor who will not want lots of signatures on lots of documents. Consider a dedicated project role to track internal stakeholder obligations, sign-offs etc.

2. Meet the project’s objectives / requirements

Again, easy to think of this as a no brainer – regs are regs, and they all need to be adhered to, how hard can it be?  Three issues arise here:

• Have the regs been correctly interpreted and does the project scope lead directly to the meeting of obligations – here a properly structured traceability matrix is invaluable, so that delivered scope does, and can be shown to, lead back to the obligations
• Regulators are increasingly moving away from prescriptive rules-based regs to principle based. Partly this is because organisations have a track record of navigating through the cracks in the rules to minimise compliance effort, and partly because the regulators themselves don’t have all the answers.  So, you get vague requirements like “an entity shall perform such monitoring and surveillance activities as are consistent with the nature and scale of its business and the risks to which it is exposed”.  Every firm in an industry will have a different interpretation of how to meet this sort of requirement, often regulators will refuse to engage in a clarification discussion, knowing they can play off industry participants against each other.  Our view is to engage good legal advice and try to implement solutions which meet your requirements but are similar to those of your peers.  If uncertain, spend more money and adopt a conservative approach.
• It is common in reg projects to see that complying is an opportunity to make improvements to the systems impacted “While the hood is up, why don’t we …”. It is our experience that, given the unique nature of compliance projects, this approach generally leads to low-outs of scope, time and budget, increased delivery risk and should be avoided, especially where timelines are fixed and consequences of failure are high.

3. Meet an agreed budget

It still surprises us how many organisations try the “minimum cost to comply” approach.  In projects of this nature it’s very common for initial cost estimates to be way too low, partly because no one really wants to acknowledge the scale of the challenge, partly because of the fact that regulators often change requirements during the project delivery, and partly because varying quality expectations can dramatically impact cost. Our view is to allow plenty of contingency in the early stages, and don’t lock in a final budget until requirements are fully understood.  Even then, regulators can change their mind at any time, so a good change control process is needed, and extra money needs to be made available when required.

4. Deliver the project on time

 Not always the case.  Many regulations have hard delivery dates, and with recent attitudinal changes from some Australian regulators this is becoming more common.  However, there may be scope to discuss with regulators your desire to deliver a quality, long lasting change, and in doing so negotiate reasonable timeframes for delivery.  An alternative where regulators won’t move dates is to try to come to some understanding of the quality of delivery on go-live date.  New EU financial derivative trade reporting rules went live in January 2018, but the regulators had tacitly admitted industry readiness was not high and indicated they’d take no action against partial compliance for at least 6 months post go-live provided they could see progress. Some firms went live with accuracy rates below 20% and the regulator was OK, if they could see a commitment to improvement.

5. Add value for the organisation

This is about whether the project adds financial value – if a reg project doesn’t then say so.  Resist the temptation to generate positive financial benefit by adding a strategic uplift stream to it. As we mentioned earlier this can greatly complicate an already complicated project.  What looks like a simple engine tune can easily become an engine replacement, putting the primary compliance obligation at risk.

6. Meet quality standards

This is the biggest sleeper in terms of delivery risk and cost.  No compliance regime can be perfect.  However, as the Banking Royal Commission showed, you will always get judged on your outliers.  It won’t matter if you were 99.9% right if the 0.1% you got wrong is given all the attention.  Increasing quality comes at exponentially increasing cost.  Take the time to really understand and define your quality outcomes, including extra BAU support post go-live. Allow plenty of budget to deliver and make sure you have great change management processes to transition from project to BAU. Consider driverless cars as an example.  30,000 people a year die in US road accidents, an “acceptable” number for society. If your response is “no road death is acceptable” we’d contend that if this were widely believed society would accept things like 40 km/hr speed limits everywhere or 10 years jail for driving with a blood alcohol level above zero. We have evidence that driverless cars will be safer that ones with drivers.  A rational argument for an “improved quality” outcome might be say, for driverless cars to reduce road deaths by 50%.  But that would mean “driverless cars kill 15,000 people a year”.  Society’s quality expectation is for driverless and driven cars are not the same, zero in the case of driverless cars.  This makes getting these cars on the road really hard, in the meantime the accident rate stays high.  In a project sense this means if you are introducing new processes you’ll almost certainly be held to a much higher quality standard than the processes you are replacing.  “But it’s better than the old one” may not cut it.

7. Have a sense of professional satisfaction for the team

Regulatory projects are not easy.  Stakeholders are demanding, and jobs are on the line.  It’s easy to take frustrations out on project teams.  Values led organisations well understand these pressures and take care to look after their delivery teams – ensuring there are enough staff who are well supported and engaged.  People who can successfully deliver reg projects are a valuable resource and should be looked after, not just for their own sakes, but so that organisations can rely on teams to deliver the next time and the time after that.

Regulatory and compliance projects matter – in many cases, they are mission-critical.  Take them seriously, invest in them properly, prioritize them at or near the top of your list, execute them to high standards, ensure active “C-Level” governance and put your best teams onto them.

Finally, do whatever you can to celebrate and raise the profile of the people working on these difficult projects … they are critical in keeping your organisation succeeding.