When banking transformation begins, it is difficult to contain — but drawing boundaries on the transformation is essential to managing the scope of delivery. There are a collection of analogies used to describe projects that take on too much scope: boil the ocean, swallow the river, solve world hunger.. There are many cliches that can be used to evoke images of impossible tasks, but in the context of banking transformation initiatives drawing the line between too much scope and adequate scope is difficult
This is a difficult aspect of any transformation effort, and the complexities of the architectural landscape itself are further exacerbated by:
- Old product boundaries vs. new product boundaries
- Old organizational boundaries vs. new organizational boundaries
- New processes front ending new and old systems
- Old and new reporting and analytics systems
- Traceability of data across the conversion
Typically in the planning stages of a program lines are drawn up to help constrain the cost and define the scope, but often the complexities are not fully understood until deep into the analysis in the program. The end result is that the boundaries move and the costs increase.
To avoid these surprises requires front loading the program with the analysis required to draw a firm boundary around the transformation. The deliverable should identify those systems that are in scope for replacement as well as those systems that are to remain intact (and how they will be kept whole through the transformation) and analysis on data mapping for both analytics and integration.
Unfortunately, boundary analysis takes time but this time is well spent as without solid boundaries the cost, schedule and complexity of a major transformation initiative is unclear.