Bid Management and Negotiations

Bid Management and
Contract Negotiations for

IT Services Projects
Javeed Ahmed
(Consultant)
2008
1|Page
All Rights Reserved. Copyright © 2008. Javeed Ahmed

Managing IT Services Project Risks at Proposal and Contract stage
TABLE OF CONTENTS
1. Preamble ................................................................................................................................................................ 7
1.1 Scope of the document ................................................................................................................................... 7
2. Introduction ........................................................................................................................................................... 8
3. Project Stages and Risk Management .................................................................................................................. 9
Table 1 : Project Stages and Risk management ...................................................................................................... 9
4. Pre-Proposal Stage: Bid or No- Bid Decision ..................................................................................................... 10
4.1 Bid/No- Bid decision ...................................................................................................................................... 10
4.2 Consequences of delaying taking bid/no bid decision .................................................................................. 10
4.3 Critical Issues to consider for the bid/no bid decision .................................................................................. 11
4.4 Recommendations for the bid/no bid decision ............................................................................................ 12
5. Proposal................................................................................................................................................................ 13
5.1 Pre Proposal Due Diligence ........................................................................................................................... 13
5.1.1 Draft Contract Document................................................................................................................................. 13
5.1.2 Scope of Work .................................................................................................................................................. 13
Example 1: Example of unclear requirements ...................................................................................................... 14
5.2 Strategies for preparing a winning bid .......................................................................................................... 14
5.2.1 Looking at risks from the 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 ............................................................................................................................................ 20
Example 5: Project Objectives for an Enterprise data warehousing and Business Intelligence Solution ............. 20
5.2.5 Project Benefits ................................................................................................................................................ 21

Example 6: Project Benefits for an Enterprise data warehousing and Business Intelligence Solution................. 21
5.2.6 Innovative Pricing Model for winning Projects ................................................................................................ 22
Example 7: Innovative Pricing model .................................................................................................................... 22
5.3 Areas of focus at Proposal stage ................................................................................................................... 25
5.3.1 Dependency Risks............................................................................................................................................. 25
Interfaces............................................................................................................................................................... 26
5.3.2 Commercially Available Off the Shelf Solution (COTS).............................................................................. 26
5.3.3 Subcontracting Risks ........................................................................................................................................ 27
5.3.4 Suppliers .................................................................................................................................................... 30
5.3.5 Hardware Sizing: .............................................................................................................................................. 31
Sizing Parameters .................................................................................................................................................. 31
Sizing Process ........................................................................................................................................................ 31
Risk Transference .................................................................................................................................................. 32
5.3.6 Timelines .......................................................................................................................................................... 32
Example 8 – Negotiating timelines........................................................................................................................ 32
5.4 Dealing with identified risks in the contract at the proposal stage. ............................................................. 34
Example 9: Options to deal with identified risks .................................................................................................. 34
Example 10: Seeking modification of proposed clause during negotiation: ........................................................ 35
5.5 Pricing for risks .............................................................................................................................................. 36
Pricing of Program Risks ........................................................................................................................................ 37
Pricing of Risk for Hardware sizing ........................................................................................................................ 38
Pricing of Risks on account of effort variation in fixed price contract .................................................................. 39
Pricing of Maintenance contracts ......................................................................................................................... 40
Maintenance Contracts – Negotiating under difficult Economic and Business Conditions.................................. 43
5.6 The Proposal Document ................................................................................................................................ 43

5.7 Proposal Defense .......................................................................................................................................... 44
6 Contract Negotiations.......................................................................................................................................... 46
6.1 Types of contract........................................................................................................................................... 46
6.1.1 Time and Material Contracts........................................................................................................................ 46
6.1.2 Fixed Price Contracts .................................................................................................................................... 46
6.1.3 Time and Material Contracts with a cap ...................................................................................................... 47
6.2 Important considerations for Negotiation .................................................................................................... 48
Main items for Negotiation ................................................................................................................................... 48
6.3 Letter of Intent .............................................................................................................................................. 49
6.4 The Contract Document ................................................................................................................................ 50
6.4.1 Scope and Delivery related clauses .............................................................................................................. 50
6.4.1.1 Solution Ownership ................................................................................................................................... 50
Example 11: Solution Ownership .......................................................................................................................... 50
6.4.1.2 Project Commencement Date ................................................................................................................... 51
6.4.1.3 Simplifying Scope....................................................................................................................................... 51
Example 12: Simplifying Scope .............................................................................................................................. 52
6.4.1.4 Clauses to cover dependency risk .............................................................................................................. 53
Example 13: Dependency Risk .............................................................................................................................. 54
Example 14- Customer’s Obligations included in a contract: ............................................................................... 56
6.4.1.5 Change Control .......................................................................................................................................... 61
6.4.1.6 Maintenance Contracts - Service Level Agreement ................................................................................... 62
Example 15: Negotiating for Service Level (SL) ..................................................................................................... 62
Generally Accepted Service Level Principles ......................................................................................................... 65
6.4.1.7 Back to Back SLA with partner .................................................................................................................. 66
6.4.1.8 Availability SL ............................................................................................................................................ 66

6.4.1.9 Maintenance Contracts – Effort Estimates and Pricing ............................................................................ 67
6.4.1.10 Maintenance Contracts - Efficiency sharing ............................................................................................ 67
6.4.1.11 Maintenance Contracts – Benchmarking of Effort .................................................................................. 69
6.4.1.12 Maintenance Contracts – Exclusivity Clause ..................................................................................... 70
Example 16: Maintenance Contract – Benchmarking and related clauses........................................................... 70
6.4.1.13 Maintenance Contracts – Term of the Agreement............................................................................ 71
6.4.2 Legal Clauses ................................................................................................................................................ 72
6.4.2.1 Complete Agreement and Complete Offer Clause .................................................................................... 72
Table 2 List of Contract Documents ...................................................................................................................... 72
6.4.2.2 Termination Clause.................................................................................................................................... 73
6.4.2.3 General Damages ...................................................................................................................................... 74
Limiting Applicability of General Damages in a Contract based on competitive bidding ..................................... 74
6.4.2.4 Exclusions in the General Damages definition .......................................................................................... 75
6.4.2.5 Affiliates .................................................................................................................................................... 76
6.4.2.6 Indemnities ................................................................................................................................................ 76
Example 17: Representations and Warranties ..................................................................................................... 77
6.4.3 Commercial .................................................................................................................................................. 77
6.4.3.1 Payment Terms.......................................................................................................................................... 77
6.4.3.2 Bank Guarantee for Performance ............................................................................................................. 78
6.4.3.3 Project Funding ......................................................................................................................................... 78
6.4.3.4 Pricing – Granting of Most Favored Customer Status ............................................................................... 79
6.4.3.5 Audit ......................................................................................................................................................... 81
6.4.3.6 Liquidated Damages ................................................................................................................................. 82
Example 18 - Liquidated Damages ........................................................................................................................ 82
7 Re-negotiating Contracts .................................................................................................................................... 83

