MED INF 408: MEDICAL TECHNOLOGY ACQUISITION AND ASSESSMENT

FALL 2011

ASSIGNMENT 5

CONTRACT NEGOTIATION

BY

DEEPAK KHANAL AND SUBRATA BEHERA

REPRESENTING AXOLOTL, INC. (VENDOR)

I. Develop a list of 3–5 key criteria your organization needs from the software

contract if it is to be a successful deal for your organization.

1. In Section 10.2 of the contract, we have concerns about the following statement:

“HIEU may terminate the License, without prejudice to any other remedy HIEU may

have, in the event of any material breach of this Agreement that is not remedied within

twenty four (24) hours of HIEU's notice to Vendor of the breach and HIEU's intent to

terminate the License. Termination shall not relieve HIEU's obligation to pay all

amounts that are due and payable or which HIEU has agreed to pay. “

Our specific concern is on the 24-hour window to remedy the breach. We strongly

believe that it is absolutely not practical to meet that requirement. Not only that no such

requirement was specified in the Request for Proposal (RFP), we also remind HIEU of

the turnaround time of 180 days offered to it in Section 10.2 (i) and would like to argue

that Axolotl be given a similar (180 days) timeframe to remedy a breach. We do expect

pushback from HIEU. We expect that HIEU will emphasize on the need for a quick

remedy and would argue to keep the remedy window to 24 hours or slightly higher. Our

BATNA for this item is to get at least 30 days to remedy a breach. We are also willing to

offer HIEU a proactive notification of a breach within 24 hours of its verification. We

believe that this BATNA will work because it offers the client a guarantee on getting

proactive notifications from us on any breaches we find on our own, and gives us

reasonable timeframe (30 days) to remedy any breaches they report or we find.

2. In Section 10.3 of the contract, we have concerns about the following statement:

“In addition to any other remedy that Vendor may have at law, in equity or under this

Agreement, upon the occurrence of any breach set forth in Section 10.2 above, HIEU

shall have the right to immediately enter Vendor's premises, access Vendor's computer

systems and to seize any copies of the Solution or Documentation or any modifications or

materials derived thereof. If the latter event occurs, paper copies of all patients' records

in the current calendar year will be printed from the system and provided to HIEU for its

use.”

Our specific concern is on HIEU’s right to enter our premises, and access/seize our

computer systems. We strongly believe that this is too strongly worded and is not

practical to implement. We are also concerned about the disruptiveness of such an event

to the operations of our organization and our reputation. Our BATNA for this item is to

prevent HIEU from physically accessing the Axolotl premises and its computer system

immediately in case of a breach. We would like to add clauses for advance notice, ideally

three, but at least one from HIEU of its intention to access the premise, and allow Axolotl

to resolve the issue in order to prevent such action. We expect pushback from HIEU that

they need to resolve the Axolotl breach as quickly and effectively as possible, but our

strategy in negotiating this would be to turn the table and get the HIEU to “step to their

side” (Ury, 1993). We will ask HIEU if a similar action by Axolotl in case of a breach by

HIEU would be acceptable.

3. We have concerns about the following statements in the contract:

a. In Section 12.2.b:

“Temporarily, if Vendor fails to correct or provide a workaround for a business-critical

error in the Solution for a period exceeding 30 business days, and for the length of time

needed for HIEU to correct or provide a workaround for such error. In either case,

HIEU may use such copy of the Source Code solely for purposes of supporting HIEU’s

use of the Solution pursuant to the License; HIEU may not make or distribute copies of

the Source Code, nor create derivative works based thereon, or make or distribute copies

of such derivative works, except to the extent necessary for such purposes”

b. In Section 12.4:

“If HIEU’s right to use Source code is temporary, then it will return its escrow copy of

the Source Code to the escrow agent upon completion of its use rights and will certify to

Vendor in writing that HIEU has destroyed all other copies.”

Specifically, our concern is on the release of the source code to HIEU. The release of the

source code can be fatal to our business, since it can disclose intellectual property, trade

secrets and security algorithms embedded into our software. While HIEU may claim to

protect its confidentiality, any inadvertent breach (such as by third-party theft) of this

confidentiality can cause an irreparable damage to our products, business and all of our

clients (Friedberg, Aquilina, & Friedrich, 2010).

Our BATNA for this item is to revise the terms of the agreement in this section to allow

