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

RPM 1

Procurement Planningfor IT Components

February 27 – March 3, 2006, Zagreb, ECA.

RPM 2

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

RPM 3

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

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

SBD for Goods

RPM 5

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:http://web.worldbank.org/WBSITE/EXTERNAL/PROJECTS/PROCUREMENT/0,,contentMDK:20153575~menuPK:84283~pagePK:84269~piPK:60001558~theSitePK:84266,00.html

http://web.worldbankorg/shop-IT

Shopping

RPM 6

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

RPM 7

… 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

RPM 8

The criteria listed below indicate circumstances when the use of SBDfor 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

RPM 9

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

RPM 10

Use of the RFP Approach

RPM 11

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 ofapplication software but this is NOT recommended.

Use of R F P

RPM 12

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

RPM 13

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

RPM 14

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 thecircumstances, may need to obtain advice in the process.

Use of R F P

RPM 15

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

RPM 16

As the software product emerging from a consultant contract gains profile/structure and permits the identification of a desirable productionsystem,

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


RPM 17

• 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 2003.

• 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).


RPM 18

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)

RPM 19

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

RPM 20

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….”

RPM 21

• 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)

RPM 22

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”

RPM 23


• 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;

RPM 24


• 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

RPM 25


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

RPM 26

• 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

RPM 27

• 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

RPM 28

• 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

RPM 29

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)

RPM 30


• 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

RPM 31


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.

Documents

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