bid management and negotiations

8/6/2019 Bid Management and Negotiations

1/93

1 | P a g e

2008

Bid Management and

Contract Negotiations for

IT Services ProjectsJaveed Ahmed

(Consultant)

All Rights Reserved. Copyright 2008. Javeed Ahmed


2/93

Managing IT Services Project Risks at Proposal and Contract stage


TABLE OF CONTENTS

1. Preamble ................................................................................................................................................................ 7

1.1 Scope of the document ................................................................................................................................... 7

2. Introduction ........................................................................................................................................................... 8

3. Project Stages and Risk Management.................................................................................................................. 9

Table 1 : Project Stages and Risk management ...................................................................................................... 9

4. Pre-Proposal Stage: Bid or No- Bid Decision..................................................................................................... 10

4.1 Bid/No- Bid decision ...................................................................................................................................... 10

4.2 Consequences of delaying taking bid/no bid decision .................................................................................. 10

4.3 Critical Issues to consider for the bid/no bid decision .................................................................................. 11

4.4 Recommendations for the bid/no bid decision ............................................................................................ 12

5. Proposal................................................................................................................................................................ 13

5.1 Pre Proposal Due Diligence ........................................................................................................................... 13

5.1.1 Draft Contract Document ................................................................................................................................. 13

5.1.2 Scope of Work .................................................................................................................................................. 13

Example 1: Example of unclear requirements ...................................................................................................... 14

5.2 Strategies for preparing a winning bid .......................................................................................................... 14

5.2.1 Looking at risks from the Customers perspective........................................................................................... 14

5.2.2 Need Statement ............................................................................................................................................... 16

Example 3: Addressing Customers Special Needs................................................................................................ 16

5.2.3 Project Vision ................................................................................................................................................... 20

Example 4: Project Vision for an Enterprise data warehousing and Business Intelligence Solution .................... 20

5.2.4 Project Objectives ............................................................................................................................................ 20

Example 5: Project Objectives for an Enterprise data warehousing and Business Intelligence Solution ............. 20

5.2.5 Project Benefits ................................................................................................................................................ 21


3/93



Example 6: Project Benefits for an Enterprise data warehousing and Business Intelligence Solution ................. 21

5.2.6 Innovative Pricing Model for winning Projects ................................................................................................ 22

Example 7: Innovative Pricing model .................................................................................................................... 22

5.3 Areas of focus at Proposal stage ................................................................................................................... 25

5.3.1 Dependency Risks............................................................................................................................................. 25

Interfaces............................................................................................................................................................... 26

5.3.2 Commercially Available Off the Shelf Solution (COTS) .............................................................................. 26

5.3.3 Subcontracting Risks ........................................................................................................................................ 27

5.3.4 Suppliers .................................................................................................................................................... 30

5.3.5 Hardware Sizing: .............................................................................................................................................. 31

Sizing Parameters .................................................................................................................................................. 31

Sizing Process ........................................................................................................................................................ 31

Risk Transference .................................................................................................................................................. 32

5.3.6 Timelines .......................................................................................................................................................... 32

Example 8 Negotiating timelines........................................................................................................................ 32

5.4 Dealing with identified risks in the contract at the proposal stage. ............................................................. 34

Example 9: Options to deal with identified risks .................................................................................................. 34

Example 10: Seeking modification of proposed clause during negotiation: ........................................................ 35

5.5 Pricing for risks .............................................................................................................................................. 36

Pricing of Program Risks ........................................................................................................................................ 37

Pricing of Risk for Hardware sizing ........................................................................................................................ 38

Pricing of Risks on account of effort variation in fixed price contract .................................................................. 39

Pricing of Maintenance contracts ......................................................................................................................... 40

Maintenance Contracts Negotiating under difficult Economic and Business Conditions .................................. 43

5.6 The Proposal Document ................................................................................................................................ 43


4/93



5.7 Proposal Defense .......................................................................................................................................... 44

6 Contract Negotiations.......................................................................................................................................... 46

6.1 Types of contract ........................................................................................................................................... 46

6.1.1 Time and Material Contracts ........................................................................................................................ 46

6.1.2 Fixed Price Contracts .................................................................................................................................... 46

6.1.3 Time and Material Contracts with a cap ...................................................................................................... 47

6.2 Important considerations for Negotiation .................................................................................................... 48

Main items for Negotiation ................................................................................................................................... 48

6.3 Letter of Intent .............................................................................................................................................. 49

6.4 The Contract Document ................................................................................................................................ 50

6.4.1 Scope and Delivery related clauses .............................................................................................................. 50

6.4.1.1 Solution Ownership ................................................................................................................................... 50

Example 11: Solution Ownership .......................................................................................................................... 50

6.4.1.2 Project Commencement Date ................................................................................................................... 51

6.4.1.3 Simplifying Scope....................................................................................................................................... 51

Example 12: Simplifying Scope .............................................................................................................................. 52

6.4.1.4 Clauses to cover dependency risk.............................................................................................................. 53

Example 13: Dependency Risk .............................................................................................................................. 54

Example 14- Customers Obligations included in a contract: ............................................................................... 56

6.4.1.5 Change Control.......................................................................................................................................... 61

6.4.1.6 Maintenance Contracts - Service Level Agreement................................................................................... 62

Example 15: Negotiating for Service Level (SL) ..................................................................................................... 62

Generally Accepted Service Level Principles ......................................................................................................... 65

6.4.1.7 Back to Back SLA with partner.................................................................................................................. 66

6.4.1.8 Availability SL ............................................................................................................................................ 66


5/93



6.4.1.9 Maintenance Contracts Effort Estimates and Pricing ............................................................................ 67

6.4.1.10 Maintenance Contracts - Efficiency sharing............................................................................................ 67

6.4.1.11 Maintenance Contracts Benchmarking of Effort.................................................................................. 69

6.4.1.12 Maintenance Contracts

Exclusivity Clause ..................................................................................... 70

Example 16: Maintenance Contract Benchmarking and related clauses ........................................................... 70

6.4.1.13 Maintenance Contracts Term of the Agreement............................................................................ 71

6.4.2 Legal Clauses ................................................................................................................................................ 72

6.4.2.1 Complete Agreement and Complete Offer Clause .................................................................................... 72

Table 2 List of Contract Documents ...................................................................................................................... 72

6.4.2.2 Termination Clause.................................................................................................................................... 73

6.4.2.3 General Damages...................................................................................................................................... 74

Limiting Applicability of General Damages in a Contract based on competitive bidding ..................................... 74

6.4.2.4 Exclusions in the General Damages definition .......................................................................................... 75

6.4.2.5 Affiliates .................................................................................................................................................... 76

6.4.2.6 Indemnities................................................................................................................................................ 76

Example 17: Representations and Warranties ..................................................................................................... 77

6.4.3 Commercial .................................................................................................................................................. 77

6.4.3.1 Payment Terms.......................................................................................................................................... 77

6.4.3.2 Bank Guarantee for Performance ............................................................................................................. 78

