bid management and negotiation

8/3/2019 Bid Management and Negotiation

http://slidepdf.com/reader/full/bid-management-and-negotiation 1/95

1 | P a g e

2008

Bid Management andContract Negotiations for

IT Services ProjectsJaveed Ahmed

F O R I N T E R N A L C I R C U L A T I O N O N L Y



Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

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

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 Customer’s perspective........................................................................................... 14

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

Example 3: Addressing Customer’s 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 ............................................................................................................................................ 21

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





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

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

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

Example 7: Innovative Pricing model .................................................................................................................... 23

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

5.3.1 Dependency Risks............................................................................................................................................. 26

Interfaces............................................................................................................................................................... 27

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

5.3.3 Subcontracting Risks ........................................................................................................................................ 29

5.3.3 Suppliers .................................................................................................................................................... 31

5.3.5 Hardware Sizing: .............................................................................................................................................. 32

Sizing Parameters .................................................................................................................................................. 32

Sizing Process ........................................................................................................................................................ 32

Risk Transference .................................................................................................................................................. 33

5.3.6 Timelines .......................................................................................................................................................... 33

Example 8 – Negotiating timelines........................................................................................................................ 33

5.4 Options at the proposal stage to deal with identified risks .......................................................................... 35

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

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

5.5 Pricing for risks .............................................................................................................................................. 37

Pricing of Program Risks ........................................................................................................................................ 39

Pricing of Risk for Hardware sizing ........................................................................................................................ 39

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

Pricing of Maintenance contracts ......................................................................................................................... 42

Maintenance Contracts – Negotiating under difficult Economic and Business Conditions .................................. 44





5.6 The Proposal Document ................................................................................................................................ 45

5.7 Proposal Defense .......................................................................................................................................... 46

6 Contract Negotiations.......................................................................................................................................... 48

6.1 Types of contract ........................................................................................................................................... 48

6.1.1 Time and Material Contracts ........................................................................................................................ 48

6.1.2 Fixed Price Contracts .................................................................................................................................... 48

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

6.2 Important considerations for Negotiation .................................................................................................... 50

Main items for Negotiation ................................................................................................................................... 51

6.3 Letter of Intent .............................................................................................................................................. 51

6.4 The Contract Document ................................................................................................................................ 52

6.4.1 Scope and Delivery related clauses .............................................................................................................. 52

6.4.1.1 Solution Ownership ................................................................................................................................... 52

Example 11: Solution Ownership .......................................................................................................................... 52

6.4.1.2 Project Commencement Date ................................................................................................................... 53

6.4.1.3 Simplifying Scope....................................................................................................................................... 53

Example 12: Simplifying Scope .............................................................................................................................. 54

6.4.1.4 Clauses to cover dependency risk .............................................................................................................. 55

Example 13: Dependency Risk .............................................................................................................................. 56

Example 14- Customer’s Obligations included in a contract: ............................................................................... 58

6.4.1.5 Change Control .......................................................................................................................................... 63

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

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

Generally Accepted Service Level Principles ......................................................................................................... 67

6.4.1.7 Back to Back SLA with partner .................................................................................................................. 68





6.4.1.8 Availability SL ............................................................................................................................................ 69

6.4.1.9 Maintenance Contracts – Effort Estimates and Pricing ............................................................................ 69

6.4.1.10 Maintenance Contracts - Efficiency sharing............................................................................................ 70

6.4.1.11 Maintenance Contracts–

Benchmarking of Effort .................................................................................. 71

6.4.1.12 Maintenance Contracts – Exclusivity Clause ..................................................................................... 72

Example 16: Maintenance Contract – Benchmarking and related clauses ........................................................... 72

6.4.1.13 Maintenance Contracts – Term of the Agreement ............................................................................ 73

6.4.2 Legal Clauses ................................................................................................................................................ 74

6.4.2.1 Complete Agreement and Complete Offer Clause .................................................................................... 74

Table 2 List of Contract Documents ...................................................................................................................... 74

6.4.2.2 Termination Clause.................................................................................................................................... 75

6.4.2.3 General Damages...................................................................................................................................... 76

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

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

6.4.2.5 Affiliates .................................................................................................................................................... 78

6.4.2.6 Indemnities................................................................................................................................................ 78

Example 17: Representations and Warranties ..................................................................................................... 79

6.4.3 Commercial .................................................................................................................................................. 79

6.4.3.1 Payment Terms.......................................................................................................................................... 79

6.4.3.2 Bank Guarantee for Performance ............................................................................................................. 80

6.4.3.3 Project Funding ......................................................................................................................................... 80

6.4.3.4 Pricing–

Granting of Most Favored Customer Status ............................................................................... 81

6.4.3.5 Audit ......................................................................................................................................................... 83

6.4.3.6 Liquidated Damages................................................................................................................................. 84

Example 18 - Liquidated Damages ........................................................................................................................ 84





7 Re-negotiating Contracts .................................................................................................................................... 85

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

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

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

8.1 Role and Responsibility ................................................................................................................................. 89

8.1.1 Mandatory Review of Proposals: ................................................................................................................. 89

8.1.2 Providing Guidance: ..................................................................................................................................... 90

8.1.3 Review of Contract Documents: .................................................................................................................. 90

8.1.4 Transition to Delivery: .................................................................................................................................. 90

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

8.3 Structural Issues ............................................................................................................................................ 93

8.4 Risky Projects ................................................................................................................................................ 94

9 Conclusion............................................................................................................................................................ 95





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 iscompetitive 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 simpleTime 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 Supplier‟s 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 the

subject.





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.





3. Project Stages and Risk Management

Risk Document is an important input for prime contract negotiations. There are four stages in a project asfollows.

Table 1 : Project Stages and Risk management

RiskManagement

STAGES

Critical Issues What needs to be done?

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

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 Supplier‟sexpectations 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.





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

4.1 Bid/No- Bid decision

Bidding for a contract involves the following risks:

Risk of not winning.

Winning but not being able to execute it.

The objective is therefore to:

Go all out to win and secure a safe deal when execution is considered possible.

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

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