for at least three notices to Axolotl, each at least one month apart, to correct the problem.

HIEU is expected to push-back on this, since the operational continuity is obviously very

important to them. We will use the “Don't push: Build them a golden bridge” strategy

(Ury, 1993) to negotiate this. We must not trivialize their concern and must not make

them feel as though they are losing on this. We must reiterate our commitment to provide

prompt service for any critical issues and that their business continuity is always at our

heart. We will try to convince them on the risk (to both us and them) of inadvertent leak

of the software source code. We should reassure the client that Axolotl will assess the

situation and work with HIEU to determine the criticality of the issue. We will also

assure the client that Axolotl has a well-defined software development process and takes

pride in it. We believe that our BATNA and our argument will work because we will not

make the client feel like they are losing on their need for operational continuity and will

make them appreciate the mutual risk of a potential software source code leak.

4. We have concerns in the contract that there is no provision for incentives for excellence.

We at Axolotl subscribe to the idea that a properly defined performance-based incentives

scheme can be very beneficial to both parties in a vendor-client relationship (Montague,

2001). As such, we would like include a clause in the contract for financial incentives to

Axolotl for exceeding its performance expectations. Our ideal goal for this item to

establish a tiered incentives model using the following formula:

Additional 1% of the cost of the service for each 1% of the better-than-expected

turnaround time achieved. As such, if Axolotl, for example, delivers a solution to

HIEU in 3 months, where up to 6 months were allowed, then HIEU rewards

Axolotl with a financial bonus of additional 50% of the agreed upon amount for

normally expected turnaround.

While the above is our ideal goal, we do expect pushback from HIEU, given the potential

for significant amounts to be paid to us in incentives. Our strategy in negotiating this

item is “Don’t escalate: Use power to educate” (Ury, 1993). We will point the client to

the industry testimonials and studies showing benefits of the performance-based

incentives (Rogin, 2001) (Ransom, 2008). Our BATNA for this item is to establish at

least some kind of incentives scheme in the contract rewards Axolotl for its performance

excellence. Minimum accepted incentives would be a fixed or average reward of at least

5% for any better-than-expected turnaround. We are also open to adding penalty clauses

in the contract that are equivalent to the incentives rewards for any failed milestones or

worse-than-expected turnaround. We believe that this will work because it will drive both

client and vendor towards excellence. Given our track record, we are also confident that

we’ll be able to achieve the performance thresholds required to earn the incentives.

5. We have concerns in the contract that there is no stated framework for longer-term

partnership.

We at Axolotl believe in long-term partnership with our clients. We are a growing

company and have benefited from our partnerships with our existing clients, and the

testimonials1 we have received from our clients strongly suggest that the benefit is

mutual. There have also been several articles written on the importance of the

partnership (Baldwin, 2008) (Cyon Research Corporation, 2005). However, this contract

in its current form does not encourage this kind of partnership beyond the immediate

scope of work. We would like to argue that a provision be added in the contract to allow

for greater cooperation between HIEU and Axolotl. Specifically, we would like to

include the following clauses:

a. HIEU-Axolotl Summits: Annual meeting at various levels of the two organizations,

including the executive level to evaluate, align and strengthen the partnership.

b. Cooperation with Axolotl R&D Efforts: At Axolotl, we constantly strive to improve

and innovate better solutions for our clients and their customers. At times, we need

cooperation from our clients to validate our concepts and designs. This cooperation

may be in the form of focus group participation, beta testing and customer surveys.

We would like to add a clause in the contract that, when requested by Axolotl, HIEU

will cooperate with Axolotl’s R&D activities to the extent possible.

1 http://www.axolotl.com/company/testimonials.html

We do anticipate some pushback from HIEU that they would prefer to keep the contract

only on the scope of work specified in the Request for Proposal. Our strategy to negotiate

this item is a combination of Reframe and “Step to their side” (Ury, 1993). We will make

every attempt to understand all of the client’s concerns and seek their advice on how best

they think we could accomplish our goal. We will also try to convince them on the

benefit they will have working with the vendor who is constantly working on refining its

products. Additionally, we will remind HIEU that, as they grow, the need for new

features may come up in the future and it may be necessary for them to evaluate and align

the strategic partnership with us on an ongoing basis to achieve their future needs. Our

BATNA for this item is a provision in the contract for periodic review of the partnership

