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.