Example 19: Re-negotiating Contracts - Networking ............................................................................................ 83
Example 20: Re-negotiating Contracts - Synchronizing Objectives of stakeholders ............................................ 85
8 Process owner for the Bid Management and Negotiation process .................................................................. 87
8.1 Role and Responsibility ................................................................................................................................. 87
8.1.1 Mandatory Review of Proposals: ................................................................................................................. 87
8.1.2 Providing Guidance: ..................................................................................................................................... 88
8.1.3 Review of Contract Documents: .................................................................................................................. 88
8.1.4 Transition to Delivery: .................................................................................................................................. 88
8.2 What Delivery needs to know about the Contract ....................................................................................... 89
8.3 Structural Issues ............................................................................................................................................ 91
8.4 Risky Projects ................................................................................................................................................ 92
9 Conclusion ............................................................................................................................................................ 93

1. Preamble
This document has been written from the perspective of Supplier of IT services. The term Supplier,
System Integrator (SI), Prime or Prime Contractor, or Bidder have been used in this document as
appropriate based on the context and signify the same entity. The context of this document is
competitive bidding based on a Request for Proposal from a Customer.
1.1 Scope of the document

The document covers the Bid Management and Contract negotiation process as well as the
process 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 mitigated
through appropriate measures during the bidding and contract process is a special feature of this
document. The body of knowledge available on this subject is meager. As we move from simple
Time and Material contracts to fixed bid contracts and now to ever more complex multi Vendor
System Integration contracts, there is a need to build the required competency and establish best
practices. This document is an attempt in that direction.
Intended Audience
The intended audience of this document is the Supplier‟s bid management and negotiating teams
as well as the Program and Project Managers. It is hoped that the document will provide fresh
insights 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 within
budget. 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 risk
management are to ensure that this happens.
A large System Integration Project involves bringing together multiple products and services
from multiple parties into an overall integrated Solution architected and lead by the System
Integrator who is also usually the prime contractor. The activities of these multiple parties have
to be coordinated, the interdependencies have to be identified and managed, the progress of all
parties have to be meticulously tracked to ensure that the efforts converge in delivering the final
integrated solution. The negotiations and drawing up of the contract needs to be managed to
ensure that the prime contractor does not end up carrying risks that are transferable. Proper risk
identification and risk transference are therefore key activities during the proposal and contract
stages for a prime contractor. The contract document creates a structure of roles and
responsibilities, rewards and penalties, communication, escalation and dispute resolution
mechanisms, change control procedures, acceptance criteria etc. These are the enablers as
well as constraints and govern behavior of the parties during contract performance. In a System
Integration Project the structure is complex owing to the involvement of multiple parties in the
delivery process. The sub contract must be aligned with the Prime contract to facilitate rather
than frustrate the delivery process. This document lists the issues and shows a way to deal with
the complexity.

3. Project Stages and Risk Management

The project goes through distinct stages. The actions and decisions to be taken at each stage are shown
below:
Table 1 : Project Stages and Risk management
Risk Critical Issues Actions

Management
STAGES
Pre Bid/No Bid decision. What are the benefits of A formal document may be prepared for
Proposal doing the project and what are the associated taking the bid/no bid decision.
risks? Are the benefits commensurate with the A pre designed scoring sheet is also in
risks? If yes, how to improve the chances of use in many organizations to take the
(Predict and submitting the winning proposal with acceptable
Prevent bid/no bid decision.
level of risks?
Risks)
Proposal What are the risks over which Supplier has The proposal could cover Supplier‟s
preparation control? What are the risks over which the expectations from the Customer in
Customer has control? What are the risks over managing the risks under their control.
which partners have control? Can the Supplier could also propose at this
(Predict and responsibility for risk management be transferred stage, specific clauses in the contract
Prevent to the party which has control? How to make each that they would like to be included in
Risks) party responsible for managing the risks over case this is considered safe.
which they have control? What are the possible A document may be prepared on the
consequences of failing to manage the risks well? subject for the legal/commercial teams
How can each party be made to take responsibility to secure a `safe‟ deal.
for the consequences of risks that are not
managed well? What specific clauses need to be
negotiated and incorporated in the contract?
Contract How to negotiate and secure a „safe‟ deal? The negotiating team may be provided
negotiation with full details of the risks and the riders
(Mitigate that need to be added to the proposed
risks) clauses.
Contract How to manage the risks? What data needs to be Agreement with various parties on the
performance collected to detect emergence of risk, what reporting, communication and escalation
reporting mechanisms need to be in place, what is plans, and templates to use.
the escalation plan based on severity of issues?
(Pro act and
manage Should risks emerge, is there a plan for managing
risks) them and a mechanism for monitoring the success
of the measures until the risks are contained?

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

4.1 Bid/No- Bid decision
The objective of a bid/no bid decision is to:
 Avoid a contract that is difficult or impossible to complete within budget and within the given
time or is otherwise too risky.
 Avoid the effort and expenses of putting in a bid where the chances of winning are slim
 Go all out to win and secure a safe deal when execution is considered possible, chances of
winning fair and risks that are acceptable or can be mitigated, transferred or shed.
The bid/no bid decision is therefore of considerable importance and must be taken early for the following
reasons:
 A clear decision to bid implies `just go and win it‟. It empowers the bid manager to employ all
