RPM1 Procurement Planning for IT Components February 27 – March 3, 2006, Zagreb, ECA.

RPM2 Use Single and Two-Stage SBDs for Information Systems as default anytime, but especially if procurement package combines critical Goods and Service elements and the result is essential for operation; [Ideally] Requires complete specifications, but as a minimum comprehensive functional specifications. IS1STG or IS2STG SBD

RPM3 Use of the SBD for Goods for Procurement of Off-the-shelf IT Products

RPM4 The SBD for Goods may be used as an alternative when the procurement package comprises only off-the-shelf IT which can adequately be handled by the simpler payment, intellectual property, warranty and other provisions of the SBD for Goods, and where cost factors alone, or overwhelmingly, determine the ranking of bids. SBD for Goods

RPM5 The ITQ for Shopping (SH) may be used as an alternative when the procurement package is: only off-the-shelf IT and is small in value (consult thresholds in LA/DCA/PP) and can be handled by simple payment on Delivery (in any case max US$100,000); only incidental services are delivery and installation; must use the ECA Shopping Website: entMDK: ~menuPK:84283~pagePK:84269~piPK: ~theSitePK:8 4266,00.html Shopping

RPM6 Procurement packages that may make use of the SBD for Goods should satisfy all of the following conditions: 1. They define ready-made equipment and materials, pre-installed software packages and consumables only, and there is no expectation of unusual pre-bid uncertainty, i.e., the need for site visits or for staging a pre-bid conference would be the exception; 2. The services and works elements are all incidental to the purchase and would mostly be included in the price of the goods, such as installation (including the wiring of local area networks) and standard training/orientation, in total amounting to no more than around 15% in overall value of the entire procurement package; … SBD for Goods

RPM7 … 3. The logistics are straightforward enough to allow complete implementation of the contract within at most six months from contract effectiveness; and, 4. The on-going technical support required is solely for the vendor's or manufacturer's standard warranty provisions for the products and the licensed use of the software packages, both for up to three years. SBD for Goods

RPM8 The criteria listed below indicate circumstances when the use of SBD for Goods would not be appropriate: (i) transfer of business application area expertise or complex contract execution logistics which bidders need to address by a project/staffing plan; (ii) sophisticated hardware requiring an informed performance comparison and special training requirements; (iii) a dominating value of the software packages within the overall procurement, and extra installation and support requirements for these; … SBD for Goods

RPM9 The criteria … (iv) software design, large-scale adaptation and/or development; (v) the purchase and operation of telecommunications circuits or a Wide-Area Network (WAN); (vi) requirements for the supplier to continue to operate the equipment after installation; or (vii) other discrete services components. In this case, the IS1STG or IS2STG SBD must be used. SBD for Goods

RPM10 Use of the RFP Approach

RPM11 Consultants have naturally been used by our clients for the provision of intellectual services such as IS project management support, development of ICT strategies, development of user requirements, development of functional specifications and design of application software, and the assembly of IT bidding documents. In addition, the use of consultants via the RFP approach has been extended, with success, to the actual implementation of application software but this is NOT recommended. Use of R F P

RPM12 If a procurement focuses primarily on software design, development or adaptation services, it is acceptable to use the RFP approach, i.e., procure the required software work in the form of "consultant" services, including the options of using lump-sum and time-based contracts. The assignment should also be of a nature where it is more important to make progress in understanding and shaping the likely end product (such as by creating a pilot) than in procuring a fully production-worthy system with precise functional and performance indicators (which would rather call for the use of the IS SBDs). Use of R F P

RPM13 Under an RFP approach, the Borrower assumes a larger risk, therefore there should be less at stake in the sense of a critical production outcome. Further, the hardware and packaged software content should be minimal, e.g., less than 20% of the estimated contract value, at the most allowing the consultant to procure a development platform as part of the contract price. Use of R F P

RPM14 There needs to be some customization of the Bank's standard Consultant contract form: to address property rights to the software to be developed, secure ongoing warranty/support after the end of the development work, determine the disposition of the development equipment and development software licenses, lay out the approach to testing and acceptance, and customize the payment clause for milestones/achievements reflecting software development (rather than report writing as in the typical consultant assignment). The PS/PAS would need to clear these provisions, and, depending on the circumstances, may need to obtain advice in the process. Use of R F P

RPM15 To the extent that is practical, the development of an Information System via the RFP approach should avoid determining the hardware and software brands that will have to be used for the future production environment. If, after seeking the Bank's advice, such determination still cannot be avoided, the need for possible brand pre- determination via the assignment should be made explicit in the RFP so that consultants expressing interest (and their possible partners) would be aware of the full stakes of the procurement. Use of R F P

RPM16 As the software product emerging from a consultant contract gains profile/structure and permits the identification of a desirable production system, the scaling-up, finalization and deployment/roll-out of the production-version of this Information System would, in most instances, necessitate separate procurement using either the IS1STG or IS2STG approach. IS1STG or IS2STG SBD

