Shirley Consulting

Over the past the 16 months I have led the engineering teams that delivered a new Small Business customer focused SaaS products for a couple of Tier 1 retail banks.  A huge amount of time & technical effort has been spent directly integrating with the bank’s account opening/on-boarding systems along with engineering areas of the product to support a true white-labeled, scalable SaaS platform that meets the necessary security and regulatory banking requirements. While remaining flexible and useful to our end-customers.

But this is just hard work, with delivery being the most exciting aspect of the overall process.   Yet the real challenges one faced was bridging the divide between two fundamentally different organisations both in size culture and expectations.  Wading through external processes, shaping our internal procedures, much of which was not scoped for in the original tender(s), project planning and general scoping of the commercial offering.

Being engaged as an external consultant/contractor you are placed in a unique/privilege position when delivering solutions for your client’s customers.  Often one is viewed as an independent/semi-impartial party, which in itself has a number of moral challenges (particularly when you have to justify yourself as an expense during the project).

Context

In this particular instance I was dropped into the fray at the beginning of September 2014.  Tensions were running high due to previous frictions relationships and expectations around a successful delivery were low.   Last minute specification changes were coming thick and fast and I was responsible for a relatively inexperience engineering team using a technical stack brought in by contractors which was at odds with the experience of the permanent engineering staff.  The odds were definitely stacked against us as we had 100’s of defects, new functionality, no test automation (aside from an off-shore team whom execute manual test scripts) and a product that fundamentally did not work due to the over complexity of the system architecture along with many third-party integrations.

Product

Essentially the main USP of this solution is a cost saving for banking customers, while consolidating all of their operational needs into a single-sign-on solution offering a selection of best-of-breed products as identified by the customer’s bank. Furthermore to simplify cost management for the customer the solution was to be a pre-paid rolling monthly contract providing the flexibility to add/remove individual tools whenever the business owner deemed it necessary.

Issues

Banking legislation is in continual flux with a drive to do the best by the customer. Banks have changed the way they incentives employees moving away from the hard-sell to a more softly-softly needs-met approach. Thus to ensure new offerings fit within legislation a large number of internal committees/governing bodies need to be consulted resulting in a less agile delivery and ever increasing costs; rumor has it one such change cost £500K (I am guessing mailing internal costs) to change the copy and style of a public site button.

To be fair this considerations for changing site copy or adding new features are immense when you analysis the legislative requirements and Banks must now meet.

Information interchange is another hurdle, be it specification/design amendments through to testing results and management information. Simple email does not work due to the sensitive content. Fortunately Banks have become more adept at providing secure email alternatives as well as implementing TLS between public and private SMTP services.

Summary

As always the main challenges in delivering banking solutions are generally not technical. We (as developers) can build code/solutions that will satisfy a specification (whether or not that specification was correct is another matter). Building solutions to a timescale and budget is second nature (OK this can be a bit tricky), but at the end of the day we want to see our solutions ship and be used by customers.