6.4.3.3 Project Funding ......................................................................................................................................... 78

6.4.3.4 Pricing Granting of Most Favored Customer Status............................................................................... 79

6.4.3.5 Audit......................................................................................................................................................... 81

6.4.3.6 Liquidated Damages................................................................................................................................. 82

Example 18 - Liquidated Damages ........................................................................................................................ 82

7 Re-negotiating Contracts .................................................................................................................................... 83


6/93



Example 19: Re-negotiating Contracts - Networking ............................................................................................ 83

Example 20: Re-negotiating Contracts - Synchronizing Objectives of stakeholders ............................................ 85

8 Process owner for the Bid Management and Negotiation process.................................................................. 87

8.1 Role and Responsibility ................................................................................................................................. 87

8.1.1 Mandatory Review of Proposals: ................................................................................................................. 87

8.1.2 Providing Guidance: ..................................................................................................................................... 88

8.1.3 Review of Contract Documents: .................................................................................................................. 88

8.1.4 Transition to Delivery: .................................................................................................................................. 88

8.2 What Delivery needs to know about the Contract ....................................................................................... 89

8.3 Structural Issues ............................................................................................................................................ 91

8.4 Risky Projects ................................................................................................................................................ 92

9 Conclusion............................................................................................................................................................ 93


7/93



1.Preamble

This document has been written from the perspective of Supplier of IT services. The term SupplierSystem Integrator (SI), Prime or Prime Contractor, or Bidder have been used in this document asappropriate based on the context and signify the same entity. The context of this document is

competitive bidding based on a Request for Proposal from a Customer.

1.1 Scope of the document

The document covers the Bid Management and Contract negotiation process as well as theprocess for transition to delivery to ensure a successful and safe bid and contract.

The coverage of risks arising from the contract and the risks that can be prevented or mitigatedthrough appropriate measures during the bidding and contract process is a special feature of thisdocument. The body of knowledge available on this subject is meager. As we move from simple

Time and Material contracts to fixed bid contracts and now to ever more complex multi VendorSystem Integration contracts, there is a need to build the required competency and establish bestpractices. This document is an attempt in that direction.

Intended Audience

The intended audience of this document is the Suppliers bid management and negotiating teamsas well as the Program and Project Managers. It is hoped that the document will provide freshinsights on the subject to the practitioner. This document is not meant to be a textbook on thesubject.


8/93



2.Introduction

The goal of project management is completion of Project on time, to specification and withinbudget. In the case of maintenance and support projects, the goal is to achieve service levels on

a consistent basis, within budget and with higher efficiencies year on year. The objectives of riskmanagement are to ensure that this happens.

A large System Integration Project involves bringing together multiple products and servicesfrom multiple parties into an overall integrated Solution architected and lead by the SystemIntegrator who is also usually the prime contractor. The activities of these multiple parties haveto be coordinated, the interdependencies have to be identified and managed, the progress of allparties have to be meticulously tracked to ensure that the efforts converge in delivering the finaintegrated solution. The negotiations and drawing up of the contract needs to be managed toensure that the prime contractor does not end up carrying risks that are transferable. Proper riskidentification and risk transference are therefore key activities during the proposal and contractstages for a prime contractor. The contract document creates a structure of roles and

responsibilities, rewards and penalties, communication, escalation and dispute resolutionmechanisms, change control procedures, acceptance criteria etc. These are the enablers aswell as constraints and govern behavior of the parties during contract performance. In a SystemIntegration Project the structure is complex owing to the involvement of multiple parties in thedelivery process. The sub contract must be aligned with the Prime contract to facilitate ratherthan frustrate the delivery process. This document lists the issues and shows a way to deal withthe complexity.


9/93



3.Project Stages and Risk Management

The project goes through distinct stages. The actions and decisions to be taken at each stage are shownbelow:

Table 1 : Project Stages and Risk management

RiskManagement

STAGES

Critical Issues Actions

PreProposal

(Predict andPreventRisks)

Bid/No Bid decision. What are the benefits ofdoing the project and what are the associatedrisks? Are the benefits commensurate with the

risks? If yes, how to improve the chances ofsubmitting the winning proposal with acceptablelevel of risks?

A formal document may be prepared fotaking the bid/no bid decision.

A pre designed scoring sheet is also inuse in many organizations to take thebid/no bid decision.

Proposalpreparation

(Predict andPreventRisks)

What are the risks over which Supplier hascontrol? What are the risks over which theCustomer has control? What are the risks overwhich partners have control? Can theresponsibility for risk management be transferredto the party which has control? How to make eachparty responsible for managing the risks overwhich they have control? What are the possibleconsequences of failing to manage the risks well?

How can each party be made to take responsibilityfor the consequences of risks that are notmanaged well? What specific clauses need to benegotiated and incorporated in the contract?

The proposal could cover Suppliersexpectations from the Customer inmanaging the risks under their control.Supplier could also propose at thisstage, specific clauses in the contractthat they would like to be included incase this is considered safe.

A document may be prepared on the