RPM17 There are single-stage (IS1STG SBD) and two-stage version (IS2STG SBD) of the Standard Bidding Document for Supply and Installation of Information Systems on the website. They were updated in March The SBD for Supply and Installation of Plant and Equipment served as the model for the IS SBDs. The single- and two-stage versions differ from each other only in the Preface, the Invitation for Bids, ITB, BDS and the Bid Form(s). The two versions are identical in all other aspects, namely, the sections on Eligibility, GCC, SCC,Technical Requirements, and Sample Forms, except for the Bid Form(s). IS1STG or IS2STG SBD

RPM18 Use Single-stage SBD for Information Systems (IS): Procurement is simple e.g. “supply and install” Technical requirements are well defined and can be defined by clear technical specifications; Buyer is clear what technical solution is required; Solution can be met by products that are already available; Procurement involves simply buying and installing a large number of computers and off-the-shelf software; Design risk is borne by the Purchaser; IS1STG (Single Stage)

RPM19 IS2STG (Two Stage) Purchaser is not clear what technical solution is required and there are still choices to be made or when it is unclear whether complete solutions are available from potential bidders; Requirements are defined by business processes; when the submission of technical alternatives is actively encouraged; when it is important to gain confidence via the bidding process about acceptable and desirable solutions (including the possibility of testing proposed solutions); Development risk is borne by the Supplier; Requires more time than SS (usually 4-5 months).

RPM20 Plan Contract Management (1) Fully consider component sustainability –avoid specific “IT” Components in Project Design; –ensure that end-users are involved from the beginning of system design; –encourage end users to actively participate at all stages thus engender ownership; –ensure system requirements are defined by users and not “techies” Agree on resources provided by Borrower/Beneficiary –if there is and element of investment then more likely to lead to feeling of ownership; Agree on implementation and acceptance methodology –You wouldn’t buy a car without a test drive….”

RPM21 Use Turnkey implementation only where Beneficiary capacity is low (integration) –Cost is low ownership Consider pre-qualification, LIB and two-stage procedures only in response to special requirements; Add training of technical staff of the Beneficiary in Project planning and contract management Plan Contract Management (2)

RPM22 Approaches for dividing and packaging Single responsibility (“turnkey”) contract(s), including integration –Suitable for end-to-end design, development and implementation; –“Lock Contractor in a room and throw away the key until they finish” –Single Point of Responsibility… BUT –Significant risks as cannot control development may get something different than what is expected; –“Beetroot” vs “Carrot”

RPM23 Approaches for dividing and packaging Separating the application software development from hardware procurement –Software design done under RFP; –Software development done under SIIS; –Software design and development done under SIIS; –Hardware procurement done under Goods; RISK – successful integration; BENFIT – efficiency in procurement;

RPM24 Approaches for dividing and packaging Building on existing developments (if they hold promise) –Based on strategy document; –Based on a developed design (user requirements/functional specifications) –Based on existing system (fully or partially developed), want to expand Possible justification for SS/DC Possible justification for Brand Names

RPM25 Approaches for dividing and packaging Phasing application software development (prototyping, RAD, piloting, partial and full “roll- out”) –Allows single contractor to do all; or –Have a split approach (design, development, roll-out) –Design and supervision. –Implementation and roll-out.

RPM26 Prototyping –Largely hands-off by Purchaser –May already have a prototype developed; or –Have a small contract to design and develop a prototype (ICB) –Review/assess (Consultants/Purchaser); –Technical specifications for changes (Consultants); –Goods contract for Implementation and roll-out. Approaches for dividing and packaging - Prototyping

RPM27 RAD (Rapid Application Development) –Close involvement by Purchaser (ownership) –Usually single contract for D/D/Imp. (ICB) –Review/assess (Purchaser/Consultants); –Technical specifications for changes; The system will evolve (continuous versions) Requires hands-on by Purchaser/Beneficiary Approaches for dividing and packaging - RAD

RPM28 Piloting –Requires several stages –Usually single contract for D/D/Imp. (ICB) –Result is a pilot (test installation in a single region, or partial functionality) –Review/assess (Purchaser/Consultants); –Technical specifications for changes; May have a modified pilot May have expanded pilot –Clear Roll-out stage (can be Phase II or separate contract) Approaches for dividing and packaging - Piloting

RPM29 Approaches for dividing and packaging - Piloting Piloting (partial and full roll-out) –May require several contracts –Usually single contractor responsible for a region; –Roll-out usually used for hardware purchase and installation; –Usually use already developed software; –Generally will be simple goods (supply and install no additional services required)

RPM30 Approaches for dividing and packaging Splitting procurement and managing several suppliers (splitting in time, geographically, by type of procurement package) –RFP approach for design (also possibly supervision); –ICB for development (Single or Two-Stage); –ICB for implementation (roll-out) –Single package, but split geographically in lots Have to define inputs and outputs (interfaces) Have option to choose best solution Have ‘alternative’ if something goes wrong

RPM31 Approaches for dividing and packaging CHOICE between APPROACHES: Each approach has its own set of pros and cons. Actual approach used needs to fit the situation. Above all must reflect Borrower’s competence and will.