A very personal note this time. Last week I released a project that was pretty-much the largest single release that I’ve worked on for my current employer.

Like many systems, the history of this one is that as customer applications made their way through the relevant processes, the system recorded various information about the processes that happened and how they worked out. The system then used the presence or absence of those success / fail records to decide what needed to be done next.

The problem with this approach is that it is very inhuman… especially as far as the Customer Service Representatives work. To construct a list of things that are left to be done before an application can be completed (in this case, for a loan) actually left quite a lot of processing. Furthermore, a lot of things had been hard-coded, when the system allowed only one application process, and as time wore on and variation entered the system, those hard-coded items became less and less valid.

This particular change was therefore substantially about improving life for CSR’s… and in due course also improve the system for customers who have their own login area.

How did we do that? Primarily, by turning the pre-existing approach on its head (while leaving the old mechanisms in place for – you got it – reasons of supporting pre-existing reporting and so on).

Think of a trip to the supermarket… our pre-existing system was the equivalent of making a list of where you had been, but not what you wanted or needed to do. Instead, now we make a decision pretty early on in the process about what we want to do for a particular customer. Then, we make a list of those things to do. Simple, now we have a shopping list! As we complete certain things, we simply mark those to-do’s as complete.

An important part of the initial specification was that certain tasks should not need to be sequential or processed in any particular order; although inevitably many of them did require some kind of ordering as the details of the project were worked out.

It’s never quite as simple as you hope it will be, and what we actually ended up with is a system that allows for several concurrent mini-workflows, with an event-like system for changing one ‘to-do’ into a different type – if for example we have some kind of ‘fail’ condition. So, for example, our ‘Automated Card Input’ action allows the customer to input their card details online, or a CSR to do it over the phone, but if we can not validate that card, the action rolls-over into a different action that requires the customer to send us documentary evidence of their card ownership.

As I mentioned when discussing Generating Data, there are issues with creating records in advance of knowing that you will need them. For example, a certain percentage of applicants never get past certain stages, and so creating records that may be required after that point can sometimes seem like a lot of work. Nevertheless, the project as a whole seems to be working quite well, and although it is early days as far as the new CSR UI is concerned (everything is dynamically created to visibly show not just what remains to be done, but also the actual controls necessary to complete those actions) responses so far have been good.

Anyway, it was a fun project and a relief that no big issues have been found in the first week of operation. As our client tends to be the type of company who will sign-off something in testing, and then come up with a hundred things they want changed the minute we go live; that’s pretty good going!