Over my last ten years in the Collections and Recoveries industry I have been involved with many migration projects as a user, developer and finally as a consultant. Although I have mostly worked with FICO Debt Manager products, my observations are system and industry agnostic and could in theory apply to any new software implementation or upgrade programme.
The first in a series of three Lessons Learnt blogs will focus on documentation and the importance of this throughout the lifecycle of a collections and recoveries system implementation. These observations include some from new software implementation projects that have had significant overrun, which in part can be attributed to poor documentation at the inception of the project.
Do you know what position your documentation is currently in?
The documentation story starts before the inception of a migration or upgrade project and sits well and truly within business as usual (BAU). It’s critical that current processes and system design are accurately documented and more importantly that they are accurately updated as and when changes are made.
It has become clear to me that throughout the lifecycle of a system the documentation is either not updated at all or is inconsistently updated and this can lead to an inaccurate picture of the deployed system. This is often due to priority being given to more changes being implemented rather than rigorously following the change management process in place.
The levels of documentation and who owns it will always vary between industries, organisations and systems. There should be at least some form of requirement documentation which is often owned by the business unit or an overarching credit risk function. These will often be the first link in the chain of the change process impacting the collections and recoveries system.
Following receipt of these requirements, the systems team should then create an expression of how the system will deliver that requirement document. This is often expressed using a Functional Specification Document (FSD) which explains how the system will meet the requirements and will hopefully also explain why those design choices have been made.
Along with the FSD there should be a pictorial expression of the build within the system, which is at a low enough level to detail exact transactions within the system but will also allow non-technical users to see how their requirements are being met.
Finally, there needs to be an inventory of the configuration within the system. These documents vary widely depending on the product being implemented, but the inventory is very much a minimum requirement to understanding what configuration is within the system at any given moment. For some systems, it is possible for this to be produced by the system itself or indeed derived from the configuration within the system, however, not for all.
Are you looking to implement a new Collections and Recoveries system?
When a new system implementation is being explored it is vital to assess your current documentation status. If the documentation is below par it will slow the progress of the new implementation and should be taken into account within the project plan. Consideration should be given to ringfencing relevant business experts to undertake updating or improving documentation ahead of an impending project inception. Ideally those ringfenced personnel should be empowered and rolled into the project itself going forward and have a key role to play in the post project support model.
Another impact of poor BAU documentation will be the reliance too heavily on individuals within the system support team who know the system inside out. This can quite often be a very small population of senior developers and throughout the project their time will become a bottleneck. In a worst-case scenario, these people could move on to other roles and without a robust handover the knowledge could move away with them.
Sometimes there are inconsistencies with the initial requirements. Credit risk or a business unit owns the system requirements, but they may have lost track of the current build due to incident fixes or changes requested that aren’t reflected in the requirements. This means that the new product may have no (or an incorrect) baseline to work from. This could require a period of reverse engineering from the current system to create the requirements for the new product and if this situation arises, you would need to cover this within the project scope and plan. This can be less of a problem if you are also enhancing the system at the same time and there are new requirements, but if a like-for-like upgrade is required, knowing the requirements and underlying design becomes even more important.
How to document the implementation of a new system
The next stage of the documentation journey is during the implementation phase of the new system. Just as it’s important to keep the documentation up to date during BAU activity, it’s even more critical to create a regime of tight document control during the design and build of the new system. This is becoming even more important with the new series of systems being introduced by vendors, as the configuration is often more complex and consists of many more interconnected parts.
During the initial design process and subsequent testing phases the level of updates applied to the system and therefore the design documentation will be large. This means that there is a need for robust controls around the design and configuration documentation.
This issue of needing to keep documentation updated is often compounded during the testing and implementation phase due to multiple environments in play. Each environment can often have different streams of testing or implementation within it and knowing what configuration is within each environment becomes very important.
This can be delivered using a release notes system which details the version of configuration within each environment and what that version of configuration does and sometimes more importantly (if looking to retest defects or issues) doesn’t contain. This will supplement the main configuration documents (configuration design documents, technical flows, business flows, FSDs and BRDs) which should also contain version control elements for each piece of configuration or code which can then be related back to the release documentation.
In my experience, accurate control of the documentation is a team effort. Ultimately it will only take one person to get the documentation out of step from the system for issues to occur. This will then take further time to rectify or, if not identified, can result in incorrect configuration making it all the way through to deployment. It’s important from the outset of the project that this mantra of system documentation and version controlling is followed and understood from all levels. Although this does impose an initial overhead on the design and build teams, which again should be accounted for within the project planning, it will make the path through to implementation much smoother.
There is a virtuous cycle in all of the above in that clear accurate project documentation becomes the source material for post implementation effective BAU, which is where this piece began. Arum have a lot of experience, within both project and BAU, across many CnR systems to enable best practice processes, formats and approaches to be taken to reduce risks and maximise the return on the investment being made in the system; so regardless of whether you’re just beginning a project or simply in BAU mode, if this piece sparks concerns about your documentation, get in touch.
Part two will take a look at the lessons we have learnt while in the various testing phases of a CnR implementation project.
Michael Knight – Senior Consultant