Blog article
See all stories »

Flexbility is killing

Over the last couple of years I’ve had the opportunity to look at a variety of core banking solutions. What strikes me is that more and more these solutions are similar, not only in coverage – which we can assume they have to be to support the variety of banking functions needed – but also in construct.  Service oriented architecture, frameworks, agile development, multi-tier architecture, enterprise architecture approach, etc are the main buzzwords. Also it seems that the focus is placed less on the banking functions themselves – as most solutions present similar coverage – but more on the flexibility of the solution.

This must be good news for bank CIO’s, right?

Well unfortunately, not really ...

As we all know, scope creep is a major risk in our banking IT projects. The problem with flexibility in software is that it increases the risk of scope creep enormously. Flexibility is a bit like the Trojan horse of scope creep as it looks great at the beginning and it is not until later that it reveals its real face.

Faced with flexibility it is all too easy to delay decisions on certain aspects of the software as ‘it is flexible and can easily be configured later’. Very often this lack of proper initial identification of what is required to bring out the scope will shorten the scope analysis phase and will be considered a benefit, not only to the bank implementing the solution but also to the vendor delivering the solution. Users can and will delay decisions – as we know bank users are of an indecisive nature to start with so this certainly doesn’t help. A culture of last minute changes is bred. Milestones are set and milestones are pushed back. It becomes more and more difficult to fix an end goal. The project slips, budgets explode and in the worst cases projects get aborted.

Sounds familiar, right?

Luckily we have great project management methodologies available to properly define, document and control the project scope.

But first and foremost, it’s important to acknowledge the threat that flexibility brings as, I’m sure, you certainly don’t want your project to end up like the city of Troy.


Comments: (3)

Nicholas Hacking
Nicholas Hacking - ERI Bancaire SA - Geneva 06 February, 2013, 11:35Be the first to give this comment the thumbs up 0 likes

A very interesting comment. Of course flexibility is important, as each bank will tell you they are not exactly like the others and you need to be able to accomodate each bank's particular requirements, processes etc.

But you also need to be able to limit the effect of scope creep by delivering a system which is as close as possible to the requirements of the target bank. This requires a vendor to have had considerable experience, preferably across multiple institutions in multiple geographies.

But as for delaying decisions, that comes back to how a project is run and the involvement of the bank's own management team in making decisions or empowering and then pushing users to make decisions.

It also needs experienced staff, preferably who know the product and not "just hired" juniors or temps from a consultancy firm, who can not only advise the users but also oush back when it looks as if scope creep is getting beyond the boundaries of what would be reasonable given the project, the budget and the desired timelines.

A Finextra member
A Finextra member 06 February, 2013, 13:29Be the first to give this comment the thumbs up 0 likes

If scope creep is your problem... move to agile.

A Finextra member
A Finextra member 07 February, 2013, 09:31Be the first to give this comment the thumbs up 0 likes

Thanks for the comments.

Randall, flexibility and agile? In banks? Sounds frighteningly heroic ...

Nicholas, don't tell me ERI Bancaire is going the agile route now as well ...

Now hiring