Bid Management and Negotiation

Bid Management and Contract Negotiations for IT Services Projects
Javeed Ahmed
2008
1|Page
FOR INTERNAL CIRCULATION
ONLY
Managing IT Services Project Risks at Proposal and Contract stage
TABLE OF CONTENTS
1. Preamble ................................................................................................................................................................ 7 1.1 2. 3. Scope of the document ................................................................................................................................... 7
Introduction ........................................................................................................................................................... 8 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 4.2 4.3 4.4 Bid/No- Bid decision ...................................................................................................................................... 10 Consequences of delaying taking bid/no bid decision .................................................................................. 10 Critical Issues to consider for the bid/no bid decision .................................................................................. 11 Recommendations for the bid/no bid decision ............................................................................................ 13
5.
Proposal................................................................................................................................................................ 13 5.1 Pre Proposal Due Diligence ........................................................................................................................... 13
5.1.1 Draft Contract Document................................................................................................................................. 13 5.1.2 Scope of Work .................................................................................................................................................. 13 Example 1: Example of unclear requirements ...................................................................................................... 14 5.2 Strategies for preparing a winning bid .......................................................................................................... 14
5.2.1 Looking at risks from the Customers perspective ........................................................................................... 14 5.2.2 Need Statement ............................................................................................................................................... 16 Example 3: Addressing Customers Special Needs................................................................................................ 16 5.2.3 Project Vision ................................................................................................................................................... 20 Example 4: Project Vision for an Enterprise data warehousing and Business Intelligence Solution .................... 20 5.2.4 Project Objectives ............................................................................................................................................ 21 Example 5: Project Objectives for an Enterprise data warehousing and Business Intelligence Solution ............. 21 For Internal Circulation only Page 2

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

5.6 5.7 6 The Proposal Document ................................................................................................................................ 45 Proposal Defense .......................................................................................................................................... 46
Contract Negotiations.......................................................................................................................................... 48 6.1 Types of contract........................................................................................................................................... 48
6.1.1 Time and Material Contracts........................................................................................................................ 48 6.1.2 Fixed Price Contracts .................................................................................................................................... 48 6.1.3 Time and Material Contracts with a cap ...................................................................................................... 49 6.2 Important considerations for Negotiation .................................................................................................... 50
Main items for Negotiation ................................................................................................................................... 51 6.3 6.4 Letter of Intent .............................................................................................................................................. 51 The Contract Document ................................................................................................................................ 52
6.4.1 Scope and Delivery related clauses .............................................................................................................. 52 6.4.1.1 Solution Ownership ................................................................................................................................... 52 Example 11: Solution Ownership .......................................................................................................................... 52 6.4.1.2 Project Commencement Date ................................................................................................................... 53 6.4.1.3 Simplifying Scope....................................................................................................................................... 53 Example 12: Simplifying Scope .............................................................................................................................. 54 6.4.1.4 Clauses to cover dependency risk .............................................................................................................. 55 Example 13: Dependency Risk .............................................................................................................................. 56 Example 14- Customers Obligations included in a contract: ............................................................................... 58 6.4.1.5 Change Control .......................................................................................................................................... 63 6.4.1.6 Maintenance Contracts - Service Level Agreement ................................................................................... 64 Example 15: Negotiating for Service Level (SL) ..................................................................................................... 64 Generally Accepted Service Level Principles ......................................................................................................... 67 6.4.1.7 Back to Back SLA with partner .................................................................................................................. 68 For Internal Circulation only Page 4

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