A clear decision to bid empowers the bid manager to employ all necessary resources to submit awinning proposal and to think, act and behave as if the deal is already won. This frame of mindhelps in adopting a comprehensive approach to Risk Management without which, certain aspectsare ignored since `we may not win anyway‟! In Risk management, this is the stage where risks can be prevented. In later stages, only mitigation is 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, create the rightenvironment for ensuring that no key risk is missed. 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 is very difficult to halt midwayAlso there are other 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 a

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





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 forfair 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 the

process 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?

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 while

meeting 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 expectationof 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.

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 the

supplier‟s concerns. The supplier‟s 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 aboutwinning an argument. The Supplier‟s 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 Supplier‟s 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 opportunityfor 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 in





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

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 canbe 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 Customer‟s 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 Customer’s perspective

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

address the Customer‟s 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 customer‟s 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 customer‟s 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 passenger‟s other requirements for hotel bookings, car booking, tour packages etc which is catered to by a custom application

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 estimateso More defects due to lack of understanding of domain requiring longer time to fix problems

and more iterations

o Delay in delivering the project

o Quality and Support issues

Assessing the supplier‟s 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 customer‟s business / IT personnel)

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

Assessing the Supplier‟s implementation approach and best practices for minimizing risks.

Assessing the Supplier‟s software development quality assurance process to ensure that the qualityis able to satisfy Customer‟s 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 Supplier‟s cultural fit to minimize behavioral risks. Inability to get cooperation from thebusiness user could seriously jeopardize quality and timelines.

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

Assessing the Supplier‟s 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 Supplier‟s perspective? What

strategies, 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 similarcomplexity?

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 thedevelopment work for “most critical” 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) Allow

the 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 Customer‟s 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 Supplier‟s 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 Customer‟s special needs.

Example 3: Addressing Customer’s 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 Supplier’s of IT Services and will not be

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

clear 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 Supplier’s 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 ProductCompany and also derisks the Supplier against possible miscalculation of effort at initial stage is described below:

Step 1- Request for enhancement. Product Company’s 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

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 becomesliable 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 Supplier’s efforts

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

the end of previous stage.

The Supplier’s 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

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 costas 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 systematicimprovement 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 equivalentresource 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.

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 alean, 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

Customer‟s 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

Building an Executive Information System comprising dashboards

Effective control through actionable information, exceptions, and trends

Improved Risk Management

Achieving Customer delight and improved Customer Relationship Management

Enable collaborative performance planning and review

5.2.5 Project Benefits

The RFP document may not contain details of the benefits the Customer is expecting from the project.

However, the Top Management‟s concern is whether the investment will bear good results. Given below is

an example of project benefits for an Enterprise Data warehousing and Business Intelligence Solution.





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

Project Benefits:

Besides meeting all of the Bank’s reporting requirements, the Solution will provide analytical insights for strategy

formulation and decision making, and actionable information for execution, to meet the Bank’s financial and non-

financial strategic objectives. Some of the relevant metrics to measure the benefits from the Project are:

Increase in Market share

Increase in business volume per employee

Increase in profit per employee

Business from New customers

Reduction in attrition of profitable customers

Increase in profit per customer

Increase in stickiness of customer or accounts per customer

Decrease in income leakage

Reduction in costs

Increase in usage of appropriate Channels and reduction in transaction costs

Increase in fee income on non-fund based business

Reduction in Non Performing Assets through better risk management

Reduction in cycle time of transactions

Reduction in Defect Density and customer complaints

Better governance and Increase in span of control for a leaner and flatter organization

5.2.6 Innovative Pricing Model for winning Projects





Given below is an example of a pricing model that takes into account project risks from the customer‟s

perspective and is at the same time rewarding to the Supplier

Example 7: Innovative Pricing model

Risk-Reward model for Executing BI and DW Projects for the Banking Industry

Scope of a BI and DW project can be divided into two parts as follows:

Part 1. Addressing the customer’s pain points in the area of Compliance and Regulatory Reporting,

Operational and MIS reports, financial consolidation and Reporting.

Part 2. The remaining part of the scope covers implementation of Analytical and Point Solutions, the

potential value of which is rarely quantified or understood although the customer may have some notion of

the solution.

While the customer has clarity on what to expect for part 1 of the scope and can come up with detailed

requirements and acceptance criteria and can control the quality of the deliverables, this is not the case for part 2

of the scope.

If part 2 of the scope is managed poorly, the customer can incur the costs without realizing the full potential of the

Solution. This is where appropriate deal structuring can make the difference between a poorly implemented

solution that delivers little value and a well executed Solution that delivers great value.

The Risk/Reward model of pricing part 2 of the scope is particularly suitable as the investment is discretionary and

the value derived from the investment is highly dependent on the manner in which the project is conceived and

implemented and not so much on the investment in money terms.

Given below is an outline of the risk-reward model for the Banking Industry:

Agreement on benefits, measures of benefits and monetary values:

The EDW Solution is expected to provide three major measurable benefits as follows:

1. Decrease in head count for meeting the requirements for compliance reporting and operational reports

2. Increase in Business Volumes over and above the normal increase that can be attributed to the Solution

3. Improved profitability.

1. Meeting basic Reporting requirements:

The part of the solution that provides this can be separately costed. The justification for the investment wil

be in terms of reduction in head count enabled by the automated processes for data acquisition

integration and reporting. Once justified, the benefits are assumed since actual reduction in head countmay not happen and the same head count may be deployed for other activities. Part 1 of scope of the

project could therefore be executed on the basis of a firm price.

2. Increase in Business Volumes on account of better Customer Services:

The solution provides analytical insights for strategy formulation and decision making, and actionableinformation to meet the Bank‟s financial and non-financial strategic objectives. Some of the relevant metrics





to measure the benefits from the Project are:

Business from New customers (Customer acquisition Solution)

Increase in stickiness of customer or accounts per customer (CRM solution)

Reduction in cycle time of transactions (Analytical Solution, BPM solution)

Reduction in Defect Density and customer complaints (Analytical Solution)

The benefit of the Solution would therefore be (increase in Business Volume – Normal increase in business

volume)* profit/business volume

Only increase in volumes over and above the normal rate of increase will be considered. The normal rate of

increase would be the historical growth rate for the Customer adjusted for common factors affecting the industry in

that year or the average growth rate for the industry as compared to the previous year.

3. Improved profitability as a result of:

Increase in business volume per employee (Employee empowerment through makingavailable actionable information for instant decisions)

Increase in profit per employee

Reduction in attrition of profitable customers

Increase in profit per customer

Decrease in income leakage

Reduction in costs

Increase in usage of appropriate Channels and reduction in transaction costs

Increase in fee income on non-fund based business

Reduction in provisioning for Non Performing Assets through better risk management

Better governance and Increase in span of control for a leaner and flatter organization

The benefit of the Solution would therefore be Business Volume * ((profit/business volume) now – (profit/business

volume) base)

The base figure of profit/business volume is the prevailing figure at the start of the project and adjusted for

common factors affecting the industry. The common factors affecting the industry are :

Net Interest Income (Differential interest rate on loans and advances and interest rate on deposits). This is

to some extent dependent on the business climate and actions of the Regulator.

Growth in Non – Performing Assets. There is a part that is attributable to the business climate and affects

the industry as a whole.

Risk/Reward sharing

The Project Cost comprises:

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 be jointly 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 jointly

avoided.

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

process well

True partnership as Supplier becomes a stakeholder in exploiting the full potential of the Solution to

maximize 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 Supplier

can 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 and

supervision.

o Quicker delivery in the interests of the Supplier

o Quicker and wider adoption of the Solution in the interests of Supplier





o Maintaining SLAs in the interests of Supplier.

The deal structure puts huge pressure on the Supplier to deliver consistent performance and at the right

times. Most Suppliers’ wow the Customer in the initial phase, win the contract but then do not keep

wowing the Customer until the project ends. In this type of deal structure, the Supplier has to wow the

Customer with outcomes at the end of each sub Project delivered in order to continue with the next. The

wow experience for the Customer has to be continuous and especially big at the end.

Advantage to Supplier

Providing Solutions to customer in true partnership mode is the future of IT Services business. The faster

the Supplier gets there, the better it is for its survival and growth.

The rewards are commensurate with the risk and bigger than what can be expected otherwise. The revenue

stream for scope in part 1 is similar to any fixed price project. For project scope in part2, it starts in about 6

months to one year time and continues until the end of the support period of 5-7 years. The revenues for

the development/implementation effort are only pushed out by about 30 months. The project on the

whole has regular revenue stream which is not delayed for the fixed price portion and the support portion.

Easier to sell the services.

BI and DW projects offer the greatest opportunity for value creation and therefore are most suitable for this kind of

deal structuring.

5.3 Areas of focus at Proposal stage

From a risk perspective, the main areas of focus in the proposal are discussed in this section

5.3.1 Dependency Risks

Consider the following from a Government Tender:

Supplier shall liaise directly with current suppliers to extract data.

The risks are:

Cost - The current supplier would expect to be compensated for services and perhaps for loss of

profits as well if they stand to lose business by cooperating.

Failure - The current supplier may not cooperate if they stand to lose existing business sooner by

cooperating. This is perhaps the reason why the Customer is unwilling to take responsibility

and is shifting the responsibility entirely to the Supplier . There are instances of projects that

have been delayed by 6 months and more negotiating with existing suppliers for their help in

extracting data from proprietary systems or systems where business metadata is undocumented.





Quality – Source data needs to be understood and mapped to target. Clear and unambiguous

business definition of each data element is required. Who takes this responsibility? An

uncooperative supplier?

Delay – The current supplier may not give the data in a timely manner.

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 Customer‟s obligation:

“For integration of Application in scope with current applications in use and deployed on Customer’s

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 Customer‟s 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 technicalspecification 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 day‟s 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 can

render 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 today‟s 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 thereforeintroduces a rigidity that makes the Solution more and more painful in the long term whilesatisfying an immediate need. Example: A Bank applies interest on loan accounts every monthwhereas contractually, (purely for historical reasons) it should be applied every quarter. Therequirement was therefore to use an adjusted rate (rate adjusted to give the same effect onmonthly compounding as using the given rate and compounding quarterly). If this requirement

is taken as given by the customer and every rate input by the user is converted to adjustedrates, then the change becomes a severe constraint if should tomorrow, the contractual termsare changed to mean monthly compounding. It is possible to provide a generic solution thatcan take care of all possibilities and future proof the change against any requirement that mayarise. This however requires involvement of the right caliber of domain experts and a greatereffort.

Any change to the core system requires thorough regression testing and goes through severaliterations before becoming stable. Too many requirements that require extensive development,is a sure recipe for failure or for extensive delays. As a thumb rule, any major enhancement toan existing Application that requires 1 month of coding requires 2 months for getting therequirements, 2 months for design and 2 months of testing and debugging.

Other reasons for deferring development

Pushing all development to phase 2 assures that the Solution goes live in phase 1.

Customers quickly adapt to the features of the new System and their perception of gaps thatrequire new development changes dramatically bringing down the need for development to abare minimum. Example: A Public Sector Bank had evaluated a core banking solution andcome up with a list of changes that were required to take care of the Bank‟s requirements. Thecost of new development was 3 times the cost of the license fee. There was considerable delayin giving the requirements which had to go through several iterations. The Solution was in themean-time implemented. It was quickly discovered that none of the enhancements wererequired. Changes to existing business processes made it possible to use the System às itwas‟ without any ènhancement‟. Some of the ènhancements‟ when delivered were never

used as they had introduced some unanticipated rigidity or impacted some other function whichmade it unusable. The Bank implemented the Solution in 10,000 branches of the Bank withouta single line of code being changed to the core system.

Generally speaking, COTS vendors have little interest in Customer Specific enhancements anddo not put their best people on the job. This is irrespective of the fees that may be paid. Theirinterest is only in undertaking Product enhancements that appeal to a number of customers.Customer specific enhancements create many versions of a standard product which is everyproduct vendor‟s nightmare





The COTS solution must therefore be capable of meeting all of the customer‟s requirementsthrough parameterization or through customization alone. Otherwise, look for an alternate COTSSolution.

5.3.3 Subcontracting Risks

The Subcontracting risk is the risk of mismatched pricing, scope or terms of contract such as:

Scope of work, roles and responsibility. The scope of work expected from the subcontractorshould match the scope in the prime contract. In a fixed price contract, the subcontractormay not be allowed to show efforts in the subcontract for the activities that have nodependency 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 there

is delay on account of the dependencies not being managed as agreed. The roles andresponsibility 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 Customerwho 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 extractionscripts?

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 runthose 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 wherethe 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 needto 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 (Customer‟s preferred option) or fixed period after the license agreement issigned (sub contractor‟s 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 the customer, the bargaining position of the contractor is strengthened, and it becomes extremely difficult to negotiate appropriate terms thereafter. The project could become financially unviable and 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.

5.3.3 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 if the 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 into

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

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 after

successful completion of the Bench Mark test. In the meantime a Letter of Intent could be issued togive 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 theirTool/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.

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 the

proposal. 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 partner‟s 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 insizing 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

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

5.4 Options at the proposal stage to deal with identified risks

At the proposal and contract stage, the various options for dealing with identified risks are:

Ignore the risk

Propose changes

Say nothing in the proposal with intent to take it up at contract stage

Deal with the risk during execution.

Ignoring the risk can be considered only if both the impact and probability of occurrence is low.

If the Customer provides a structure for response to their RFP and the structure requires a response of`Will Comply‟ or `Will Comply with Exceptions‟ or `Will not comply‟, then a response of `Will Comply‟ rulesout the possibility of taking up the issue at the contract stage. However, a response of `Will comply‟ at theproposal stage may still allow the scope for qualifying the clauses or to add riders. The risk of respondingwith `Will not comply‟ is that the Customer may eliminate the proposal for non-compliance.

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 execution

phase.

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

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 customer‟s expectations onthe schedule.

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 Supplier‟s performance of the Services is below the industry standards

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

review and approval, a plan to bring Supplier‟s performance up to industry standards as soon as practical ly possible

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

Benchmarking Price: The Bench marker will review Supplier‟s pricing, comparing Supplier‟s charges for suchServices to the least costly deciles in the world for comparable services (the "Charges Target" ).

If a benchmarking reveals that Supplier‟s 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.

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 Integrator‟s 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.

The subcontractors may not therefore price in risks arising out of their dependency on third partiessince 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 that

price.

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 asagreed. 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 which

include 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 damage is many times whatever percentage may be added.

If there are risks with high probability that also have a high impact then such a project must be

avoided. There is no point in adding a small percentage to the price and getting hit by a disaster that is

certain or adding a large percentage and losing the bid.

Risks with low probability and low impact may be ignored for the purpose of pricing. All estimates

cover for normal contingencies which is sufficient to cover such risks. Any addition to the price will onlymake the bid uncompetitive.

Risks with high probability and low impact are to be prevented, mitigated and managed within a small

price that may be added to cover the risk (say 8 to 12% of the project cost representing residual risks

after risk transference. It may be noted that this does not include uncertainty in effort estimate for the

given scope as this is internal to the delivery units and partners and included in their price/estimates).

Depending upon project complexity, the risk price, after risk transference wherever appropriate, may

vary between 8 to 12% of the project cost in competitive bidding. If the risk price arrived at is

substantially higher, then it implies one or more of the following:

Lack of effective risk transference especially for dependency risks

Uncertainty arising out of not tying up with partners and subcontractors with appropriate

teaming agreements

Making a proposal based on incomplete information

If the above mentioned conditions prevail, then any risk price arrived at is itself a guess estimate and

unreliable.

When there is no competition, a markup of upto 20% may be considered. The higher percentage is

justified by the additional services rendered in creating the project from scratch and for avoiding thecosts of floating an RFP by the Client. If the project is managed well without touching the risk

provisions, then the risk provision is the additional gain over executing a risk free T&M contract.

Pricing of Risk for Hardware sizing





As far as hardware is concerned, the risk that is carried is on the sizing. Should additional hardware be

required on account of incorrect sizing then the cost for such additional hardware may have to be

borne by the System Integrator. It is tempting to propose a simplistic model as follows for pricing the

risk:

For example, if based on the experience of the SI, the probability of occurrence for additionalhardware is 5% and the likely impact is $1000,000, then should something of the order of $50000 be

added to the price?

The simplistic model is however flawed. The occurrence of the risk has nothing to do with chance and

depends upon whether all the relevant parameters for the sizing have been considered and whether a

well tested methodology has been employed for sizing and validated by empirical data from similar

implementations. Only risks arising out of external factors beyond the control of the Prime contractor

may be considered on the basis of probability of occurrence and not risks that are on account of poor

planning.

While sizing hardware, the important considerations are the architecture and scalability. If the

hardware is easily scalable, then while proposing what in the opinion of the System Integrator may be

the optimum hardware required, provisions may be made for the likelihood of procuring additional

CPUs or memory or storage under various scenarios for meeting agreed service and performance

parameters and a provision be made for it. Ordinarily such a provision may be between 5 to 10% of the

cost of hardware. If it exceeds 10%, then obviously the SI is not confident about the sizing and the

error could be in either direction meaning, the hardware could as easily be oversized. A larger

provision then could easily make the proposal unviable if it is on top of over sizing.

The SI usually marks up the price quoted by the hardware vendor by 5 to 10% and the quantum of

mark up is to cover the contingency provision required.

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

Major Variation in Effort from the estimates has the following consequences:

It affects the delivery schedule

In a System Integration Project involving multiple Vendors, it can affect all parties

The consequent effort required to get the project on track is both costly and time consuming

Results in major customer dissatisfaction.

Results in loss

Variation in effort estimate is on account of the following reasons:





a) Incomplete information: Try to get as much relevant information as possible. In the absence

of complete information, make assumptions from experience of similar projects or based on the

data available within the estimation tool. List those assumptions clearly in the proposal and if

possible in the contract as well. The detailed assumptions help in the following ways:

o

Makes comparison with other competitor‟s proposals possible.

o Brings transparency to the process of project costing and builds an environment of trust

o The Customer may come back with feedback on the assumptions which helps refine the

estimates and firm up the scope.

o Helps to set the expectations

A lump sum price quoted in the proposal without a detailed description of what would be delivered

will get no sympathy or cooperation from the Customer when things go awry. In the absence of

clearly stated requirements or assumptions of the requirements, delivery cannot set appropriate

expectations and manage them.

An analysis of the Customer‟s requirements will quite often reveal that it is possible to deliver 95%

or more of value that the customer expects to derive from the Project within 70% of total effort and

the remaining 5% of value takes a disproportionately larger effort of another 40%. So if,

the actual scope turns out to be in excess of the clearly stated assumptions and,

it can be shown that by dropping low value requirements, the timelines can be met or

that meeting of all the requirements would cause a major delay

then, the Top Management of the Customer can be expected to cooperate since for them, it is

important that that the project deadlines are met. This argument may not work directly withBusiness Users who will be less willing to compromise as they are more concerned with the exact

requirements being met. The issue must therefore be taken up and resolved at the Top

Management level.

For the purpose of pricing, increase the effort estimated based on assumptions by about 15%. This

buffer is required since the Customer may not be bound contractually by the assumptions and in

case the actual effort exceeds the effort based on assumptions by say 50%, it then becomes

possible to convince the Customer to drop less important requirements while showing that even

after such dropping, the Supplier is still delivering 15% in excess of the effort budgeted.

b) Estimate made by an inexperienced person: Use a good estimation tool to arrive at the firstcut estimate. The estimation tools use empirical data from a large number of projects to arrive

at the estimate. These estimates are generally found to be conservative. No further buffers are

therefore required when effort has been made using a good tool.





Pricing of Maintenance contracts

The factors to be considered for pricing of maintenance contracts are:

1. Likely Variability in the effort estimates and its financial impact.

Use of a good estimation tool can eliminate this risk. If the same work was hitherto being

done by another Supplier, and if historical data regarding year wise effort, record of Service

Levels maintained over the period are made available, then the same can be used to

estimate effort, and also to project productivity improvements.

A new Support and Maintenance contract may be awarded in one of the following three

situations:

a) Following implementation of a new Applicationb) Transitioning from another provider on account of Service Levels not being met by

the incumbent.

c) Transitioning from another provider for cost considerations

The maintenance and support effort for a newly implemented Application in year 1 is almost

twice of the effort required for the same Application in year 3. This is on account of higher

number of support calls, training needs and larger number of fixes in the initial years.

Therefore while budgeting for higher effort in initial years; it is possible to show a 20% reduction

Year on Year for the second and third year. By the end of third year, a steady state is reached

and further reduction in the effort is slow and may actually increase on account of additional

efforts to support enhancements to the Application.

If statement b) above is true, then the reasons for SL not being met by incumbent Supplier

need to be examined. If the incumbent Supplier is also the developer of the Application that is

to be maintained, then it is unlikely that another Supplier would be able to better the SL

achieved by the incumbent Supplier at least in the first year. If the incumbent Supplier is not the

developer of the Application, then the SL achieved may have been low on account of less

skilled resources employed. The Supplier will therefore have to meet higher SL than what was

achieved by the incumbent Supplier and may have to employ better skilled resources in larger

numbers. The price of service can then be expected to be higher than that of the incumbent

Supplier.

If the change is on account of cost considerations then clearly the SL achieved by incumbent

supplier have to be matched at a lower cost. A lower cost does not imply lower effort. The effort

in year 1 for the new Supplier is likely to be higher than what was achieved by the incumbent

Supplier during their last 12 months on account of non-familiarity with the Applications to be

maintained. Cost effectiveness will thus have to be achieved through lower billing rates of the

new Supplier and not necessarily through lower efforts.





2. Likely financial impact of Service Level Credits. In case historical data is available, the same

may be used to predict likely impact. If there is any doubt about meeting any Service Level on

a consistent basis, agree to a lower level that the Supplier is confident of meeting and agree to

review and revise the Service Level after 3 months to bring it in line with the Customer‟s

expectations. Price in the likely impact.

3. The probable impact of the embedded options in the contract such as:

a. Early Termination of the contract for convenience. The risk may be covered by including

in the contract, a Termination fee depending upon the period for which the contract has

run - a larger fee for termination within 12 months and a reduced fee for Termination

beyond 12 months. If this is not possible, then maybe a 20% cost of early termination

could be added to the price assuming a one in a five chance of early termination within

the first 12 months.

b. Reduction in price due to benchmarking. The risk may be covered by providing the

Supplier the opportunity to negotiate the benchmark failing which it may be subject to

the Dispute Resolution process. If the outcome of the Dispute Resolution process is

unacceptable to the Customer, they still have the option to terminate the contract or the

specific work order for convenience.

c. Option to extend the contract beyond the original term. The risk may be covered by

making the extension subject to price renegotiation. Else, it is certain that this option

would be exercised by the customer only in circumstances favorable to them. In such a

case, an increase in the Annual Project price by about 10% for the entire term is

justified to cover the risk.

The totality of the risks in a contract must be considered for pricing. For example:

The option of early termination for convenience enables the Customer to replace the

Supplier with another Supplier who may offer a more favorable price and/or terms or to

renegotiate the price and terms even during the term of the agreement.

The option to extend the contract beyond the initial term enables the Customer to extend

the contract at a price and on terms that are fixed today without the obligation to do so.

As far as the Supplier is concerned, in case the price or terms turn out to be unfavorable to the

Supplier, the Supplier does not have the option to either renegotiate the terms or the price. On the

other hand, the Supplier may be compelled to extend the contract for further periods at the same price

and terms based on the option given to the Customer for extending the term.

Every option must therefore be carefully considered and appropriately priced. Any reduction in price as

a result of negotiations should be accompanied by a corresponding dropping/curtailment of Options

available to the Customer. An internal document containing the basis for pricing comes in very useful

during the negotiation process. The option to extend the contract may not be as valuable to a

Customer as say a 10% reduction in price (assuming that 10% was added for this option). This is so





since a 10% reduction in price is a definite gain for the customer vis-à-vis a potential increase in price

in the future when the Customer negotiates for an extension of the term.

For the Supplier, it is worth reducing the price by 10% rather than commit for extensions at the same

price and run the risk of losses for an extended period if the contract turns out to be a losing

proposition for any reason. The following is just by way of elucidating what the option for extension ofthe contract really means. Consider the following option for extensions:

The Customer may at their option extend the term of the contract twice by one year each

time, at the end of the term at the same price and terms. (It makes no difference even if it is

agreed today that the price for the extended period shall be increased by 5% or any other

fixed percentage for each extension.)

What this effectively means is that the Customer will extend the contract at the lower of the following

two prices:

Price that the Customer may negotiate at the time of extension.

The Price fixed in the contract today for the extension

The Option to extend the contract in the future at a price that is fixed today is therefore valuable to the

Customer and a risk to the Supplier and this must be reflected in the Price that is charged today for the

services.

Maintenance Contracts – Negotiating under difficult Economic and Business Conditions

When negotiating maintenance contracts under difficult Economic and Business conditions, the risks

are as follows:

The Price will be low

The Customer would like to take advantage of the conditions to negotiate for a longer term

and with options for further extensions of the term at the same price.

The Supplier should aim at:

Decreasing the term to one year and allowing for any number of annual extensions with a

review of price.

In case there is no agreement on price during the review and the Customer chooses not to

extend the contract at a price acceptable to the Supplier, then the contract will be deemed

to be extended for a period of 4 months at the same price to allow the Customer to make

alternate arrangements. The Supplier may also agree to provide free Transition Assistance

during the last one month of the 4 month period.





The above stipulations safeguard the interests of the Customer as well as the Supplier in an equitable

manner ensuring that distress prices do not continue longer than necessary and the Customer is not

inconvenienced on account of the shorter term.

5.6 The Proposal Document

The Request for Proposal document is an invitation to offer

The Proposal Document is an offer

As per the Contract Act, if the customer communicates acceptance of the proposal, a valid contract is

created and the Supplier is obliged to deliver the services/goods in the offer document subject to the terms

in the offer document. No further agreement or contract is required.

The above is only to emphasize the importance of the proposal document although, in practice, for large

complex projects, the Customer would like to have a proper agreement. The proposal should therefore be

capable of serving the purpose of a contract document and must be complete in all respects and without

loose ends. The language must be crisp, clear, businesslike and unambiguous. Marketing hyperbole must

be avoided. Literature of the marketing variety may be attached but then the proposal document must

contain a paragraph detailing the sections of the Proposal that constitute the complete offer. These

sections containing the offer must be free of all ambiguity and marketing hyperbole.

The proposal document may not contain the word ` assumption‟ unless accompanied by a caveat as to the

