In Pursuit of an Efficient System

Looking back to my experience, there was one project I am especially proud of – implementation of the new banking system (including operations core) in a Russian bank with 54 offices and 3 branches back then. It may not sound much, yet it was a major bank for the roughly 25 million of people. The project almost crashed, and the Board was thinking of reverting the whole thing, while eventually, it worked even better than expected – by undertaking tough decisions.

I was a junior project manager, while the head on internal control was the senior one. We had the task to change the whole system, including front and back office to the completely different one within a year – and this is for the consumer business with around 60 thousand cards, so you may guess that the operations should go online, with no delays. There also was a task to keep people informed through SMS within 3-5 seconds after performing the transaction, while sustaining transactions between accounts during holidays for all the transactions within the bank, including branches.

The new system was shiny, fast and reliable while the vendor made a presentation (to tell the truth it eventually was so). However, the first point we got stuck was that to get the proper data, you should have the proper data, while business users usually avoid this. It was solved by the sub-project of data improvement, when more than one hundred credit officers scanned over ten thousand documents, filling in the missing fields in the system, as it was their job anyway, and while remembering the importance on keeping the business running as fast as possible, we should always have control-aware thinking to mitigate both operational and legal risks.

We created a technical requirements template for the users so they would provide proper documentation for the developers, making it precise enough to make it feasible to work with.

Fortunately, the vendor had good business analysts, so they could also read the regulation and share their opinion, making it a fruitful discussion, as they already implemented the system in fifteen banks on the market.

Unfortunately, I first realized the joke about development (you know, the meme picture that goes around on the internet). When the first module was launched for the balance sheet part and accountants tested it, it looks like…well, I cannot use such a word here. We asked for corrections, they were done in several weeks, and it got even worse, as those implementing systems in banks should understand the bank processes and at least of the assets-liabilities idea.

As it seems, this is the most dangerous gap which appears on the road of the implementation, as users usually lack the technical knowledge to express it thoroughly for the developers – and anyway – why should they? It is either the thing that requires a special person in the middle – or there should be an additional requirement for the development team. Excellent business analysts couldn’t help us, as they were not technology-aware, too. The project got stuck, users were frustrated with huge amounts of work and lines of code being sent to them by the development team, endless discussions that lead nowhere, seeing sunset out of the windows while being on the meeting every day. And that was a turning point. We did something that allowed us to implement the new system in full within a three-month timeframe utilizing a single 24-hour break in the online transactions information, while relaying transactions on the backup servers.

It was a hard decision to make, yet after six months trying to get the development team to show some results, we requested to change the whole development team or to break the contract. Both senior project manager and I participated in the selection of those who were involved in the new development team, which reduced the size in comparison to the previous one – but suddenly, it also increased efficiency of communication and implementation itself.

We also created a responsibilities matrix, assigned dedicated users to test modules and re-arranging their daily routine so they could accommodate those.

We agreed with the development team we cannot accept any new module unless there is a training documentation on how to use it and basic stability testing done on their side with proper documentation.

Questions were gathered by their team lead on a daily basis and sent out at least two hours prior to the discussion so we could think them over.

Project team lived at work, I should admit, yet most people involved were not affected anymore, they had their lives and work-life balance – unlike it was the first half a year.

While adhering to the strict technical requirements templates, we accomplished something that seemed impossible. Actually, we decided that the sentence “it is impossible” is a reason for immediate escalation, as one should at least think on a possible alternative solution instead of plainly rejecting something that is hard to do. We stopped talking and started doing.

When we were launching the system at the end of the project, after all the testing was done, I recalled the TRON movie, as, after all, this implementation was done for the sake of clients, hence users. It was a tremendous success, both time-saving and stability-improving.

The main thing I took out of this project was that one should always do what’s best for the clients while adhering to the regulations, as this, on a free market, usually benefits the economy as a whole – and sometimes you have to make hard decisions to keep it that way. Without taking this step, we could have failed our clients and put their daily operations at risk, as the old system was clearly outdated and lagging, while keeping the initial path of implementation of the raw and underdeveloped product could have led to the mistakes of another kind, threatening the financial stability of the bank.

It helped our clients to prosper and our business to grow, allowing us to perform 24/7 interbank transactions for both individuals and legal entities, enhanced correctness of the reporting and optimize capital ratio as it should be, instead of using legacy approach due to lack o required data in the system.

While being one of the hardest times in my experience, I fell it as one of the most exciting and challenging ones that helped me to become a team lead I am glad to be.

I would be really delighted to hear my readers’ opinion on this matter and your personal experience or feelings about that.

Sometimes we should choose the red pill.

Personal viewpoint. It can’t be considered to be any company’s viewpoint.