Scroll
Contact us

Our clients tell us that we are open, honest and approachable. Please do not hesitate to contact us, we will respond to all enquiries.

7 Recommendations for the design phase of a debt collection systems project 16 JUNE 2016

7 Recommendations for the design phase of a debt collection systems project

In a previous article one of our Lead Consultants Matt Riddall explained some of the lessons learnt during the collections implementation projects that the Arum team have worked on. I would like to explore in more detail some of the most important phases of any project, the design and build phase.

You have that new shiny system, it’s fair to say it wasn’t particularly cheap and you want to maximise that ROI as soon as possible so getting the design correct is vital to achieving that aim. The list below is not exhaustive but I wanted to share some recommendations for the Design Phase from the lessons learned over many projects.

1. Configuration Design Principles 


With all system configurations certain design elements can be configured a number of different ways. We have found that by agreeing a standard set of design and naming convention principles, that have been outlined in a design principle document you will create a uniform build of the system using the specific best practice be that Debt Manager, Tallyman, CACS or any other system.

2. Visual Design


A visual (e.g. using Visio) creation of the business process requirements will assist with the business understanding that you have interpreted the requirements correctly. It will also inform and help with your analysis and thinking in terms of how the requirements will fit into the system. Version control is also an important element so that you can track how your designs have evolved over time.

This part of the design phase is the “how” you will design the engine of the system. Some vendors will have a set of Visio design templates but I like to use system agnostic flows which perhaps lean towards your system but which your stakeholders can still easily follow and are not too much into the technical detail. The visual designs can be turned into one-pager type documents for senior stakeholders to understand the customer journey through the process, slightly more detailed for functional analysts and then full detailed designs for coders and the system administration team.

3. Visual Design Walkthroughs


The most important people involved with the system will be both the end user and ultimately the customer whose account is being maintained within it. The designs need to ensure that cost to collect is kept to a minimum and ensure total compliance with relevant regulations.
The best way to ensure all parties involved with the system are aligned and that requirements have been interpreted correctly is to run through your visual designs with key stakeholders and ask them to sign off that what you have designed mirrors the business requirements and processes. As mentioned during the Visual Design section above you can tailor your designs for the relevant audience.

4. Detailed Design 


We are now ready to turn the visual designs into a build configuration planning document or spreadsheet. At this stage we will note down either in the document or on the planning sheet all the elements that need to be configured in the build stage. This document will be the basis of the code configuration and needs to be version controlled to ensure changes are well documented and maintained. By planning out how the business Visio is to be interpreted into the system you will have the advantage of visually seeing errors before you start configuration.

5. Peer Reviews 


A peer review of design code or configuration should lead to smoother Unit/UAT phases later on in the project. Peer reviewing can be time consuming but it will iron out any mistakes such as account black holes or simple configuration errors that can cause pain and would take more time to resolve once the test phases of the project are in full flow. Peer reviews should take the form of both self-reviewing and reviewing of your work by your peers.

6. Change Control 


Once the designs have been signed off its important to put in place a mechanism that allows for change to be managed, requested changes must be signed off, prioritised and documented. It is important to manage this to ensure that unnecessary scope creep does not become an issue, but which allows for agile authorised change.

7. Technical Specification Document 


This document should outline how the design and build within the system has been configured. It will contain the follow elements:
• Purpose of the document
• Scope what is included not included within the build
• Build Methodology
• Testing Approach
• List all the objects and code that make up the system configuration.

This template should then be used for all further configuration system developments.
It’s important to remember that during all phases of design and build its extremely important to have a control and audit process in place. This will ensure that what has been designed and coded meets with initial requirements and has been configured and coded correctly and adheres to the principles initially agreed.

Summary


Using these simple lessons during the design and build phase will help with the follow on phases of test and implementation and will ensure your project is set up for success.

If you would like discuss how Arum can support you on a specific project, contact us today.

Stuart King, Lead Collection Systems Consultant

Request a Callback