7 There is often understandable pressure on purchasers and potential suppliers to conclude a deal and to seize as soon as possible the benefits of the project. But it is never acceptable to sign a contract with fundamental "agreements to agree" the detail of the service in the future, even if as in this case, they are intended to be resolved quickly. Allowing realistic timescales for early planning and detailed specification will pay dividends in terms of overall project delivery and cost.
8 Departments undertaking IT procurement projects should fully understand the quality and quantity of resources available which actually will be committed by the supplier to deliver the agreed services. This is particularly important where new software development is required. It should be agreed during the competitive process how resource requirements can be achieved and measured, and the agreement should be drafted into the contract.
9 For major, mission-critical, tailored and bespoke projects, there should be proper piloting of technical solutions to address the full service requirement, rather than reliance on part-functional demonstrations. Departments may have to consider part-funding such pilots and should also consider awarding separate contracts for the design and development of systems before contracting with the developer for full implementation of the successful pilot. This approach also allows keener pricing of the later service implementation and operation stages by suppliers because the risks to them are reduced.
10 There must be agreement between purchasers and suppliers at the outset of information technology projects on the extent to which new systems will either replicate the purchasers' existing systems, or re-engineer and simplify them.
11 After examining the scope to simplify their business processes, and given certainty as to the detailed requirement, Departments should examine with potential suppliers the scope to use generic and widely used system components where available. This process may in turn suggest modifying the initially proposed solution. A major risk of the Benefits Payment Card elements of the project turned out to be their "bespoke" nature. Building bespoke systems adds to the development costs and the longer-term vulnerability of any solution.
12 Where there are major project developments which involve more than one system being developed in parallel, as was the case here with the Benefit card, CAPS and new Post Office systems, it is sensible to plan and monitor these jointly.