subject for the legal/commercial teamsto secure a `safe deal.

Contractnegotiation

(Mitigaterisks)

How to negotiate and secure a safe deal? The negotiating team may be providedwith full details of the risks and the riderthat need to be added to the proposedclauses.

Contractperformance

(Pro act andmanagerisks)

How to manage the risks? What data needs to becollected to detect emergence of risk, whatreporting mechanisms need to be in place, what isthe escalation plan based on severity of issues?

Should risks emerge, is there a plan for managingthem and a mechanism for monitoring the successof the measures until the risks are contained?

Agreement with various parties on thereporting, communication and escalatioplans, and templates to use.


10/93



4.Pre-Proposal Stage: Bid or No- Bid Decision

4.1 Bid/No- Bid decision

The objective of a bid/no bid decision is to:

Avoid a contract that is difficult or impossible to complete within budget and within the giventime or is otherwise too risky.

Avoid the effort and expenses of putting in a bid where the chances of winning are slim

Go all out to win and secure a safe deal when execution is considered possible, chances ofwinning fair and risks that are acceptable or can be mitigated, transferred or shed.

The bid/no bid decision is therefore of considerable importance and must be taken early for the followingreasons:

A clear decision to bid implies `just go and win it. It empowers the bid manager to employ allnecessary resources to submit a winning proposal and adopt a comprehensive approach to RiskManagement without which, certain aspects are ignored since `we may not win anyway! In Riskmanagement, this is the stage where risks can be prevented. In later stages, only mitigationis possible.

The Project Manager can be identified once a decision to bid is taken who can then be associatedwith the bid process. His/her experience coupled with the delivery responsibility, assures acomprehensive approach to risk management. Identification of the PM is a clear signal to allparties regarding the seriousness of intent which goes a long way in ensuring a successful bid.

4.2 Consequences of delaying taking bid/no bid decision

Quite often there is no explicit bid/no bid decision taken. The consequences are:

The bid process once begun quickly acquires momentum and it is very difficult to halt itmidway. There are considerations such as loss of face internally, with partners, Customer etcall of which make decision making difficult.

A late decision of no bid is often diluted into a decision of bid to lose. This may be worse thandeciding to withdraw. The bid team is demoralized more by such a decision rather than with aclear decision to withdraw. Also, if this happens too often, partners begin to lose trust. There isalso the risk of winning an unwanted contract inspite of bidding to lose.

The fact that there is no explicit decision taken to bid also takes away the certainty ofOrganizational support for the bid all the way through which is crucial to submitting a winningproposal.

Key activities that require considerable effort such as completing all subcontract arrangementsbefore the proposal is submitted are often ignored.


11/93



4.3 Critical Issues to consider for the bid/no bid decision

Analysis of the Customer:

Would we like to do business with the Customer? What is the reputation of the customer for

fair play, reasonableness and meeting commitments

What is the Project budget? Is the budget adequate for meeting all critical requirements othe customer?

Competition Analysis:

Who are the competitors?

What standing/influence do they have with the customer?

Are they already working with the customer?

If already working with the Customer, then how is their delivery performance?

What are the relative strengths and weaknesses of the competitors

What is the likely strategy of the competitors and what are their strengths and weaknesses?

What alignments exist between competitors and Solution Vendors?

What is the strategy for overcoming the competition?

What is the confidence level in overcoming the competition?

The Requirement:

Are the requirements detailed enough to make a good estimate of effort?

What further details are required? Is there an opportunity for getting further details as partof the pre-bid process?

What is the familiarity with the domain and the technology?

What processes are required to execute the project? Are all the processes suited to theactivities necessary to accomplish the project goals defined and documented? What is theprocess maturity or what projects have been executed using the processes?

Is it possible to come up with accurate effort estimates with a high level of confidence?

What are the grey areas and the associated risks?

What are the dependencies on the customer and other third parties?

Do we have a clear understanding of the stated and unstated vision, goals and objectivesof the project?


12/93



Does the customer have a preference for any Solution or Technology?

Partners and Sub Contractors:

Is there need for partners and/or Sub contractors?

Have the partners/sub contractors been identified?

Is there prior experience of working with the partner/subcontractor? If yes, any pointers towhat may be expected?

Has responsibility been assigned for executing necessary teaming agreements with cleardeadlines for execution?

Has the scope of work been defined for the partners and the terms and conditions in theteaming agreement defined with traceability to the prime contract draft?

Is there choice of more than one partner/sub contractor for the same purpose before/afterthe proposal is submitted?

For all the high value items of project cost, have we identified partners who can bedepended upon to cooperate with us in submitting a winning bid?

Project Budget:

What is the budget for the project? Can we submit a proposal within the budget whilemeeting all critical requirements of the customer?

Prime contract:

What risks does the draft contain?

What risks can be shed or transferred?

What is the plan to manage the risks that cannot be shed or transferred?

Strategic Benefits

Are there any strategic benefits in executing this project such as: building capability in anarea where the Supplier would like to grow, build a reference able customer, or expectation

of other downstream projects etc?

4.4 Recommendations for the bid/no bid decision

Reasoned recommendations for the go/no go decision to be formally put up to a high level Decisionmaking authority based on assessment as above jointly by Proposal Owner and Relationship Owner.


13/93



5.Proposal

5.1 Pre Proposal Due Diligence

5.1.1 Draft Contract Document

The set of RFP documents distributed by the Customer also includes a draft Prime Contract or clausesthat the Customer intends to include in the contract. The terms of the draft agreement have the interests ofthe Customer in mind and may therefore appear to be one-sided. However, customers are seeking toforge a long term partnership with their suppliers and are willing to recognize and accommodate thesuppliers concerns. The suppliers concerns are quite often met by adding details to the clauses proposedby the Customer and this is easily accomplished during the negotiation process. Contract negotiation is aprocess during which a relationship of mutual understanding and accommodation is built between theCustomer and Supplier. The fear that the proposal may be rejected if all the terms are not acceptedwithout qualification is unfounded. This document contains examples where the Supplier has expressed adiffering view point that was readily accepted. Contract negotiation is not an adversarial process or about

winning an argument. The Suppliers negotiating team must respectfully state their position clearly andwith sound justification.

The terms of the draft Prime Contract must therefore be carefully considered at the proposal stage as wellas the modifications that need to be negotiated. If the modification that is to be negotiated does not negatewhat is proposed by the customer but merely describes the boundaries, then response to the clause is`Will Comply and the comment column may be used to add the riders. In the rare instance that aproposed clause is unacceptable under any circumstances, then the Suppliers position may be statedbriefly but clearly, leaving the final outcome `to be negotiated indicating a willingness to accommodate avalid counterpoint. A principled approach at the very beginning helps to build a relationship based onequity and mutual trust. One sided clauses can be easily shown to be inimical to the achievement of thebroad project objectives and therefore against the larger interests of the Customer. The pre bid opportunity

for seeking clarifications must be utilized for clearing all ambiguity.

5.1.2 Scope of Work

The RFP document sometimes comes with a disclaimer as regards scope of work. The Supplier isexpected to conduct independent due diligence on the scope of work. The due diligence is facilitated if theSupplier has a checklist for different types of Projects. The check list also comes in handy for seeking prebid clarifications. In brief, the information available in the RFP document together with the clarificationsmust be adequate to determine effort and skill sets required. Any inadequacy must be highlighted as arisk. This could be on account of not receiving a comprehensive response to the clarification sought. Forobvious reasons, it should not be on account of failure to seek the required clarification.

A basic requirement for a firm price bid is fixed scope. The Customer is therefore under an obligation tosupply all information required to correctly assess effort required. The customer may define scope inbusiness terms. For the supplier of IT services, it needs to be translated into metrics that enableestimation of effort required.

For example:

Number of Business Processes and distribution by complexity.

The complexity may be defined in terms of number of Functional Points per business process.


14/93



If the Customer has listed all the business processes and given enough information for classifying theseby complexity, then the scope may be defined with reference to this list.

Change in scope would therefore be additional business processes. If the formula for calculating additionaeffort and additional billing is incorporated in the contract, then there is no need for any negotiations duringcontract performance on the commercial aspects of change in scope. The change control procedure can

be an effective mechanism to control effort and costs only if the scope of work and requirements aredetailed and specific. The requirements section should not contain words such as `etc.

Example 1: Example of unclear requirements

A Banking Customer had the following in the requirements section:

Government Pensions

A COTS (Commercial off the shelf) solution was offered that had Government pensions as one of the

modules. During implementation, it was discovered that the COTS solution catered to Central

Government Pensions only. The Customers requirements covered Defense Pensions and Pensions of

the Punjab State Government also which the COTS solution was incapable of handling and required

considerable development.

5.2 Strategies for preparing a winning bid

5.2.1 Looking at risks from the Customers perspective

The key to preparing a winning bid is to look at Project Risks from the Customers perspective and to

address the Customers key concerns in a manner that assures the Customer that the Supplier:

Is fully cognizant of the risks

Has a workable plan to address all the risks in an apt manner

Has a track record to prove that the Supplier has successfully executed similar projects

The RFP document sometimes contains an explicit procedure and criteria for evaluation of a proposal. In

such a situation, the task is clearly cut out. Sometimes, the criteria are not spelt out. A risk document from

the customers perspective can be prepared in such a situation. This would help prepare a proper

response covering in detail areas that are apparently critical from the customers perspective.

Example 2: Strategy for winning proposal bid

Let us consider the following scenario

A prospective Customer from the airlines industry is planning to implement the next generation coresystem for Passenger Services by a certain date;

they also have ancillary business to cater to a passengers other requirements for hotel bookings, carbooking, tour packages etc which is catered to by a custom application


15/93



If this Custom Application is to be reengineered with vastly enhanced functionality, and be ready to beimplemented and integrated with the new generation Core system in time then,

The risk to the customer if the Application for ancillary business is not ready in time is to suffer

considerable loss of ancillary business with possible impact on the main business itself. Time and quality

are therefore of the essence.

The Customer would therefore try to de-risk the situation by:

Ensuring that the supplier has experience in implementing a system for other airlines of similarcomplexity and size. Lack of this would imply the following risks:

o Inaccurate effort estimates

o More defects due to lack of understanding of domain requiring longer time to fix problemsand more iterations

o Delay in delivering the project

o Quality and Support issues

Assessing the suppliers capability and familiarity with projects of this nature from the project planwhich should contain :

o Granular level tasks,

o key milestones, timelines

o resource plan (suppliers as well as customers business / IT personnel)

o Clear definition of the roles and responsibilities of each party in each stage of the projectimplementation

Assessing the Suppliers implementation approach and best practices for minimizing risks.

Assessing the Suppliers software development quality assurance process to ensure that the qualityis able to satisfy Customers requirements with minimal errors, defects and bugs on all codedeliveries so that agreed functionality can be implemented on time.

Assessing whether the Project Plan contains meaningful review checkpoints at periodic intervals toensure that the project is on track.

Assessing Suppliers cultural fit to minimize behavioral risks. Inability to get cooperation from thebusiness user could seriously jeopardize quality and timelines.

Assessing the Suppliers capability to identify the risks correctly and to come up with a workable planto prevent/mitigate the risks.

Assessing the Suppliers Technology competence for the Technology stack proposed for the Solution

A response that merits serious consideration would have to cover all of the above areas

comprehensively. If the Supplier has not executed a similar project before, then the following

considerations may become important:

Does the Supplier have case studies of having implemented equally complex systems in any industryfirst time which was delivered on-time and with low defects? What are the best practices for achievingsuccess in first-time projects?

What are the risks in first time projects of equal complexity from the Suppliers perspective? Whatstrategies, the supplier has adopted in the past and with what results?

How many such first time projects has the Supplier delivered successfully?

Does the cumulative experience add up to an assured approach for any first time project of similar


16/93



complexity?

What investments the supplier is willing to make or makes in first time projects

Is re badging an important part of the strategy? If yes, then is this possible in the current context?

How does the Supplier deal with cultural diversity

A de risking strategy for first time projects could be for the Supplier to have a plan to complete all the

development work for mostcritical compulsory functions by a date far ahead of the implementationdate for the new generation system and have an end-to-end system walk through and review with thecustomer. (This allows the customer enough time to take appropriate action which could be a) Allowthe Supplier to go ahead with the Project and complete the remaining functionality b) Change theSupplier if the progress is unsatisfactory c) Find interim solution such as develop interface with theexisting systems.)

To have a fair chance of winning such a bid, the response has to be reassuring to the Customer from

their perspective of risk.

5.2.2 Need Statement

Apart from looking at risks from the Customers perspective, the response should be anchored around a

clearly articulated needs statement of the Customer. The RFP document may or may not contain a well

articulated need statement apart from scope. Even where, the Customer has included a need statement,

the same may be paraphrased or improved upon based on Suppliers understanding of what value the

Customer would appreciate in the offering. This is different from the value propositions. Value proposition

may come at the end of the response and must clearly relate to the need statement at the beginning of the

proposal. The need statement serves two very useful purposes:

1. Brings clarity and structure to the response

2. Makes a powerful and favorable impact on the Customer who begins to believe that the Supplier is

worth doing business with and improves the chances of being called for negotiations. The

Customer is more likely to overlook other shortcomings such as the commercials not coming up to

the expectations, if they believe that the Supplier is truly interested in going the extra mile to

discover and address the Customers special needs.

Example 3:Addressing Customers Special Needs

A Product Company requests for a proposal for IT Services covering:

1. Maintenance and Support of their Solution implemented at various customer sites

2. Development of enhancements to the Product based on Customer requests.

The first part viz. Maintenance and Support is a standard practice for Suppliers of IT Services and will not be


17/93



covered.

The special features of the second requirement is covered below:

Development:

All Development activity is related to enhancements that the Product Company will commission as a result of

request from their Clients. This is going to be a continuous and repetitive activity over the life of the engagement

with new requests flowing in from time to time. The process for carrying out the enhancement activity must

therefore be clear and robust to stand the test of time.

The needs of Product Company are likely to be as follows:

A process that assures a fair price for all development activity every time. It should be transparent and

auditable

A high conversion rate of requests for budgetary estimate for enhancements to Purchase Orders

Year on Year increase in productivity through learning, trainings and development of productivity tools. Aclear plan and appropriate metrics to measure success against plan. The benefits to be shared with

Customer.

Decrease in costs through use of appropriate number of well trained junior level resources.

Quick turnaround for responses to requests for budgetary estimates and for delivery against Purchase

Order. Supplier to maintain sufficient development resources and have the ability to quickly ramp up

resources to meet time commitments

Quality Assurance

All invoices relating to development to be based purely on enhancements alone to enable Product

Company to pass on all development costs to the Customer seeking the enhancement. In other words no

invoicing other than for enhancement.

The needs of Supplier are likely to be:

Visibility into plans of Product Company so that effective resource planning is possible

High loading factor of development resources

A clean well understood process that is followed uniformly for all enhancements

Fulfillment of obligations by Product Company/their Client relating to Suppliers dependencies in the

process to be followed for each enhancement.

A broad outline of the enhancement process that contains an assurance of fair pricing of enhancements to Product

Company and also derisks the Supplier against possible miscalculation of effort at initial stage is described below:

Step 1- Request for enhancement. Product Companys Customer comes up with a request for

enhancement. At this stage, the requirement is at a high level in the language of the Business User.

Step 2- Budgetary Estimate. Supplier submits a budgetary estimate based on the request

Step 3 Go/No go decision. Customer communicates approval based on budgetary estimate or

communicates lack of further interest. If the Customer does not approve the budgetary proposal, the


18/93



enhancement is shelved and there are no payment obligations for the effort in submitting a budgetary

proposal. If the Customer approves the proposal, the process is taken forward and the Customer becomes

