2.19 Many of the Department's projects are subject to timetables which leave little room for slippage, for example, because they have to be operational by key target dates such as 6 April, the beginning of the tax year. If the definition and development of the requirement is rushed, stakeholders may not be fully consulted and a poorly defined specification may be produced. Similar risks are attached to the development of solutions.
2.20 Our investigation of the projects selected for review highlighted the value of allocating sufficient time to developing the business requirement to provide a firm foundation for EDS proposals. The scope of a project is also less likely to expand during the development stage if the Department has considered the business requirement fully.
2.21 The benefits of allocating sufficient time at this stage of a project are illustrated by the construction industry scheme project. The Department originally envisaged that the project would be procured from the private sector as a managed service under the Private Finance Initiative. To ensure fair competition and ultimate delivery of the desired service, a very clear specification was needed and the Department allowed sufficient time for this to be prepared. The Department then decided that EDS should produce the software through the normal new work process. Although the project was still in development at the time of our review, the level of EDS costs closely corresponded to its original estimates. This is attributed by both EDS and the Department to the quality of the original specification.
2.22 To reduce project development times, EDS have introduced "rapid application development" (see Figure 8) and this development tool is now used on many projects.
Rapid application development |
|
|
Figure 8 |
| |
Traditionally, software is developed in discrete stages. The user first draws up a requirement. Systems and business analysts from the information technology supplier then consider the requirement and propose a solution. This proposed solution sets out the analysts' understanding of what the user has asked for and describes how their proposed system will fulfil the requirement. The proposed solution is considered by the user, who either accepts it or requests changes. This cycle can be repeated several times until a mutually acceptable proposed solution is arrived at. Development of the system then starts. Rapid application development seeks to shorten the overall time from requirement definition to delivery of the completed system. Under the approach, the user and the systems analyst work together as a team to refine the detail of both the requirement and the solution as development takes place. As they build the system together, the analyst develops and demonstrates to the user increasingly refined versions of the system as his/her understanding of the requirement, and the user's understanding of the solution, develops. The approach tends to reduce the input required from EDS staff, saving scarce resources and cost, but at the expense of greater input from Departmental users. This input can add value to the final product because early involvement of users may not only prevent nugatory work but may also lead to additional benefits which might not have arisen using the traditional approach. The advantages of rapid application development need to be balanced against the increased risks, at least in theory, of weak control over solution development, poor documentation and the choice of a solution without sufficient consideration of alternative approaches. These risks may make rapid application development less suitable than traditional approaches for very large or complex projects without the use of appropriate controls. | ||
2.23 The rapid application development process requires the original business requirement specification to be sufficiently defined to allow the joint Inland Revenue/EDS development team to consider alternative solutions. This is because the process does not separate requirement definition, solution generation and solution evaluation as sharply as the development processes traditionally used by the Department. The broad specification and the iterative process also make it more difficult to estimate accurately at the outset the likely cost of a project. The Department addresses this difficulty by setting a maximum budget which is 40 per cent higher than the minimum estimate for the development. Any growth above the maximum budget would require specific authorisation. This limits, but does not remove, the risk of the developed solution exceeding the true business requirement.
2.24 Five of the twelve projects we examined were subject to rapid application development. One of the five reduced in scope, two showed no growth, while growth on the remaining two projects was 35 per cent (the integrated debt management system currently in development) and 93 per cent (the integrated repayments system for the Financial Intermediaries and Claims Office) (see paragraph 2.18 above). In neither case could the growth be attributed to the choice of the rapid application development approach.
2.25 Departmental project managers considered that projects carried out using the rapid application development approach tended to increase in scope, but considered that this was a reflection of the positive impact which user involvement in the development of solutions had on the quality of the final product.