implications if the assumption does not hold. Assumptions by themselves are weak statements and do not

create an obligation or excuse the Supplier for non-performance if the assumptions do not hold good. It is

therefore advisable to be direct. If the Project requires the Customer to perform something do not

`assume‟ that the customer will perform but stipulate the requirement as the Customer‟s obligation.Acceptance of the proposal then amounts to acceptance by the Customer of their obligations as well.

Supplier‟s assumptions on the other hand remain the Supplier‟s assumptions and may amount to nothing.

The scope may also be defined in clear and unambiguous terms. Any assumption made should be

accompanied by a clear and unambiguous caveat as to the precise implications if the assumption does not

hold good. It is not enough to say that the effort will vary if the assumed scope varies without precisely

stating by how much. Merely stating that the effort will vary leaves the matter for later negotiation and in a

project with time pressures, delivery cannot stop for the sake of negotiations and the Supplier is rarely

compensated for any variation in effort that is not precisely provided for in the contract. For example, if the

assumed scope for data migration is 10 million accounts, then, if this number varies, what is the precise

additional charge for say every additional 100,000 accounts?

Avoid the inappropriate use of the word `Option‟. For example, if the scope consists of implementing a

Solution for a Customer in three countries, do not say that the Customer has the option to ask for

implementation in 5 countries without mentioning the price for exercising the option. An option without the

price implies that the customer is at liberty to exercise the option at no additional cost.





5.7 Proposal Defense

When the Customer calls the Supplier to make a presentation and defend their proposal, the customer has

already had a chance to go through the proposals of all the bidders. The Supplier may therefore expect

probing questions in areas where their Solution differs from that of the competitors. The team making thepresentation should prepare well and give clear answers to all the questions. Inability to come up with a

quick and adequate response would indicate that the Supplier has not thought through all the

requirements for the project or that the Solution has been prepared without care, or that the Supplier does

not wish to be transparent. This is also an opportunity to convince the Customer on the appropriateness of

the Solution proposed so that any variation in details vis-à-vis the competitors becomes a point in their

favor and against the competitors.

A representative set of questions that may be expected is given below:

Effort estimates: Quantum of work assumed and justification for the same. Productivity

norms and how do these compare with the competitors. Relationship between variousactivities. For example if testing effort is normally 15% of total effort and in the proposal it is

20% then why?

Team size and Timelines: Why cannot the Supplier compress timelines by increasing

team size? Are they employing optimal team size? What is an optimal team size and how

has this been arrived at for any given activity? What is peak team size? What is the

average team size? Average team size is easily calculated. It is Effort Estimate divided by

Project Duration. Peak team size can be known only when a detailed plan with resources

required is drawn up. If the peak team size is very much greater than average team size,

this could be on account of massive parallelization of activities to achieve aggressive

timelines. Peak team size can be brought closer to the average team size by serializing

some of the activities. This however results in elongation of timelines. Please remember,

that it may be impractical to vary team size significantly. The stress on management of

resources is greater when team size fluctuates widely through the course of the project.

The ideal scenario is when the team ramps up to reach its peak size and then gradually

ramps down as the project comes to closure.

Interactions with the Customer: What will be the Supplier team size and composition for

gathering the requirements? What will be the duration? What team size and profile of team

members is expected from the Customer.

Offshore development: Feasibility, issues, connectivity required, and concern for data

privacy.

Hardware sizing: Assumptions, sizing methodology, template and exact formula used.

Here the Supplier should be able to convince the customer that they have neither oversized

nor undersized and that the sizing is optimal. Hardware sizing by different bidders is likely





to vary significantly making the customer nervous. Staggering of purchases to defer cash

outflow whether done or not?

Solutions stack justification: This should be shown to be indeed the best of breed or

most appropriate for the requirements.

Integration of the best of breed solutions: Has the Supplier worked on an identical stack

before? What could be the integration issues? Case studies where the Supplier has worked

on a similar stack.

Strength of Supplier’s alliances with product and tool Vendors: For the Solution stack

chosen, what support from these vendors is required and whether the same is available?

Does the Supplier have teaming agreements with them? Are they supporting the Supplier in

ensuring that all terms of the RFP are adhered to?





6 Contract Negotiations

6.1 Types of contract The Planning and preparation that has to go in for negotiations depends upon the type and nature of

contract. The main types of contracts are discussed below

6.1.1 Time and Material Contracts

From a risk perspective Time and Material contracts are simple. The Project is managed by the customer

and hence the Supplier does not carry the risks of Project failure, cost escalation or timelines getting

stretched. The Supplier‟s success in such contracts depends upon their ability to supply adequately skilled

resources in required number when required and provide for replacements when necessary. Negotiations

are centered on relatively simpler issues such as billing rates, and whether there would be a trial period foreach resource during which the resource can be billed or not. The key resources are most often screened

by the customer before acceptance. Contract performance is based on fulfillment of resource

requirements. If the customer is unhappy with the quality of resources, replacements are given and in

extreme cases, when the productivity is low during the learning stage, the customer is satisfied if a rebate

or discount is given to cover for the period of low productivity. Supplier behavior that characterizes

successful T&M contracts is:

Little or no negotiation

Prompt fulfillment of requirements

Prompt replacements where necessary

6.1.2 Fixed Price Contracts

Fixed price contracts are far more complex. Payment to Supplier is based on achievement of Project

milestones. There are penalties for delay and liabilities exceeding the contract value if the Project fails.

There are dependencies on Customer and other parties which if not managed well, can result in delays or

in extreme cases in failure. Fixed Price, System Integration projects are the most complex where the

Prime Supplier takes on the responsibility for the integrated Solution comprising hardware, systemsoftware, Applications, Interfaces and Networking. The Prime contractor has to manage multiple vendors

to deliver an integrated solution. The web of interdependencies creates a complexity which must be

recognized and addressed through:

creation of an appropriate structure of roles and responsibility,

clearly defined scope for each party,





granular level project plans for each sub project,

an Integrated project plan that has sufficient slack to cover anticipated risks,

disincentives for delay by any party,

severe liability for material default,

payment terms that keep each party sufficiently interested in the Project at every stage,

Clarity and agreement on the change Management plan,

Clear definition of Acceptance Criteria, Defect and Defect Severity

Clear definitions of L1, L2, L3 support and Agreement on post production support

The negotiating skills required for Fixed Price contracts are therefore of an order that is far higher than thatrequired for T&M Contracts. MNC customer‟s have their own in-house teams for negotiation. Smaller

companies engage the services of Firms specializing in such contracts. These professional teams are

skilled at probing and pushing until the Supplier can take no more. Going into such negotiations without

planning and preparation and clarity on the position to take on every issue is therefore likely to end up in a

weak contract that puts delivery at a tremendous disadvantage.

6.1.3 Time and Material Contracts with a cap

Time and Material contracts with a cap are resorted to by customers, when they are unable to specify

exactly what the requirements are. Let us understand the needs of various groups within the customerorganization:

Management – Meet the requirements of the Organization within the budget set by the cap

CIO – Project should be executed within 80% to 90% of the cap to earn some personal recognition

from her management for managing the project well.

Business User – All requirements to be met. Vendor should accept that the requirements will

evolve through an iterative process.

The risks are therefore as follows:

No clear scope and therefore control with reference to requirements specified in contract is not

possible

Business user likely to take a long time giving the requirements. They are also likely to revise the

requirements several times. The process is likely to be iterative.





Without proper safeguards in the contract, the Supplier is therefore at risk as far as effort, duration and

cost of the project is concerned.

The safeguards that may be built in such contracts to cover the above mentioned risks are as follows:

Requirements gathering and analysis may be carried out on T&M basis with a separate cap. The

understanding should be that the requirements would be frozen once the cap for the duration of the

study is reached and no further requirements coming from the customer would be included in

scope. Any requirements or changes in the requirements after the duration for the study is crossed

shall be treated as a change request.

Productivity norms for the build and deployment phase may be agreed upfront and the cap should

be in terms of Size and complexity of the Application to be delivered besides cost. This implies that

the Project may have to be trimmed to fit the cap.

6.2 Important considerations for Negotiation

It must be recognized that in a negotiation there are:

a) Legitimate requirements of the Customer that need to be accommodated

b) Needs of the Customer‟s negotiating team to exceed the expectations of their management which may

not be satisfied if this comes at a heavy cost to the Supplier.

c) The negotiations can therefore break off if a) is not satisfied but cannot break off if b) is not satisfied.

The Customer‟s negotiating team cannot go to their management and report that the negotiations have

broken off when the demands made are unreasonable.

When the Supplier‟s negotiating team is in a position to clearly state their position on any clause with well

articulated reasons, the Customer‟s negotiating team quickly realizes that the Supplier‟s team has thought

through the contract and is well prepared, and where the line is being drawn by them and stops pushing

further. In T&M contracts, Customer appeasement is a strategy that works well. In the negotiations for a

fixed price contract, if the same appeasement strategy is adopted, the Customer will correctly assume that

the Supplier has little maturity for executing firm price contracts and this will make them uncomfortable.

The Customer would then try to compensate their sense of unease by including onerous clauses to protecttheir interests. The interests of both the parties are therefore well served, if the negotiations are informed

by enlightened self interest and in a spirit of trying to forge a long term relationship of partnership which

requires appreciation and recognition of each other‟s needs.





Main items for Negotiation

The main items for negotiation and agreement are:

1. Scope or the statement of work

2. Service Level Agreements and Service Credits

3. Project Governance

4. Liquidated Damages for delay

5. General Damages and Limitation of Liability

6. Termination for Cause and Termination for Convenience

7. Indemnities and warranties

8. Payment Terms

9. Project fees.

The above sequence is a logical sequence to follow from the Supplier‟s perspective. In any case, Payment

Terms and Project Fees should be discussed after agreement is reached on the first 6 items.

The Customer‟s, choice is to negotiate the price first. From their perspective, the price is most important

and heads the list followed by Liquidated Damages, SLAs and Service Credits, and finally the scope which

may contain a few surprises resulting in the Supplier accepting a larger scope after the price is fixed. If the

Customer insists on following a different sequence, then the strategy could be to park a definitive

response to the price and Payment Terms until agreement is first reached on all the first 6 items.

6.3 Letter of Intent

Sometimes, pending drawing up of a formal contract, the Customer desires that the Supplier commence

work based on a Letter of Intent. A letter of Intent is just a letter expressing the customer‟s intention to

award the contract. It does not create any obligations.

Once the work commences, the customer has little incentive to conclude the contract early. The Supplier

on the other hand, comes under pressure since without the contract no payment need/can be made by the

customer for the efforts put in and for the expenses incurred on mobilizing the team. The longer it takes to

conclude the negotiation, the stronger becomes the Customer‟s position and the Supplier very soon gets

into a desperate situation and is compelled to agree to terms of the customer that they would not

otherwise have agreed to.

A Purchase order based on a formal Proposal document or a Statement of Work containing scope,

deliverables, timelines, price, and payment terms creates an enforceable contract. The negotiations on the





Master agreement can then take time without putting the Supplier to any risk. In this situation, the

customer is at a disadvantage to introduce any terms favorable to themselves in the Master Agreement,

since the Supplier is under no pressure or obligation to accept them as they already have a valid contract.

The Supplier needs to recognize that commencing work based on a Letter of Intent is tantamount to

agreeing to all terms including scope, price, payment schedule, timelines, penalties, warranties etc that wilbe proposed by the customer. The negotiations under such circumstances take a considerably long time

since the customer is in no hurry. The Customer may take upto 3 months for coming up with a draft

agreement to which the Supplier responds. The negotiations can drag on for another 3 months without the

