Regulatory projects are commonplace, but should we give them special treatment? 0
Posted on 13, January 2014
in Category bsg insight
Do you remember the story of Eva and Tim? Refresh your memory here. While there is no one-size-fits-all answer to Eva's predicament, there are a series of dimensions which she can consider to help shape how she chooses to respond. In this post, we explore those dimensions.
In our experience helping clients with compliance projects, we’ve noticed some fundamental aspects in which these regulatory change initiatives are different from other business-driven change initiatives. We thought we’d share 5 of the most distinctive differences, which you might have already considered in Eva’s struggle.
Drop dead dates
Deadlines are fixed and set externally.
In regulatory projects the deadline is fixed by the regulator and individual firms have little influence on implementation dates. There have been instances when the initial deadline has been so tight that no market participants could meet them. In these situations the regulators may be forced to re-consider, but this isn’t commonplace and generally organisations have far less room to manoeuvre timelines in regulatory projects than in business-driven projects.
Poorly-defined requirements
Requirements remain uncertain until late in the game.
The winds of a change in regulation are often felt well before the deadline. But unfortunately the devil lies in the details. After high level drafts, there are consultation periods and it can take years to produce the detailed technical standards. Meanwhile the implementation deadlines remain fixed. Firms can start projects to implement the changes, but until the final text of the regulation is produced the industry can only make assumptions about what the final guidance will state. This is contrary to an ordinary business project where the traceability of requirements is carefully managed and all changes go through an acceptance process before being applied.
Everything is “must-have”
There’s a fixed list of requirements to implement.
Regulatory requirements define a mandatory set of functions. Everything is must-have and this could be a serious hindrance in any project methodology.
But how does it affect the iron triangle of project management? We’ve already spoken about the time and features elements, which are fixed to some extent and this is different from the traditional methodologies.
Figure 2 The regulatory shift in the iron triangle
You might already be familiar with the waterfall and agile versions of the triangle. The regulatory one is probably a blend of the two as you can see from the third picture. The only factors you can really influence are cost and quality. Everyone would like to decrease the former while increasing the latter. But the elements move together, they are inter-dependent. Assuming that the planned solution is optimal, if you reduce the budget, some of the other elements will have to move down with it. Create a partial solution or run out of time and you’ll surely face huge fines. The only viable choice for reducing costs seems to be reducing quality. But whose choice is it?
Who is the business owner?
When no one wants to be.
By interpreting the legal text, Legal or Compliance becomes the “source” of requirements in regulatory projects. But, not every organisation is prepared for that when it comes to project governance. After identifying the affected systems and processes, the impacted department becomes the official owner of the project. But are they truly engaged in this mediator role?
If you think about how regulatory changes usually take the resources from business initiatives, it must be hard for the owners of those shelved business projects to wholeheartedly support the unexpected guests. But these projects desperately need the engagement of business, because compliance can only advise of the final state, but not how to get there. That capability lies in the hands of the business users.
Now how does this affect our project planning triangle? Resources are scarce; the cost has to be minimized. This seems to be reasonable for a project which does not bring direct benefits for the organisation or the investor.
The argument is questionable on two fronts. When we speak about direct benefits, have we considered the fines which we don’t have to pay if the project is successful? This might not be a strategic benefit and as a best result we just maintain the status quo. But avoiding costs is as important as reducing them, not to speak about the reduced risk brought by the regulation. On the other side, with respect to minimising costs, which costs are we talking about? The immediate costs of executing a project until the deadline or the total cost of the change, which potentially includes years of manual work instead of automation? Additionally, what about the costs associated with the maintenance and operation of new systems as well as future changes? And the list continues with the financial consequences of being shut down by the regulators.
If we blindly minimize immediate costs, we’re risking the reduced quality of the solution which will increase costs in the long run.
Quality is the fourth perspective from which the legislation usually doesn’t define how the change should be implemented. Should you use automation or manual processes, develop an in-house solution or integrate a boxed product? There are lots of decisions about quality which can be and must be made carefully in a regulatory project.
Everyone is equally affected
You might be fooled into thinking that the same regulation affects everyone in the marketplace equally. But are all participants equally impacted? In our experience the depth of the effect on resources and the business can be vastly different. An organisation which has its compliance eye on its processes may be better prepared and can therefore focus more on advantageous projects. Therefore it’s important to watch the regulatory horizon with eyes wide open and to be willing to adopt a culture which supports proactive thinking about the possibilities. Meeting the regulatory requirements should be the consequence, not the driver of a thorough organisational risk culture. Look behind the tickboxes.
Andras Rusznyak
Andras is a BSG Consultant who, at the time of authoring this article, supported BSG project teams on various compliance initiatives.
0 Comments