liable for all efforts if the final estimate is within budget.

Step 4 User Requirements Document. If the go ahead is given, detailed requirements are collected and

URD is prepared and submitted by Supplier. The effort estimate is reassessed based on detailed URD. The

likely scenarios are:

o Reassessed effort is within budgetary estimate and if

Customer decides to go ahead then proceed to next step

If Customer decides to drop the enhancement, bill for the effort in doing the URD and

preparing the estimates

o Reassessed effort is greater than budgetary estimate communicate to customer and get clearance

for going further. If clearance does not come forth, the enhancement is dropped without any

obligation to customer. If the customer decides to go ahead, then proceed to step 5. The budgetary

estimate stands revised.

Step 5 Functional Specifications Document. Supplier prepares the Functional Specifications Document and

the System Specifications Document. Effort is reassessed

o Reassessed effort is within budgetary estimate and if

Customer decides to go ahead then proceed to step 6

If Customer decides to drop the enhancement, bill for the effort upto this stage

o Reassessed effort is greater than budgetary estimate or revised estimate at previous stage

communicate to customer and get clearance for going further. If clearance does not come forth,

the enhancement is dropped without any obligation to customer. If the customer decides to go

ahead, then proceed to step 6 and the budgetary estimate stands revised to the new estimate.

Step 6 Detailed Design. Supplier prepares a detailed design and comes up with a final estimate as well as

implementation plan. From here on, the price and delivery timelines are fixed

o Customer approves Kick off enhancement and go to step 7

o Customer does not approve since final estimate is higher than budgetary estimate or revised

estimate at previous stage. Enhancement dropped without any obligation to customer

o Customer does not approve although final estimate is within estimate at the end of previous stage.

Customer pays for efforts upto this stage.

Step 7 Development, Implementation.

The outlined process has the following advantages:

The Customer has no obligation to proceed with the enhancement or pay for the Suppliers efforts

unless the final proposal is within the approved budgetary price or the approved revised price at

the end of previous stage.

The Suppliers efforts are compensated when the final price is within the approved budget even if

the Customer chooses to shelve the enhancement.

The Supplier has the option to revise the price in any direction based on final detailed analysis of


19/93



requirements, specifications and design. In case the Supplier revises the price upwards and the

Customer chooses not to go ahead, then the only risk to the Supplier is of wasted effort upto the

stage at which the price is revised upwards. The probability of occurrence of such an event is low

since on most occasions, the budgetary estimate is likely to be higher than the final refined

estimate.

The process provides for continuous refinement of the estimate which benefits the customer on

most occasions. It also derisks Supplier should the final estimate be significantly higher than the

budgetary estimate.

The process is transparent and fair to all parties. The customer gets the enhancement at least cost

as it is based on the final estimate that is closest to actual effort with no buffers or cushions. The

risk to Supplier is also minimized.

The natural inclination to play safe by quoting a considerably higher price for budgetary purpose is

checked by the fear of killing the opportunity early, if the Customer does not see value vis--vis the

budgetary estimate. Norms can be evolved and stipulated as Key Performance index (KPI), if felt

necessary, requiring that the budgetary estimate is no higher than 15% of the final refined

estimate. Another KPI of interest to all parties is the proportion of requests for enhancements that

are converted to Purchase Orders.

Productivity norms can be agreed to and revised from time to time based on actual project metrics,

bringing in further transparency into the effort estimates. The Supplier can also plan for systematic

improvement of productivity through learning on the job, trainings and development of

productivity tools and show the customer increasing value in the relationship Year on Year.

Billing rates for Development

Under the best of circumstances, the loading factor for development activity will not exceed 80 -85%. If it exceeds

85% then it implies that many of the requests will have to wait in a queue before being addressed. If it is low, then

the cost goes up. It is therefore fair to assume and maintain a loading factor of 80% in the long run. The billing rate

for the Development resources can then be justifiably be higher by 25% when compared with an equivalent

resource for the maintenance activity. If the loading factor exceeds 80%, then the Supplier could agree to share the

benefit with Product Company.

The approach as outlined above is likely to find favor as it meets the critical concerns of the Product Company. The

other aspects of the process such as Quality Assurance etc are not touched upon since these pertain to standard

practices of the Supplier.


20/93



5.2.3 Project Vision

In the normal course, the Project Vision should come from the Customer. In the absence of it, the Supplier

could attempt to abstract the Project Vision from the requirements statement. Given below is an example

of a Vision statement for building an Enterprise Data warehouse Solution for a customer.

Example 4: Project Vision for an Enterprise data warehousing and Business Intelligence Solution

Project Vision:

To build a platform that would enable the Customer maintain its leadership position and transform into a

lean, agile, responsive, customer focused, rapidly growing organization with increasing profitability and

safety.

The advantage of a well constructed Project Vision is that it captures in a single sentence what the

Customers Top Management would like to achieve through the project and helps to get their buy in.

5.2.4 Project Objectives

Although most Request for Proposal documents from the customer contain the Project Objectives, there is

considerable scope to improve upon them. Given below is an example of project objectives for an

Enterprise Data warehousing and Business Intelligence Solution.

Example 5: Project Objectives for an Enterprise data warehousing and Business Intelligence Solution

Project Objectives:

To architect an integrated, scalable, agile and intelligent Information system for the Enterprise.

Organization of data from multiple source systems into unified information in an Enterprise Data

warehouse (EDW). The EDW will be a source of a single version of truth and meet all requirements

for reporting and analysis and the needs of existing as well as proposed downstream applications.

Delivery of reliable and consistent information at reduced cost, in a timely manner, in an

appropriate format and through convenient channels.

Building an effective decision support system with subject area data marts and OLAP tools


21/93


22/93


23/93


24/93



Bought out items

Services Component

These are roughly in the proportion 50:50 considering implementation and support services for a seven year period

The Customer pays for all the bought out items (shares 50% risk).The bought out items can bejointly sourced and

negotiated. Budget will be prepared by Supplier for all bought out items.

The Supplier is paid on a reward sharing basis (carries 50% risk on the project cost)

Formula for Reward Sharing

The rewards that we have considered are only those attributable to the Solution. These can be shared in the same

proportion as risks are shared for a period of 5-7 years from the date of completion of the project. The reward for

the Supplier can have a cap of say 3 times the fee based on hourly rates. The Project is for

development/implementation and support for 5-7 years and the cost split is approximately 50:50. The support fee

is expected to be realized from benefit sharing in a regular stream from start of the support period. The

development/implementation cost alone is funded for an average period of 30 months. Considering a funding costof 10% PA for the payments for development activity that may be pushed out by about 30 months on an average,

this effectively translates to about 280% of the fee computed based on hourly rates.

Advantages of the model

Advantages that are common to the Customer and Supplier are:

Prioritization based on ROI for delivering projects.

Over investment on bought out items is against the interests of both the parties and therefore jointlyavoided.

Change Management is key to success and Supplier becomes an equally interested party in managing thisprocess well

