Click here for search results

Guidance on Selecting SBDs for ICT Procurement



Procurement of Information and Communications Technology (ICT) --
Guidance on Selecting Standard Bidding Documents (SBDs)

(as first issued on December 19, 2003)


Project Procurement


1. This web site supports the procurement of Information and Communications Technology (ICT).  It offers downloads of single-stage and two-stage versions of the World Bank's Standard Bidding Document (SBD) for the Supply and Installation of Information Systems. The single-stage document (IS1STG SBD) was originally released for trial use in February 1999 and became an SBD in June 2002. It was further updated in March 2003, in parallel with the development of the two-stage version (IS2STG SBD). As is the case with the SBD for Supply and Installation of Plant and Equipment which 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). The two-stage version responds to para. 2.6 of the old and new Procurement Guidelines and fills an often expressed need.

2. You will also find Publication Notes for both versions.  Translations in Spanish and French are either already posted or are being prepared. If you do not find the download you need, please enquire with us. An unofficial translation of both versions in Russian, carried out by the World Bank's office in Moscow, is also available. Visitors of the web site will find "zipped" versions for reducing downloading times, and versions adjusted for the international A4 paper format. As in the past, feedback from within and outside the World Bank from using the SBDs in actual procurement will be most welcome (

3. The IS1STG SBD, and, where appropriate, the IS2STG SBD, may be used for all categories of ICT procurement. In particular, they address the specific procurement and contract needs of software packages and services, besides physical products (hardware). However, we realize that for some types of ICT procurement, these SBDs are clearly more comprehensive in approach and contract coverage than necessary. The following discussion addresses the situations where comparatively simpler procurement approaches would be adequate and acceptable to the World Bank.

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

4. 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. Procurement packages that may make use of the SBD for Goods would typically have to satisfy all of the following conditions:

  • 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; 
  • 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;
  • The logistics are straightforward enough to allow complete implementation of the contract within at most six months from contract effectiveness; and,
  • 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.

5. When the SBD for Goods is appropriate, we recommend to use the "harmonized" edition as posted on our general procurement web site, either in its trial version or, as soon as available, its standard version. The harmonized SBD for Goods explicitly supports the possibility of organizing procurement packages into lots, or of bidders organizing themselves in joint ventures, as is often conducive in ICT procurement. When producing the Schedule of Requirements, the guidance and sample structure as in Section VI of IS1STG SBD may be used.

6. The criteria listed above imply that use of the SBD for Goods would not be appropriate when the procurement package includes, for example, any of the following: (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; (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, except as provided in the next section of this note.

Use of the Request for Proposals (RFP) Approach

7. Consultants have naturally been used by our clients for the provision of intellectual services such as IS project management support, development of ICT strategies, user requirements, functional specifications and design of application software, and the assembly of ICT bidding documents. However, the use of consultants via the RFP approach has even been extended, with success, to the actual implementation of application software.

8. If a procurement focuses primarily on software design, development or adaptation services, it would, therefore, be 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). Under an RFP approach, the client 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.

9. There would need to be some customization of the World 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 World Bank's Procurement Specialist/Procurement Accredited Staff assigned to the project would need to clear these provisions, and, depending on circumstances, may him/herself need to obtain advice in the process. OPCPR is prepared to assist, among others, by providing samples for the additional or adjusted clauses.

10. 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 World 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.

11. 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.

Future Steps

12. We expect that the single and two-stage IS SBDs - in conjunction with the use of the SBD for Goods and the RFP approach in situations as defined above - reasonably cover most of the ICT procurement situations encountered in practice. This set of procurement instruments is complemented by the ICT Toolkit for TTLs as developed under the aegis of our colleagues in the World Bank's CIT Department. In line with the fast development of the field's technology and market, we plan to continue our work on improving SBDs and guidance materials, including the possible introduction of completely revised SDBs or major parts of them, as useful and necessary.