Contractor Selection Case Study

Many Years ago, our main consultant Nigel had an experience of development with a major London Borough which served as an education for his later work.  Senior staff at the borough had requested development of a system for use in their contracts department that would serve several key needs:

  • Businesses that wanted to work on council projects needed authorisation, and authorisation was to work on concurrent projects up to a limited financial value;
  • As projects were created, authorised businesses in related areas (e.g. construction, education etc) were invited to tender for the project;
  • Contracting firms that offered tenders would be entered in the system, and a winner would be chosen within a framework of rules that included limiting work to their financial limit and existing projects, and a random element.

This was in an era when software development was undertaken using waterfall development, and much of the specification of the design was completed up-front, and end-user interaction was minimal.  Our consultant developed a solution that met all the criteria for development, and with extensive end-to-end testing the package was conclusively shown to meet the requirements.

Nigel designed a normalised database structure to hold the necessary data, and layered the functionality on top, all developed it in a database system called Paradox for Windows at the client’s request.  Considerable end-to-end testing proved the package was capable of delivering the required results.

The day came to install the system at the client-office, and train the team to use the new tool.  When the training began, one of the first questions from the team was ‘What are you here for?’.  It became very clear that the team members had not even been informed that a system was being developed for them!  Now, perhaps this was because one aspect of the system was to ‘remove bias in contractor selection’ (read into that what you will) so perhaps there were reasons why the team would not want an automated tool to take selection out of their hands. But whichever way, it was clear to Nigel that – even though the system delivered the necessary functionality in a way that was easy-to-use (especially compared to the mainframe systems used elsewhere in the borough) – not having the users involved in the process was a considerable flaw in the project.

Unfortunately we are not able to tell you how the package was used after that point, but the message is clear; users should have been involved in the project and hand-held through the process of a change in their role; perhaps their concerns were purely around making more of their job use a computer at a time when they were more used to handling piles of paper. Or perhaps there were other reasons? If so, that would make it even more relevant to manage the process of actually using the solution.

It turns out that delivering a project successfully; one that both works correctly, and is used successfully, involves more than just writing code that works.