Customer agreeing to any changes. Quite often, the customer utilizes the time to further `refine‟ the

document. After about 6 months, the Supplier may realize that they can either accept the agreement

proposed by the customer or pull out. After having incurred expenses on the project for a considerable

period, the decision to pull out is not easy to make since it also involves loss of face besides considerable

financial loss.

6.4 The Contract Document

The Contract document creates a structure. Structure is aptly defined by Robert Fritz, father of structural

dynamics as “the elements in relationship to each other that give rise to behavior”. Does the underlying

structure created by the contract support the desired behavior or is it likely to drive counterproductive

behavior? Projects often fail because the structure is inadequate or defective. These forces are

significantly underestimated as the cause of success or failure. Winston Churchill once said. “First we

shape our structures. Afterwards they shape us.”

The important clauses that form the structure and shape behavior during contract performance arediscussed in this section. The position that the Supplier‟s negotiating team may take and rationale for it is

given where relevant. Each point is made through an appropriate example.

6.4.1 Scope and Delivery related clauses

6.4.1.1 Solution Ownership

Does the Customer own up the Solution? This is an important determinant of behavior. Projects that are

driven by IT departments rather than the Business have huge challenges in gaining acceptance. It

is important that the Customer starts owning up the Solution from the start.

Example 11: Solution Ownership

Given below is a clause from draft contract:





Supplier is a reputed global System Integrator with vast experience in Consulting andImplementing solutions for the banking industry. The Supplier confirms that the Solutioncomprising various Applications proposed is capable of meeting Customer's requirements.

The following addition was proposed by us:

Customer has carried out due diligence of the Solution proposed by Supplier and has found itsuitable for their requirements

Without the addition, there is no ownership of the Solution by Customer. It becomes entirely the Supplier’s burden to get the Solution accepted .

6.4.1.2 Project Commencement Date

If the project is being executed in several phases, then define Project Commencement Date as follows:

(a) In respect of Project Phase I, 1 July 2008 or such other date as may be agreed between the

parties; and

(b) In respect of Project Phase II, two (2) months after the Go-Live date for Phase I, or such other date

as may be agreed between the parties.

Rationale: Defining only one date for Project commencement fixes the end date for the rest of the phases

even when the previous phase is delayed. Linking commencement date for each subsequent phase to end

date of previous phase protects the time available for each phase.

.

6.4.1.3 Simplifying Scope

An SI project may involve implementation of a number of Solutions. The end result that the Customer is

seeking is an integrated system where all Applications work together seamlessly. When the number of

new Applications being implemented is high, we have the following risks:

The Customer‟s business teams must gain familiarity with each Solution before they can give

requirements. The requirements are not just existing requirements but new requirements based on

useful functionality available in the Solution in order to benefit from the investment being made.

This requires the Customer to formulate new business processes and seek necessary approvalwithin their organization. This is an iterative and time consuming process. When, the number of

new Solutions is more than one, and these solutions are interdependent, the complexity grows. It

becomes impractical to begin work on a downstream dependent Solution unless the design is

frozen on the main Application. Also, when the same business team has to look into all the

Solutions, the demands on their time may delay the phase for freezing the business requirements.

Under these circumstances, it makes sense to focus on the main Solution and implement it before





taking up the other Solutions. This can be done by phasing out the delivery where feasible. The big

bang approach of all Solutions going live together and working in a seamlessly integrated manner

from day one rarely works unless it is a Greenfield organization without any legacy.

However, quite often, the requirements in the RFP are for the big bang approach. This happens for

two reasons. The Customer‟s IT organization finds it easier to get a single large approval rather than many smaller approvals. The RFP process is costly and therefore it makes sense to club all

requirements together. The phased approach is not taken in the RFP since, if the phased

approach is taken, it does not justify purchasing all the hardware and software licenses at the start.

Phasing out the purchases has two challenges.

o The discounts are for single large order

o If the purchases are phased out the price quoted will not hold beyond the validity period

The constraints above pose an enormous challenge to delivery and must be addressed.

Example 12: Simplifying Scope

Consider the following clause from a draft contract:

7. Final Acceptance: If the System fails to pass its applicable Final Acceptance Tests after tworepeat series of tests are conducted, then Customer may, by thirty (30) days written notice toSupplier elect at its option:

7.1 to require Supplier to provide at no extra charge such additional services and replacementitems as shall enable the System to pass the relevant tests within a reasonable time as mutuallyagreed between the Parties and in any event within 10 Working Days or such other longer period

as the parties may agree in writing of such notice; or

7.2 to accept the System or part thereof with an abatement of the Charges (the abatement beingsuch amount taking into account the circumstances, as is reasonable and mutually agreedbetween the Parties); or

7.3 to terminate this Agreement and recover all Charges already paid to Supplier under thisAgreement.

The Project involves implementation of several Applications over several phases. The contract as worded

above gives the discretion to the customer to cancel the contract and recover all monies paid even if a

single Application is rejected at the final phase. The following amendment was therefore proposed:

Clauses 7.2 and 7.3 shall be governed by the following rule:

The Project scope Involves:

1. Implementation of Core Business Solution (CBS)

2. Implementation of ERP GL module





3. Implementation of ERP Financials module

4. Implementation of ERP HRMS module

5. Implementation of CRM

6. Integration of CBS with GL

7. Integration of CBS with CRM

8. Implementation of Budgeting and planning Solution

9. Implementation of Profitability Solution

It is recognized that items 1 to 5 have value for the Customer by themselves and acceptance of these

deliverables and payment for the services rendered in delivering these items will not be affected by failure

of any other part of the Solution. It is also recognized that items 8 and 9 are dependent upon items 1, 2

and 3 and these cannot be accepted until items 1, 2 & 3 are accepted. Failure to gain acceptance for

items 1, 2 or 3 will therefore result in failure of acceptance for items 8 and 9 as well. Likewise item 6 can

be accepted only after items 1 and 2 are accepted. Item 7 can be accepted only after item 1 and 5 areaccepted. Failure of any part in a subsequent phase shall not affect anything that is already accepted as

part of a previous phase. This defines the rule for abatement in section 7.2 and rule for recovery of

charges in section 7.3.

In case section 7.3 is invoked, then the deliveries made in respect of failed items shall be

returned/destroyed and may not be used. Also, in such a case, the Supplier will be obliged to carry out

Knowledge Transfer of items accepted on payment of a mutually agreed fee for carrying out the

transition.

Note: If we are to incorporate a clause as above, we also need to give a breakup of the commercials by

line item. Quite often, there is a reluctance to do so. Giving more details, invites greater scrutiny and

gives the Customer a better opportunity to negotiate on the commercials. The Customer could alsoconsider splitting the contract between multiple Vendors or de scope part of the project at a later stage.

On the other hand, giving a breakup upfront prevents disputes later on, if for some reason, the

implementation does not go as planned and some of the Solutions are deferred for implementation. This

is a very likely scenario since implementing multiple Solutions together puts a tremendous pressure on

the Customer‟s business teams to give the requirements, prepare test cases, perform UAT etc. for

multiple Solutions and a decision to defer the non-critical Solutions and focus on the critical ones is highly

likely. In practice, the big bang approach rarely works. Giving a break up therefore avoids the need for

ongoing negotiations if all Solutions are not implemented together as per original plan.

6.4.1.4 Clauses to cover dependency risk

Ideally, the Supplier would like to accept only the risks over which they have control and transfer the rest.

They would therefore like to have a contract which:





Clearly defines the dependency on the other party

Consequences to schedule and cost on account of default by the other party.

Recovery of extra cost incurred on account of delays to the project caused by the other party.

In practice it may not be possible to get an ideal contract if the customer is adamant about not changingany clause in the draft Prime Contract. Under these circumstances, consider including the Project Plan

and the Risk Plan included as an annexure with the tasks to be completed by the Customer clearly spelled

out.

If the customer insists on penalties for delay, then the principle of equity can be invoked to incorporate a

clause for payment by customer for the consequences of delays caused by the customer. At the very

least, there could be debits for delay by customer which can be set off against any credits for defaults by

the supplier without involving any actual payment of money by the customer. An arrangement, which does

not involve any liability for the customer for making actual payment for delay, is more readily accepted.

Additionally, for the tasks which are under the control of the customer, the Supplier may not accept theresponsibility for completion on time since they have little control over it.

Example 13: Dependency Risk

Example A

If the total time for implementation is 9 months and the break-up is as follows:

Requirement gathering, analysis and sign off – 2 months,

Development, testing and implementation - 7 months,

then, the date of completion could be written in the contract as 7 months from the date the

requirements are signed off. Then, if the customer takes longer to complete the requirements

phase, the Supplier is not penalized.

Example B

While accepting Liability for Liquidated Damages for delay, the following clause was added after

negotiation to protect the Supplier‟s interests for delays caused by Customer:

Supplier‟s failure to perform its obligations under this Agreement shall be excused if and only to the extent

that Supplier can demonstrate that:

the failure results from the Customer not complying with any Customer Obligation (the “Relief Event”);

it has informed Customer:





where reasonably practicable to do so, in a manner so as to prevent the Relief Event; or

where the Relief Event was not reasonably foreseeable, in a manner so as to give Customer (where

possible) a reasonable opportunity to remedy or to mitigate the impact of the Relief Event,

and Supplier may inform Customer under this Clause on a weekly basis during project meetings or using

a project review report provided that there is a written record of any such meeting or report; and

it has used or will use reasonable endeavors to perform the affected obligations notwithstanding the

Relief Event and has mitigated (or will mitigate) as far as possible the impact of the Relief Event on the

provision of the Services,

save always that Supplier may not rely, in claiming a Relief Event, on events or other circumstances to

the extent that they arise in circumstances where Customer has been unable to perform or complete any

act or fulfill any obligation where prevented to do so by an act or omission of Supplier.

Subject always to Clause 0 above, Customer shall be responsible for any costs (calculated in accordance

with the Rate Card) to the extent that such costs were reasonably incurred by Supplier as a result of each

Relief Event.

The parties agree that, in relation to each Relief Event, the relief granted by Clause above and the

compliance by Customer with the provisions of the clauses above shall be the sole and exclusive

remedies of Supplier in respect of each relevant Relief Event. However, notwithstanding anything

contained in this Agreement, in no event shall Supplier be liable for any delay or failure of Customer to

comply with Customer Obligations.

Notes:

A schedule was added to the contract containing a comprehensive list of Customer‟s obligations. Delay

on account of non-compliance by Customer of any of these obligations can trigger the `Relief Event‟

Also note that the MoM of a Project Review meeting is enough for the Supplier to inform the Customer ofthe likelihood of a Relief Event. If the word `notice‟ is used in place of inform, there could be trouble. A

notice by definition is a very formal and serious process. It is impractical for a Project Manager to serve

notices on the Customer.





Example 14- Customer’s Obligations included in a contract:

The following is an example of Customer’s Obli gations included as a schedule in a contract and linked to a clause on the `Relief Event’.

SCHEDULE X

CUSTOMER’S OBLIGATIONS

General:

1. Project sponsorship by CUSTOMER’s Top Management (CEO);

2. To provide Top Management Commitment as required from time to time to facilitate successful completion

of the Project as per Implementation Plan;

3. On time availability of the Operating Environment (including but not limited to Third Party Software) as perthe Implementation Plan for providing Services under the Agreement;

4. Supply, installation and commissioning of hardware, storage and network device as required for the

performance of Services under this Agreement;

5. CUSTOMER shall ensure continuous support of and supervision over hardware and software vendors, as

required from time to time, for the duration of the Services;

6. To provide access to (physical/remote) to the Premises, and the designated hardware and software to

enable Supplier to provide the Services;

7. Obligations of Customer under the Implementation Plan;

8. Availability of support resources upon reasonable request on an as-needed basis;.

9. Collaboration and cooperation of stakeholders during the transitioning to production and Go-Live;

Specific

ID No Responsibility When Due

1 A program director and project manager from CUSTOMER. Additionally a single

point of contact for all communications with IT and business teams. Designatedpersonnel from CUSTOMER will be empowered with appropriate authority to

take timely decisions.

Prior to start of the

project

2 Appoint a steering committee to review Project Deliverables and handle issues

requiring escalation. Such steering committee to include at a minimum IT

representative and one business representative.


project





CUSTOMER to ensure representation from hardware and networking vendors, as

and when required, in the steering committee for the entire duration of the

Services.

3 Appoint an empowered Customer project team with the relevant domain,

business and technical skills to engage with Supplier’s implementation team for

the entire duration of the Services (Customer to ensure continuity of team as far

as is possible).;

Formation – prior to

business analysis

phase of the project

and to be available

for the duration of

the services.