True partnership as Supplier becomes a stakeholder in exploiting the full potential of the Solution tomaximize the benefits.

Joint creation of value by Customer and Supplier. Scope can therefore evolve over the course of the project

The project can be segmented into defined value chunks with a provision that the Customer or the Suppliercan walk away at the end of any segment. This way, neither the Customer nor the Supplier has to commit

to the whole project at once but can do so in smaller pieces. This way, series of value checkpoints are

established to ensure that the project is on the right path. Part 1 of project scope can be executed on the

fixed price model and can be the first check point. By the time this stage is completed, both the Customer

and the Supplier are in a better position to assess the risk- reward aspects of the remaining scope.

Advantage to customer

Cost of failure shared by Supplier and therefore Supplier becomes an interested party in ensuring success.

Deal structured to make the Supplier a responsible party reducing overheads on monitoring andsupervision.

o Quicker delivery in the interests of the Suppliero Quicker and wider adoption of the Solution in the interests of Suppliero Maintaining SLAs in the interests of Supplier.


25/93


26/93



The Supplier may therefore carry out necessary due diligence and ascertain the risks before accepting the

responsibility.

Interfaces

If the Application that is in scope for delivery is required to be interfaced or integrated with existing

Applications, ensure that the following is included as Customers obligation:

For integration of Application in scope with currentapplications in use and deployed on Customers

legacy systems, the Customer shall procure services of the relevant application vendors as necessary to

work with Supplier and its subcontractors for the integration.

5.3.2 Commercially Available Off the Shelf Solution (COTS)

If the Solution offered to the customer includes COTS Solutions, then the COTS Solution must be capable

of meeting all of the Customers requirements in the subject area for which it is chosen without requiring

any development. Customization for any single requirement should not exceed effort of 2 person days.

Customization may be defined as follows:

Customization means any report, enquiry, program, screen, or similar function which can be directly

programmed on the System without needing a functional specification document and a technical

specification document. The maximum duration of effort of a unit under the customization band is two

(2) man days of effort and no additional charge shall be made for such effort. If the unit requires more

than two (2) man days effort, the Parties will mutually agree the scope and charges for such work, which

will be delivered as a Development, under the Change Control Procedure in phase 2.

Development may be defined as follows and kept out of scope at least for phase 1 of the implementation.

Development means enhancements to the Core product which require more than two (2) man days of

effort and which are delivered in the form of Patches, Project Builds, Service Packs and Upgrades.

Developments will be discussed between the Parties and agreed in accordance with the Change Control

Procedure. It is agreed by the parties that development is out of scope in phase 1.

Rationale:

Developments that require change to the core Application require considerable effort and skills of ahigh order for carrying out the following tasks:

Impact analysis. A change to a part can impact other functions.

Design. If the change is exactly the same as specified by the customer, then the change canrender that part of the Solution obsolete and unusable very quickly. All changes have to beattempted from the perspective of making the change as generic as possible to take care of notonly todays needs but needs that may arise in future or similar requirement of other customers. This requires involvement of high caliber domain specialists who are scarce and thereforeunavailable for Customer specific enhancements. Each and every enhancement therefore


27/93


28/93



dependency on the Customer or other third parties. The contract, in a fixed price project isto deliver as per the scope agreed irrespective of the effort. Inclusion of effort estimateenables the subcontractor to come back at a later stage and ask for additional fees if theeffort is exceeded. The subcontract can however list all dependencies that are to bemanaged by the Prime contractor and expect to be compensated for costs incurred if thereis delay on account of the dependencies not being managed as agreed. The roles and

responsibility of the various parties (System Integrator, Customer and Subcontractor) in thedelivery of the services by the subcontractor must be clearly defined. Other obligations of Sand Customer must also be included such as making available required licensed systemsoftware, hardware requirements for the various environments (Test, Development,Training and Production). The roles and responsibility must cover all aspects such asinstallation, tuning for performance, training, list of documents the subcontractor has todeliver in each phase of the project, data migration, data cleansing, data validation, testscripts and testing, deployment, post production support. In a multi party situation, it isextremely important to have very clear understanding of the roles and responsibilities at thegranular level. For example, data migration involves the following tasks:

o Data mapping from legacy to target system. This requires support from Customer

who understands the legacy system and the subcontractor who understands thetarget system. The precise business definitions of each data element in legacy andtarget system must be understood. Who will do the data transformations that maybe required? For example, the target system may store accrued interest, whereasthe legacy system may store daily products. While migrating, daily products have tobe converted to accrued interest.

o Missing data in legacy that is mandatory in target. Strategy for providing missingvalues. If this has to be manually keyed in, who will develop the input screens andwho will key in the data?

o Data in legacy that cannot be mapped to any field in target system. What is to be

done?o Data extraction from legacy. Whose responsibility? Who will develop the extraction

scripts?

o Data cleansing. Whose responsibility is it to identify data quality issues and whoseresponsibility is it to do the data cleansing? Will the data be cleansed in the sourcesystem before migration or will it be done after extraction?

o Data validation and reconciliation before uploading. What Reports will be producedand who will give the sign off? Who will develop those Reports

o Data upload scripts and data upload. Who will develop the scripts and who will run

those scripts for uploading?

o Data validation and reconciliation after loading. Who will develop the reports andwho will validate and give a sign off?

o Who is responsible for business loss on account of inaccurate data?

Implementation Milestones and Deliverables, definition of Defects of various severity,Acceptance Criteria: Precise back to back clauses are essential to avoid a situation where


29/93



the subcontractor claims that a milestone is successful and the customer says that it is not,and both are right according to their contracts with the SI.

Implementation methodology that would be followed must be agreed to.

Liquidated Damages. Back to back arrangements must be made. Considerations that need

to be weighed are:

o If delay is solely on account of the subcontractor, can all of the LD be passed ontothe subcontractor?

o If delay is by multiple parties, in what manner the LD may be distributed.

Contract term: Maybe defined as a definite date or on sign off of a milestone or end ofwarranty period plus a safe period of say 3 months.

Validity period of offer. This must match with the Prime Contract so that the subcontractorcannot vary the price while it is fixed for the SI.

Warranty and warranty period: When does it begin? After the Solution goes live inproduction (Customers preferred option) or fixed period after the license agreement issigned (sub contractors preferred option). Unless care is exercised, a mismatch is highlylikely.

Termination for cause. The SI must be empowered to terminate the contract for causewithout the prime contract being terminated. Back to back arrangement on termination forconvenience is essential including the services that have to be rendered by sub contractoron termination.

Indemnities, performance guarantee, liability for general damages, and limitation of liability:Arrangements should be made that are no less onerous than those in the prime contract.

Date of commencement of maintenance contract: Is it at end of warranty period?

Post implementation support. Precise definitions of L1, L2 and L3 support and who doeswhat should be spelled out.

Service Levels for performance. The terms and conditions agreed with subcontractorsshould be no less onerous that those in the prime contract.