at an executive level, and we believe we’ll be able to accomplish this since the client

doesn’t really have much to give up for this.

6. In addition to the above concerns we have in the current contract, we also anticipate some

concerns that HIEU may raise. We believe that preparation is key in any negotiation

(Ury, 1993), and thus have the following positions on the potential HIEU concerns,

should they arise:

a. HIEU may try to re-negotiate the costs and get a discount particularly on the on-

going charges which currently contain a annual escalator clauses (e.g. annual

license, maintenance). Our position on this is that our quotes in the RFP have

been very competitive and there is not much room for further discounts. However,

should this item be a make-or-break proposition, we will be prepared to strike the

3% escalator clauses as long as the contract is re-negotiated (and not auto-

renewed) each year.

b. In Section 3.1 of the Contract, HIEU may have concerns that 10 days window for

acceptance after delivery. As with some of our other clients, they may ask for

significantly larger window. We should be prepared to give some ground on this

and offer up to 30 days for the acceptance. However, we must re-state that HIEU

may not use the system in production until the acceptance, or the system will be

considered accepted.

c. In Section 4.6 of the Contract, HIEU may have concerns that 1% deduction for

each delay of 1 week is insufficient. While we have rarely had delays in getting

the products delivered, we should be careful not to allow significantly higher

penalty deduction, should the situation arise. Our position should be to keep the

penalty to a prorated daily amount for each day delayed. As such, if, for example,

our delivery is delayed by one month, we should accept the penalty no more than

the prorated fees for that month.

d. In Section 12 of the Contract, HIEU may have concerns that the current clauses

do not require the escrowed software to be up-to-date. HIEU may ask that each

build of the software be escrowed. Our position on this should be to remind HIEU

of the logistical challenge of ensuring this and that of the minimal practical value

of the escrow to it. However, if this becomes a make-or-break clause, we should

be prepared to include a clause in the contract that calls for the check into escrow

of every released copy of the software. This is the practice we already perform, so

can be used as a no-cost trade-off for HIEU’s acceptance of one of our concerns

discussed earlier.

7. On a minor note, we would also like to correct the typo in Section 4.6 of the Contract,

where the last instance of the word ‘than’ should be replaced with ‘then’.

II. Explain the risks and benefits of using a go to the balcony approach in

negotiating the terms of a service level agreement.

Negotiations are basically a process that is used achieve a mutually acceptable outcome.

Great negotiated outcomes are when both parties feel they have ‘won’; acceptable outcomes

are when the parties can ‘live with’ the results (Mosaic Projects, 2010).

Negotiation techniques are necessary for a successful implementation of a Service Level

Agreement of an HIE. Since the SLA is a legally binding agreement between the two parties,

it is understandable that each party would try to minimize their obligations and maximize that

of the other side. So it is easy for the tempers to flare up during the negotiations phase as

each side might not want to concede certain terms in the determining the SLA. Even though

it would be in the best interests of both the vendor and the customer to negotiate terms in the

SLA which are workable and can be achieved, emotions and confrontations can get in the

way.

Issue might arise during the contract negotiation phase when parties involved in the SLA

negotiation lose focus and display uncontrolled emotions. As pointed out in the book

“Getting Past No” (Ury, 1993), such uncontrolled displays of emotions can be detrimental to

the negotiation. “Don’t react: Go to the Balcony” is one of the five strategies for successful

negotiation suggested in the book.

The Go to the Balcony approach can be of tremendous help in serious negotiations as it

allows the participants to abstain from reacting and regain their composure. It can provide

time to control the emotion and regain clarity about the work at hand and working towards an

amicable solution. This approach considers the following three characteristics for failed

negotiations: striking back, breaking off and giving in. If an individual on the negotiation

table can keep these in check, then s/he would be able to achieve a successful negotiation,

and the Go to the Balcony approach helps us reach that goal.

There are also certain risks that are associated with the Go to Balcony approach. If a

negotiator uses this approach on every item the other side brings to the table, then s/he can

appear not-ready, not informed or confident, which can be counterproductive to the goal.

Some questions and comments require a prompt answer, and a negotiator must be able to

distinguish between an event that can potentially result in a confrontation versus an event that

is simply a high-pitch query. A successful negotiation also depends on the perception of the

other party of your conduct and behavior during negotiation, so a negotiator must use the

tactics only when appropriate.

III. Describe two other approaches to negotiating your SLA.