4 Provide the required software (such as Outlook, Visio, MS Office/Project, tools

(Project Tracking (if any), Defect Management, system change management tool

etc.), hardware and networking for Supplier Development team required to

perform the Services set forth herein. Customer shall hold valid contracts for the

above.

Prior to build phase

5 Provide a single point of contact for managing change control. Throughout

Engagement

6 Provide access to appropriate staff to attend meetings, workshops and

discussions at a central location. It is the responsibility of Customer to identify

the most appropriate staff to attend in order to achieve the objectives of the

Work package.

Customer will provide all necessary resources as and when required on a

mutually agreed basis.

Throughout

Engagement

7 Customer shall provide suitable meeting tools and office space, office supplies,

furniture, telephone (with international dialing facility), Internet Access and

other facilities at Customer’s office necessary for Supplier to fulfill its

responsibilities and tasks set forth in this Operating Environment. Customer shall

also provide such access outside normal office hours.

Throughout

Engagement

8 Customer shall provide access to all relevant internal documentation and the

documentation shall be in English.

Customer shall ensure that all project related documentation which it

prepares or provides will be in English.

Throughout

Engagement

9 Customer shall facilitate access to the Oracle Metalink for logging service

requests concerning the Project.


project





10 The response time for feedback on a document/issue from Customer as soon as

reasonably possible but in any event not longer than Five(5) Working Days unless

otherwise stated in the Master Services Agreement. Any delay on this account

will have an impact on Project schedules, efforts and costs.

Throughout

Engagement

11 Customer to ensure that User Acceptance Testing will be completed within thestipulated time period. In case of change in timelines, Supplier would initiate a

CCN to rework the estimates. Any delay on this account will have an impact on

Project schedules, efforts and costs.

Validate phase anddeployment phases

12 Customer will provide data required for data migration as CSV file format. Any

other format for data migration shall be mutually agreed upon between Supplier

and Customer. Data cleansing rules will be done by Customer.

Customer to be responsible for data integrity and validity.

During the Data

Migration cycle

13 Provide requisite data from the legacy system in CSV formats (or such other

mutually agreed compatible format) for data loading.

Build and Test

14 Provide format for the different reports and inputs for forms to be developed (if

any)

Analysis and Design

15 Provide Test cases and test data for the various testing phases of the Project to

validate the appropriateness of the solution being deployed.

Build and Test

16 Provide detailed business requirements Business Process

Analysis Phase

17 Training would adopt the ‘Train-the-Trainer’ approach and the Customer would

provide necessary training infrastructure such as Training Rooms with related

tools, desktops for the users and also ensure participation of the nominated

business users who will then be responsible to train the end users.

Various Training

phases of the

Project.

18 For integration of the Applications in scope with current Applications in use,

procure services of the other Application Vendors as necessary to work with

Supplier for the integration.

As necessary





19 Provide “C” Compiler for OS XXXX Prior to installation

of Licensed software

20 Customer to secure required Public IP addresses for deployment of webapplications.

By commencement date

21 The Customer shall get a sign off from Supplier before releasing Purchase Order for

hardware including Networking components to enable Supplier to verify that all

details/specifications in the Purchase Order are in conformity with the Architecture, Sizing

and Performance assumptions.

Operating Environment

Operating Environment particulars/details as specified below shall berequired from the various stages as outlined below till the end of the Project.Stage Particulars/Details

Before

release of

Purchase

Orders





Pre-kickoff

1. Project Office Infrastructure

a. Seating Capacity for an average strength of 30+ Consultants (peak

strength of 40)

b. Seating for BMI core team (Key User Team)

c. For each of the 40 seats, ready-for-use Work Stations (at least 1 GB

RAM) + Network Connectivity + Internet Access + Telephone

d. Color Printers + Copiers

e. File and Print server

f. Meeting Room with Projector & Screen

g. Three (3) Training Rooms (with PCs) (the project team is to pre-advise

Customer of the exact dates and times when these are required)

2. Software: All required standard desktop and project documentation

(such as Outlook, Visio, MS Office/Project, tools including project

tracking (if any), defect management etc.) should be licensed for use.

3. Hardware for the application environment: Development, Test and

Training Instances/Environment with OS installed.

4. Establishment of Virtual Private Network (VPN) connectivity to allowaccess to the application environment

SolutionDesign

5. Virtual Private Network (VPN) connectivity to allow access to the

application environment

SolutionBuild

6. Hardware: Production environment available and configured as per the

solution architecture.

EntireProject

7. Any other requirements for the Operating Environment would be

identified and agreed at the end of the project initiation phase.





6.4.1.5 Change Control

The Change Control procedure can be an effective mechanism to control scope creep only when:

Requirements are specific and detailed.

The Contract maintains a balance of power between Customer and Supplier. ( see Payment Terms

and Dependency Risks)

There are no clauses in the contract that create a wider unspecified obligation.

Customers like to include a clause such as follows:

“To the extent that, in connection with the Project, it transpires that any additional or ancillary services are

required to be performed by Supplier for the proper performance of the Services so far as they relate to

the Project, Supplier shall perform such additional or ancillary services without additional charge and in compliance with this Agreement and such additional or ancillary services shall be deemed to form part of

the Services.”

It is difficult to predict the effect of a clause such as above on scope creep. Consider rewording the clause

as follows:

“To the extent that, it transpires that additional or ancillary services are required to be performed by

Supplier for the Project, so far as they are reasonable in nature and necessary for the delivery of the

Project (but not including any Developments), Supplier shall perform such additional or ancillary services

in accordance with the Change Control Procedure and in compliance with this Agreement and such

additional or ancillary services shall be deeme d to form part of the Services.”

Alternatively, the following could be added to the clause:

Any services, functions, tasks, or responsibilities that are significant in terms of effort are mentioned

specifically in the Agreement and are out of the purview of this clause. The total effort on account of such

deemed services shall not exceed 2% of the total effort.

For variations that may be expected in scope, it is advisable to add a rate card to cover those variations to

avoid the need for negotiations during project execution. For example, if it is assumed in scope that data

migration will be carried out for 10 million accounts, then a rate card for every additional 100,000 accounts

may be agreed upfront to avoid the need for any negotiations on the price during contract performance. In

a project situation, the Supplier is under time pressure for meeting project milestones and cannot wait fornegotiations to conclude before carrying out the activity. In the absence of agreement on the price before

delivery of the service, the supplier may not get a fair price for the additional services rendered.





6.4.1.6 Maintenance Contracts - Service Level Agreement

The SLA should be negotiated to minimize the likely impact of the SL not being met. Apart from the

financial impact, underperforming the SL results in poor Customer Satisfaction and the Project Team

comes under tremendous stress. Repeated failure to meet the Service Levels leads to escalations and

demands on top executive time which has a tremendous cost to the Organization.

The SL must be reasonable and achievable. The definitions must be clear.

Normally, the total SLA credit is capped at 10 % of the contract value for the period (usually month)

relevant for SLA measurement.

The contract value must be clearly defined and should include only the service component excluding allother costs. The SLA credit should be a percentage of the fee relevant for rendering the service.

The period of measurement could be a month/quarter/half year/year. A longer period helps in making up

for an unusually bad month. On the other hand, if there is an unusually bad month which results in not

achieving the SL for the year, then the financial impact is on the fee for the year rather than fee for month.

In balance therefore, a month as a period for SLA credits may be preferable. While the probability of

incidence of SLA credit goes up when the period is short rather than long, the impact is also small.

Example 15: Negotiating for Service Level (SL)

Example A

Given below is an example of SL proposed in a RFP

End-To-End Application Support -

Performance Category Expected Minimum

Measurement

Window

% of

Invoice

GoldApplication Availability (minutes down

per month during hours of operation) 65 130 Monthly 8.00%

Severity Level 1 incidents Resolved

Within 1 hour (during hours of operation) 99.50% 99.00% Monthly 8.00%


Within 24 hour (during hours of operation) 98.50% 98.00% Monthly 5.00%





Severity Level 3 incidents Resolved as

agreed 98.50% 98.00% Monthly 2.00%

Silver

Application Availability (minutes down


Severity Level 1 incidents ResolvedWithin 3 hours (during hours of operation) 98.00% 97.50% Monthly 8.00%


Within 48 hours 97.00% 94.50% Monthly 5.00%


agreed 97.00% 94.50% Monthly 2.00%

Bronze

Application Availability (minutes down



Within 6 hours (during hours of operation) 97.00% 94.50% Monthly 8.00%


Within 96 hours 92.00% 89.50% Monthly 5.00%


agreed 92.00% 89.50% Monthly 2.00%

Enhancement - Performance

Category Expected Minimum

Measurement

Window

% of

InvoicePromoted into production within +- 3% of

budget 95.00% 90.00% Monthly 1.00%

Promoted into production with zero

defects 99.00% 98.00% Monthly 2.00%

Promoted into UAT with zero defects 95.00% 90.00% Monthly 1.00%

Key Deliverables completed on or before

planned date 95.00% 90.00% Monthly 1.00%

Reduction in number of code defects by10% 100.00% 98.00% Monthly 2.00%

Log "sev1 monitoring alerts" (auto

generated alarms) within 15 minutes 95.00% 90.00% Monthly 2.00%

Application Performance - Performance


Measurement

Window

% of

Invoice

Batch Schedule Completion On-Time

Rate 98.50% 98.00% Monthly 4.00%

Application Response Time as per SOR 97.50% 92.50% Monthly 2.00%

Transaction time for standard Database

transactions 0.8 sec 0.1 sec Monthly Test 2.00%

Transaction time for standard Tibcotransactions 3.2 sec 3.5 sec Monthly Test 2.00%

Customer Satisfaction - Performance


Measurement

Window

% of

Invoice

Customer Satisfaction 90.00% 80.00% Monthly 4.00%

Staffing Expected Minimum Measurement % of





Window Invoice

Supplier Key Personnel (personnel

identified in RFP) Annual Turnover 15.00% Semi-Annual 2.00%

Total Supplier Personnel Annual Turnover

Assigned to TFS In US 15.00% Semi-Annual 2.00%

Supplier Personnel Annual Turnover

Assigned to TFS Outside US 20.00% Semi-Annual 2.00%

Total 98%

The SL credit will be issued if:

Performance is below minimum.

Performance is below expected for any 3 months in previous 12 month period.

Points to note:

1. End to End SLA for Application Availability includes time lost due to Infrastructure issues as well as

due to Application. The Infrastructure and the Service desk may be handled by different Vendors.While from the customer‟s perspective, end to end SLA makes sense, from the Supplier‟s point of

view, they could be penalized even if Application is down in a month longer than the SL due to

infrastructure issues alone.

2. Although the total SLA credit is capped at 15% of invoice value for month, the SLA credit weight

ages assigned to individual line items add up to 98% of invoice value. The cap can be reached with

as few as two line items out of twenty six in default. The financial impact even for normal variances

from the SL will be high.

3. Examine the SL for “Promoted into production within +- 3% of budget” The minimum is 90% and

expected 95%. Such high percentages make sense only when a large number of items (50 ormore) are promoted into production in a month. This is a large number. If the number is say 9

then even if one is not within +- 3% of budget, then the achieved number is 88.88 percent which is

below the minimum acceptable. In this situation, defining minimum as 90% is the same as 100%

since, if even one enhancement does not meet the SL, the Supplier is in default. The same holds

good for the next two SLs.

4. Examine the SL `promoted into production with zero defects‟. This depends upon the rigor followed

in conducting the UAT which is Customer‟s responsibility.

5. Customer Satisfaction – Should this be an SLA for monthly monitoring or at half yearly intervals?

Should the weight age be as high as 4% of invoice value? Should this be a SL or KPI? What arethe objective parameters for measuring Customer Satisfaction? Are not the rest of the SLs the

objective parameters that determine Customer Satisfaction and what are left out are the subjective

parameters. Should subjective parameters be allowed as SL carrying a hefty 4% penalty?

6. Examine the SL `Reduction in number of code defects by 10%‟ on a Year on Year basis. This pre

supposes that there is scope for such improvement. If the number of defects is already low, then

there may not be scope for reduction at the rate of 10% per year. It is better to define what is the





target say x defects per 100 lines of code and agree for a YoY reduction until the target is reached.

Thereafter, maintain the standard achieved. Also, the method of measurement is important. If it is

100 –(number of defects in current month*100/number of defects in same month in previous year ),

then it is possible that the same month in previous year may have had very few defects on account

of fewer enhancements released or low complexity of enhancements. These definitions therefore

need to be refined.

Generally Accepted Service Level Principles

The generally accepted principles about SL are:

1. Not designed to penalize the Supplier or reduce cost to Customer

2. Meant to maximize the Service Level

3. All parameters must be objective and measurable

4. Achievable

If the principles are enunciated and agreed before the SLA is negotiated, they facilitate quick closure. The

four principles are self evident and easy to agree with. Once the principles are agreed, then it becomes

difficult to maintain a position that violates the accepted principles. In a particular engagement, intense

negotiations were carried on over several sittings spread over 2 weeks without coming to closure. Finally,

in one sitting, the Supplier‟s team started the meeting by enunciating the principles and getting the

Customer‟s agreement on them. That happened to be the last sitting and agreement was reached on all

SLAs in a very large System Integration project within hours.

If we look at the SL proposed in the example above, the total weight ages assigned is 98% of invoice

value and this violates the first principle. The intention is clearly to get a 15% cut on the invoice value any

which way (even if 2 out of 26 SLs are not met).

There are no incentives for overachieving while there is heavy penalty for under achievement. This

violates both principles 1&2.

Any SL which is in the nature of double counting violates principle 1. Customer Satisfaction may be one

such. The objective parameters for Customer Satisfaction are all the other SLs and what remains are the

subjective parameters which cannot become a SL as they violate the third principle.

If the cap is more than 10% of invoice value, then it violates principle 1

The Achievable principle has to be tested with past records. Necessary due diligence must be carried out

to ensure that the SLs can be achieved consistently.

Example B

In a Support and Maintenance Contract, Service Level with SL credits at 10% of fee is proposed for

meeting the SL relating to the Mean Time to Defect (MTTD). The Mean Time to Defect is defined as





number of days between two defects materially affecting the business.

The Supplier may agree to accept MTTD as a Key Performance Index without SL credits but may not

accept it as a SL with SL credits for the following reasons:

The greater the number of defects that gets past the UAT the lower the MTTD. It is thereforea function of the rigor followed in UAT which is customer‟s responsibility. .

A low MTTD could indicate a need to reduce code complexity or retire an application that hasoutlived its utility. Over a period, the number of changes/enhancements carried out to anApplication render the code too complex until a stage is reached when the falling MTTDindicates that the Application needs to be reengineered or retired.

The causes of a low MTTD are therefore rarely attributable to the quality of Support and Maintenance

Services being rendered by the Current Supplier.

6.4.1.7 Back to Back SLA with partner

In a SI project where a Networking Solution Provider was a partner, the SL that the partner committed

upfront was 99.5% availability.

How availability is defined by Networking Solution Provider and Customer will differ.

For the customer, what is relevant is availability during the hours the Network is required. For the NW

Solution provider, it is availability on a 24hrsx365 days basis. Let us see how this translates to the

Customer‟s definition.

Availability of 99.5% implies downtime of <= 0.5% of 365*24 hours = 43.8 hours.

Remember that the 43.8 hours of downtime can be during the Customer‟s business hours. (Any downtime

outside these hours will not be noticed and recorded. The partner can then justifiably claim that the SLA

has been met).

For the customer this translates to downtime of 43.8 hrs/(270 working days*12hours per day) =1.35 %

Or Availability of 98.65%

The SI or Prime contractor therefore concluded an SLA of 98.5% with the Customer. Had they concluded

for anything more than that, they would not have been in a position to pass on all of the SL credits to

partner. This example, underlines the need for careful definition of the SL.





6.4.1.8 Availability SL

The availability of the IT Solution is affected should the primary site go down and the secondary (DR site)

has to take over. Should the downtime required for switchover count for the availability SL? If the DR site

is not in an Active/Active mode, then the answer can be a no.

Rationale: If the DR site is in an Active/Passive mode, then the time required for it to takeover is

considerable. The Supplier cannot be penalized if the Customer has opted for a cheaper technological

Solution that takes more time for the switch over. The understanding as to what constitutes downtime for

calculating the Availability SL should be clearly documented.

6.4.1.9 Maintenance Contracts – Effort Estimates and Pricing

A new Support and Maintenance contract may be awarded in one of the following three situations:

d) Following implementation of a new Application

e) Transitioning from another provider on account of Service Levels not being met by the incumbent.

f) Transitioning from another provider for cost considerations

The maintenance and support effort for a newly implemented Application in year 1 is almost twice of the

effort required for the same Application in year 3. This is on account of higher number of support calls,

training needs and larger number of fixes in the initial years. Therefore budget for higher effort in initialyears showing a 20% reduction Year on Year for the second and third year. By the end of third year, a

steady state is reached and further reduction in the effort is slow and may actually increase on account of

additional efforts to support enhancements to the Application.

If statement b) above is true, then the reasons for SL not being met by incumbent Supplier need to be

examined. If the incumbent Supplier is also the developer of the Application that is to be maintained, then

it is unlikely that another Supplier would be able to better the SL achieved by the incumbent Supplier at

least in the first year. If the incumbent Supplier is not the developer of the Application, then the SL

achieved may have been low on account of less skilled resources employed. The Supplier will therefore

have to meet higher SL than what was achieved by the incumbent Supplier and may have to employ

better skilled resources in larger numbers. The price of service can then be expected to be higher thanthat of the incumbent Supplier.

If the change is on account of cost considerations then clearly the SL achieved by incumbent supplier

have to be matched at a lower cost. A lower cost does not imply lower effort. The effort in year 1 for the

new Supplier is likely to be higher than what was achieved by the incumbent Supplier during their last 12

months on account of non-familiarity with the Applications to be maintained. Cost effectiveness will thus





have to be achieved through lower billing rates of the new Supplier and not necessarily through lower

efforts.

6.4.1.10 Maintenance Contracts - Efficiency sharing

The Customer often expects Supplier to realize year over year efficiency improvements and sharing of

benefits in fixed price contract.

A fixed price maintenance contract has to be competitive to win the bid. Year over Year efficiency is

therefore factored in while arriving at the fixed price contract. The Supplier may therefore agree to share

benefits, if the efficiency improvement is beyond what is already factored in.

For example:

If the fixed price quoted, takes into account improvement in efficiency @ say 5% per annum and increase

in Supplier‟s costs @5% per annum then for any gains, beyond this, the Supplier may agree to pass on

40% of the benefit after adjusting for unexpected expenses.

Note: The best companies show improvement in efficiency of 4 to 5% per annum on a stable and mature

process. A higher improvement of 15% to 20% is possible only during the first couple of years of a New

Application.

For any commitment to customer for Year on Year increase in efficiency, analyze the components of work

that will contribute to such improvement such as:

1. Support Calls: Reduction in number of support calls that are purely for clarification/education of

the user. Make the customer commit for YoY decrease in support calls as a necessary condition fo

passing on any benefit of reduction in effort for addressing such calls. The benefit of cost reductionis realized if the effort drops by at least one FTE or in multiples thereof.

Some of the ways in which support calls could be reduced are:

A list of Frequently Asked Questions and their answers can be published over the

Customer‟s intranet with search facility to quickly access relevant information. The user can

be encouraged to use this information rather than make calls for support.

11Feedback to the Customer on the nature of support calls may be given by means of a

periodic Report so that they can identify training needs and take appropriate steps to train

the end users.

Extrapolate the historical trend of reducing support calls to predict future effort

2. Fixes: This effort can be split into time required to diagnose the problem, coding, testing, patch

release. Time required to diagnose a problem will reduce with better documentation, learning

gained over a period and skill of the consultant. There could a planned reduction in the effort for

providing 1fixes by shortening the time to diagnose a problem.





3. Reduction i1n number of fixes required. Historical trend of reducing number of fixes that are

required each subsequent year could be used as a guide.

4. New Developments: Keep new developments out of scope of fixed price contract if possible.

Sometimes small developments requiring not more than a few person days effort for each

requirement is included in the scope. In such a case, limit the number of such developments andhave this limit incorporated in the contract.

5. Change Order: New developments will require additional effort for supporting and maintaining the

enhancement. The contract should provide for increase in the price to cover for this additional

effort. The basis for arriving at the additional effort and the charges for it may be made explicit in