Payment Terms: The time required for invoicing the Customer after invoice is received frompartner and time required to make payment to partner after payment is received fromCustomer will have to be added to whatever payment terms are agreed with Customer.

There should also be a provision for further negotiations if the prime contract undergoes change basedon negotiations with the customer.

If agreement is not concluded with subcontractor by the time the proposal is submitted to thecustomer, the bargaining position of the contractor is strengthened, and it becomes extremelydifficult to negotiate appropriate terms thereafter. The project could become financially unviableand also fail, if the Prime contractor cannot have back to back agreement on the Service Levels,scope of work, timelines, roles and responsibilities with the subcontractor.


30/93



5.3.4 Suppliers

In a SI Project, the prime contractor may be responsible for providing the complete solution covering:

Hardware

Software

Network

Implementation

Support

All the items of purchase are not required immediately and just in time purchases will be desirable from

the cost and cash flow point of view. For example the production environment in the data center can be

ready a month before the production go live date. If the production go live date is 9 months from the start

date of the project, then the hardware required for the production environment can arrive 6 months after

the project start date. The plan to network all offices of the Customer (for example, 1000 branch offices of

a Bank) may be spread over a 2 year period. If all the equipment required is purchased in one lot, then this

does not only involve cash outflow and interest costs but also warehousing costs and insurance. The

warranty period will run through while these equipments are still lying in the warehouse. The equipment is

also subject to obsolescence and depreciation.

Purchase agreements must therefore be explicitly made for staggered purchases with firm delivery lead

times and severe penalties for delays. In the absence of an explicit and documented understanding, once

the prime contract is signed with the customer, the Suppliers will insist that:

The Orders are to be placed immediately for the price to be valid.

Prices quoted are valid only ifthe entire requirement is purchased in one lot.

The solution proposed may not allow changing the specifications of the items and therefore may rule out

sourcing material from alternate suppliers. Necessary care must therefore be exercised while entering intopurchase agreements.

Explore the possibility of having back to back terms traceable to the RFP if possible. For example,

If payment is subject to acceptance by the customer then all software items may be purchased on

the same terms.


31/93



If payment for hardware is after installation and commissioning, then purchase can be on credit

against Letter of Credit (if necessary) with a credit period long enough to allow installation and

commissioning. While the risk for purchase is borne by the supplier, there is no negative cash flow

from the project.

If Bench Mark test is stipulated by customer then Purchase Order should be issued aftersuccessful completion of the Bench Mark test. In the meantime a Letter of Intent could be issued to

give comfort to the hardware vendor that there is serious intent to purchase the hardware on

successful completion of the Bench Mark.

5.3.5 Hardware Sizing:

A System Integration Project may require hardware to be sized, procured, installed, administered andmanaged by the SI as per SLAs stated in the RFP.

Here the risks are:

Over sizing will make the bid uncompetitive

Under sizing would require additional hardware to be procured by the SI at own cost and affectproject profitability adversely.

Sizing Parameters

Ensure that data on all project parameters that affect sizing including expected growth indata/transactions is obtained from the customer and included in the contract.

Additional hardware requirements necessitated by any factor exceeding the stated parametersshould be to the account of the Customer.

Sizing Process

An iterative process involving the following steps gives good results

First Cut sizing by tool or Application vendor. The Tool/Application vendors generally tend to sizehardware on the higher side to ensure that the experience of the users with the Tool/Application isgood and the hardware resources are not found wanting.

Sizing based on published performance benchmarks of the Tool/Application vendor. This gives alow number since Bench Mark performance data published by vendors are to show that their

Tool/Application is not resource intensive compared to competing products

Getting equivalent sizing for the hardware chosen by Supplier from the Hardware Vendor

Reference data collected from other sites where the Supplier may have projects with identicalTools/Applications for identical workloads. The workloads need not necessarily be identical sinceWeb and Application servers are linearly scalable.


32/93



Arriving at final sizing based on extensive discussion with Tool and HW vendor to reconciledifferent sizing arrived at based on the steps above.

Risk Transference

In an SI deal, the hardware Vendor and the major Application Vendors are the partners. They stand tobenefit immensely if Prime wins the bid and therefore have as much interest in ensuring success of theproposal. They would therefore appreciate the risk of over sizing and making the bid uncompetitive. Thismakes it possible for the Prime to involve them in the sizing exercise and transfer some or all of the risk.This expectation should be incorporated in the teaming agreement. All three parties viz. SI, HardwareVendor and the Application vendor should jointly conduct the sizing exercise. The SI should ensure thatthe right people from the partners side come for the exercise with relevant benchmark and empirical dataof similar projects together with their sizing methodologies.

As far as transference of risk is concerned, it should be recognized that all risks are priced in. If theApplication Vendor and the Hardware Vendor are asked to take the risks for under sizing, they would pricein the risk. The price would depend on the perceived risk which is a function of their degree of comfort in

sizing for the given situation and their willingness to take the risk. In theory therefore, the price of the riskis minimized, if the risk is taken by the party that is most confident on the sizing and willing to take the risk.The willingness to take risk is also a function of the strength of the relationship of the Prime with thepartners, the number of projects done together, common future plans and maturity of the alliancemanagement process and involvement of the right people at the right stage. The Prime could ask thepartners to give their prices with/without under sizing risks and try to minimize the price of the risk throughappropriate risk transference. Some degree of risk transference is desirable to ensure that all parties bringin the required degree of seriousness to the exercise and that there is no attempt to deliberately undersizeto ensure a competitive bid without any risk to them.

5.3.6 Timelines

There may be opportunity for negotiating for more time for development without affecting the overall delivery

schedule. Make use of such opportunities. Given below is a relevant example.

Example 8 Negotiating timelines

Consider the following schedule from a RFP:

Milestone Completion date

Contract Award 1/5/2008

Project Initiation 1/6/2008

Gap Analysis 1/7/2008

Technical Design 1/9/2008

Application Development and Factory Test 15/11/2008


33/93



System Availability 1/12/2008

System installation/ configuration/training 15/2/2009

System Functional Testing & integration testing 31/3/2009

System Integration & Acceptance 1/6/2009

Pre-Production System Availability 05/8/2009

Production Go Live 20/4/2010

From the above, it can be seen that the time available for coding and Factory Testing is 2.5 months

Some pointers for negotiations:

Time for Application Development and Factory Testing 2.5 months Why should the System not be available by the time Factory Test is completed so that Functional

Testing can begin immediately after the Factory Test? Time for System installation, configuration and training is 1.5 months. Consider curtailing this by 3

weeks and increasing time for development by the same period. Time for System Functional Testing and Integration Testing 1.5 months. Consider curtailing this by

0.5 months and increasing time for development by the same period. System Integration and acceptance 2 months. Consider reducing this to 6 weeks and increasing

Development time by the same period.

Potentially, the development period can be increased by upto 1.5 months without affecting the overall

schedule which will considerably derisk the project.

The timelines show that the Customer has sufficient buffers for the tasks where their employees are

involved and have squeezed the time available for development.

Inadequate time for development could compromise quality at Factory Test stage which would mean more

