Implementations - From Complex to Common Sense (Parts 5&6 - Testing, Implementation and Support)

Welcome to the final two of a six-part set of articles, looking at complex[1] financial technology or service implementation projects[2] and how, by utilising some common-sense ideas and tools, they can be simplified, and ultimately delivered more effectively and efficiently, without affecting quality.

Recapping from previous articles, we broke down a complex financial implementation project into six key phases, which each article will tackle separately, these are:

1)      Initiation (Article from 24/11).

2)     Planning and scoping (including any vendor selection); (Article from 01/12).

3)     Detailed requirements gathering. (Article from 08/12).

4)     Build and configuration. (Article from 15/12).).

5)     Testing. (Today’s article).

6)     Implementation and support. (Today’s article).

As per above, today’s article will focus on Testing, Implementation and Support.

Q) If what we requested has been built and passed initial testing, why do more testing? Let’s just get the implementation live already.

In the previous article we talked of testing the functionality as it is being delivered, in isolation and to prove the functionality is there. A more thorough testing phase is important to, not only validate the original testing, but to also test that the functionality in unison, and that functionality, suddenly when put together, does not break the overall deliverable.

This phase, in our experience, tends to be the one that gets reduced due to earlier project delays. The need to “meet the go-live date” means companies will agree to do minimal testing if it means being “on-time.” While we do not agree with this, we are pragmatic and so it is about finding ways to quicken up the testing process while keeping the quality of testing high.

Q) How can you deliver testing in a short timeframe?

Firstly, we have a starting point by using the Detailed Requirements document. Once this document was signed off a list of tests can be created, linked to these requirements, with the expected output, ready for day one of testing. Secondly, these tests would need to be rated based on the impact of failure. Some tests will be key to many processes and, if they do not work, would be deemed critical failures. Other tests may only affect one small part of a process and can be “worked around” in the short term. These would be deemed non-critical failures. Any critical failure would be deemed a showstopper and needing to be resolved, tested and passed before go-live. Non-critical issues in isolation would not stop go-live, but an agreed number all together may become a showstopper. As long as the non-critical failures were put on a backlog and resolved soon after go-live, you can progress with a go-live having not signed off all tests as having passed. These criteria should be agreed in advance and any agreement to progress with go-live should be done via the Steering Committee. You can risk even not completing certain non-core functionality testing if your timelines are really short but, remember it is much harder to retrospectively deliver functionality changes once you are already live on a system or service.

In a perfect world, you would complete all testing with 100% pass rate before you go-live, but this is not pragmatic, especially on smaller budgets. Testing of some degree though is necessary and going live without any testing is a pathway to implementation failure. Good support from the vendor, ensuring internal subject matter experts are doing the testing and anyone with testing experience can all aid this phase too.

Implementation and Support

Testing has been signed off and we are approaching the go-live date, what do we do now?

Whether your testing phase was reduced or not, one further risk mitigant to help test the system or service before a full go-live is to do parallel testing or “friends and family” testing. Parallel testing means you mirror a normal business day into the new system but are not actually “live.” You can then monitor the output to see it is as expected. This would also enable you to do further volume testing[3]. Friends and family testing is using a small subset of friendly clients, or even staff who are clients, to go-live with and test functionality in the real world, before putting all clients on the new system/service.

Whether the above are used or not, there is still a checklist of things to complete[4] before the go-live date. One key item is to ensure all users who will be using the system from go-live are trained ready to use the system and provide support to any clients. Training can start as early in the project as you wish to but, in our experience, it should not finish until close to the go-live date. People can often forget what they have been taught if they are not using that knowledge daily. So, completing training weeks in advance means by go-live people have forgotten what they need to do. If go-live gets delayed, refresher training should be scheduled so people are still ready.

With testing signed off, training done, the implementation checklist completed, and all required signoffs received, the implementation go-live can occur. Where possible the go-live date should avoid holiday periods and busy business periods, but again sometimes this is not practical. Whenever go-live is, there should be as much support as possible from all involved parties on go-live date. A good vendor should agree, as part of the initial contract, to a “warranty” period where continued support is high to deal with any issues that may arise and resolve them as quickly as possible. Once the warranty period is over, this is when the service should move into the contracted service provision between client and vendor.

Thank you for taking time in reading this article. Like any article of this nature, it is written from our viewpoint based on our experiences within the field. We are very much open to constructive discussion and debate on this or any topic, as collaboration between Change Specialists should lead to better project delivery outcomes for end clients. Plus, it makes common sense 😊.

[1] An implementation of more than one process, involving more than one department.

[2] For example, an introduction of a new wealth platform service, a new client relationship management system or an outsourcing to a product provider.

[3] Testing with large amounts of transactions or data, which is sometimes hard to recreate in the normal testing phase without test scripts that can be uploaded into the system.

[4] There are a number of items on this which Common Sense Implementations can provide as part of our service.