necessary resources to submit a winning proposal and adopt a comprehensive approach to Risk
Management without which, certain aspects are 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 associated
with the bid process. His/her experience coupled with the delivery responsibility, assures a
comprehensive approach to risk management. Identification of the PM is a clear signal to all
parties regarding the seriousness of intent which goes a long way in ensuring a successful bid.
4.2 Consequences of delaying taking bid/no bid decision

Quite often there is no explicit bid/no bid decision taken. The consequences are:
 The bid process once begun quickly acquires momentum and it is very difficult to halt it
midway. There are considerations such as loss of face internally, with partners, Customer etc
all 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 than
deciding 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 is
also 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 of
Organizational support for the bid all the way through which is crucial to submitting a winning
proposal.
 Key activities that require considerable effort such as completing all subcontract arrangements
before 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 for
fair play, reasonableness and meeting commitments
 What is the Project budget? Is the budget adequate for meeting all critical requirements of
the 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 part
of 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 the
activities 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 objectives
of 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 to
what may be expected?
 Has responsibility been assigned for executing necessary teaming agreements with clear
deadlines for execution?
 Has the scope of work been defined for the partners and the terms and conditions in the
teaming agreement defined with traceability to the prime contract draft?
 Is there choice of more than one partner/sub contractor for the same purpose before/after
the proposal is submitted?
 For all the high value items of project cost, have we identified partners who can be
depended 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 an
area where the Supplier would like to grow, build a reference able customer, or expectation
of other downstream projects etc?
4.4 Recommendations for the bid/no bid decision