the contract. This could be based on number of Function Points delivered or based on any other

reliable metric.

The contract must therefore have clarity on:

The sources of efficiency gains, extent of gain expected, dependency on customer (if any) to

achieve the gain and any minimum commitment that may be made.

Sources of increase in effort and the basis for additional billing on account of it.

The Contract, while providing for sharing of the gains of an increase in efficiency, should also provide for

increase in cost on account of additional effort for supporting New Developments or Enhancements.

An activity wise quarterly resource deployment plan may be drawn up before making any commitment on

sharing of efficiency gains. Thereafter, the plan may be used to achieve the gains. In the absence of

detailed planning, the Supplier may commit to gains based on a guess which may turn out to be

unachievable.

6.4.1.11 Maintenance Contracts – Benchmarking of Effort

Maintenance contracts sometimes come with a clause giving customer the right to benchmark the services

for Price and Service Levels anytime during the contract period and for making adjustments in price and

service levels as a result of the benchmarking exercise.

The following safeguards may be added:

Bench marker should be an independent party well qualified to carry out the exercise and

should not be a competitor of the Supplier.

Similar services provided by other pre-eminent companies comparable with the Supplier

should be studied for arriving at the benchmark.

The contract may contain a list of pre approved bench markers to prevent any disputes at a

later date.

Price adjustments should be possible in both directions and equally binding on both parties.





Supplier should have a right to initiate a benchmarking exercise

The fees for benchmarking could be shared or paid by the party at whose instance the

exercise is taken up.

The possible objections against providing for adjustments in price both ways or for allowing the Supplier to

initiate the benchmarking exercise could be the specious argument that the Supplier is expected to be an

expert and not make mistakes in their effort estimate:

The possible response to the objection is:

The need for the clause arises only on account of the possibility that there could be an error

in the estimate and the error could be either way.

The effort estimate can go wrong since it may be based upon imperfect information. Studies

of projects executed worldwide show that the error in effort estimate is very common.

Projects may get completed as per schedule but rarely as per efforts budgeted. If the

contract is awarded as a result of a competitive bidding process, then the process rules outthe possibility of a Supplier being selected who has estimated effort on the higher side. The

Supplier selected as a result of the competitive bidding process is therefore likely to have

underestimated the effort. The Supplier is therefore in greater need of the benchmarking

clause than the customer. (As a matter of fact, a competitive bidding process is itself a

process of benchmarking the selected Supplier for price and SL against all the available

competition. The Customer therefore has little justification for insisting on a clause for

benchmarking. The opportunity may therefore be utilized by the Supplier to get an even

handed clause inserted which may prove to be beneficial)

Principle of Equity requires equal protection to both parties from errors committed.

6.4.1.12 Maintenance Contracts – Exclusivity Clause

The Supplier may not be granted the exclusive right to perform maintenance and support services. In

addition, the Customer may want to have the right to gradually transition the work to a third party. In such

a situation constraints on such rights may be considered such as:

Not more than (say 15%) of the contract value can be divested for any reason whatsoever.

Cumulatively, if more than (say 15% of the services) are divested for any reason, then the Suppliermay insist on the right to terminate the whole contract for cause.

A right to divest without any constraint can be misused to develop a weak but low cost competitor to

gradually take up all the work starting with the simplest work.

Example 16: Maintenance Contract – Benchmarking and related clauses

:





A proposed draft contract for Maintenance and Support activity with multiple SOWs (statement of works) hadthe following clauses:

Non –Exclusivity clause. The Customer is free to engage other service providers for thesame/similar work

Customer has the right to terminate the whole contract or individual SOWs for convenience.

Customer has the right to terminate the whole contract or individual SOWs for cause. If terminatedfor cause, the Supplier is obliged to provide free services for transitioning to alternate Supplier thatcould extend upto 12 months to enable the new Supplier to take over.

The Customer has the right to determine at their sole discretion the benchmark price and servicelevel for any service anytime during the contract period. Customer‟s decision is not subject to anyof the provisions for Dispute Resolution and therefore cannot be disputed or even taken up fordiscussion in any of the Project Management forums.

Supplier has a choice of accepting the benchmark price and Service Levels within 3 months.

Non-Acceptance of the benchmark by Supplier is sufficient `cause‟ for termination of the SOW

Implications:

The Contract enables the Customer to find a low cost supplier at a future date and bench mark against theirprice. The Supplier can then either accept the `benchmark‟ or transition to the low cost supplier over a periodthat could extend upto 12 months without charging any fee for the transitioning service. This can be done oneSOW at a time providing ample flexibility to build alternate low cost suppliers.

The portions inimical to the Supplier‟s interests requiring negotiation are:

The Bench marker is not a mutually acceptable independent third party but the Customer who is verymuch an interested party.

From the contract it is not clear what the benchmark is. For example, comparable services providedby Supplier‟s of similar standing could be the benchmark. Since no such detail is mentioned here,there is no benchmark to speak of but an arbitrary determination of price and SL by the customer.

Any arbitrary determination of the `benchmark‟ cannot become the `cause‟ for termination of a SOWrequiring the Supplier to provide free transitioning services for a period that could extend upto 12months.

Even in case of termination for genuine cause, the period for free transitioning of services may be nolonger than the period taken by the Supplier when this was transitioned to them. For transitioningservices required beyond this period, fee should be chargeable.

Since the Customer can in any case terminate the SOW for convenience, there is no need for such anarbitrary and one sided clause for `benchmarking‟ whose sole purpose appears to be to enableCustomer to get free services for transitioning.

6.4.1.13 Maintenance Contracts – Term of the Agreement





Customers prefer to have a fixed term and an option to extend the term multiple times. For example, a

fixed term of 3 years with an option to extend the term further by 2 (two) one year periods.

The Supplier may like to renegotiate the price or other terms at the time of renewal and may therefore be

unwilling to provide the customer such an option. , the Supplier may like to stipulate (say 5%) increase in

the price at each renewal. Else, the Supplier may like to add a price for the option to arrive at the overallprice.

There is a risk associated with every option and the risk must be priced in. Some of the common

embedded options in a maintenance contract are:

Termination for convenience

Benchmarking for Price and Service Levels

Extensions in the term

Variations in the services

Please also see section 5.5 - Pricing of Options in Maintenance Contracts

6.4.2 Legal Clauses

6.4.2.1 Complete Agreement and Complete Offer Clause

The prime contract document must expressly include a „complete agreement‟ clause which details all of

the documents which together constitute the whole agreement between the parties.

Due care as indicated, must be exercised while including the following documents:

Table 2 List of Contract Documents

Document Reason for not including

RFP Contains many lose statements as to the requirements including words such as etc.The final scope is what is agreed in a Statement of Work (SOW) and not what iscontained in the RFP. It should be made clear that when the various documentsdiffer, the priority for deciding the correct intention will be the SOW documentfollowed by the Proposal or RFP response document.

Proposal or RFPresponse

The Proposal document constitutes the offer based on which the contract isawarded and therefore cannot be left out. The proposal document must have astatement as to what constitutes “an entire offer”.

The executive summary or the covering letter which summarizes the advantages ofawarding the contract to the Supplier written to generate the sale is part of theproposal but clearly not part of the offer. The advantages are only indicative of whatthe Client may expect but not part of the deliverables. An explicit statement of what sections of the Proposal constitute the offer is therefore necessary to rule out the executive summary being interpreted as part of the offer.





Also care should be exercised about including third party specifications andstandards that are subject to change without notice and without consent of buyer.

Third party process and methodology documents may not be incorporated unlessthese form part of the subcontractor‟s offer document to the prime contractor andare binding on the subcontractor.

Proposal Defensepresentations

This is not a very precise document and by nature brief and concise. Could poseproblems in interpretation later and should be left out.

Clarifications toquestions raised by thecustomer

The clarifications could be detailed or summary. Short answers often create largerobligations as these are likely to be interpreted differently by the customer fromwhat was intended. The question itself may not have been understood well. Greatcare should therefore be exercised while giving clarifications. A good practice is tofirst give a detailed description of what we have understood by the question beforegiving a reply.

Should avoid giving a reply in a hurry or on the spot or without getting the responsevetted by a person who is most competent to give the reply. The replies create

representations which become binding. In case, the customer insists on includingthese as part of the contract, have the replies vetted again and modified ifnecessary before inclusion.

6.4.2.2 Termination Clause

Termination for cause

In the case of Termination for cause, the following maybe added:

“The Customer shall return/destroy and may not use any and all deliverables that are: a) not paid for or b)

where the Supplier has refunded the fee paid for the deliverables while complying with the terms of the

termination clause”.

Rationale: The principle is a simple one. The Customer must pay for what they keep. This makes

termination difficult without paying to keep the deliverables.

To avoid any doubt as to what has been paid for, it helps if there is a separate line item in the commercials

for each deliverable.

The Termination for cause clause may provide for the payment of the following:

o Unrecovered elements of any unamortized capital investments

o Charges relevant to Services performed upto the effective date of termination, including any

Continuation Services. In the case of a Development activity, this may be pro-rated against the

relevant Milestone payment.





o Termination Assistance charges on a time and materials basis, using the Day/Hour Rates of theresources used to provide the Termination Assistance. If the same resources are also providingcontinuation services, then the exact hours put in for Termination Assistance may be logged.


If there is also a Termination for convenience clause, it is all the more necessary to have line items for

each deliverable so that payment on what is delivered is fully realized. A Termination for convenience

provides for early termination of the contract by the Customer. A fixed bid contract price is based on the

assumption that the contract will run its term. An early termination therefore has implications for the bottom

line. This has to be considered and factored in. A fee to be paid if the contract is terminated for

convenience may be added or the payment plan may be drawn up in a manner so that a larger proportion

of the fee is realized early to compensate for potential loss for early termination.

The Termination for convenience clause must provide for the payment of the following:

o Lease breakage charges (including those paid to Supplier‟s employees) and the unrecovered

elements of any unamortized capital investments

o Unamortized portion of the cost of mobilizing the team. For example, if the average cost of

mobilizing one team member is $3000 and size of the team is 50 and the Project Term which was

originally 36 months is terminated at the end of the 15th month, then the unamortized portion of

this cost is $3000*50*((36-15)/36) = $87500. The assumption here is that this cost is recovered

uniformly over the period of the contract.

o Charges relevant to Services performed upto the effective date of termination, including any

Continuation Services. In the case of a Development activity, this may be pro-rated against the

relevant Milestone payment.

o Termination Assistance charges on a time and materials basis, using the Day/Hour Rates of theresources used to provide the Termination Assistance. If the same resources are also providingcontinuation services, then the exact hours put in for Termination Assistance may be logged.

6.4.2.3 General Damages

Invocation of the clause for General Damages may only be allowed on termination of the contract.

Rationale: This is a reasonable stipulation. A situation where the Customer sues Supplier for General

Damages is serious enough for termination. A Supplier cannot be expected to continue to provide services

while the Customer sues them for General Damages. Such a stipulation prevents frivolous litigation or

threats of litigation.





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

The price in a competitive bid is based on cost to the supplier for delivering the services plus a margin.

The implications of the pricing model for the contract are:

The price is not based on value delivered to customer or the profits that the customer stands to

realize from the services or the savings that they stand to gain. The Supplier need not therefore

take responsibility for actual loss of profit or revenue to customer on account of delays or missing

of the Service Levels (SL). The assurance to the customer as regards on time delivery, quality and

meeting of SL is the company‟s track record and its quality certifications besides agreement on the

SL and delivery dates. The sole remedy for delays or for not meeting of the SLs should be

termination of contract for cause if the infringements are serious enough. The clause on general

damages may therefore cover other material breaches such as breach of confidentiality, IP

infringement, gross negligence etc and not delays or missing of the SLs.

Contracts sometimes provide for Liquidated Damages (LD) for delays or for SL infringements inwhich case there is a strong legal argument for excluding SL infringements and delays from any

clause that seeks to recover actual loss since LD by definition are ascertained amount of damage

and compensation for the damage for a specific breach (e.g., SL Default) agreed between the

parties at the time of the contract.

The price is not based on the size of the customer‟s business whereas loss to the customer on

account of breach of confidentiality, IP infringement, etc is linked to the size of the customer‟s

business. There is therefore, a justification to limit the liability for general damages to actual

ascertained damages or some fraction/multiple of the size of the contract or to fees paid in the

previous 12 months if the contract covers a long period.

6.4.2.4 Exclusions in the General Damages definition

Liability for Indirect or consequential, incidental or special loss or damage or any loss of profits or revenue,

loss of business or loss on account of inaccuracy of data is risky and may be excluded.

While negotiating a contract the Customer and their attorneys were very firm on including the above. The

attorney said that they had never negotiated a contract where the abovementioned items were excluded.

The Customer also said that this went against the company‟s policy and was unacceptable. This required

escalation to the highest level and the negotiating team had no hope that it would be cleared.

The response of the Supplier‟s team was as follows:

The fee is based on the efforts and not linked to the size of the Customer‟s business, or the benefit

that the Customer would derive in terms of increase in revenue, profits etc. So when the

compensation is not based on the benefits that the Customer would derive, the Supplier cannot be

held accountable for any loss of revenue, profit etc. This went against the Suppliers‟ pricing and

business model and was therefore unacceptable for the Supplier.





The negotiating team could therefore put up the matter to their management and get a clearance

for the exclusions or the Supplier and Customer could sit down together and prepare fresh

commercials based on the benefit the customer would derive from the Solution.

The Customer understood and accepted the Supplier‟s position and agreed for the exclusions.

6.4.2.5 Affiliates

Some of the contracts also include a definition for Affiliates with the intention that should the company

acquire Affiliates, the Solution can be extended to the Affiliates.

Since this is for a future acquisition, the Supplier is entitled to negotiate a fee per Affiliate, if the Solution is

extended to the Affiliate. This is over and above any implementation fee that the Supplier may charge for

services for implementing the Solution for the Affiliate.

A view may be taken that since there is no additional effort for every Affiliate, the Supplier can agree to

allow the Solution to be extended without any fee. In such a case, damage to Affiliates may not be allowedin the General Damages clause. Extending a benefit for free to the Affiliate, and taking on the liability for

damages to the Affiliate on account of the Solution does not stand to reason.

6.4.2.6 Indemnities

There are a host of indemnity clauses which are fairly standard including covering claims on the Customer

by third parties for infringement of IP. Generally speaking, IT Service Provider provides only services and

therefore there is little scope for third party claims for infringement of IP by the Supplier. Nevertheless, a

contract document contains several `standard clauses‟ which may do no harm even if these are not

relevant.

The Customer sometimes puts conditions that imply that the Customer‟s products and processes are their

IP and seek to protect their IP through onerous confidentiality clauses even where the Customer is in the

services industry.

If there is an element of IP in the products and processes, and in case there is a claim by a third party that

the IP actually belongs to them, then is the Supplier exposed to a risk by virtue of delivering a Solution that

covers the product or process? If the Supplier perceives such a risk then it can be covered by

incorporating a suitable clause as follows:

“Customer shall fully indemnify and keep indemnified Supplier against all claims, demands, actions, costs,expenses (including, but not limited to, full legal costs and disbursements on a solicitor and client basis),

losses and damages suffered by Supplier arising from or incurred by reason of any infringement or alleged

infringement (including, but not limited to, the defense of such alleged infringement) of any Intellectual

Property Right in the Service product or business process that is specified by Customer for delivery by the

Supplier.”





Example 17: Representations and Warranties

