4. ICL considered that the problem with PFI development contracts was a somewhat naive assumption that all of the risk could be transferred to the developer. Developing a large scale IT software project required a partnership between the two sides, with a shared understanding of costs and user requirements. When the risks were relatively low, IT systems were good candidates for a PFI approach, and it was appropriate for the contractor to carry the development risk. The statement of requirements could be expressed in an unambiguous and complete way, and the contracting authority could be confident that the requirement would not be affected by changed circumstances. As the level of risk increased, however, the PFI route became increasingly less attractive, to the point where the risk on both sides would become so high that the contracting authority would be well advised not to pass the development risk to the contractor. Instead the contracting authority would need to manage the development risk during the design and development phase of the project, and the use of the PFI would be inappropriate.4
5. The Department felt that the level of professional and commercial expertise in the public sector was lower than was desirable to handle contracts of this nature where considerable risk was being transferred. Having a single supplier for quite different types of services was not necessarily sensible. The public sector needed to look at what the market could provide and at people's individual expertise. It then needed to put a package of expertise together from several different sources, and ensure that these were effectively managed either in-house or by employing somebody to manage them. Single supplier contracts were sensible only for a single service where it was clear that the contractor was fully able to provide what was required.5
_______________________________________________________________
4 Q5; Ev 30-31
5 Qq 197-199