Reasoned recommendations for the go/no go decision to be formally put up to a high level Decision
making 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 clauses
that the Customer intends to include in the contract. The terms of the draft agreement have the interests of
the Customer in mind and may therefore appear to be one-sided. However, customers are seeking to
forge 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 proposed
by the Customer and this is easily accomplished during the negotiation process. Contract negotiation is a
process during which a relationship of mutual understanding and accommodation is built between the
Customer and Supplier. The fear that the proposal may be rejected if all the terms are not accepted
without qualification is unfounded. This document contains examples where the Supplier has expressed a
differing view point that was readily accepted. Contract negotiation is not an adversarial process or about
winning an argument. The Supplier‟s negotiating team must respectfully state their position clearly and
with sound justification.
The terms of the draft Prime Contract must therefore be carefully considered at the proposal stage as well
as the modifications that need to be negotiated. If the modification that is to be negotiated does not negate
what 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 a
proposed clause is unacceptable under any circumstances, then the Supplier‟s position may be stated
briefly but clearly, leaving the final outcome `to be negotiated‟ indicating a willingness to accommodate a
valid counterpoint. A principled approach at the very beginning helps to build a relationship based on
equity and mutual trust. One sided clauses can be easily shown to be inimical to the achievement of the
broad project objectives and therefore against the larger interests of the Customer. The pre bid opportunity
for seeking clarifications must be utilized for clearing all ambiguity.
5.1.2 Scope of Work
The RFP document sometimes comes with a disclaimer as regards scope of work. The Supplier is
expected to conduct independent due diligence on the scope of work. The due diligence is facilitated if the
Supplier has a checklist for different types of Projects. The check list also comes in handy for seeking pre
bid clarifications. In brief, the information available in the RFP document together with the clarifications
must be adequate to determine effort and skill sets required. Any inadequacy must be highlighted as a
risk. This could be on account of not receiving a comprehensive response to the clarification sought. For
obvious 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 to
supply 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 enable
estimation 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 these
by 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 additional
effort and additional billing is incorporated in the contract, then there is no need for any negotiations during
contract performance on the commercial aspects of change in scope. The change control procedure can
be an effective mechanism to control effort and costs only if the scope of work and requirements are
detailed and specific. The requirements section should not contain words such as ètc‟.
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 core
system 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 be
implemented 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 similar
complexity and size. Lack of this would imply the following risks:
o Inaccurate effort estimates
o More defects due to lack of understanding of domain requiring longer time to fix 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 plan
which 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 project
implementation
 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 quality
is able to satisfy Customer‟s requirements with minimal errors, defects and bugs on all code
deliveries so that agreed functionality can be implemented on time.
 Assessing whether the Project Plan contains meaningful review checkpoints at periodic intervals to
ensure that the project is on track.
 Assessing Supplier‟s cultural fit to minimize behavioral risks. Inability to get cooperation from the
business user could seriously jeopardize quality and timelines.
 Assessing the Supplier‟s capability to identify the risks correctly and to come up with a workable plan
to 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 industry
first time which was delivered on-time and with low defects? What are the best practices for achieving
success 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 similar

complexity?
 What investments the supplier is willing to make or makes in first time projects
 Is re badging an important part of the strategy? If yes, then is this possible in the current context?
 How does the Supplier deal with cultural diversity
 A de risking strategy for first time projects could be for the Supplier to have a plan to complete all the
development work for “most critical” compulsory functions by a date far ahead of the implementation
date for the new generation system and have an end-to-end system walk through and review with the
customer. (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 the
Supplier if the progress is unsatisfactory c) Find interim solution such as develop interface with the
existing 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 Product
Company 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 becomes
liable for all efforts if the final estimate is within budget.
 Step 4 – User Requirements Document. If the go ahead is given, detailed requirements are collected and
URD is prepared and submitted by Supplier. The effort estimate is reassessed based on detailed URD. The
likely scenarios are:
o Reassessed effort is within budgetary estimate and if
 Customer decides to go ahead then proceed to next step
 If Customer decides to drop the enhancement, bill for the effort in doing the URD and
preparing the estimates
o Reassessed effort is greater than budgetary estimate – communicate to customer and get clearance
for going further. If clearance does not come forth, the enhancement is dropped without any
obligation to customer. If the customer decides to go ahead, then proceed to step 5. The budgetary
estimate stands revised.
 Step 5 – Functional Specifications Document. Supplier prepares the Functional Specifications Document and
the System Specifications Document. Effort is reassessed
o Reassessed effort is within budgetary estimate and if
 Customer decides to go ahead then proceed to step 6
 If Customer decides to drop the enhancement, bill for the effort upto this stage
o Reassessed effort is greater than budgetary estimate or revised estimate at previous stage–
communicate to customer and get clearance for going further. If clearance does not come forth,
the enhancement is dropped without any obligation to customer. If the customer decides to go
ahead, then proceed to step 6 and the budgetary estimate stands revised to the new estimate.
 Step 6 – Detailed Design. Supplier prepares a detailed design and comes up with a final estimate as well as
implementation plan. From here on, the price and delivery timelines are fixed
o Customer approves – Kick off enhancement and go to step 7
o Customer does not approve since final estimate is higher than budgetary estimate or revised
estimate at previous stage. Enhancement dropped without any obligation to customer
o Customer does not approve although final estimate is within estimate at the end of previous stage.
Customer pays for efforts upto this stage.
 Step 7 – Development, Implementation.
The outlined process has the following advantages:
 The Customer has no obligation to proceed with the enhancement or pay for the 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 cost
as it is based on the final estimate that is closest to actual effort with no buffers or cushions. The
risk to Supplier is also minimized.
 The natural inclination to play safe by quoting a considerably higher price for budgetary purpose is
checked by the fear of killing the opportunity early, if the Customer does not see value vis-à-vis the
budgetary estimate. Norms can be evolved and stipulated as Key Performance index (KPI), if felt
necessary, requiring that the budgetary estimate is no higher than 15% of the final refined
estimate. Another KPI of interest to all parties is the proportion of requests for enhancements that
are converted to Purchase Orders.
 Productivity norms can be agreed to and revised from time to time based on actual project metrics,
bringing in further transparency into the effort estimates. The Supplier can also plan for systematic
improvement of productivity through learning on the job, trainings and development of
productivity tools and show the customer increasing value in the relationship Year on Year.
Billing rates for Development
Under the best of circumstances, the loading factor for development activity will not exceed 80 -85%. If it exceeds
85% then it implies that many of the requests will have to wait in a queue before being addressed. If it is low, then
the cost goes up. It is therefore fair to assume and maintain a loading factor of 80% in the long run. The billing rate
for the Development resources can then be justifiably be higher by 25% when compared with an equivalent
resource for the maintenance activity. If the loading factor exceeds 80%, then the Supplier could agree to share the
benefit with Product Company.
The approach as outlined above is likely to find favor as it meets the critical concerns of the Product Company. The
other aspects of the process such as Quality Assurance etc are not touched upon since these pertain to standard
practices of the Supplier.

5.2.3 Project Vision
In the normal course, the Project Vision should come from the Customer. In the absence of it, the Supplier
could attempt to abstract the Project Vision from the requirements statement. Given below is an example
of a Vision statement for building an Enterprise Data warehouse Solution for a customer.
Example 4: Project Vision for an Enterprise data warehousing and Business Intelligence Solution
Project Vision:
“To build a platform that would enable the Customer maintain its leadership position and transform into a
lean, agile, responsive, customer focused, rapidly growing organization with increasing profitability and
safety.”
The advantage of a well constructed Project Vision is that it captures in a single sentence what the
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 will
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 count
may 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 actionable
information 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 making
available 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 cost
of 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 technical
specification document. The maximum duration of effort of a “unit” under the customization band is two
(2) man days of effort and no additional charge shall be made for such effort. If the unit requires more
than two (2) man 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 a
high 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 be
attempted from the perspective of making the change as generic as possible to take care of not
only 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 therefore
unavailable for Customer specific enhancements. Each and every enhancement therefore
introduces a rigidity that makes the Solution more and more painful in the long term while
satisfying an immediate need. Example: A Bank applies interest on loan accounts every month
whereas contractually, (purely for historical reasons) it should be applied every quarter. The
requirement was therefore to use an adjusted rate (rate adjusted to give the same effect on
monthly 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 adjusted
rates, then the change becomes a severe constraint if should tomorrow, the contractual terms
are changed to mean monthly compounding. It is possible to provide a generic solution that
can take care of all possibilities and future proof the change against any requirement that may
arise. This however requires involvement of the right caliber of domain experts and a greater
effort.
 Any change to the core system requires thorough regression testing and goes through several
iterations 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 to
an existing Application that requires 1 month of coding requires 2 months for getting the
requirements, 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 that
require new development changes dramatically bringing down the need for development to a
bare minimum. Example: A Public Sector Bank had evaluated a core banking solution and
come up with a list of changes that were required to take care of the Bank‟s requirements. The
cost of new development was 3 times the cost of the license fee. There was considerable delay
in giving the requirements which had to go through several iterations. The Solution was in the
mean-time implemented. It was quickly discovered that none of the enhancements were
required. Changes to existing business processes made it possible to use the System às it
was‟ without any ènhancement‟. Some of the ènhancements‟ when delivered were never
used as they had introduced some unanticipated rigidity or impacted some other function which
made it unusable. The Bank implemented the Solution in 10,000 branches of the Bank without
a single line of code being changed to the core system.
 Generally speaking, COTS vendors have little interest in Customer Specific enhancements and
do not put their best people on the job. This is irrespective of the fees that may be paid. Their
interest 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 every
product vendor‟s nightmare
The COTS solution must therefore be capable of meeting all of the customer‟s requirements
through parameterization or through customization alone. Otherwise, look for an alternate COTS
Solution.
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 subcontractor
should match the scope in the prime contract. In a fixed price contract, the subcontractor
may not be allowed to show efforts in the subcontract for the activities that have no
dependency on the Customer or other third parties. The contract, in a fixed price project is
to deliver as per the scope agreed irrespective of the effort. Inclusion of effort estimate
enables the subcontractor to come back at a later stage and ask for additional fees if the
effort is exceeded. The subcontract can however list all dependencies that are to be
managed 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 and
responsibility of the various parties (System Integrator, Customer and Subcontractor) in the
delivery of the services by the subcontractor must be clearly defined. Other obligations of SI
and Customer must also be included such as making available required licensed system
software, hardware requirements for the various environments (Test, Development,
Training and Production). The roles and responsibility must cover all aspects such as
installation, tuning for performance, training, list of documents the subcontractor has to
deliver in each phase of the project, data migration, data cleansing, data validation, test
scripts and testing, deployment, post production support. In a multi party situation, it is
extremely important to have very clear understanding of the roles and responsibilities at the
granular level. For example, data migration involves the following tasks:
o Data mapping from legacy to target system. This requires support from Customer
who understands the legacy system and the subcontractor who understands the
target system. The precise business definitions of each data element in legacy and
target system must be understood. Who will do the data transformations that may
be required? For example, the target system may store accrued interest, whereas
the legacy system may store daily products. While migrating, daily products have to
be converted to accrued interest.
o Missing data in legacy that is mandatory in target. Strategy for providing missing
values. If this has to be manually keyed in, who will develop the input screens and
who will key in the data?
o Data in legacy that cannot be mapped to any field in target system. What is to be
done?
o Data extraction from legacy. Whose responsibility? Who will develop the extraction
scripts?
o Data cleansing. Whose responsibility is it to identify data quality issues and whose
responsibility is it to do the data cleansing? Will the data be cleansed in the source
system before migration or will it be done after extraction?
o Data validation and reconciliation before uploading. What Reports will be produced
and who will give the sign off? Who will develop those Reports
o Data upload scripts and data upload. Who will develop the scripts and who will run
those scripts for uploading?
o Data validation and reconciliation after loading. Who will develop the reports and
who will validate and give a sign off?
o Who is responsible for business loss on account of inaccurate data?
 Implementation Milestones and Deliverables, definition of Defects of various severity,

Acceptance Criteria: Precise back to back clauses are essential to avoid a situation where
the subcontractor claims that a milestone is successful and the customer says that it is not,
and both are right according to their contracts with the SI.
 Implementation methodology that would be followed must be agreed to.
 Liquidated Damages. Back to back arrangements must be made. Considerations that need
to be weighed are:
o If delay is solely on account of the subcontractor, can all of the LD be passed onto
the 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 of
warranty period plus a safe period of say 3 months.
 Validity period of offer. This must match with the Prime Contract so that the subcontractor
cannot vary the price while it is fixed for the SI.
 Warranty and warranty period: When does it begin? After the Solution goes live in
production (Customer‟s preferred option) or fixed period after the license agreement is
signed (sub contractor‟s preferred option). Unless care is exercised, a mismatch is highly
likely.
 Termination for cause. The SI must be empowered to terminate the contract for cause
without the prime contract being terminated. Back to back arrangement on termination for
convenience is essential including the services that have to be rendered by sub contractor
on 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 does
what should be spelled out.
 Service Levels for performance. The terms and conditions agreed with subcontractors
should be no less onerous that those in the prime contract.
 Payment Terms: The time required for invoicing the Customer after invoice is received from
partner and time required to make payment to partner after payment is received from
Customer 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 based
on 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.4 Suppliers
In a SI Project, the prime contractor may be responsible for providing the complete solution covering:
 Hardware
 Software
 Network
 Implementation
 Support
All the items of purchase are not required immediately and just in time purchases will be desirable from
the cost and cash flow point of view. For example the production environment in the data center can be
ready a month before the production go live date. If the production go live date is 9 months from the start
date of the project, then the hardware required for the production environment can arrive 6 months after
the project start date. The plan to network all offices of the Customer (for example, 1000 branch offices of
a Bank) may be spread over a 2 year period. If all the equipment required is purchased in one lot, then this
does not only involve cash outflow and interest costs but also warehousing costs and insurance. The
warranty period will run through while these equipments are still lying in the warehouse. The equipment is
also subject to obsolescence and depreciation.
Purchase agreements must therefore be explicitly made for staggered purchases with firm delivery lead
times and severe penalties for delays. In the absence of an explicit and documented understanding, once
the prime contract is signed with the customer, the Suppliers will insist that:
 The Orders are to be placed immediately for the price to be valid.
 Prices quoted are valid only 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 to
give comfort to the hardware vendor that there is serious intent to purchase the hardware on
successful completion of the Bench Mark.
5.3.5 Hardware Sizing:
A System Integration Project may require hardware to be sized, procured, installed, administered and
managed 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 affect
project profitability adversely.
Sizing Parameters
 Ensure that data on all project parameters that affect sizing including expected growth in
data/transactions is obtained from the customer and included in the contract.
 Additional hardware requirements necessitated by any factor exceeding the stated parameters
should 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 size
hardware on the higher side to ensure that the experience of the users with the Tool/Application is
good and the hardware resources are not found wanting.
 Sizing based on published performance benchmarks of the Tool/Application vendor. This gives a
low number since Bench Mark performance data published by vendors are to show that their
Tool/Application is not resource intensive compared to competing products
 Getting equivalent sizing for the hardware chosen by Supplier from the Hardware Vendor
 Reference data collected from other sites where the Supplier may have projects with identical
Tools/Applications for identical workloads. The workloads need not necessarily be identical since
Web and Application servers are linearly scalable.

 Arriving at final sizing based on extensive discussion with Tool and HW vendor to reconcile
different 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 to
benefit 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. This
makes 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, Hardware
Vendor and the Application vendor should jointly conduct the sizing exercise. The SI should ensure that
the right people from the partner‟s side come for the exercise with relevant benchmark and empirical data
of 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 the
Application Vendor and the Hardware Vendor are asked to take the risks for under sizing, they would price
in the risk. The price would depend on the perceived risk which is a function of their degree of comfort in
sizing for the given situation and their willingness to take the risk. In theory therefore, the price of the risk
is 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 the
partners, the number of projects done together, common future plans and maturity of the alliance
management process and involvement of the right people at the right stage. The Prime could ask the
partners to give their prices with/without under sizing risks and try to minimize the price of the risk through
appropriate risk transference. Some degree of risk transference is desirable to ensure that all parties bring
in the required degree of seriousness to the exercise and that there is no attempt to deliberately undersize
to 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 are
involved and have squeezed the time available for development.
Inadequate time for development could compromise quality at Factory Test stage which would mean more
defects. In the interests of the Project therefore, timelines may be adjusted to provide adequate time for
development.
This also has cost implications. Development teams would have to move onsite to fix defects during the
Testing Phase. A longer duration for this phase would mean an increase in the onsite component.

5.4 Dealing with identified risks in the contract at the proposal

stage.
If both the impact and probability of occurrence of the risk is low then ignore the risk
Use the opportunity provided in the pre bid conference to suggest changes to the contract as appropriate,
or to seek further clarifications that would help quantify the risk. Try to shed the risk or transfer it to the
customer if possible.
Example 9: Options to deal with identified risks
If the Supplier believes that it is not possible to complete the project on time as stipulated by the customer,
then there are the following choices:
 No proposal.
 Propose an alternative schedule
 Propose to meet the completion date but hope to shift the date while negotiating the contract
 Propose to meet the completion date hoping that the risk can be `managed‟ during the execution