7 Re-negotiating Contracts .................................................................................................................................... 85 Example 19: Re-negotiating Contracts - Networking ............................................................................................ 85 Example 20: Re-negotiating Contracts - Synchronizing Objectives of stakeholders ............................................ 87 8 Process owner for the Bid Management and Negotiation process .................................................................. 89 8.1 Role and Responsibility ................................................................................................................................. 89
8.1.1 Mandatory Review of Proposals: ................................................................................................................. 89 8.1.2 Providing Guidance: ..................................................................................................................................... 90 8.1.3 Review of Contract Documents: .................................................................................................................. 90 8.1.4 Transition to Delivery: .................................................................................................................................. 90 8.2 8.3 8.4 9 What Delivery needs to know about the Contract ....................................................................................... 91 Structural Issues ............................................................................................................................................ 93 Risky Projects ................................................................................................................................................ 94
Conclusion ............................................................................................................................................................ 95
For Internal Circulation only
Page 6
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 Suppliers 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.
Page 7
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.
Page 8
3. Project Stages and Risk Management

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

4.1

Bid/No- Bid decision
Bidding for a contract involves the following risks: Risk of not winning. Winning but not being able to execute it.
The objective is therefore to: Go all out to win and secure a safe deal when execution is considered possible. Avoid a contract that is difficult or impossible to complete within budget and within the given time.
The bid/no bid decision is therefore of considerable importance and must be taken early for the following reasons: A clear decision to bid empowers the bid manager to employ all necessary resources to submit a winning proposal and to think, act and behave as if the deal is already won. This frame of mind helps in adopting 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, create the right environment for ensuring that no key risk is missed. 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 is very difficult to halt midway. Also there are other 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. Page 10
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?
Page 11

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?
Page 12
Managing IT Services Project Risks at Proposal and Contract stage 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 suppliers concerns. The suppliers 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 Suppliers 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 Suppliers 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 For Internal Circulation only Page 13

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 Customers requirements covered Defense Pensions and Pensions of the Punjab State Government also which the COTS solution was incapable of handling and required considerable development.
5.2
Strategies for preparing a winning bid
5.2.1 Looking at risks from the Customers perspective

The key to preparing a winning bid is to look at Project Risks from the Customers perspective and to address the Customers key concerns in a manner that assures the Customer that the Supplier: Is fully cognizant of the risks Has a workable plan to address all the risks in an apt manner Has a track record to prove that the Supplier has successfully executed similar projects
The RFP document sometimes contains an explicit procedure and criteria for evaluation of a proposal. In such a situation, the task is clearly cut out. Sometimes, the criteria are not spelt out. A risk document from the customers perspective can be prepared in such a situation. This would help prepare a proper response covering in detail areas that are apparently critical from the customers perspective. For Internal Circulation only Page 14

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 passengers 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 suppliers 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 customers business / IT personnel) o Clear definition of the roles and responsibilities of each party in each stage of the project implementation Assessing the Suppliers implementation approach and best practices for minimizing risks. Assessing the Suppliers software development quality assurance process to ensure that the quality is able to satisfy Customers 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 Suppliers cultural fit to minimize behavioral risks. Inability to get cooperation from the business user could seriously jeopardize quality and timelines. Assessing the Suppliers capability to identify the risks correctly and to come up with a workable plan to prevent/mitigate the risks. Assessing the Suppliers Technology competence for the Technology stack proposed for the Solution
A response that merits serious consideration would have to cover all of the above areas comprehensively. If the Supplier has not executed a similar project before, then the following
Page 15

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 Suppliers 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 Customers perspective, the response should be anchored around a clearly articulated needs statement of the Customer. The RFP document may or may not contain a well articulated need statement apart from scope. Even where, the Customer has included a need statement, the same may be paraphrased or improved upon based on Suppliers understanding of what value the Customer would appreciate in the offering. This is different from the value propositions. Value proposition may come at the end of the response and must clearly relate to the need statement at the beginning of the proposal. The need statement serves two very useful purposes: 1. Brings clarity and structure to the response 2. Makes a powerful and favorable impact on the Customer who begins to believe that the Supplier is worth doing business with and improves the chances of being called for negotiations. The Customer is more likely to overlook other shortcomings such as the commercials not coming up to the expectations, if they believe that the Supplier is truly interested in going the extra mile to discover and address the Customers special needs. Example 3: Addressing Customers Special Needs
Page 16

