This is the second in a series of articles from City Integration and Limina written with the intention of demystifying some of the complexities around platform implementations.
In our last article we outlined some thoughts around implementation approach and discussed the merits of this as either Big Bang vs Phased. In this article we take that thinking further and focus on implementation methodology, another of the decisions to be made at the outset of any implementation.
The main methodologies used in financial services tend to be ‘Waterfall’ or ‘Agile’. Other approaches such as Six Sigma and Kanban are available but these tend to be more specialised and less utilised in banks and investment managers, so for the purposes of this article we will focus on the first two.
What then do we mean by “Waterfall”?
First introduced around 1970, the traditionally favoured method of project delivery was to use a ‘Waterfall’ approach, where the various stages of the project were tackled sequentially with zero overlap and formal gateways between the phases:
Objective Definition -> Analysis & Design -> Development -> Testing -> Go-Live -> Maintenance
This approach was largely defined by the constraints of the mainframe platforms prevalent at the time and which were typically only subject to major upgrades or enhancements every 1-2 years or more.
As with any approach there are always Pros and Cons:
Waterfall – Pros
- Clearly defined end-goal known at the outset
- Clearly defined delivery roadmap
- Allows focus on one stage at a time, with clear transition between each
Waterfall – Cons
- Prone to extended timelines (and increased cost) due to need to formally transition between stages
- Extended time to first delivery – implementation can only occur once all prior phases complete
- Inflexible – if new or amended requirements emerge during development phase it can be difficult to accommodate without replanning as phases cannot be reopened once closed
Over the past 10-12 years with improvements in platforms, cloud-based hosting, SaaS etc, and also major advances in development and project management tools such as Jira, this method is now considered to be somewhat clunky and outdated, and many organisations are now utilising a more flexible ‘Agile’ approach to implementations.
So what then do we mean by ‘Agile’?
Using an ‘Agile’ methodology, organisations are able to condense the entirety of the development lifecycle within a much shorter timescale and deliver the work incrementally.
This work is done by initially documenting the requirements (documented as the ‘backlog’) and then working in ‘sprints’ – typically of 2-4 weeks – where specific items are taken from the backlog and allocated across the team based on their work capacity. Over the course of the project the full backlog is tackled, but this approach allows the team to get to the first delivery more quickly (albeit with limited content/functionality) and then builds on that in subsequent deliveries.
The Agile approach can be broken down as follows:
Concept -> Inception -> Iteration -> Release -> Maintenance
Within the Iteration phase, we can break down further into:
Define Requirements -> Develop -> Test -> Deliver -> Refine
As ever, each methodology come with its own set of pros and cons:
Agile – Pros
- Speed to market for first components – early delivery of Minimum Viable Product (MVP)
- Fail fast, if something does not work then a fix is less intrusive and less costly to resolve
- Integrated development tools (e.g. Jira) allow greater visibility of progress and status across the team
- Further integrations with tools make it possible to allow automated testing and deployment (DevOps)
Agile – Cons
- Fragments the bigger picture – main focus is on immediate deliverables rather than strategic vision
- Focus on speed of delivering first components can actually end up delaying delivery of the final end-product
- Requires specialist skills to be most effective – e.g. qualified Scrum Master required to proactively manage the backlog and team
So what is the answer?
There is rarely a simple answer – a straightforward technical upgrade with little or no business impact (e.g. a new website, or change of data provider) may well suit a purely Agile approach, whereas a small-scale project where requirements are clear from the outset and unlikely to change may suit a Waterfall-style delivery.
Realistically, and from what we see in practice, the complexity of financial services organisations tends to see them utilising a hybrid approach for medium to large projects, applying elements of both methodologies with the precise balance being dependent on the specifics of the project and the impacts across the business, operations and technology
In our experience – and regardless of methodology – there are a number of critical things that are central to any project and which need to feed into any decision on approach:
- Requirements definition – clearly establishing the overall objective(s) for the work early in the process
- Planning – breaking those requirements down into phases
- Disciplined programme and project management – across analysts, project managers, developers, testers
- Managing the engagement with key stakeholders and sponsors and securing their backing and commitment
Successfully navigating these options is what will help define the approach and is where City Integration can help. Our specialist professionals have 25+ years experience delivering complex programmes of work at blue-chip organisations such as investment banks, investment managers, central banks and sovereign wealth funds, supported by our fully-qualified team of analysts, developers, scrum masters and project managers