phase.
The appropriate choice depends upon the circumstances as well. There could be one of the following
scenarios:
a) The time is considered short for the bidder but not for the competitors because of certain
relative disadvantages/advantages. The competition is therefore likely to accept the
schedule.
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 if
the Supplier is convinced that they cannot meet the required dates, then not submitting a proposal
is an option.
Proposing an alternative date runs the risk that the proposal will be ruled out at an early stage of
the process if the other potential suppliers accept the timelines. However, if scenario b) above is
true and most potential suppliers propose an alternate date with justification and the bidder is the
only one who accepts the proposed date, then also the bidder is in danger of being eliminated for
not knowing what the Project takes. In this situation, it is better to propose an alternate date or
indicate that it requires further discussion.
An alternative date may also be proposed if scenario a) is true and offer some trade off to the
customer to make the proposal acceptable inspite of not meeting the customer‟s expectations on
the schedule.
Accepting the proposed date and hoping that the risk can be managed during execution, is based
on the assumption that in a major project there will be a change of scope which would provide the
opportunity 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 and
attracting 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 practically 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 such
Services 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 the
clauses 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 suppliers
with a similar/comparable cost profile
3. If Supplier is not in a position to comply with the benchmark, a negotiated and revised benchmark
may be agreed to failing which the Customer may terminate the service in question for
convenience.
At the proposal stage, the entire contract document is not completely fleshed out. It is therefore justifiable
to add necessary details later on to provide for situations that may arise. For example, the Supplier may
not be in a position to achieve the benchmark or the price may not work out for them. There should then
be 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 parties
since the CFU assumes the responsibility for coordination and for compensating the subcontractor
should there be a cost escalation on account of a dependency that is not managed by the CFU as
agreed.
The Profits of the CFU arise from the risk price and how well the CFU manages the risks within 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 SI
for costs incurred on account of delays attributable to the Customer not meeting their obligations as
agreed. Even with such arrangements, there are some residual risks since Liquidated Damages levied
on a subcontractor for failure may not fully cover claims for compensation from other subcontractors
whose delivery is affected by the failure.
The residual risks after risk transference must be measured and priced in. The final price quoted may
be the total price arrived at in this manner or some other price which in the opinion of the CFU, the
market is willing to pay. (On account of competition a final judgment call is taken on what may be the
winning price for the bid which could be higher or lower than the price determined as described). The
profits of the CFU then depend upon how well it can manage the risks within the risk price that the
market is willing to pay.
This understanding must be clear on all sides. If the subcontractors also price in dependency risks,
then there is multiple pricing of dependency risks which will make the bid uncompetitive.
The process described above ensures:
Subcontractors are compensated for their skill, effort and for managing the risks internal to them 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 only
make 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 the
costs 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 additional
hardware 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 with
Business 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 first
cut 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 Application