Two other approaches to negotiating the SLA could be:

Reframing (Ury, 1993); and

Using the Power to Educate (Ury, 1993)

As Ury has suggested, one way of reframing the issue is by turning your adversaries into

advisors. So for the SLA, we could ask the client to advise us on what they would believe

would be a realistic and fair term, then give them the burden to prove why it is fair. As

negotiators for the vendor, we would act as though we are really siding with the client, but in

reality we would be trying to achieve our company’s goals. A reference example for this

approach is the negotiation that then Senator Joe Biden did with the Russian Foreign Minister

in 1997 (See Ury book page 78 for the story). The specific tactics that can be used in

reframing the issue are: Going around the stonewalls, while ignoring but also testing them at

the same time; Deflecting attacks, reframing them as friendly; Exposing tricks; and

Negotiating about the rules of the game. In an SLA negotiation, all of these tactics may have

to be employed depending on the situation. At the core of this strategy is an important notion

that by changing the presentation of an issue, we can change the reaction and thus achieve a

different result than would be normally expected with the original approach.

The second approach (Using the Power to Educate) can leverage the tactics discussed by Ury

(Ury, 1993), in conjunction with the analysis performed by Jane Disbrow (Disbrow, 2005) on

the topic. As Disbrow suggests, a successful contract negotiation requires that the customer:

understand the company’s needs and requirements;

understand the vendor’s strengths and liabilities; and

anticipate changes that are predictable and unpredictable.

As a negotiator for the vendor, we can use some of the techniques that Ury suggests to make

the customer achieve the above goals. Even after this has been achieved, this strategy (Using

the Power to Educate) can be applied to resolve any issue that might arise during the SLA

negotiation. For example, making the client understand the consequences of not meeting our

request can be an important step. Often times, the client may just not see the issue from the

same vantage point and bringing it up can help both parties reassess the mutual risks and

benefits. Similarly, using our BATNA to defuse the client’s reaction can be another tactic. If

the client knows that we have a BATNA and are likely to enforce it, then they might pay

closer attention to the request we are making. Also, forging a lasting and educated

agreement, while keeping the implementation in mind is an important tactic to use. The goal

here is not to make the client look uninformed or uneducated; but rather to highlight on some

areas and make sure the client is aware of your point-of-view. Ultimately, as Ury suggests,

the goal of the negotiation is a mutual satisfaction, and not a victory for either party.

IV. Discuss cloud computing, ASP, and SaaS models as operational alternatives for

your software application.

This question would perhaps be more pertinent to our client (HIEU) who has these

alternatives as they try to acquire a solution. Nevertheless, as a vendor, let us address the

concepts behind each of these alternatives and where our solution fits.

Cloud computing is an increasingly popular platform for applications that allows the software

and hardware functions of remote, often virtualized servers and resources to be leveraged in

order to solve a computing problem (Hosono, Kimita, Akasaka, Hara, & Y. Shimomura,

2011). It allows for outsourcing of computing tasks at a fairly granular level. For example, it

is possible to lease a remote processor to perform a processor-intensive task. Similarly, it is

possible to lease a remote storage service to store data. It is also possible to lease the entire

server or application over the cloud.

ASP and SaaS are application-level hosting models. While they also have the ‘cloud’

component to them (since they reside and are maintained in a remote location), the focus of

these models is on delivering the solution. In these models, the application service provider,

also known as the vendor, is responsible for maintaining the systems and offers its clients a

mutually agreed up-time guarantee. These models can be contrasted with the on-premises

systems, where the client is responsible for maintaining the system, including the software,

hardware and other resources (Kim, Jeon, & Kim, 2008).

We at Axolotl, offer our HIE solution as in the SaaS model, which leverages cloud

computing to a great extent. Our powerful hosting platform is powered by sophisticated

industry standard technologies. Our cloud platforms are scalable cloud platform that delivers

federated secure, reliable, compliant and virtualized solutions. Our private cloud enables

HIEs to deliver on SLAs, accelerates HIE application deployments and minimizes

downtime2.

V. Discuss warranty and the role it plays in this deal.

We at Axolotl are confident that our HIE solutions will meet all of HIEUnited’s requirements

stated in the Request for Proposal. However, we understand our client’s concerns about the

large investments they are making on the system and their expectation of our expressed

commitment in the quality of our products. We believe that any warranty must cover the