defects. In the interests of the Project therefore, timelines may be adjusted to provide adequate time for

development.

This also has cost implications. Development teams would have to move onsite to fix defects during the

Testing Phase. A longer duration for this phase would mean an increase in the onsite component.


34/93



5.4 Dealing with identified risks in the contract at the proposal

stage.

If both the impact and probability of occurrence of the risk is low then ignore the risk

Use the opportunity provided in the pre bid conference to suggest changes to the contract as appropriate,or to seek further clarifications that would help quantify the risk. Try to shed the risk or transfer it to thecustomer if possible.

Example 9: Options to deal with identified risks

If the Supplier believes that it is not possible to complete the project on time as stipulated by the customer,then there are the following choices:

No proposal.

Propose an alternative schedule

Propose to meet the completion date but hope to shift the date while negotiating the contract

Propose to meet the completion date hoping that the risk can be `managed during the executionphase.

The appropriate choice depends upon the circumstances as well. There could be one of the following

scenarios:

a) The time is considered short for the bidder but not for the competitors because of certainrelative disadvantages/advantages. The competition is therefore likely to accept theschedule.

b) The timelines are considered to be short for all.

If it is known that the customer will not under any circumstances consider alternative dates, and ifthe Supplier is convinced that they cannot meet the required dates, then not submitting a proposalis an option.

Proposing an alternative date runs the risk that the proposal will be ruled out at an early stage ofthe process if the other potential suppliers accept the timelines. However, if scenario b) above istrue and most potential suppliers propose an alternate date with justification and the bidder is theonly one who accepts the proposed date, then also the bidder is in danger of being eliminated fornot knowing what the Project takes. In this situation, it is better to propose an alternate date orindicate that it requires further discussion.

An alternative date may also be proposed if scenario a) is true and offer some trade off to thecustomer to make the proposal acceptable inspite of not meeting the customers expectations onthe schedule.


35/93



Accepting the proposed date and hoping that the risk can be managed during execution, is basedon the assumption that in a major project there will be a change of scope which would provide theopportunity to revise the schedule. The argument is very persuasive and therein lies the danger.Such an approach is fraught with the risk of damage to reputation for not meeting the timelines andattracting penalties/termination.

Example 10: Seeking modification of proposed clause during negotiation:

Consider the following proposed clause for a Maintenance Contract:

CUSTOMER shall have the right to benchmark the Services. Benchmarking shall be conducted by an independent

industry recognized third party benchmarking service provider designated by CUSTOMER ("Bench marker"). In the

event that the Bench marker concludes that Suppliers performance of the Services is below the industry standards

for such Services, Supplier shall, within thirty (30) days after the Bench markers decision, develop for CUSTOMER

review and approval, a plan to bring Suppliers performance up to industry standards as soon as practically possible

and in all events within ninety (90) days after CUSTOMERs approval of such plan.

Benchmarking Price: The Bench marker will review Suppliers pricing, comparing Suppliers charges for such

Services to the least costly deciles in the world for comparable services (the "Charges Target").

If a benchmarking reveals that Suppliers prices for Services are in excess of the Charges Target, Supplier will

reduce the charges to match the Charges Target.

The supplier could in principle agree to the abovementioned clause at proposal stage but qualify theclauses during negotiation stage in the following manner:

1. Bench marker will not be a competitor of Supplier and should be acceptable to Supplier

2. Benchmarking will be against the Price and Services provided by equally pre eminent supplierswith a similar/comparable cost profile

3. If Supplier is not in a position to comply with the benchmark, a negotiated and revised benchmarkmay be agreed to failing which the Customer may terminate the service in question forconvenience.

At the proposal stage, the entire contract document is not completely fleshed out. It is therefore justifiableto add necessary details later on to provide for situations that may arise. For example, the Supplier maynot be in a position to achieve the benchmark or the price may not work out for them. There should thenbe agreement on a process to resolve the issue.


36/93



5.5 Pricing for risks

Consider the following scenario:

In a System Integration Project, the scope includes:

Implementation of Core Business Solution (CBS) sub contracted to Product Vendor

Implementation of ERP GL module

Implementation of ERP Financials module

Implementation of ERP HRMS module

Implementation of CRM

Integration of CBS with GL

Integration of CBS with CRM

Implementation of Budgeting and planning Solution

Implementation of Profitability Solution

Integration of CBS solution with delivery channels such as ATM, Mobile phones - To be done by

respective vendors

Hardware sizing and supplying the required hardware

The System Integrators internal organization structure consists of a CFU (customer facing unit) that

does the Program Management and CU (competency units) that do the actual implementation. The

CFU therefore treats all CU as subcontractors.

The total price therefore consists of the price quoted and negotiated with the subcontractors (including

internal units) plus what the CFU charges for Program Management.

How should the CFU arrive at their charges and what are its components?

One component is the size of the Program Management office and expenses relating to it. The other

component is the risks that the CFU carries and how these risks are priced.

The Program Management role is to coordinate the efforts of all parties including the customer to

ensure on-time delivery. The CFU may therefore insulate all subcontractors against the risk of delay on

account of a recognized dependency and have a mechanism for compensating the subcontractor on

account of costs incurred for any delay attributable to the other parties.


37/93



The subcontractors may not therefore price in risks arising out of their dependency on third parties

since the CFU assumes the responsibility for coordination and for compensating the subcontractor

should there be a cost escalation on account of a dependency that is not managed by the CFU as

agreed.

The Profits of the CFU arise from the risk price and how well the CFU manages the risks within thatprice.

The SI may have arrangements with all subcontractors for Liquidated Damages for any delay on their

side. Here it must be kept in mind that only delays on the critical path have a cost and time implication

and not every delay. The SI may also have an arrangement with the Customer for compensating the S

for costs incurred on account of delays attributable to the Customer not meeting their obligations as

agreed. Even with such arrangements, there are some residual risks since Liquidated Damages levied

on a subcontractor for failure may not fully cover claims for compensation from other subcontractors

whose delivery is affected by the failure.

The residual risks after risk transference must be measured and priced in. The final price quoted may

be the total price arrived at in this manner or some other price which in the opinion of the CFU, the

market is willing to pay. (On account of competition a final judgment call is taken on what may be the

winning price for the bid which could be higher or lower than the price determined as described). The

profits of the CFU then depend upon how well it can manage the risks within the risk price that the

market is willing to pay.

This understanding must be clear on all sides. If the subcontractors also price in dependency risks,

then there is multiple pricing of dependency risks which will make the bid uncompetitive.

The process described above ensures:

Subcontractors are compensated for their skill, effort and for managing the risks internal to them whichinclude effort estimates for their portion of the deliverables.

The Program Management Office is compensated for their effort and for the coordination of efforts of

all parties and management of all dependency related risks.

Pricing of Program Risks

Risks that have a very low probability of occurrence but high impact are to be considered for taking an

insurance cover if available. There is no point in adding a small percentage to the price since, when

the risk manifests, the dam