b) 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 of
the 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
àssume‟ 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 Òption‟. 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 the
presentation 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 various
activities. 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 for
each 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, system
software, 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 that
required 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 customer
organization:
 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 protect
their 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 will
be 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. 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.
The important clauses that form the structure and shape behavior during contract performance are
discussed 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 and
Implementing solutions for the banking industry. The Supplier confirms that the Solution
comprising 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 it

suitable 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 approval
within 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 two
repeat series of tests are conducted, then Customer may, by thirty (30) days written notice to
Supplier elect at its option:
7.1 to require Supplier to provide at no extra charge such additional services and replacement
items as shall enable the System to pass the relevant tests within a reasonable time as mutually
agreed 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 being
such amount taking into account the circumstances, as is reasonable and mutually agreed
between the Parties); or
7.3 to terminate this Agreement and recover all Charges already paid to Supplier under this
Agreement.
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 are
accepted. 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 also
consider 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 changing
any 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 the
responsibility 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 of
the 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 Obligations 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 per
the 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 Prior to start of the
point of contact for all communications with IT and business teams. Designated project
personnel from CUSTOMER will be empowered with appropriate authority to
take timely decisions.
2 Appoint a steering committee to review Project Deliverables and handle issues Prior to start of the
requiring escalation. Such steering committee to include at a minimum IT project
representative and one business representative.
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, Formation – prior to
business and technical skills to engage with Supplier’s implementation team for business analysis
the entire duration of the Services (Customer to ensure continuity of team as far phase of the project
as is possible).; and to be available
for the duration of
the services.
4 Provide the required software (such as Outlook, Visio, MS Office/Project, tools Prior to build phase
(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.
5 Provide a single point of contact for managing change control. Throughout
Engagement
6 Provide access to appropriate staff to attend meetings, workshops and Throughout

discussions at a central location. It is the responsibility of Customer to identify Engagement
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.
7 Customer shall provide suitable meeting tools and office space, office supplies, Throughout
furniture, telephone (with international dialing facility), Internet Access and Engagement
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.
8 Customer shall provide access to all relevant internal documentation and the Throughout
documentation shall be in English. Engagement
Customer shall ensure that all project related documentation which it

prepares or provides will be in English.
9 Customer shall facilitate access to the Oracle Metalink for logging service Prior to start of the
requests concerning the Project. project

10 The response time for feedback on a document/issue from Customer as soon as Throughout
reasonably possible but in any event not longer than Five(5) Working Days unless Engagement
otherwise stated in the Master Services Agreement. Any delay on this account
will have an impact on Project schedules, efforts and costs.
11 Customer to ensure that User Acceptance Testing will be completed within the Validate phase and
stipulated time period. In case of change in timelines, Supplier would initiate a deployment phases
CCN to rework the estimates. Any delay on this account will have an impact on
Project schedules, efforts and costs.
12 Customer will provide data required for data migration as CSV file format. Any During the Data
other format for data migration shall be mutually agreed upon between Supplier Migration cycle
and Customer. Data cleansing rules will be done by Customer.
Customer to be responsible for data integrity and validity.

13 Provide requisite data from the legacy system in CSV formats (or such other Build and Test
mutually agreed compatible format) for data loading.
14 Provide format for the different reports and inputs for forms to be developed (if Analysis and Design
any)
15 Provide Test cases and test data for the various testing phases of the Project to Build and Test
validate the appropriateness of the solution being deployed.
16 Provide detailed business requirements Business Process

Analysis Phase
17 Training would adopt the ‘Train-the-Trainer’ approach and the Customer would Various Training
provide necessary training infrastructure such as Training Rooms with related phases of the
tools, desktops for the users and also ensure participation of the nominated Project.
business users who will then be responsible to train the end users.
18 For integration of the Applications in scope with current Applications in use, As necessary
procure services of the other Application Vendors as necessary to work with
Supplier for the integration.

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

of Licensed software
20 Customer to secure required Public IP addresses for deployment of web By commencement

applications. date
21 The Customer shall get a sign off from Supplier before releasing Purchase Order for Before
hardware including Networking components to enable Supplier to verify that all release of
details/specifications in the Purchase Order are in conformity with the Architecture, Sizing Purchase
and Performance assumptions. Orders
Operating Environment
Operating Environment particulars/details as specified below shall be
required from the various stages as outlined below till the end of the Project.
Stage Particulars/Details

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 allow

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

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

Build solution architecture.
Entire 7. Any other requirements for the Operating Environment would be

Project 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 deemed 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 for
negotiations 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 all
other 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 - Measurement % of

Performance Category Expected Minimum Window Invoice
Gold
Application 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
Within 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
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 Measurement % of
Category Expected Minimum Window Invoice
Promoted 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 by
10% 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 % of

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 Tibco
transactions 3.2 sec 3.5 sec Monthly Test 2.00%
Customer Satisfaction - Performance Measurement % of

Customer Satisfaction 90.00% 80.00% Monthly 4.00%
Measurement % of
Staffing
Expected Minimum 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 or
more) 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 are
the 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 therefore
a 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 has
outlived its utility. Over a period, the number of changes/enhancements carried out to an
Application render the code too complex until a stage is reached when the falling MTTD
indicates 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 initial
years 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 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.
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 for
passing on any benefit of reduction in effort for addressing such calls. The benefit of cost reduction
is 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 and
have 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 out
the 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 Supplier
may 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) had
the following clauses:
 Non –Exclusivity clause. The Customer is free to engage other service providers for the