following aspects: Performance, Services, Compliance with Applicable Law, Intellectual

Property, Integrity, and Third Party Software (Overly & Kalyvas, 2004). As such, our

contract includes several clauses to assure the client on each of these areas.

We understand that the warranties are critical to this deal and Axolotl is committed to

providing all necessary support for the uninterrupted service to the customer. We must,

however, make it clear to HIEU that we do not guarantee that our system is bug-free. Our 2 http://www.axolotl.com/services/application-services.html

guarantee to our client is that we’ve shipped the product free of defects to our knowledge and

that any new defects discovered will be addressed following the procedures set forth in this

contract. This also applies to the third-party components used in our system.

VI. Discuss source code escrow and its relevance to this transaction.

Source code escrow is a process by which the vendor deposits the source code with a

mutually trusted third party for confidential safekeeping and release only on certain

circumstances, such as vendor insolvency (Barnett, 2011). It is a tool that helps clients

mitigate or minimize the risks of vendor support failure. As the value of the investment in the

software system by an organization goes up, the importance of a reliable and trustworthy

source-code escrow of the system also goes up. This is particularly important when dealing

with smaller vendors with less than sufficient history or track record of continued support.

Relevance to this transaction: Even though Axolotl is a stable, profitable and growing

company with a coast-to-coast customer base, we understand the concerns HIEU has

regarding the availability of the system source code should Axolotl become or insolvent

unable to provide the support. It is in recognition of these concerns that we have agreed

(pending negotiation on some of our concerns raised in previous sections) to the Source Code

Escrow clause (See Section 12) in the contract.

References

Baldwin, G. (2008, 02 12). Love Thy Vendor? Retrieved 11 27, 2011, from www.hcpro.com:

http://ers.library.northwestern.edu.turing.library.northwestern.edu/ers/574-4327.pdf

Barnett, C. (2011). Source Code Escrow Is a Vital Part to Technology Transactions. Retrieved 11

30, 2011, from http://www.scottandscottllp.com:

http://www.scottandscottllp.com/main/source_code_escrow_in_tech_transaction.aspx

BATNA - Best Alternative. (n.d.). Retrieved 11 23, 2011, from The Negotiation Experts:

http://www.negotiations.com/articles/best-alternative/

Cyon Research Corporation. (2005). Strategic Partnerships: The Impact of Vendor Partnerships

on Customer Value. Cyon Research Corporation.

Disbrow, J. B. (2005, 02 22). How to Make Software Contract Negotiations Work for Your

Business. Retrieved 11 30, 2011, from http://www.gartner.com:

http://www.gartner.com/resources/126000/126089/how_to_make_sof.pdf

Friedberg, E., Aquilina, J., & Friedrich, M. (2010). Investigating Source Code Thefts. The 24th

Annual National Institute on White Collar Crime.

Hosono, S., Kimita, K., Akasaka, F., Hara, T., & Y. Shimomura, T. A. (2011). Toward Establishing

Design Methods for Cloud-Based Business Platforms. In S. Hosono, K. Kimita, F. Akasaka,

T. Hara, & T. A. Y. Shimomura, Functional Thinking for Value Creation (pp. 195-200).

Kim, H., Jeon, S., & Kim, J. (2008). ASP effects in the small-sized enterprise: the case of the

Bizmeka service from Korea Telecom. Service Business, 287-301.

Montague, D. (2001). Restoring Trust, The Handbook of Integral Management. LDM Associates.

Mosaic Projects. (2010). Negotiating and Mediating - White Paper. Retrieved 11 30, 2011, from

http://www.mosaicprojects.com.au:

http://www.mosaicprojects.com.au/WhitePapers/WP1024_Negotiating.pdf

Overly, M., & Kalyvas, J. R. (2004). Software Agreements Line By Line. Aspatore Books.

Ransom, B. (2008, 12). Institutionalizing Performance-Based Acquisition. Retrieved 11 27, 2011,

from ASIGovernment.com:

https://www.asigovernment.com/documents/Research_Institutionalizing

%20Performance-Based%20Acquisition.pdf

Rogin, R. A. (2001, 12 10). Performance-Based Service Contracting. Retrieved 11 27, 2011, from

https://www.acquisition.gov/sevensteps/library/DOTpbsc.pdf

Ury, W. (1993). Getting Past No. Bantam Books.