Consider the following clause proposed by a Customer in the logistics business with business spread across theWorld.

Supplier recognizes that CUSTOMER is not fully familiar with the laws, rules, orders, regulations, policiesand customs of the Designated Countries and that CUSTOMER has entered into this Agreement on materialreliance on Supplier‟s representation and warranty that this Agreement and the relationship created betweenCUSTOMER and Supplier does not violate any law, rule or regulation of the Designated Countries, includinglaws regulating elections. Supplier further represents and warrants that neither the receipt of fees under thisAgreement nor performance of the Services under this Agreement is in any respect a violation of the laws,rules, orders, prohibitions, regulations or policies of the Designated Countries.

It is more likely for the Customer to be familiar with the laws of the countries the Customer is operating in

rather than for the Supplier. The Customer is trying to achieve the following through the above clause:

Disown any implied warranty from Customer to Supplier that the Agreement is in accordance with the lawsof the designated countries.

Push the burden of the warranty onto the Supplier

Consider rewording the Clause as follows:

Supplier recognizes that Customer is not fully familiar with the laws, rules, orders, regulations, policies and

customs of the Designated Countries. The Supplier may therefore make independent assessment that this

Agreement and the relationship created between Customer and Supplier does not violate any law, rule or

regulation of the Designated Countries, including laws regulating elections. Supplier may further determine

that neither the receipt of fees under this Agreement nor performance of the Services under this

Agreement is in any respect a violation of the laws, rules, orders, prohibitions, regulations or policies of the

Designated Countries.

The rewording is equitable where both parties are put on guard without any implied warranty from either party.

6.4.3 Commercial

6.4.3.1 Payment Terms

In a SI project, the Payment Terms can be a source of considerable risk for the following reasons:

The Customer may link a considerably large proportion of payment to be made on delivery of the

integrated Solution.





Payment to partners is linked to their individual performances. Failure of a single subcontractor to

perform within schedule may cause the failure to deliver the larger project. This is a huge risk.

While the SI becomes liable to its partners for payment, the Customer may not become liable even

if an insignificant part is not delivered.

The payment plan may therefore be decoupled as much as possible where individual items of delivery

have value to the Customer and are likely to be used by the Customer even though the fully integrated

System may not have been delivered.

The Payment plan if not drawn up with care, can significantly shift the balance of power in favor of the

customer. This is not only a commercial issue but affects Customer behavior and therefore delivery. A

payment plan that involves a single large payment at the end of Acceptance puts the Customer in a

position to dictate terms for the final acceptance and make demands that exceed scope. The Supplier is

left with little choice but to accommodate to get final acceptance and payment. The payment plan must

therefore have:

Advance payment (say 20% of Service Value)

Monthly payments to cover at least expenses. If there are several interim milestones, then this

could be linked to the milestones

Payment covering the reamaning contract value leaving a residual of 5% to 10%

Residual payment at end of warranty

6.4.3.2 Bank Guarantee for Performance

Bank Guarantee for performance is justified when payments are received in advance. If payments are

made on delivery only, and a portion is retained until end of warranty period, then there is no justification

for a Bank Guarantee. The Bank Guarantee amount covers the advance portion of the fee paid by

Customer.

6.4.3.3 Project Funding

Sometimes, the Customer‟s requirement is also to get the SI to fund the project. The SI is called upon to

bear all costs of hardware, licenses etc. The Customer agrees to pay according to an agreed deferred

payment plan where the SI is allowed to add the financial cost for funding.

Here, it must be clearly recognized that the SI is playing two roles as follows:

Delivery

Financer





The two roles must be clearly recognized and kept distinct. Mixing up the roles exposes the SI to grave

risks.

The costs that are funded are the Capital Costs. Under no circumstances should revenue expenses be

funded. The payment plan should not be not linked to any milestones or delivery. Here the role of the SI is

that of a financer only. If the payment plan is linked to delivery of a milestone, then should the delivery bedelayed, the SI is made to fund for a longer period without being compensated for it. The more payments

a Customer can hold back, the greater power they have to dictate terms to Delivery and make

unreasonable demands.

The Service fee of the SI alone may be linked to delivery milestones.

Also, in this situation, a Bank Guarantee for performance is unjustified, since at any point in time during

the period which may be spread over 3 to 5 years, the Customer owes the SI, a considerable portion of

the Project cost.

6.4.3.4 Pricing – Granting of Most Favored Customer Status

At times the Customer desires to introduce a clause on the following lines:

“Supplier represents that the rates for the Services shall be the lowest rates which Supplier charges

any of its customers for the Services or for substantially similar Services. If at any time during the

term of this Agreement, Supplier shall sell Services or substantially similar Services to another

customer at a price that is lower and/or upon better terms and conditions (collectively the

"Favored Rate") than the price and/or terms and conditions hereunder, as the case may be, then in

effect (collectively "Current Rate"), Supplier, with respect to all Services provided to Customer after any

such event, shall change Current Rate to Favored Rate. Customer shall have the right, from time to

time, to take such action as required in Customer’s reasonable judgment to verify Supplier's

compliance with this Section”

The objections to the insertion of such a clause are:

Commercial terms of contracts with Customers, and also cost and revenue data of projects are

governed by confidentiality clauses. This information cannot be made available to a third party. The

Customer cannot therefore verify the Supplier‟s compliance with the requirement and the clause is

not enforceable. It is therefore impractical to have a clause as above.

The Customer may yet insist that the Supplier conform to the essence of the requirement on a good faith

basis and certify to that effect on an annual basis.

Further objections to having the most favored clause in any form are as follows:

The price quoted for two different projects in a Fixed Price contract are rarely comparable on

account of:





o The Services may be rendered in different geographies with different cost structures

o The quantum of work may not be equal

o The Level of work may be variable to different degrees with varying predictability resulting

in different average loading factors

o Projects risks may be dissimilar based on complexity, scope clarity, dependencies on the

Customer and other third parties and other terms and conditions that affect price such as

penalties, Service Levels, Relief available for delays on account of dependency on

customer

o The price also includes the price of embedded options in the contract such as:


Option to extend the term

Option to benchmark the price and Service Levels

Option to vary the quantum of work through fresh Purchase Orders

o The Contracts may be concluded far apart in time under vastly different economic and

business conditions. In a free market economy, (which incidentally is to the customer‟s

advantage), price is a function of the demand for services and the supply at that point in

time and is therefore determined by the opportunity available at that point in time.

o Project profitability is known with reasonable certainty (the degree of certainty depends

upon costing methodologies adopted) only at the end of the project. Even at this stage, it is

difficult to say whether the price charged was reasonable or not since the reasonablenessof the price charged cannot be decided based on the outcome but on the appropriateness

of the methodology employed and perception of risks when the price was fixed.

The Supplier may `buy‟ a small bid at a loss to penetrate into a large potential account. This then

cannot become the benchmark for revising the price.

In a contract that is awarded based on a competitive bidding process, there is little justification for

such a clause.

There are other options available to the Customer if they feel at any point in time, that the price is

significantly higher than what it should be. These are:

Renegotiate the price

If renegotiation fails, then terminate for convenience

The Supplier could agree to something as below:





“Provider shall treat Customer as a key account and afford Customer treatment as regards price and

service levels which are at least as favorable as the treatment accorded to Provider‟s top ten North

American (or whatever relevant region) customers.

The Supplier shall review the contract annually and revise the terms in accordance with the above clause

or certify that the terms continue to be in accordance with the requirements above”.

6.4.3.5 Audit

Customers sometimes like to include a clause as follows:

“Supplier will maintain and retain complete and accurate records for all transactions, financial and non-financial,

which result from and/or are created in connection with this Agreement ("Supplier Records") in accordance with US

GAAP.

Customer is entitled to have Provider's accounts and books reviewed annually by a certified accountant of

Customer's own choice strictly for the purposes stated below:(a) verify the accuracy and completeness of Supplier’s invoices; and/or

(b) verify that the Services are being provided in accordance with the Service Levels; and/or

(c) verify that Supplier is in compliance with the Regulatory Requirements and Customer’s security

guidelines and policies.

(d) Customer will bear its own costs of any audit provided that, if the audit reveals an excess of

Fees claimed:

(i) Supplier will pay to Customer a sum equal to Customer’s own costs of the audit

(ii) Supplier will immediately repay to Customer on demand a sum equal to the amount of that

excess together with interest.

(iii) If the audit reveals (a) any underpayment of Fees; and/or (b) Services provided for which

Customer has not been invoiced; and/or (c) any other amounts and/or costs for whichSupplier is entitled to be paid and/or reimbursed for which Customer has not been

invoiced, Customer will pay Supplier in accordance with paragraph 8.4 the relevant amount

due against receipt of an appropriate invoice from Supplier.”

The changes that are required to the clause above and reasons for it are given below:

Deliberate and willful over invoicing and such other acts are governed by other provisions in the contract.The clause above, therefore deals with a mistake. All invoices are raised by the Supplier in accordancewith the contract and in good faith. These are verified by the customer before payment. The customernormally takes a month for payment and has ample opportunity to verify the correctness of the invoice.

Any mistake is therefore a mistake on both sides.

The payment terms are so formulated that all payments are at least a month after the service is delivered.In real terms therefore, there is very little chance of overpayment vis-à-vis the services delivered upto thepoint the payment is made. The formulation of the payment terms therefore, is in itself a protection againstany overpayment in real terms.





The audit findings contain both facts and the auditor‟s judgment of a situation. The auditor is an appointeeof the Customer and not an independent party and therefore their findings cannot be made binding on theSupplier. The Supplier should therefore have the opportunity to dispute the findings of the auditors if theyfeel deeply aggrieved. In the normal course, the Supplier may choose to refund the amount said to havebeen invoiced in excess without accepting that they have made a mistake. This option facilitates theSupplier to maintain an environment of trust and cooperation and avoids unnecessary disputes which

harm the relationship and consume executive time and energy. The purpose of the audit by the Customeris to ensure their compliance with their internal systems. The audit serves no useful purpose for theSupplier since the accounts of the Supplier are in any case audited by their own auditors. Payment for theaudit should therefore be made by the Customer irrespective of the findings of the audit and irrespective ofwhether the Supplier refunds any amount said to have been charged in excess.

The Supplier may therefore:

Agree to the audit Have the option to comply with the findings of the audit without accepting that the finding itself is

correct Not agree to payment of interest on any amount that may be refunded by the Supplier to comply

with the Customer‟s request based on the auditor‟s report Reserve their right to dispute the findings of the audit Not agree to payment of the auditor‟s fee under any circumstances

As stated earlier, deliberate and willful over invoicing would be a breach of trust and are covered by otherprovisions of the contract.

6.4.3.6 Liquidated Damages

Liquidated damages (LD) are ascertained amount of damage and compensation for the damage for aspecific breach (e.g., late performance) agreed between the parties at the time of the contract. If the LDclause is structured to function as a penalty then the liquidated damages clause will be void.

Example 18 - Liquidated Damages

The Supplier is entering into a support and maintenance contract. The transition is expected to be as per the

transition plan agreed. The Supplier will be paid a fixed fee for the transition period. Fee for the Support and

Maintenance activity will commence from the date following successful transition. In case there is any delay

attributable to the Supplier in successfully transitioning as per plan, the Customer has proposed a Liquidated

Damages as follows:

Liquidated damages shall be 0.5% of Annual fees for every day of delay in taking over the maintenance services

from current Supplier.

Comment:

Liquidated Damages is unjustified for the following reasons:

Delay in start of the services by New Supplier does not entitle New Supplier for payment of service fees for





the delayed period. The Customer will continue to pay the outgoing Supplier for the Service until successful

transition. The Customer is therefore not put to any additional expense on account of the delay. Since there

is no anticipated loss to the Customer, the LD clause is unjustified.

The above argument is enough to establish that the LD clause is unjustified in the given circumstances. If the

Customer still insists on retaining it, then it may be used as an opportunity to negotiate favorable terms for thereverse transition clause as follows :

The per day value of the service fee is 100/365=0.27% of Annual Fee. The impact to the Supplier of any

delay is LD of 0.5% + Revenue loss of 0.27% =0.77 % of Annual fee which is 2.85 (0.77/0.27=2.85)times the

per day Value of the service.

Let us assume that the Transition period as per agreed plan is 1 month.

For Reverse Transition, when the contract is terminated, the Supplier may agree to provide continuation

services at the normal rate for a period identical to the Transition period that they have taken (1 month)

and for any period beyond this, the fee would be 200% of the normal value. The retention of the LD clause

justifies this stipulation.

7 Re-negotiating Contracts

It is not often that a contract gets amended without a change in scope. There are times when thisbecomes necessary since a structural problem cannot be resolved any other way. Quite often, resolutionis delayed as the problem is not recognized early enough as a structural issue and various other optionsare first explored. The Supplier‟s negotiating position is also extremely weak for mid-course structuralchanges and the effort required is enormous. The example below brings out the pain in mid-coursecorrections and underlines the need for thinking through all aspects of delivery and drawing up contractsthat are clear on scope and respective roles and responsibilities.

Example 19: Re-negotiating Contracts - Networking

A large SI project involved providing the networking Solution which included primary connectivity with

leased/RF lines and secondary connectivity with ISDN lines for 500 offices of the Customer spread overthe country. It was assumed that the partner for the Connectivity Solution would take up responsibility forproviding both the primary and secondary connectivity. (Pitfall of not having a teaming agreement whichdefines the scope of partner in place before submitting the proposal)

When subcontracting was taken up with the partner after executing the prime contract with customer(another pitfall of not having back to back agreement in place before signing the prime contract), thepartner to the Prime‟s surprise, refused to take responsibility for providing ISDN connections pointing outthat this was not in the portfolio of their services. The refusal was at the highest level in the Organization.





The reason for ISDN not being in the portfolio of services is that there is a significant difference betweenleased lines and ISDN as follows:

Leased Line can be procured and serviced by our partner for Connectivity in their own namesince the lines become part of the partner‟s network

Payment is based on bandwidth contracted and not linked to actual usage. CentralizedApplications for new lines and Centralized billing for leased lines is therefore available.

An ISDN connection on the other hand is an on-demand dial-up service. The billing is linked to usage andthe calls are metered at the local exchange. Application for connections, billing and payment of bills islocal. The lines are in the name of the end user and cannot be in the name of SI or provider of theConnectivity Solution. TRAI rules specifically prohibit `reselling of bandwidth‟. The issue with the taking upof responsibility for ISDN therefore involves:

Getting the Application signed by the Local Manger of Customer and submitting the form in localoffice with fee

Follow up at local level for getting the connectivity

Getting the bill from Local Manager

Paying bills locally

Follow up for maintenance of lines locally

Neither the SI nor the partner has an organization to carry out the above services at 500 branches spreadover the country.

The SI had reached a stage where 35 branches of the Customer Organization were provided with primaryconnectivity and none with secondary. Without secondary connectivity, the customer maintained that theConnectivity Solution was incomplete and refused to accept it.

The Customer maintained that as per the contract, it was the SI‟s responsibility to provide the completerange of services. The SI‟s plea that the Customer was in the best position to handle ISDN connectivitydirectly and claim reimbursement for the expenses/bills was rejected. The Customer said that thisinvolved an amendment to the contract which was unthinkable.

The Customer was then taken through a discovery phase, where they learned from MTNL/BSNL directlythe rules regarding ISDN. The customer was then asked to cite one instance where SI has taken theresponsibility for ISDN connectivity. The Customer was provided contacts in other similar organizationsfor the Customer to check up whether any of these organizations had entrusted the responsibility forISDN connectivity to the SI. The Customer made enquiries and confirmed that there was no instancewhere the SI had taken the responsibility for ISDN connectivity.