same/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 terminated
for cause, the Supplier is obliged to provide free services for transitioning to alternate Supplier that
could 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 service
level for any service anytime during the contract period. Customer‟s decision is not subject to any
of the provisions for Dispute Resolution and therefore cannot be disputed or even taken up for
discussion 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 their
price. The Supplier can then either accept the `benchmark‟ or transition to the low cost supplier over a period
that could extend upto 12 months without charging any fee for the transitioning service. This can be done one
SOW 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 very
much an interested party.
 From the contract it is not clear what the benchmark is. For example, comparable services provided
by 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 SOW
requiring the Supplier to provide free transitioning services for a period that could extend upto 12
months.
 Even in case of termination for genuine cause, the period for free transitioning of services may be no
longer than the period taken by the Supplier when this was transitioned to them. For transitioning
services 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 an
arbitrary and one sided clause for `benchmarking‟ whose sole purpose appears to be to enable
Customer 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 overall
price.
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 is
contained in the RFP. It should be made clear that when the various documents
differ, the priority for deciding the correct intention will be the SOW document
followed by the Proposal or RFP response document.
Proposal or RFP The Proposal document constitutes the offer based on which the contract is
response awarded and therefore cannot be left out. The proposal document must have a
statement as to what constitutes “an entire offer”.
The executive summary or the covering letter which summarizes the advantages of
awarding the contract to the Supplier written to generate the sale is part of the
proposal but clearly not part of the offer. The advantages are only indicative of what
the 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 and
standards that are subject to change without notice and without consent of buyer.

Third party process and methodology documents may not be incorporated unless
these form part of the subcontractor‟s offer document to the prime contractor and
are binding on the subcontractor.
Proposal Defense This is not a very precise document and by nature brief and concise. Could pose
presentations problems in interpretation later and should be left out.
Clarifications to The clarifications could be detailed or summary. Short answers often create larger
questions raised by the obligations as these are likely to be interpreted differently by the customer from
customer what was intended. The question itself may not have been understood well. Great
care should therefore be exercised while giving clarifications. A good practice is to
first give a detailed description of what we have understood by the question before
giving a reply.
Should avoid giving a reply in a hurry or on the spot or without getting the response
vetted by a person who is most competent to give the reply. The replies create
representations which become binding. In case, the customer insists on including
these as part of the contract, have the replies vetted again and modified if
necessary 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 the
resources used to provide the Termination Assistance. If the same resources are also providing
continuation services, then the exact hours put in for Termination Assistance may be logged.

Termination for convenience
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 the
resources used to provide the Termination Assistance. If the same resources are also providing
continuation 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 in
which 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 allowed
in 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 the
World.
Supplier recognizes that CUSTOMER is not fully familiar with the laws, rules, orders, regulations, policies
and customs of the Designated Countries and that CUSTOMER has entered into this Agreement on material
reliance on Supplier‟s representation and warranty 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 further represents and warrants 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.
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 laws
of 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 be
delayed, 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:
 Termination for convenience
 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 reasonableness
