This approach is problematic for four critical reasons:

The more often the team discusses "as-is," the more entrenched they unconsciously become. It causes the carrier to stick to what they know and how they've always done things. This bias usually doesn't manifest itself until E2E UAT when the team assembles all the parts and the reality of the new system becomes clear.
The SI partner should be hired to bring in new perspectives and a natural bias towards the new system, which is often true because the "as-is" pulls them towards the past and away from the future. This pull is incredibly subtle, showing up as change controls or significant functional requirements that are unintentionally aimed at making the new system behave more like the old one.
The entire system is virtually unknown until far too late in the development cycle — E2E UAT. It's one of the reasons why people often refer to the Agile method used in these projects as "Agile Waterfall." By the time the team gets to UAT and discovers all the big misses, significant pressures — namely time and money — are working against them. It's uncommon for teams to be on track as they get to UAT; this means there's little tolerance for significant changes, and even if there's tolerance, big changes are difficult to incorporate into UAT scripts that have been building for months.
Migration and integration workstreams are heavily dependent on the incremental development of the system. In the case of migration, initially, the data is not entirely understood; it takes time and effort. In the case of integration, an integration point implies that whatever part of the process being fulfilled by the system exists (which may not be the case). It's often the case that these workstreams are flying blind because they make large assumptions they have virtually no way of validating until E2E UAT.

Flip the script

The central question currently asked is: What are the gaps between your "as-is" and "to-be" systems? This question is almost the equivalent of the blind leading the blind because the SI partner doesn't know the "as-is" and the carrier doesn't know the "to-be." What if the central question was: What's broken with the new system? This question also gives rise to more questions, including: How does the new system work?

Special Reports /

Flipping the script on core transformation

Related Stories

Recommended For You