Finally, when the Customer had fully understood the gravity of the situation and the problem was framedas either:

Agree to amend the contract to deal with ISDN directly and save the Project or

The Project fails

did the Customer fully realize the gravity of the situation and agreed. This took about three months sincethe SI was attempting several solutions in the mean-time and had not fully recognized it as a fundamentalstructural issue which could not be resolved satisfactorily any other way.





The SI still had to coordinate to ensure that primary and secondary connectivity was providedsimultaneously. With two parties working separately, there could be a number of branches with either onlya primary or secondary connectivity provided. This the SI realized was another structural issue and couldbe resolved only by making the Connectivity partner take responsibility for coordination for a fee. The SIwould not recognize the branch as connected until both primary and secondary connectivity was provided

and the responsibility for coordination was with the Partner. The sub-contract was suitably amended.

This example is from a different context and has been included because it clearly brings out the crucial role played bya legal document in shaping a meaningful relationship between the parties (structure) that lead to the desiredbehavior for success The negotiator, in this example, clearly thought through all the required conditions for successand drew up the contract document accordingly.

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

The government had formulated a scheme requiring Banks to give loans to members of economicallychallenged communities for purchase of Commercial Vehicles. The scheme envisaged hiring of thesevehicles by the Mandal Development Officers for transport of commodities for the Public DistributionSystem. The arrangement was that the MDO would send cheques for the hiring charges to the financingBanks who could appropriate the loan installment amount and pay the remaining amount to the borrower.The scheme thus “ensured automatic and regular repayment of the loans”.

The scheme was a failure in 22 districts of Andhra Pradesh. Kurnool district, where the largest number ofloans was given under the scheme, was the only success. A team was sent to study what had made thescheme a success in Kurnool.

The Branch Manager, who had given loans to 30 borrowers under the scheme in Kurnool, said that he

had done only one thing different and that was, to execute a tripartite Agreement between the Borrower,MDO and the Bank. The Agreement described the scheme, rights, and obligations of each party. TheMDO undertook to govern the scheme and guarantee repayment. The borrower agreed to hire his vehicleto the MDO for transporting essential commodities. In case the borrower did not fulfill his obligationsduring the loan period, then the MDO had the power to transfer ownership of the vehicle to anotherbeneficiary. In consideration of the two parties (Borrower and MDO) having agreed to the terms of thescheme, the Bank agreed to finance.

This simple agreement ensured that all parties worked as intended and the scheme was a success.

However, since this `Agreement‟ was not envisaged under the scheme, it was not a simple matter to getthe MDO to agree to sign the Agreement. Also, the Government is a very powerful party and therefore noteasy to negotiate with. The Branch Manager successfully negotiated with the District Authorities bypointing out that without this Agreement,

The borrower could refuse to hire his vehicle to the MDO. Although the government was thesponsor and gave subsidy to cover the margin amount for the loan, this did not give them anyright over hiring of the vehicle should the borrower refuse it. The government‟s assurance to theBank that the scheme ensured automatic repayment of the loan through hire charges payable bythe MDO was therefore an empty assurance.

The Agreement ensured the following:





As Guarantor to the Loan, the MDO acquired rights to ensure that the terms of the scheme wereadhered to by the borrower and in case of default, to take possession of the vehicle and transferownership to a new beneficiary to ensure success of the `scheme‟.

Guaranteed work to the borrower during the loan period for transport of essential commodities,

Guaranteed the MDO availability of transporter at agreed rates

The Bank had legal recourse to the MDO to ensure good governance of the scheme and regularrepayment of the loan.

The Agreement was therefore in the interest of all parties.

The MDO was still unconvinced. It was therefore further argued as follows:

The scheme was economically viable. Therefore good governance of the scheme wouldensure success.

Success of the scheme would greatly enhance the prestige of the MDO and was

therefore in his interest. The Agreement empowered the MDO to ensure its success.

The Bank agreed to finance as many borrowers as sponsored by the MDO under thescheme. The MDO and the District could therefore claim immediate credit for highachievement.

The relationship between the Government and the Bank is such that, in the unlikely eventof the scheme failing inspite of good governance, the Bank could never call upon theGovernment to repay the loan as guarantor. The Government had enough clout toprevent that. The MDO therefore had nothing to lose and much to gain by signing theAgreement.

The District Collector who is the MDO‟s superior saw merit in the argument and cleared the way for

signing of the Agreement.

Although the MDO was initially reluctant to sign the agreement, he was extremely happy with theoutcome. For one, the Bank sanctioned loan to every beneficiary sponsored by him. The usualexperience is that the banks reject proposals on one pretext or another to limit their exposure to what thebanks consider as risky loans. Secondly, he had the power and he used it when warranted, to ensuresuccess of the scheme which brought laurels to him as the only MDO who made a great success of theGovernment‟s scheme to help economically and socially challenged persons to become successfultransport operators.





8 Process owner for the Bid Management and Negotiation

process

8.1 Role and Responsibility

The role of the Corporate Level Process Owner may be defined as follows:

To define and own the processes relating to bid management, negotiation and transition to

delivery

The responsibilities may include:

Review of proposals. Mandatory review of all proposals above a threshold value based on natureof the engagement and size.

Mandatory review of contract documents before these are finalized based on nature of contract

and size of the contract

Identify and codify best practices covering model contracts, estimation techniques, risk assessment

and pricing for risks

Promote excellence through education, seminars, workshops, competitions

8.1.1 Mandatory Review of Proposals:

The process owner shall review the proposal before it is submitted and ensure that the bid management

team has done the following:

Has carried out pre proposal due diligence and obtained clarity on all aspects by utilizing the

opportunity available for seeking pre-bid clarifications.

Has identified all the project risks and prepared a plan for risk transference and risk

prevention/mitigation. Has quantified and priced in all residual risks.

Has gone through a process for taking a bid/no bid decision

Has executed teaming agreements with partners/subcontractors where required with all relevant

terms and conditions with traceability to the RFP.





Identified terms that need to be negotiated or commented upon and clauses that need to be added

Has prepared an effective bid

8.1.2 Providing Guidance:

The Process owner shall provide guidance to the bid management team. For this purpose, the bid

management team‟s responsibility is to keep the Process Owner posted with the following so that

guidance can be provided at the appropriate juncture:

The RFP documents when these are received

Clarifications sought and clarifications obtained

Copy of recommendations put up internally for bid/no bid decision

Draft teaming agreement before execution

Table of Contents for the proposal and strategy for submitting a winning bid

Plan for executing an ideal contract – what terms need to be negotiated and rationale for it

8.1.3 Review of Contract Documents:

Once the bid is won and the draft agreement is prepared and negotiated, the same shall be reviewed by

the process owner to ensure that there are no untenable risks flowing from the contract. This should be

before producing a signature version so that a fait accompli position is not presented to the reviewer.

8.1.4 Transition to Delivery:

Once the contract is signed, the bid management team together with the Process Owner shall transition

ownership and responsibility for execution of the contract to Delivery and the Delivery Process Owner by

holding a prime contract launch meeting. All of the relevant business functions such as Finance (who

provide project, cost and management accounting), HR (who may have to recruit staff for the prime

contract), Corporate Services (who provide the infrastructure support), N&S, and

Commercial/Procurement also to attend as those actually undertaking the project. The principle aims of

the prime contract launch meeting are to:





Describe the nature, scope and timeframe of the prime contract;

Identify the key terms and their meaning;

Review the entire pre-contract risk analysis/ caveats register and explain how all the risks weredealt with;

Summarize the progress of the negotiations with the client highlighting any sensitive areas to be

avoided in future contracts;

Identify key subcontractors, suppliers and partners and describe how dealings with them should be

conducted;

Launch the prime contract risk register based on mitigating all risks residing with the prime

contractor;

Identify the budget and cost allocations available for spending within the prime contract price.

Discuss plans – Project Plan, Procurement, Recruitment, Training, Project kick off with customer,

Infrastructure requirements etc

Draw up and agree upon action plans for all urgent and important requirements.

This should be followed by Management level meetings with all important partners/subcontractors to

launch the project. The objective of the meetings is to:

Establish contacts at the highest levels and build rapport at an early stage.

Establish common understandings and emphasize shared objectives for successful execution of

the project

8.2 What Delivery needs to know about the Contract

The important sections of the contract from a delivery perspective are as follows:

Scope of Work: The definition of work in scope and specific exclusions from scope in the contract.

In the absence of this knowledge, Delivery teams act in `good faith‟ assuming that whatever

is asked by the Customer is in scope. The representatives of the Customer who give the

requirements are also quite often unaware of the precise definition of scope in the contract.





The requirements evolve over time and therefore the scope expands in every project.

Unless this is checked/controlled at the incipient stage, it can get out of control.

Identified dependencies on the customer and third parties for executing the project.

Delivery needs to involve these parties in their planning and coordinate with them in the

execution of the project.

Role, responsibility and obligations of customer and third parties.

To know what can be expected from these parties and how to hold them accountable for

their obligations. In the absence of this knowledge, delivery teams make do with whatever

help is rendered and struggle in the absence of cooperation.

Project Phases, timelines, milestones, deliverables and acceptance criteria and acceptance

process

Appropriate Reporting and Communication mechanisms as per contract for:

o Reporting Project progress,

o Giving warnings to customer for likelihood of project delays and for requestingcorrective action

o Informing Customer about their liability for cost escalation for Project delays on account

of Customer not meeting their obligations

o Informing customer of existence of Force Majeure conditions and likely impact on

project.

o Requesting for Re-base lining of Project timelines

o Any other event based communication required as per contract

The contractual obligation is not discharged unless evidenced by appropriate

documentation/communication. Supplier is neither protected nor are they entitled to relief without

communicating at the right time as required under the contract.

Relief available

o For scope increase – Change Control Procedure

o For cost escalation on account of dependencies on customer and customer managed

third parties. Procedure for claiming such relief. Evidence required for claiming such

relief.

Proper records need to be maintained as appropriate to claim the relief. Delivery team must be

aware of the Relief that can be claimed and the process for claiming it.

Payment PlanConditions that must be satisfied for invoicing – Documentation required evidencing

performance, milestone achievement etc.

Liquidated Damages for delay

o Definition of delay – whether linked to every milestone or final deliverable

o Relief available for delays on account of force majeure conditions

o Relief available for delays on account of customer/customer managed third parties





o Limit on LD

o LD that may be passed on to partner/subcontractor

Service Levels and Service Credits for not meeting SLAs

o Relief available for missing Service Levels on account of Force Majeure conditions

o Relief available for missing SL on account of Customer/Customer managed third

parties. Project Personnel:

o Who are the key personnel as per the contract and the process for changing the key

personnel

o Process for changing non-key personnel

o Commitments if any on Onsite/Offshore mix

Termination of contract:

o For what specific causes can the contract be terminated? What is the procedure for

termination?

o Termination for convenience – what costs are to be paid by customer? What are the

Suppliers obligations?o End of contract – What conditions must exists and the procedure for project closure.

8.3 Structural Issues

The Structural Issues that affect the Bid Management Process are:

Who leads the process – Sales, Delivery, Legal, Finance or is this an independent function? Is the

process clearly defined and subject to a process audit? Is the role and responsibility of a bid

manager clearly defined?

Who are the participants? Typically Sales, Delivery, Finance and Legal have a role to play.

Are the areas that are to be dealt with by various teams clearly defined? Does each section of the

proposal and the contract has an owner or owners?

Is the process formal or informal? Are the individual pieces signed off by respective teams or

discussions are held and consensus is assumed on the final decisions that are taken? A formal

process is to be preferred. In the absence of a formal process, the leader may take the decisions

without conviction on the part of other teams who will then not take ownership for achieving

success or even participate actively. Consensus is not necessary. However differences should be

recorded. The leader may have the power to overrule by recording his reasons for overruling.

There must be clear responsibility and accountability for decisions taken.

What are the monetary/non-monetary incentives to the various participants on winning a bid? Are

these linked to the risk/reward aspects of the bid? Is there a formal assessment of the risk/reward

aspects of a win both before and after the win? The Supplier could draw up an ideal contract that

they would like to have and for each deviation from the ideal contract, make an assessment of the





likely financial impact. The incentive can be linked to the top-line and also to the projected bottom-

line thus incentivizing achievement of the ideal contract. Just any `win‟ is not good enough and can

potentially be dangerous to the Supplier.

Is there a process to rate the risk assessors based on their predictions and is there a formal

process to analyze material deviation of performance from the predictions and to draw lessonsfrom the analysis? A feedback mechanism is required to learn from the experience and make it

count.

Is the Organization a learning Organization? Projects that require implementing a proven

methodology in a familiar environment will have high predictability of results and opportunity for

learning is limited to making incremental improvements to productivity. First time projects, using

untested methodology in an unfamiliar environment will require a different approach to build a

learning team. The learning process is based upon

o Formulating a plan based upon facts and assumptions,

o Testing the assumptions as soon as possible and collecting missing information. Revising

the plans based on better information

o Actual performance and results

o Analysis of material deviations from plan

o Recording of the learning

Performance Evaluation: Is evaluation of delivery performance based on specific parameters of the

project or with reference to organization standards? This should be based on the project or else it

could be either too easy to achieve the Organizational benchmark or too difficult and the rewardsare then either easily obtained or impossible to earn. There is little incentive in this scenario to

make a difference through deliberate effort.

8.4 Risky Projects

A clear distinction must be made between run of the mill projects and risky projects. A project is risky if

there are critical unknowns. A potentially risky project may be taken up to enter into an unfamiliar but

rewarding domain or a growth area. Performance evaluation of a risky project should be on the followingbasis:

Approach to and speed with which the critical unknowns are identified and resolved

How quickly lessons are learned, adjustments made, goals revised and negotiated with customer

Quality of decision making




Quickness with which bad news is shared and strategy reviewed.

It must be recognized that the plans will change as a result of resolving the unknowns and lessons

learned.

Unless risky projects are evaluated differently the tendency would be to:

Avoid risky projects if possible

Manipulate performance perceptions

Hide bad news

If falling behind plan, redouble efforts rather than critically reexamine approach or solution

In conclusion, if the template that is used for reporting performance of a run of the mill project is also used

for a risky project, then the measures may not be appropriate leading to faulty analysis and wrong

conclusions and adoption of an inappropriate strategy. In such a situation, risky projects become riskier on

account of an inappropriate evaluation framework.

9 Conclusion

A contract that takes into account all conditions that are required to succeed and creates the required

structure of relationships, roles, responsibilities, obligations, processes, controls and incentives facilitates

successful delivery of the project. A defective, dysfunctional or inadequate structure on the other hand

often leads to confusion, disputes, stalemates, delays and loss and in extreme cases to failure, termination

of contract and claims for damages. Any material change that a Supplier may seek in the contract during

performance gets rejected or comes at a heavy price whereas, the same change can be achieved during

the negotiation phase with relative ease. A troubled project, even if it is entirely on account of a defective

contract, is a heavy burden on the Supplier‟s Organization and resources. The Supplier‟s maturity for

executing complex projects comes into question and the Customer is unlikely to consider the Supplier for

other complex projects. The damage is far beyond the loss on the project. It therefore pays, to exercise

care and spend time on all details, and think through all conditions that are necessary to succeed, before

finalizing the contract.