Project Post Mortem

A Technical Due Diligence Case Study

A Prominent Financial Services Company

Our client is a medium sized corporate in the financial services industry. A  Big Four consultancy had conducted a development project that had gone off the rails. JFDI was called in to provide independent expert evaluation of just how bad the damage was, and what it would take to put it right.

“JFDI provided a thorough examination of everything that had been produced, and a professional evaluation of each part. We were left with a clear path forward as well as the ammunition we needed to pursue a satisfactory outcome from what was otherwise an adversarial us-and-them situation at a complete impasse.”


Technical Due Diligence Consultancy for a prominent financial services company

Our client had adopted a new low-code technology on advisement from a Big Four consultancy, and had their developers create a small, simple pilot system intended to be the first of many in order to clear a backlog of unfulfilled requirements in IT systems. The project started, a team of business analysts worked on collecting user requirements, then the developers started work and users began to use the system as it was developed. After nearly £3M expenditure it was clear the unfinished system had severe flaws and that the project was running out of control. A growing catalogue of user bug reports hinted that there might be a number of serious structural issues. JFDI was called in to review the project and evaluate had gone wrong.

 JFDI’s Approach

JFDI’s consultants obtained a copy of the entire code base, frozen at the point of the developers’ exit. We collated an extensive table of complexity metrics for each code module, to prioritise those modules requiring closer examination. We looked at user bug reports that could indicate performance bottlenecks or structural problems.

The Findings

1. Business Analysis & Documentation

We requested the outputs from the lengthy and manpower-hungry BA stage. The consultancy was not forthcoming with any documentation. No BA, no requirements, no system design, no wireframes.

2. Code Quality

In a “low-code” development project consisting of several hundred thousand lines of code, we found many examples of divergence from vendor-published best practice, a lack of functional decomposition, and even hard-coding of special-case scenarios depending on specific database record IDs.  There were hardly any code comments explaining why a particular methodology had been used.

3. Performance

The database was found to have no indices. Queries/stored procedures/views were plentiful but often unused. In many cases, processes would perform multiple whole-table scans, returning large data sets to the code where iterative processing would be performed on the data. We therefore discovered that through better database design and improved algorithms, performance could be greatly improved.

4. Security

Although ostensibly the developers had followed vendor-established best practice in authentication and authorisation, one of the algorithms adopted in their code had opened up vulnerabilities to attacks such as code injection.


Project Outputs

The project ran for four weeks and involved four consultants. JFDI presented the findings of the TDD study to the client in September 2020. Remedial work commenced on the project prioritised by user bug reports and guided by JFDI’s recommendations. Code quality is gradually being improved and many of the structural issues with the system have already been addressed.


Country or Region:

  • United Kingdom


  • Financial Services


Company Profile

The company is a prominent Financial Services company, with no internal software development capability, and a considerable backlog of IT systems requirements to fulfil.


  • Technical Due Diligence Consultancy


  • A leading low-code software platform