A Product Company requests for a proposal for IT Services covering: 1. Maintenance and Support of their Solution implemented at various customer sites 2. Development of enhancements to the Product based on Customer requests. The first part viz. Maintenance and Support is a standard practice for Suppliers of IT Services and will not be 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
Page 17

A clean well understood process that is followed uniformly for all enhancements Fulfillment of obligations by Product Company/their Client relating to Suppliers dependencies in the process to be followed for each enhancement.
A broad outline of the enhancement process that contains an assurance of fair pricing of enhancements to Product Company and also derisks the Supplier against possible miscalculation of effort at initial stage is described below: Step 1- Request for enhancement. Product Companys Customer comes up with a request for enhancement. At this stage, the requirement is at a high level in the language of the Business User. Step 2- Budgetary Estimate. Supplier submits a budgetary estimate based on the request Step 3 Go/No go decision. Customer communicates approval based on budgetary estimate or communicates lack of further interest. If the Customer does not approve the budgetary proposal, the 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
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 o Customer decides to go ahead then proceed to step 6 If Customer decides to drop the enhancement, bill for the effort upto this stage
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, Page 18

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 o Customer approves Kick off enhancement and go to step 7 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 Customer does not approve although final estimate is within estimate at the end of previous stage. Customer pays for efforts upto this stage.
Step 7 Development, Implementation.
The outlined process has the following advantages: The Customer has no obligation to proceed with the enhancement or pay for the Suppliers efforts unless the final proposal is within the approved budgetary price or the approved revised price at the end of previous stage. The Suppliers efforts are compensated when the final price is within the approved budget even if the Customer chooses to shelve the enhancement. The Supplier has the option to revise the price in any direction based on final detailed analysis of 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 For Internal Circulation only Page 19

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.
Page 20

The advantage of a well constructed Project Vision is that it captures in a single sentence what the Customers Top Management would like to achieve through the project and helps to get their buy in.
5.2.4 Project Objectives

Although most Request for Proposal documents from the customer contain the Project Objectives, there is considerable scope to improve upon them. Given below is an example of project objectives for an Enterprise Data warehousing and Business Intelligence Solution. Example 5: Project Objectives for an Enterprise data warehousing and Business Intelligence Solution
Project Objectives: To architect an integrated, scalable, agile and intelligent Information system for the Enterprise. Organization of data from multiple source systems into unified information in an Enterprise Data warehouse (EDW). The EDW will be a source of a single version of truth and meet all requirements for reporting and analysis and the needs of existing as well as proposed downstream applications. Delivery of reliable and consistent information at reduced cost, in a timely manner, in an appropriate format and through convenient channels. Building an effective decision support system with subject area data marts and OLAP tools 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 Managements 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. For Internal Circulation only Page 21

Example 6: Project Benefits for an Enterprise data warehousing and Business Intelligence Solution
Project Benefits: Besides meeting all of the Banks reporting requirements, the Solution will provide analytical insights for strategy formulation and decision making, and actionable information for execution, to meet the Banks financial and nonfinancial 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
Page 22

Given below is an example of a pricing model that takes into account project risks from the customers 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 customers 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 Banks financial and non-financial strategic objectives. Some of the relevant metrics
Page 23

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 Page 24

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 Page 25

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.
Page 26

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 Customers obligation: For integration of Application in scope with current applications in use and deployed on Customers legacy systems, the Customer shall procure services of the relevant application vendors as necessary to work with Supplier and its subcontractors for the integration.
5.3.2 Commercially Available Off the Shelf Solution (COTS)

