Regulatory changes, not for the faint of heart 0

Have you ever experienced a project delivering regulatory change? Did you notice any differences compared to other projects? Here’s a little story inspired by our experiences. Any connections with real life characters are unlikely and even if you are new to regulatory work, don’t stop here; you will still enjoy it.

21^st century London. Seagulls fly around the Shard, light drizzle dampens the pavement and the Waterloo and City line still resembles a tin of sardines more than a tube.

Eva, is a business unit leader at the retail arm of First Compliant Bank (FCB). Her team uses an internal system for tracking customer interactions in the loan collection and recovery process. The software is a bit slow and tedious to use. Eva is eager to change it to more recent technology, so she initiated a project at the last budget planning meeting. The preparation should start next month and Eva is excited because she’s imagining a much better service. The upgrade, if successful, will enable the team to follow customer interactions more easily and the new electronic reports will please management as it will eliminate the need for manual calculations and lots of paper. Relieving pain by improving efficiency and decision making and becoming green at the same time - it would be a shame to miss this.

Black clouds are gathering on the banking skyline

Have you ever heard of the Central Regulatory Authority? Not yet? Don’t worry, it’s fictional anyway. But imagine that it’s responsible for the regulation and enforcement in our fictional financial sector. These guys are serious; when they say something, it has to be that way. And now they say that the way banks handle the regulatory reporting of retail loans must be changed.

Unfortunately the reporting system in FCB also belongs to Eva’s department and it was developed by the same team as the collections and recovery system. This change clearly interferes with any plans she had. Neither the team members nor the department’s budget can sustain two such projects simultaneously. Not even her McDonald’s smile training during high school summers can help Eva to hide her disappointment. More so that she knows this project is going to give neither her team, nor FCB any advantages over their competitors.

As soon as the first draft of the new regulation came out, Group Legal and the Compliance Officer started identify the effects on FCB. By the time Eva had sight of it, they’ve already submitted the high level plans to the project governance committee. The deadline is fixed in about 8 months from today. This binds the bank legally, whereas her improvement project can be delayed; so you can imagine the committee’s decision. The bank is going to start a project to respond to the new legislation as soon as possible. What about the system refresh? Well, that might fit in next year’s budget.

Who’s going to deliver this?

Tim is the only project manager available from the pool. He’s got 8 years of experience in delivery, including 3 years in agile methodologies. The team can start the preparation this month; the problem is that the source of the requirements is only a draft regulation under consultation and so many details might change over the coming months. It is likely that the requirements will be fixed just before the deadline. This is not new to Tim, but in this case it can’t delay the deadline or reduce the scope. The scope is another painful point because every feature derived from it is a must-have requirement. This defines the so-called “minimum viable product” for the project. Tim’s concern is that this could change significantly before the deadline.

 Figure 1 The time - cost - quality triangle of the new project

So the minimal scope and the deadline are fixed, and Eva probably wants to minimize the costs, so that she can hopefully spare some budget for the other project to commence. With both scope and time fixed, a decreased budget will surely have a negative impact on quality.

What can they do to save the situation?

One possibility is for Eva to fight against this project. This would make Tim’s work harder, probably resulting in a low quality solution only finalised after the mandatory deadline. It will probably leave a fair amount of work to be done manually and lots of changes to be developed later. But is there another possible future?

Theoretically there are an infinite number of other possibilities. One of them is that Eva pushes through her project, which in turn frees some of the team members by increasing efficiency. They can create the required new reports manually. Even this option might be feasible if the automation involves high costs.

Another possibility is that Eva and Tim, together with Group Compliance, identify the required functions and the possible changes which could come from the regulator before the deadline. The business team, when familiar with the problem, should be able to prioritize the functions. Consider what would be the easiest to do manually in the short-term if the software was not ready to perform at the deadline. The IT team can implement a model based solution which can later be configured according to the changes. That reduces the running cost and can save some work for Eva’s team to focus on other duties. But with limited resources it is unlikely that the team will be able to address many of Eva’s original concerns in the scope of the new project.

Can you imagine other solutions? Have you ever been in a similar situation? What did you do? Tell us in the comments.