of 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 which
Supplier 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 accordance
with the contract and in good faith. These are verified by the customer before payment. The customer
normally 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 the
point the payment is made. The formulation of the payment terms therefore, is in itself a protection against
any overpayment in real terms.
The audit findings contain both facts and the auditor‟s judgment of a situation. The auditor is an appointee
of the Customer and not an independent party and therefore their findings cannot be made binding on the
Supplier. The Supplier should therefore have the opportunity to dispute the findings of the auditors if they
feel deeply aggrieved. In the normal course, the Supplier may choose to refund the amount said to have
been invoiced in excess without accepting that they have made a mistake. This option facilitates the
Supplier 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 Customer
is to ensure their compliance with their internal systems. The audit serves no useful purpose for the
Supplier since the accounts of the Supplier are in any case audited by their own auditors. Payment for the
audit should therefore be made by the Customer irrespective of the findings of the audit and irrespective of
whether 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 other
provisions of the contract.
6.4.3.6 Liquidated Damages
Liquidated damages (LD) are ascertained amount of damage and compensation for the damage for a
specific breach (e.g., late performance) agreed between the parties at the time of the contract. If the LD
clause 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 the
reverse 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 this
becomes necessary since a structural problem cannot be resolved any other way. Quite often, resolution
is delayed as the problem is not recognized early enough as a structural issue and various other options
are first explored. The Supplier‟s negotiating position is also extremely weak for mid-course structural
changes and the effort required is enormous. The example below brings out the pain in mid-course
corrections and underlines the need for thinking through all aspects of delivery and drawing up contracts
that 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 over
the country. It was assumed that the partner for the Connectivity Solution would take up responsibility for
providing both the primary and secondary connectivity. (Pitfall of not having a teaming agreement which
defines 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), the
partner to the Prime‟s surprise, refused to take responsibility for providing ISDN connections pointing out
that 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 between
leased lines and ISDN as follows:

 Leased Line can be procured and serviced by our partner for Connectivity in their own name
since the lines become part of the partner‟s network
 Payment is based on bandwidth contracted and not linked to actual usage. Centralized
Applications 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 and
the calls are metered at the local exchange. Application for connections, billing and payment of bills is
local. The lines are in the name of the end user and cannot be in the name of SI or provider of the
Connectivity Solution. TRAI rules specifically prohibit `reselling of bandwidth‟. The issue with the taking up
of responsibility for ISDN therefore involves:
 Getting the Application signed by the Local Manger of Customer and submitting the form in local
office 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 spread
over the country.
The SI had reached a stage where 35 branches of the Customer Organization were provided with primary
connectivity and none with secondary. Without secondary connectivity, the customer maintained that the
Connectivity 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 complete
range of services. The SI‟s plea that the Customer was in the best position to handle ISDN connectivity
directly and claim reimbursement for the expenses/bills was rejected. The Customer said that this
involved an amendment to the contract which was unthinkable.
The Customer was then taken through a discovery phase, where they learned from MTNL/BSNL directly
the rules regarding ISDN. The customer was then asked to cite one instance where SI has taken the
responsibility for ISDN connectivity. The Customer was provided contacts in other similar organizations
for the Customer to check up whether any of these organizations had entrusted the responsibility for
ISDN connectivity to the SI. The Customer made enquiries and confirmed that there was no instance
where 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 framed
as 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 since
the SI was attempting several solutions in the mean-time and had not fully recognized it as a fundamental
structural issue which could not be resolved satisfactorily any other way.
The SI still had to coordinate to ensure that primary and secondary connectivity was provided
simultaneously. With two parties working separately, there could be a number of branches with either only

a primary or secondary connectivity provided. This the SI realized was another structural issue and could
be resolved only by making the Connectivity partner take responsibility for coordination for a fee. The SI
would 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 by
a legal document in shaping a meaningful relationship between the parties (structure) that lead to the desired
behavior for success The negotiator, in this example, clearly thought through all the required conditions for success
and 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 economically
challenged communities for purchase of Commercial Vehicles. The scheme envisaged hiring of these
vehicles by the Mandal Development Officers for transport of commodities for the Public Distribution
System. The arrangement was that the MDO would send cheques for the hiring charges to the financing
Banks 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 of
loans was given under the scheme, was the only success. A team was sent to study what had made the
scheme 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. The
MDO undertook to govern the scheme and guarantee repayment. The borrower agreed to hire his vehicle
to the MDO for transporting essential commodities. In case the borrower did not fulfill his obligations
during the loan period, then the MDO had the power to transfer ownership of the vehicle to another
beneficiary. In consideration of the two parties (Borrower and MDO) having agreed to the terms of the
scheme, the Bank agreed to finance.
This simple agreement ensured that all parties worked as intended and the scheme was a success.
However, since this Àgreement‟ was not envisaged under the scheme, it was not a simple matter to get
the MDO to agree to sign the Agreement. Also, the Government is a very powerful party and therefore not
easy to negotiate with. The Branch Manager successfully negotiated with the District Authorities by
pointing out that without this Agreement,
 The borrower could refuse to hire his vehicle to the MDO. Although the government was the
sponsor and gave subsidy to cover the margin amount for the loan, this did not give them any
right over hiring of the vehicle should the borrower refuse it. The government‟s assurance to the
Bank that the scheme ensured automatic repayment of the loan through hire charges payable by
the 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 were
adhered to by the borrower and in case of default, to take possession of the vehicle and transfer
ownership 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 regular
repayment 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 would
ensure 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 the
scheme. The MDO and the District could therefore claim immediate credit for high
achievement.
 The relationship between the Government and the Bank is such that, in the unlikely event
of the scheme failing inspite of good governance, the Bank could never call upon the
Government to repay the loan as guarantor. The Government had enough clout to
prevent that. The MDO therefore had nothing to lose and much to gain by signing the
Agreement.
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 the
outcome. For one, the Bank sanctioned loan to every beneficiary sponsored by him. The usual
experience is that the banks reject proposals on one pretext or another to limit their exposure to what the
banks consider as risky loans. Secondly, he had the power and he used it when warranted, to ensure
success of the scheme which brought laurels to him as the only MDO who made a great success of the
Government‟s scheme to help economically and socially challenged persons to become successful
transport 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 nature
of 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 were
dealt 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 requesting
corrective 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 Plan
Conditions 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 lessons
from 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 rewards
are 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 following
basis:
 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.

Bid Management and Negotiations

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Bid Management and Negotiations

Caricato da

Copyright:

Formati disponibili

Bid Management and

Contract Negotiations for

All Rights Reserved. Copyright © 2008. Javeed Ahmed

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

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.4 Recommendations for the bid/no bid decision ............................................................................................ 12

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

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

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

All Rights Reserved. Copyright © 2008. Javeed Ahmed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

All Rights Reserved. Copyright © 2008. Javeed Ahmed

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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