If the Solution offered to the customer includes COTS Solutions, then the COTS Solution must be capable of meeting all of the Customers requirements in the subject area for which it is chosen without requiring any development. Customization for any single requirement should not exceed effort of 2 person days. Customization may be defined as follows: Customization means any report, enquiry, program, screen, or similar function which can be directly programmed on the System without needing a functional specification document and a technical specification document. The maximum duration of effort of a unit under the customization band is two (2) man days of effort and no additional charge shall be made for such effort. If the unit requires more than two (2) man days effort, the Parties will mutually agree the scope and charges for such work, which will be delivered as a Development, under the Change Control Procedure in phase 2. Development may be defined as follows and kept out of scope at least for phase 1 of the implementation. Development means enhancements to the Core product which require more than two (2) man days of effort and which are delivered in the form of Patches, Project Builds, Service Packs and Upgrades. Developments will be discussed between the Parties and agreed in accordance with the Change Control Procedure. It is agreed by the parties that development is out of scope in phase 1.
Page 27

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 todays needs but needs that may arise in future or similar requirement of other customers. This requires involvement of high caliber domain specialists who are scarce and 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 Banks 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 vendors nightmare Page 28

The COTS solution must therefore be capable of meeting all of the customers 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. 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? Data in legacy that cannot be mapped to any field in target system. What is to be done? Data extraction from legacy. Whose responsibility? Who will develop the extraction scripts? 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? Page 29
o o o

o o o o Data validation and reconciliation before uploading. What Reports will be produced and who will give the sign off? Who will develop those Reports Data upload scripts and data upload. Who will develop the scripts and who will run those scripts for uploading? Data validation and reconciliation after loading. Who will develop the reports and who will validate and give a sign off? 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 o If delay is solely on account of the subcontractor, can all of the LD be passed onto the subcontractor? 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 (Customers preferred option) or fixed period after the license agreement is signed (sub contractors 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. Page 30

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.3 Suppliers
In a SI Project, the prime contractor may be responsible for providing the complete solution covering:
Hardware Software Network Implementation Support
All the items of purchase are not required immediately and just in time purchases will be desirable from the cost and cash flow point of view. For example the production environment in the data center can be ready a month before the production go live date. If the production go live date is 9 months from the start date of the project, then the hardware required for the production environment can arrive 6 months after the project start date. The plan to network all offices of the Customer (for example, 1000 branch offices of a Bank) may be spread over a 2 year period. If all the equipment required is purchased in one lot, then this does not only involve cash outflow and interest costs but also warehousing costs and insurance. The warranty period will run through while these equipments are still lying in the warehouse. The equipment is also subject to obsolescence and depreciation. Purchase agreements must therefore be explicitly made for staggered purchases with firm delivery lead times and severe penalties for delays. In the absence of an explicit and documented understanding, once the prime contract is signed with the customer, the Suppliers will insist that: The Orders are to be placed immediately for the price to be valid. Prices quoted are valid only if the entire requirement is purchased in one lot. Page 31
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. Page 32

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 partners 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:
Page 33

Milestone Contract Award Project Initiation Gap Analysis Technical Design Application Development and Factory Test System Availability System installation/ configuration/training Completion date 1/5/2008 1/6/2008 1/7/2008 1/9/2008 15/11/2008 1/12/2008 15/2/2009
System Functional Testing & integration testing 31/3/2009 System Integration & Acceptance Pre-Production System Availability Production Go Live 1/6/2009 05/8/2009 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.
Page 34

This also has cost implications. Development teams would have to move onsite to fix defects during the Testing Phase. A longer duration for this phase would mean an increase in the onsite component.
5.4 Options at the proposal stage to deal with identified risks

At the proposal and contract stage, the various options for dealing with identified risks are: Ignore the risk Propose changes Say nothing in the proposal with intent to take it up at contract stage Deal with the risk during execution.
Ignoring the risk can be considered only if both the impact and probability of occurrence is low. If the Customer provides a structure for response to their RFP and the structure requires a response of `Will Comply or `Will Comply with Exceptions or `Will not comply, then a response of `Will Comply rules out the possibility of taking up the issue at the contract stage. However, a response of `Will comply at the proposal stage may still allow the scope for qualifying the clauses or to add riders. The risk of responding with `Will not comply is that the Customer may eliminate the proposal for non-compliance.
Example 9: Options to deal with identified risks
If the Supplier believes that it is not possible to complete the project on time as stipulated by the customer, then there are the following choices: No proposal. Propose an alternative schedule Propose to meet the completion date but hope to shift the date while negotiating the contract Propose to meet the completion date hoping that the risk can be `managed during the execution phase.
The appropriate choice depends upon the circumstances as well. There could be one of the 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. For Internal Circulation only Page 35

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 customers 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 Suppliers performance of the Services is below the industry standards for such Services, Supplier shall, within thirty (30) days after the Bench markers decision, develop for CUSTOMER review and approval, a plan to bring Suppliers performance up to industry standards as soon as practically possible and in all events within ninety (90) days after CUSTOMERs approval of such plan.
Benchmarking Price: The Bench marker will review Suppliers pricing, comparing Suppliers charges for such Services to the least costly deciles in the world for comparable services (the "Charges Target"). If a benchmarking reveals that Suppliers prices for Services are in excess of the Charges Target, Supplier will reduce the charges to match the Charges Target.
The supplier could in principle agree to the abovementioned clause at proposal stage but qualify the clauses during negotiation stage in the following manner: For Internal Circulation only Page 36

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
Page 37

The System Integrators internal organization structure consists of a CFU (customer facing unit) that does the Program Management and CU (competency units) that do the actual implementation. The CFU therefore treats all CU as subcontractors. The total price therefore consists of the price quoted and negotiated with the subcontractors (including internal units) plus what the CFU charges for Program Management. How should the CFU arrive at their charges and what are its components? One component is the size of the Program Management office and expenses relating to it. The other component is the risks that the CFU carries and how these risks are priced. The Program Management role is to coordinate the efforts of all parties including the customer to ensure on-time delivery. The CFU may therefore insulate all subcontractors against the risk of delay on account of a recognized dependency and have a mechanism for compensating the subcontractor on account of costs incurred for any delay attributable to the other parties. 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. For Internal Circulation only Page 38

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 For Internal Circulation only Page 39

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:
Page 40

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 o o Makes comparison with other competitors proposals possible. Brings transparency to the process of project costing and builds an environment of trust The Customer may come back with feedback on the assumptions which helps refine the estimates and firm up the scope. 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 Customers 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.
Page 41
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. For Internal Circulation only Page 42

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 Customers 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 For Internal Circulation only Page 43

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. Page 44

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 Customers obligation. Acceptance of the proposal then amounts to acceptance by the Customer of their obligations as well. Suppliers assumptions on the other hand remain the Suppliers 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.
Page 45
Managing IT Services Project Risks at Proposal and Contract stage 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
Page 46

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 Suppliers 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?
Page 47
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 Suppliers 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, Page 48

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 customers 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. Page 49
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 Customers 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 Customers negotiating team cannot go to their management and report that the negotiations have broken off when the demands made are unreasonable. When the Suppliers negotiating team is in a position to clearly state their position on any clause with well articulated reasons, the Customers negotiating team quickly realizes that the Suppliers 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 others needs.
Page 50

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 Suppliers perspective. In any case, Payment Terms and Project Fees should be discussed after agreement is reached on the first 6 items. The Customers, 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 customers 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 Customers 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 For Internal Circulation only Page 51

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. Structure is aptly defined by Robert Fritz, father of structural dynamics as the elements in relationship to each other that give rise to behavior. Does the underlying structure created by the contract support the desired behavior or is it likely to drive counterproductive behavior? Projects often fail because the structure is inadequate or defective. These forces are significantly underestimated as the cause of success or failure. Winston Churchill once said. First we shape our structures. Afterwards they shape us. The important clauses that form the structure and shape behavior during contract performance are discussed in this section. The position that the Suppliers 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:
Page 52

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 Suppliers 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 Customers 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 Page 53

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 Customers 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 o The discounts are for single large order 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
Page 54

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 Customers 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: For Internal Circulation only Page 55

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 Suppliers interests for delays caused by Customer: Suppliers 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:
Page 56

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 Customers 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.
Page 57
Example 14- Customers Obligations included in a contract: The following is an example of Customers Obligations included as a schedule in a contract and linked to a clause on the `Relief Event. SCHEDULE X CUSTOMERS OBLIGATIONS General: 1. Project sponsorship by CUSTOMERs 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 1 Responsibility A program director and project manager from CUSTOMER. Additionally a single point of contact for all communications with IT and business teams. Designated personnel from CUSTOMER will be empowered with appropriate authority to take timely decisions. Appoint a steering committee to review Project Deliverables and handle issues requiring escalation. Such steering committee to include at a minimum IT representative and one business representative. When Due Prior to start of the project Prior to start of the project
Page 58

CUSTOMER to ensure representation from hardware and networking vendors, as and when required, in the steering committee for the entire duration of the Services. Appoint an empowered Customer project team with the relevant domain, business and technical skills to engage with Suppliers implementation team for the entire duration of the Services (Customer to ensure continuity of team as far as is possible).;
Provide the required software (such as Outlook, Visio, MS Office/Project, tools (Project Tracking (if any), Defect Management, system change management tool etc.), hardware and networking for Supplier Development team required to perform the Services set forth herein. Customer shall hold valid contracts for the above. Provide a single point of contact for managing change control. Throughout Engagement
Formation prior to business analysis phase of the project and to be available for the duration of the services. Prior to build phase
Provide access to appropriate staff to attend meetings, workshops and discussions at a central location. It is the responsibility of Customer to identify the most appropriate staff to attend in order to achieve the objectives of the Work package. Customer will provide all necessary resources as and when required on a mutually agreed basis.
Throughout Engagement
Customer shall provide suitable meeting tools and office space, office supplies, furniture, telephone (with international dialing facility), Internet Access and other facilities at Customers 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. Customer shall provide access to all relevant internal documentation and the documentation shall be in English. Customer shall ensure that all project related documentation which it prepares or provides will be in English.
Customer shall facilitate access to the Oracle Metalink for logging service requests concerning the Project.
Prior to start of the project
Page 59

10 The response time for feedback on a document/issue from Customer as soon as reasonably possible but in any event not longer than Five(5) Working Days unless otherwise stated in the Master Services Agreement. Any delay on this account will have an impact on Project schedules, efforts and costs. Customer to ensure that User Acceptance Testing will be completed within the stipulated time period. In case of change in timelines, Supplier would initiate a CCN to rework the estimates. Any delay on this account will have an impact on Project schedules, efforts and costs. Customer will provide data required for data migration as CSV file format. Any other format for data migration shall be mutually agreed upon between Supplier and Customer. Data cleansing rules will be done by Customer. Customer to be responsible for data integrity and validity. Provide requisite data from the legacy system in CSV formats (or such other mutually agreed compatible format) for data loading. Throughout Engagement
11
Validate phase and deployment phases
12
During the Data Migration cycle
13
Build and Test
14
Provide format for the different reports and inputs for forms to be developed (if any)
Analysis and Design
15
Provide Test cases and test data for the various testing phases of the Project to validate the appropriateness of the solution being deployed.
Build and Test
16
Provide detailed business requirements
Business Process Analysis Phase
17
Training would adopt the Train-the-Trainer approach and the Customer would provide necessary training infrastructure such as Training Rooms with related tools, desktops for the users and also ensure participation of the nominated business users who will then be responsible to train the end users. For integration of the Applications in scope with current Applications in use, procure services of the other Application Vendors as necessary to work with Supplier for the integration.
Various Training phases of the Project.
18
As necessary
Page 60

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

Prekickoff
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 Design Solution Build Entire Project
5. Virtual Private Network (VPN) connectivity to allow access to the application environment 6. Hardware: Production environment available and configured as per the solution architecture. 7. Any other requirements for the Operating Environment would be identified and agreed at the end of the project initiation phase.
Page 62

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.
Page 63
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 Performance Category

Gold Application Availability (minutes down per month during hours of operation) Severity Level 1 incidents Resolved Within 1 hour (during hours of operation) Severity Level 2 incidents Resolved Within 24 hour (during hours of operation)
Measurement Expected Minimum Window
% of Invoice
65 99.50% 98.50%
130 99.00% 98.00%
Monthly Monthly Monthly
8.00% 8.00% 5.00%
Page 64

Severity Level 3 incidents Resolved as agreed Silver Application Availability (minutes down per month during hours of operation) Severity Level 1 incidents Resolved Within 3 hours (during hours of operation) Severity Level 2 incidents Resolved Within 48 hours Severity Level 3 incidents Resolved as agreed Bronze Application Availability (minutes down per month during hours of operation) Severity Level 1 incidents Resolved Within 6 hours (during hours of operation) Severity Level 2 incidents Resolved Within 96 hours Severity Level 3 incidents Resolved as agreed 98.50% 98.00% Monthly 2.00%
260 98.00% 97.00% 97.00%
360 97.50% 94.50% 94.50%
Monthly Monthly Monthly Monthly
8.00% 8.00% 5.00% 2.00%
360 97.00% 92.00% 92.00%
430 94.50% 89.50% 89.50%
Monthly Monthly Monthly Monthly
8.00% 8.00% 5.00% 2.00%
Enhancement - Performance Category

Promoted into production within +- 3% of budget Promoted into production with zero defects Promoted into UAT with zero defects Key Deliverables completed on or before planned date Reduction in number of code defects by 10% Log "sev1 monitoring alerts" (auto generated alarms) within 15 minutes Application Performance - Performance Category Batch Schedule Completion On-Time Rate Application Response Time as per SOR Transaction time for standard Database transactions Transaction time for standard Tibco transactions Customer Satisfaction - Performance Category Customer Satisfaction Staffing
Measurement Expected Minimum Window

95.00% 99.00% 95.00% 95.00% 100.00% 95.00% 90.00% 98.00% 90.00% 90.00% 98.00% 90.00% Monthly Monthly Monthly Monthly Monthly Monthly Measurement Window Monthly Monthly Monthly Test Monthly Test Measurement Window Monthly Measurement
% of Invoice
1.00% 2.00% 1.00% 1.00% 2.00% 2.00% % of Invoice 4.00% 2.00% 2.00% 2.00% % of Invoice 4.00% % of
Expected 98.50% 97.50% 0.8 sec 3.2 sec
Minimum 98.00% 92.50% 0.1 sec 3.5 sec
Expected 90.00% Expected
Minimum 80.00% Minimum
Page 65

Window Supplier Key Personnel (personnel identified in RFP) Annual Turnover Total Supplier Personnel Annual Turnover Assigned to TFS In US Supplier Personnel Annual Turnover Assigned to TFS Outside US 15.00% 15.00% 20.00% Semi-Annual Semi-Annual Semi-Annual Invoice 2.00% 2.00% 2.00%
Total The SL credit will be issued if: Performance is below minimum. Performance is below expected for any 3 months in previous 12 month period.
98%
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 customers perspective, end to end SLA makes sense, from the Suppliers 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 Customers 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 For Internal Circulation only Page 66

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 Suppliers team started the meeting by enunciating the principles and getting the Customers 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 For Internal Circulation only Page 67

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 customers 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 Customers 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 Customers 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.
Page 68
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 For Internal Circulation only Page 69

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 Suppliers 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 Customers 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. Page 70

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. Page 71

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 : For Internal Circulation only Page 72

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. Customers 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 Suppliers 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 Suppliers 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

For Internal Circulation only Page 73

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
RFP
Reason for not including

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. The Proposal document constitutes the offer based on which the contract is 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.
Proposal or RFP response
Page 74

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 subcontractors offer document to the prime contractor and are binding on the subcontractor. Proposal Defense presentations Clarifications to questions raised by the customer This is not a very precise document and by nature brief and concise. Could pose problems in interpretation later and should be left out. The clarifications could be detailed or summary. Short answers often create larger obligations as these are likely to be interpreted differently by the customer from 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 o Unrecovered elements of any unamortized capital investments 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.
Page 75

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 Suppliers employees) and the unrecovered elements of any unamortized capital investments 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. 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. 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.
Page 76

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 companys 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 customers business whereas loss to the customer on account of breach of confidentiality, IP infringement, etc is linked to the size of the customers 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 companys 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 Suppliers team was as follows: The fee is based on the efforts and not linked to the size of the Customers 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. Page 77

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 Suppliers 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 Customers 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.
Page 78

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 Suppliers 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. Page 79

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 Customers 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 Page 80

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 Customers 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 Suppliers 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: Page 81

o o o The Services may be rendered in different geographies with different cost structures The quantum of work may not be equal The Level of work may be variable to different degrees with varying predictability resulting in different average loading factors 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 The price also includes the price of embedded options in the contract such as: o 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
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 customers 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. 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:
Page 82

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 Providers 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 Suppliers 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 Customers 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 Customers 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.
Page 83

The audit findings contain both facts and the auditors 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 Customers request based on the auditors report Reserve their right to dispute the findings of the audit Not agree to payment of the auditors 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 Page 84

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 Suppliers 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 Primes 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.
Page 85

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 partners 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 SIs responsibility to provide the complete range of services. The SIs 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.
Page 86

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 governments 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:
Page 87

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 MDOs 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 Governments scheme to help economically and socially challenged persons to become successful transport operators.
Page 88
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. Page 89

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 teams 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: For Internal Circulation only Page 90
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. Page 91

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 Page 92

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 Page 93

likely financial impact. The incentive can be linked to the top-line and also to the projected bottomline 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 o Formulating a plan based upon facts and assumptions, Testing the assumptions as soon as possible and collecting missing information. Revising the plans based on better information Actual performance and results Analysis of material deviations from plan Recording of the learning
o o o
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 For Internal Circulation only Page 94

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 Suppliers Organization and resources. The Suppliers 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.
References for section 3, 4 and 5.4 Project Risk Management: The Commercial Dimension a Report by Tim Boyce
Published by Thorogood
All Rights Reserved. Copyright 2008. Javeed Ahmed
Page 95

Bid Management and Negotiation

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Bid Management and Negotiation

Transféré par

Droits d'auteur :

Formats disponibles

Bid Management and Contract Negotiations for IT Services Projects

FOR INTERNAL CIRCULATION

Managing IT Services Project Risks at Proposal and Contract stage

Managing IT Services Project Risks at Proposal and Contract stage

Managing IT Services Project Risks at Proposal and Contract stage

Managing IT Services Project Risks at Proposal and Contract stage

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

Scope of the document

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

3. Project Stages and Risk Management

Table 1 : Project Stages and Risk management

What needs to be done?

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

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

Bid/No- Bid decision

Consequences of delaying taking bid/no bid decision

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

Critical Issues to consider for the bid/no bid decision

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Pre Proposal Due Diligence

5.1.1 Draft Contract Document

5.1.2 Scope of Work

Managing IT Services Project Risks at Proposal and Contract stage

Strategies for preparing a winning bid

5.2.1 Looking at risks from the Customers perspective

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

5.2.2 Need Statement

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

Step 7 Development, Implementation.

Managing IT Services Project Risks at Proposal and Contract stage

5.2.3 Project Vision

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

5.2.4 Project Objectives

5.2.5 Project Benefits

Managing IT Services Project Risks at Proposal and Contract stage

5.2.6 Innovative Pricing Model for winning Projects

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

For Internal Circulation only

Managing IT Services Project Risks at Proposal and Contract stage

Areas of focus at Proposal stage

5.3.1 Dependency Risks