COTS Software Licensing Day 1 Overview Session 2014

  • Slides: 107
Download presentation
COTS Software Licensing Day 1: Overview Session 2014

COTS Software Licensing Day 1: Overview Session 2014

Agenda 0800 to 1200 – FOUNDATIONAL TOPICS – A BASELINE UNDERSTANDING q Welcome, Purpose

Agenda 0800 to 1200 – FOUNDATIONAL TOPICS – A BASELINE UNDERSTANDING q Welcome, Purpose of the Class, Agenda Review q Introductions, Roles, Experience Level, Goals for Class q Introduction to Do. D ESI q Information Technology (IT) Industry Overview & Ecosystem q Intellectual Property (IP) Introductory Concepts q Privity / Software Publisher & Reseller Business Models q Software Publisher Products and Services 2

Agenda 1300 to 1600 q Pricing and License Models q Services Overview q Source

Agenda 1300 to 1600 q Pricing and License Models q Services Overview q Source Code Escrow q Preparing for the Acquisition q Building the Team q Requirements q Negotiating Strategy q Ordering from ESI – if time permits 3

Agenda Day 2: Dive into the core components of a Software License Agreement MORNING

Agenda Day 2: Dive into the core components of a Software License Agreement MORNING AFTERNOON q Key Clauses in a Software License Agreement q Panel Discussion q License Grant q Pricing q Warranty q Maintenance and Support q General Provisions q Structural Considerations q ITAM / SAM q ESI Tools 4

Do. D ESI Team / Instructor Introductions Suzi Ellison| Enterprise Agreements Manager Over 25

Do. D ESI Team / Instructor Introductions Suzi Ellison| Enterprise Agreements Manager Over 25 years of engineering, acquisition and leadership experience with U. S. Navy combat systems and subsystems. Navy Lead SPM for Do. D ESI. Program Manager for the IT Umbrella Program. Experienced in system acquisition and life cycle planning of Navy programs including all phases of program management, budget preparation and execution. Tom Crawford | IT Contracting SME, Contract Support to Do. D ESI 20+ years in senior executive positions and consulting roles including Do. D ESI. Previously VP at SAP, People. Soft, Oracle, and BMC. Former CEO of Cyber-Ark. Served in the U. S. Navy after graduating from the U. S. Naval Academy. John Zettler | Pricing & Contract SME, Contract Support to Do. D ESI 30+ years in government contract costing, pricing, and program financial management, with particular expertise in IT services and enterprise software acquisition. Maintains a TS/SCI Clearance. Dee Wardle | Software Licensing SME, Contract Support to Do. D ESI 30+ year expert in software licensing for Do. D Services and Agencies mostly with the U. S. Army. Former Software Division Chief for the Computer Hardware Enterprise Software & Solutions (CHESS) Program and Program Executive Office Enterprise Information Systems (PEO EIS). Served Federal Smart. BUY Programs and the Do. D ESI Program. 5

Class Introductions: Name Organization Core Responsibilities Goals for Class / Hot Topics Attended a

Class Introductions: Name Organization Core Responsibilities Goals for Class / Hot Topics Attended a Prior Do. D ESI Class or Webinar? 6

Introduction to the Do. D Enterprise Software Initiative (ESI) Prepared by Do. D ESI

Introduction to the Do. D Enterprise Software Initiative (ESI) Prepared by Do. D ESI | August 2014

Do. D ESI’s Mission 8

Do. D ESI’s Mission 8

9

9

10

10

Organizational Structure 11

Organizational Structure 11

Training Strategy for Do. D ESI 12

Training Strategy for Do. D ESI 12

FOUNDATIONAL CONCEPTS (Before Diving into the Contractual Impacts) Prepared by Do. D ESI |

FOUNDATIONAL CONCEPTS (Before Diving into the Contractual Impacts) Prepared by Do. D ESI | August 2014

1. 0 The IT Industry Prepared by Do. D ESI | August 2014

1. 0 The IT Industry Prepared by Do. D ESI | August 2014

Overview: Industry Overview / Spend Analysis Hardware e Softwar Services Global Spending (Gartner Outlook)*

Overview: Industry Overview / Spend Analysis Hardware e Softwar Services Global Spending (Gartner Outlook)* 2013 $809 B** $300 B $922 B 2014 $840 B $320 B $963 B % ‘ 14 39% 15% 46% Federal Government Spending (est. using same % as Global Spending)*** 2014 $32 B $13 B $37 B % ‘ 14 39% 15% 46% * Does not Include Telecommunications Spending ** Includes Devices and Data Center Spending *** Fed IT Spending ($82 B in 2014) expected to decrease by 2 -3% per year next few years 15

Overview: Industry Overview / Ecosystem The Key Players & Roles Customers Industry Analysts Hosting

Overview: Industry Overview / Ecosystem The Key Players & Roles Customers Industry Analysts Hosting Partners Resellers Publishers Hardware Partners System Integrators Escrow Agents Software Partners 16

2. 0 Intellectual Property Prepared by Do. D ESI | August 2014

2. 0 Intellectual Property Prepared by Do. D ESI | August 2014

Overview: Intellectual Property – Protection Methods Four Ways to Protect IP Patents protect rights

Overview: Intellectual Property – Protection Methods Four Ways to Protect IP Patents protect rights for inventions, up to 20 years. Trademarks protect words, names, symbols for as long as they are being used in business. Copyrights protect works of authorship (e. g. writing, music, art, software) tangibly expressed. Trade Secrets protect competitive advantages. Software Industry Examples Software algorithms Logos, icons, corporate name Source code, screen layouts Customer lists 18

Overview: Intellectual Property Protection Methods for Software Source Code (Human Readable – Secret Recipe)

Overview: Intellectual Property Protection Methods for Software Source Code (Human Readable – Secret Recipe) Object Code (Machine Readable) License Agreement Maintenance Parties, Grant of License, Quantity, Duration, Permitted Use, Price, Warranty, Remedies Bug Fixes, Patches, Updates 19

Overview: Intellectual Property – Source v. Object Code Examples Source Code (Human Readable –

Overview: Intellectual Property – Source v. Object Code Examples Source Code (Human Readable – Secret Recipe) Object Code (Machine Readable) import javax. servlet. http. Http. Servlet. Request; Import org. springframework. beans. factory. annotation. Au towired; @Controller public class Guest. Controller • Binary code 0100001001010010000001110011010 10111001001 • Binary opened in terminal output ^@^@^@<BC><BB><FC><^@^@^@^@^@^@METAINF/PK^C^D • Binary converted to hex 0000 50 4 b 03 04 0 a 00 00 00 bc bb fc 3 c 00 00 |PK. . . <. . | 00000010 00 00 00 09 00 00 00 4 d 45 |. . . ME| 20

Overview: Intellectual Property - Ownership Rights Developer Who Owns These IP Rights? Development Tools

Overview: Intellectual Property - Ownership Rights Developer Who Owns These IP Rights? Development Tools = Developer Property (ala Toolbox) Publisher Customer Resale May Be Restricted Rights Can Be Jointly Owned (e. g. Core COTS SW Application Licensed for Commercial Use) COTS (Design, Development, Test & Deployment) Hybrid or Derivative Works Custom Development (Work for Hire) 21

Overview: Intellectual Property – Derivative Works Sample Book to screenplay example Book Screenplay Movie

Overview: Intellectual Property – Derivative Works Sample Book to screenplay example Book Screenplay Movie Nothing Lasts Forever Roderick Thorp Screenplay by Lawrence Gordon Joel Silver Produced by Steven E. de Souza & Jeb Stuart Extra credit – Name the Movie!! Derivative Work: Requires original author’s approval to write a screenplay based on the book or to make a movie based on her book. § § § What makes one piece of work a derivative of another? With books, it might be the plot, the characters or some other identifiable IP. Would a movie about sharks terrorizing swimmers infringe on the IP in Jaws? Would a restaurant named Mickey Dee’s with yellow arches infringe on Mac. Donald’s” How do these examples work in the software industry? ? 22

3. 0 Publisher & Reseller Business Models (FROM WHOM ARE WE BUYING? ) Prepared

3. 0 Publisher & Reseller Business Models (FROM WHOM ARE WE BUYING? ) Prepared by Do. D ESI | August 2014

Reseller & Publisher Relations Who is authorizing the use of the software? 24 24

Reseller & Publisher Relations Who is authorizing the use of the software? 24 24

Publisher Model / Contracting Methods Impacts on Privity of Contract Privity with the Publisher

Publisher Model / Contracting Methods Impacts on Privity of Contract Privity with the Publisher No Privity with the Publisher DIRECT SALES INDIRECT SALES Publisher VAR/Distributor System Integrator Hardware Vendor Customer Field Sales Inside Sales On-line Sales Tele-sales Customer Examples of Contract Provisions Where Privity Matters: • License Grants • Warranty • Transferability of Licenses • Level 3 Support • Source Code Escrow • IP Indemnification • Ownership of Derivative Works 25

Publisher Model / Contracting Methods GSA’s Approach to Publishers, Resellers & Privity 1 GSA

Publisher Model / Contracting Methods GSA’s Approach to Publishers, Resellers & Privity 1 GSA 2 GSA Publisher GSA deals directly with Publishers when possible, thereby creating privity with them. Reseller Letter of Supply GSA also deals directly with Resellers and often accepts letters of supply as a means of tying Reseller promises to Publishers. Since GSA does not consider most of the IP related Ts and Cs to be within their scope of responsibility, the FSS agreements with Publishers do not address those topics – or the Publisher ensures IP related Ts and Cs in FSS agreements are favorable to Publisher. 26

Publisher Model / Contracting Methods ESI’s Approach to Publishers, Resellers & Privity 1 2

Publisher Model / Contracting Methods ESI’s Approach to Publishers, Resellers & Privity 1 2 ESI IP Agreement EULA Publisher 1. ESI seeks to have Publishers sign EULAs to ensure privity for all promises in EULAs. EULA Reseller Publisher 3 Agreement between Pub and Reseller 2. ESI deals directly with Resellers. ESI seeks to have the Publisher sign along with the Reseller. If the Publisher will not sign the EULA, ESI seeks privity with Publisher for the key IP related terms in a document signed by Publisher. 3. If Publisher will not sign a document creating privity for IP issues, ESI seeks to incorporate the Publisher agreement with its Resellers into the ESI EULA with the Resellers. Obtain a copy of the agreement between the Publisher and its Resellers where Publisher authorizes Resellers to sell licenses, extend warranties, etc. Attach that agreement to the EULA with the Reseller and add a paragraph that incorporates it into the EULA. This is reasonable evidence of Publisher’s intentions. 27

Publisher Model / Contracting Methods Competition Among Resellers ESI When a single brand is

Publisher Model / Contracting Methods Competition Among Resellers ESI When a single brand is selected and a J&A is obtained, competition is achieved by soliciting bids from multiple Resellers. Reseller 1 Resellers This competition is far less advantageous to the government than competition among Publishers. 28

Publisher Model / Contracting Methods Agents and Dealers GSA Reseller Publisher A. Some Resellers

Publisher Model / Contracting Methods Agents and Dealers GSA Reseller Publisher A. Some Resellers use agents or dealers to fulfill orders and request that the government pay the agent or dealer. Agent / Reseller This introduces two potential problems: 1. Privity is further removed from the Publisher 2. The agent or dealer may not have a contract with the government or a CAGE code to enable payment. B. ESI seeks to avoid dealing with agents or dealers. Resellers might use them for order fulfillment, but the Reseller (or preferably the Publisher) must remain responsible for promises in the EULA and must take payment. 29

Revenue Recognition – a Frequently Used Objection • Revenue of publicly traded software companies

Revenue Recognition – a Frequently Used Objection • Revenue of publicly traded software companies is closely scrutinized by the SEC. • Private companies have no basis to use rev rec. as an excuse to avoid discounting. • For a publicly traded Software Publisher to recognize revenue immediately upon sale (and not ratably over time) certain conditions must be met. – Signed contract or formal agreement, with a fixed price, non-refundable provisions, and a high probability of collection. – Software must be delivered in usable format, accessible to end user. – No significant modifications required, no promise of future functionality, no promise of future products, and no deal-altering contingencies. – Software performance guarantee limited to standard warranty and acceptance that software will perform according to Publisher’s documentation. – Implementation and consulting service performance cannot be tied to acceptance, return, or payment for the software licenses. 30

Revenue Recognition – a Frequently Used Objection • VSOE – Vendor Specific Objective Evidence

Revenue Recognition – a Frequently Used Objection • VSOE – Vendor Specific Objective Evidence – is a revenue recognition mechanism to prevent inconsistent pricing and discounting from favoring certain classes of revenue. – Funneling revenue to software licenses can make the company look more valuable than it is. • Why should you care? – Rev rec is often used as a negotiating tactic to say no to requests for discounts and certain Ts and Cs. – Very few software sales people or executives understand VSOE. – It is often a smokescreen. • Two easy responses – Ask for specifics about how your discount or term violates VSOE. – Ask why your deal can’t be one of the 20% permitted to be outside of VSOE range. 31

VSOE – Vendor Specific Objective Evidence • General Rule – 80% of the time,

VSOE – Vendor Specific Objective Evidence • General Rule – 80% of the time, the price must be within a band that is plus or minus 15% of the average price range for a product Upper VSOE Limit $1150 +15% Actual average high price $1000 Actual overall Average price $800 Actual average low price $500 Lower VSOE Limit $425 -15%

Sales Compensation Based on Commission • Most U. S. sales people paid “on commission”

Sales Compensation Based on Commission • Most U. S. sales people paid “on commission” (base salary plus a percentage of sales). • If you don’t sell, you don’t eat. • Software firms attract top sales personnel by offering significant compensation based largely on performance. Sales Compensation Plan Incentives • Sales people are incented to be more aggressive based on compensation plans. • Leverage is associated with sales aggressiveness. • Low base pay/high sales compensation = highly leveraged. • High base pay/low sales compensation = not highly leveraged. 33

Reseller & Publisher Relations- Pricing / Discounts Publishers may: • Offer same discounts to

Reseller & Publisher Relations- Pricing / Discounts Publishers may: • Offer same discounts to all resellers. • Be consistent and level the playing field. • Reward the Reseller with the best sales execution. • Offer volume discounts to top resellers. Resellers usually: • Compete on their “pass-through” • Get additional discounts on larger deals as “one-off” deals. • Get exclusive treatment when they “find” the sale. • Get same price from Publisher in response to RFP. 34 34

Example of Publisher Discount to Reseller & Reseller Pricing to Customers 1. List Price

Example of Publisher Discount to Reseller & Reseller Pricing to Customers 1. List Price from Publisher = $10, 000 4. Reseller Mark-ups & Prices A 20% on $6, 000 = $7, 200 B 15% on $6, 000 = $6, 900 2. Discounts are extended by Publisher to Resellers A, B & C C 20% on $5, 500 = $6, 600 A 3. Standard discount to Resellers A & B = 40% so price to A & B = $6, 000 4. Volume Discount to Reseller C = 45% so price to C = $5, 500 B Conclusion: C Reseller C is able to earn a 20% mark-up and win with low price because of a volume discount from the Publisher. 35

ACQUISITION-CENTERED CONCEPTS (What are you Buying? ) Prepared by Do. D ESI | August

ACQUISITION-CENTERED CONCEPTS (What are you Buying? ) Prepared by Do. D ESI | August 2014

4. Products & Services Prepared by Do. D ESI | August 2014

4. Products & Services Prepared by Do. D ESI | August 2014

Products & Services: SOFTWARE COMPONENTS SOFTWARE LICENSED PRODUCTS MAINTENANCE & SUPPORT SERVICES OUTSOURCING (e.

Products & Services: SOFTWARE COMPONENTS SOFTWARE LICENSED PRODUCTS MAINTENANCE & SUPPORT SERVICES OUTSOURCING (e. g. Cloud/Saa. S) The type of product you are buying impacts the agreement structure and terms 38

Agreements Involved in COTS SW Life-Cycle Licensed Products Maintenance & Support Agreement Services -

Agreements Involved in COTS SW Life-Cycle Licensed Products Maintenance & Support Agreement Services - Implementation / Training (or) Contracted Assurances Agreement Outsourcing / Hosting / Service Level Agreements (SLA) 39

Products & Services: Product Categories - Overview COTS LICENSED PRODUCTS* SYSTEMS Operating Systems Utility

Products & Services: Product Categories - Overview COTS LICENSED PRODUCTS* SYSTEMS Operating Systems Utility Programs PROGRAMMING & TOOLS Software Development Kits Middleware BUSINESS APPLICATIONS Enterprise / Complex Shrink Wrap / Ready to Use DATABASES Processing Storage Some Assembly Required Open Source Windows Linux Oracle Fusion Middleware IBM Web. Sphere JBoss Enterprise Open Source Microsoft Office SAP Logistics Siebel CRM Oracle Microsoft SQL Server IBM DB 2 Sybase (SAP) * Products can also be custom built. The focus of this course is the COTS licensed software. 40

Products & Services: Product Categories – Business Applications Enterprise Shrink Wrap Definition Examples of

Products & Services: Product Categories – Business Applications Enterprise Shrink Wrap Definition Examples of Applications Examples of Publishers • Comprehensive set of software • Focused on a purposecapabilities for an enterprise. specific set of capabilities— • Usually addresses missionoften a tool or an critical business requirements. administrative application. • Provides significant flexibility • Can be used across an but requires extensive enterprise, but usually not configuration. mission-critical. • Financial accounting • Logistics • HR • SAP • Oracle Note: ratio of money spent 1 -4 vs. 1 -15 • Microsoft Office—Word, Excel, Power. Point • Adobe—Acrobat, Reader, Live. Cycle Designer, Distiller • Trend Micro—Office Scan • Microsoft • Adobe 41

Open Source Code is open for the world to see and use (with some

Open Source Code is open for the world to see and use (with some restrictions or caveats) 0 = 1 = 2 = 3 = Cost None Yes EULA? No Yes Yes Obligations of Users None Share enhancements Rights to Use Unlimited Limited Unlimited Open Source 42

Open Source and Third Party Software Licenses • Open Source (OS) and proprietary third

Open Source and Third Party Software Licenses • Open Source (OS) and proprietary third party software (TPS) can be obtained with the primary software application (PS) being licensed in two ways: – As separately licensed software – As embedded software • The embedded software case creates potential liability for the Government. Separately licensed Embedded software Licensee PS PS OS /TPS OS/TPS 43

Open Source Code and Third Party Software • How Publishers Use Open Source –

Open Source Code and Third Party Software • How Publishers Use Open Source – Some are well-known stand-alone apps • (e. g. Mozilla Firefox, Apache, Linux, Open. Office, etc. ). • They can work in concert with other applications without becoming embedded in copyrighted applications. – Other applications (or lines of code) have found their way into products published by commercial software companies who copyright their applications and sell licenses to their IP. – In both cases, Publishers of copyrighted software must use caution to avoid violating the Open Source standards and license provisions. – Third Party Software – Publishers sometimes incorporate proprietary software from other commercial publishers or Open Source into their licensed IP. – Both situations can be labeled as Third Party Software (TPS) 44

Contract Concerns with Open Source Code & Third Party Software • Clauses recommended by

Contract Concerns with Open Source Code & Third Party Software • Clauses recommended by ESI to protect against IP Infringement of TPS – Make sure the EULA includes the following covenants from the Publisher: • Disclosure of all third party software (TPS) including Open Source. • Publisher has the right to use the TPS in the way it has been used with Publisher’s IP. • No additional licenses or fees required to use the licensed or third party software. • Publisher warrants performance of its IP and the TPS included with its IP. • No obligation to share enhancements or derivative works of licensed software or included third-party software. • Other OS Considerations – No Maintenance and Support Infrastructure • Since Open Source is collaboratively developed and peer reviewed, there might be no formal infrastructure for providing fixes, patches, enhancements and updates. – “Encapsulation” can be used to isolate Open Source code from copyrighted IP. 45

4. Products and Services: Maintenance & Support Prepared by Do. D ESI | August

4. Products and Services: Maintenance & Support Prepared by Do. D ESI | August 2014

Maintenance & Support - Overview Maintenance Support Services Designed to provide customer access to

Maintenance & Support - Overview Maintenance Support Services Designed to provide customer access to the ongoing enhancements and fixes created. by the Publisher Established to report software deficiencies or malfunctions and to receive corrections or fixes. • Fixes & Patches to Bugs (1. 0. 1) - (Publisher develops; customer applies. ) • Updates (1. 1) • Upgrade / New Release / Version (2. 0) • Support Levels and Process (Who receives, diagnoses, and fixes problems? ) • Issue Severity Levels • Response Times Maintenance fees are used by Publishers to fund development of fixes and new releases. Most Publishers offer increasing levels of support at increasing prices. 47

Software Versions Nomenclature and Numbering Nomenclature Description Numbering Scheme Upgrade /New Version New functionality

Software Versions Nomenclature and Numbering Nomenclature Description Numbering Scheme Upgrade /New Version New functionality and improved features. (Always ensure that a new version is covered under annual maintenance, at no charge. ) Usually represented by a new number in front of the decimal point. (i. e. 3. 0 becomes 4. 0) Update A release with enhanced features and consolidation of all prior bug fixes. Often represented by a change one place to the right of the decimal point. (i. e. 4. 1 becomes 4. 2) Corrects issues, errors, and bugs in previous release of the same version. Often represented by a change two decimal places to the right of the version number. (i. e. 4. 2. 1 becomes 4. 2. 2) Bug Fix/Maintenance Release/Patch 48

Important Issues for the Government re Maintenance Opting out of Maintenance may save money

Important Issues for the Government re Maintenance Opting out of Maintenance may save money in the short term, but probably not in the long term. The color of money can be important – is Maintenance a Product or a Service? Publishers may try to release a major change/version as a “New Product”, not included under S/W Maintenance and requiring new license fees. Also watch for combining existing programs into a “New Product”. Example; separate programs a, b, and c get combined into product D, which must be bought if you don’t already license all three (a, b, and c). Check with Industry Analysts to determine whether these practices are acceptable industry-wide. 49

Maintenance & Support Agreements SLAs for Response Time to Reported Issues • Refers to

Maintenance & Support Agreements SLAs for Response Time to Reported Issues • Refers to the requirement imposed on the Contractor for responding to Customer reports of deficiencies. • Usually contained in packaged offerings from Contractor with response tied to severity of the issue. SLAs for System Performance • Refers to system performance as delivered by a hosting provider. • Usually expressed as a percentage of system availability out of total potential availability. • Levels of service can vary significantly. Selecting the Right Package • Because higher SLAs can be expensive, the Customer should weigh carefully the need for quick response time or substantial availability. 50

4. Products and Services: Outsourcing / Cloud and Software as a Service (Saa. S)

4. Products and Services: Outsourcing / Cloud and Software as a Service (Saa. S) Prepared by Do. D ESI | August 2014

Outsourcing Hosting / ASP / MSP Models Cloud Iaas, Paa. S, Saa. S 52

Outsourcing Hosting / ASP / MSP Models Cloud Iaas, Paa. S, Saa. S 52

Timeline to Cloud/Saa. S 53

Timeline to Cloud/Saa. S 53

Cloud Deployment Models Public Community Private Hybrid Off premise at provider On or off

Cloud Deployment Models Public Community Private Hybrid Off premise at provider On or off premise General public Multiple, related organizations Limited to a single organization Determined by each cloud Users’ concerns and purposes vary Users share the same concerns Used by various business units Users’ concerns and purposes vary 54

What Does it Mean to Deploy to the Cloud? • True or False—cloud computing

What Does it Mean to Deploy to the Cloud? • True or False—cloud computing and Saa. S are synonymous. • True or False—a perpetual license can be deployed to the cloud. • Cloud computing requires which of the following? – Internet connections – Virtualization – Saa. S licenses – Remote data storage – A special operating system 55

The Cloud’s Impact on Licensing On Premise Infrastructure Applications Data Runtime Middleware O/S O/S

The Cloud’s Impact on Licensing On Premise Infrastructure Applications Data Runtime Middleware O/S O/S Virtualization Servers Storage Networking You Manage Data You Manage Applications Managed By Vendor Servers O/S Virtualization Managed By Vendor Applications Managed By Vendor (as a Service) Middleware (as a Service) Software (as a Service) Runtime You Manage Platform Servers Storage Networking 56

Licensing Considerations – Perpetual versus Saa. S Factor Payment Perpetual License One-time payment at

Licensing Considerations – Perpetual versus Saa. S Factor Payment Perpetual License One-time payment at delivery Saa. S License Usually subscription based License Duration Into perpetuity – a permanent fixture Use while subscription is current – like a utility Physical Custody Yes No Customizations At Licensee discretion At Licensor discretion Security Depends on Licensee or subcontractor Depends on Licensor skills Data Ownership Licensee owns data & has custody & control Licensee owns data but may not have custody or control SLAs Vendor response to issues only Vendor response to issues and to system availability Hosting Location Usually on premises but can be outsourced Usually off premises Upgrades Applied at Licensor’s discretion Applied at Licensee’s discretion 57

Why Use the Cloud? • Aside from the OMB mandate, what are key business

Why Use the Cloud? • Aside from the OMB mandate, what are key business reasons for deploying to the cloud? Cost Reduction Greater Mobility Speed & Flexibility Heightened Security Easier Collaboration • Each of these factors may be valid, but we should examine them in detail. 58

Pricing Comparison Example – Saa. S Versus Perpetual Price Technology Stack Saa. S Price

Pricing Comparison Example – Saa. S Versus Perpetual Price Technology Stack Saa. S Price $1 million Application $250 K per year What happens after year 4? $ 150 K per year Data Management $ 200 K Runtime $ 100 K Middleware $ 50 K O/S $ 50 K Virtualization $ 300 K Servers $ 200 K Storage $ 100 K allocated per year Networking $100 K per year There are potential savings in each of these categories with Saa. S $ 150 K because of shared resources and $ 75 K virtualization BUT 1. Does the Government already $ 40 K own any of these resources? $ 40 K 2. Are they available for this $ 75 K application? 3. If so, will those resources go $ 100 K away or be deployed for $75 K another application? 4. If not, will the Government pay twice? 5. What happens when there are $75 K multiple Saa. S licenses with multiple vendors ? $100 K allocated Facilities per year Issues 59

Other Factors to Consider About Cloud Benefits • Flexibility – Switching Saa. S vendors

Other Factors to Consider About Cloud Benefits • Flexibility – Switching Saa. S vendors could be less costly than switching perpetual vendors, but… • …would it be as easy to switch email providers as it would be to switch ERP Saa. S vendors? – What about customizations? – What about control over the timing of upgrades? – Is virtualization limited to the cloud? – How do you put a price on flexibility gained or lost? 60

Other Factors to Consider About Cloud Benefits • Heightened Security – Even if all

Other Factors to Consider About Cloud Benefits • Heightened Security – Even if all infrastructure is outsourced, does it make sense to outsource data security? – Is data outside of the Government’s custody as secure as data that is in the Government’s custody? – What about security of the Vendor’s premises? What about their supply chain? • Analytical Approaches – A consistent approach to analyzing prices and internal costs is a mandatory prerequisite to gauging cost savings. – Should savings be measured on a deal basis or a collective basis? 61

Key Cloud/Saa. S License Considerations • SLAs • Dependence on the Vendor makes SLA

Key Cloud/Saa. S License Considerations • SLAs • Dependence on the Vendor makes SLA clauses extremely important • Ensure measureable performance standards for system up time and issue response are clear. • Upgrades • If the timing of upgrades is important, include the right to delay upgrades at your discretion. • Customizations • If you know customizations will be required, ensure there is a clause addressing your right to have customizations in your instance of the software. • Some licenses claiming to be Saa. S are not true Saa. S applications. • One large software Publisher requires customers to download software instead of remotely accessing it – and they require system access for monitoring. • Government funding might impact multi-year subscriptions. • What happens to your Saa. S app if year 2 funding disappears? 62

4. Products and Services: Pricing Models and Methods Prepared by Do. D ESI |

4. Products and Services: Pricing Models and Methods Prepared by Do. D ESI | August 2014

License Models & License Pricing • There are two primary license models – Perpetual

License Models & License Pricing • There are two primary license models – Perpetual and Term y • A Perpetual License means the license is owned into perpetuity. The full price is usually paid at delivery. • A Term License means the license is owned for a specific period of time. The price is often paid in annual increments, also referred to as Subscription Licenses - often used for Saa. S licenses. Perpetual license Price = $1 million invoiced at delivery t = infinity Key take-away Subscription License – Four year term Price (software component) = $250, 000 annually t=0 Yr 1 Yr 2 Yr 3 If your time horizon for the license is not the same as the pricing model used by the Vendor, you might overpay significantly. Yr 4 64

License Types – Duration-Based Models Perpetual/On Premises Term/On Premises Subscription/O ff Premises Duration No

License Types – Duration-Based Models Perpetual/On Premises Term/On Premises Subscription/O ff Premises Duration No time limit Term is limited Who has possession of software? Customer Vendor Who is responsible for IT environment? Customer Vendor Who is responsible for software maintenance? Customer Vendor 65

License Pricing Models – Basic Approach Duration Specified Term Perpetual Month | Year Forever

License Pricing Models – Basic Approach Duration Specified Term Perpetual Month | Year Forever Who Can Use? Count & Scope Named User Processor / Core Based Concurrent User Note: Virtualization and Unlimited Issues Site Enterprise e Only this individual may use this license (e. g. , professional, self service) Anyone can use these set number of licenses as long as no more than x use them at the same time Based on number of processors or cores in CPU Licenses may only be used at this geographic location E E Licenses may be used across the enterprise as defined in the agreement On Customers Premises How Managed / Delivery Model Customer’s Servers On Vendors Premises (Public Cloud) Hybrid Private Cloud 66

Pricing Methods and Pricing Analysis • Imagine you have started a new software company

Pricing Methods and Pricing Analysis • Imagine you have started a new software company and have your first product to license. How much should you charge for it? • How software companies determine pricing – Traditional • actual development cost plus overhead and profit – Value based • what is the actual value to the customer – Relative value • what is the value of application X versus application Y – Market based • what does company X charge for application X compared with our company’s software which is equivalent to application X – Most companies use a combination of these pricing methods • Thorough price analysis should incorporate all Vendor pricing approaches 67

4. Products and Services: Services Prepared by Do. D ESI | August 2014

4. Products and Services: Services Prepared by Do. D ESI | August 2014

Services Implementation (Systems Integration) • • Business Process Design Software Configuration Interfaces Enhancements Training

Services Implementation (Systems Integration) • • Business Process Design Software Configuration Interfaces Enhancements Training • • Project Team End User Classroom On-Site Help Desk For Issue Resolution • Level 1 – Easy • Level 2 – Moderate • Level 3 -- Difficult 69

Key Contract Elements Commercial-off-the-shelf (COTS) Software Program Select Software First – Before Selection of

Key Contract Elements Commercial-off-the-shelf (COTS) Software Program Select Software First – Before Selection of Systems Integrator Software License and Maintenance Agreement Input 1. 2. 3. Number of Users # & Location of Sites Requirements 1. Gap Analysis from SW Vendor Software Modules that Fit List of Services Needed from SI Output 2. 3. optional BUYER Hardware / Equipment Order Hosting or Outsourcing Systems Integration / Software Implementation Enterprise Software / COTS that requires configuration, implementation, and interfaces 70

Software Implementation Models Enterprise Software Seller, System Integrator, & Customer • Most Common Model

Software Implementation Models Enterprise Software Seller, System Integrator, & Customer • Most Common Model • Most Successful Model System Integrator & Customer Software Seller & Customer • Least Successful Model • Least Common Model 71

System Integration Services For Typical Commercial-off-the-shelf (COTS) Software Hardware & Networking User rts o

System Integration Services For Typical Commercial-off-the-shelf (COTS) Software Hardware & Networking User rts o p Re Se Data Base cu re Data Migration/ Conversion Interfaces Legacy Systems Software Ac ce ss Extensions / Bolt-On Apps Business Process Reengineering Requirements Development Configuration or Development Security & Controls Testing Post. Implementation Support Project Management Change Management / Training / Communications Support / Preparation / Participation in Reviews / Milestone Decisions / Oversight / Certifications / Regulatory Compliance 72

Software Implementation Capabilities & Requirements Adoption of Best Practices as Directed by Standard (out-of-the-box)

Software Implementation Capabilities & Requirements Adoption of Best Practices as Directed by Standard (out-of-the-box) Functionality of COTS/ Enterprise Resource Planning Software Reports Interfaces (non-standard) (to/from continuing systems) Data Conversions (from retiring systems) Extensions (functions not covered in COTS solution) 73

Pricing Tied to Project Phases IMPLEMENTATION RFQ / RFP / SOO Phases follow a

Pricing Tied to Project Phases IMPLEMENTATION RFQ / RFP / SOO Phases follow a proven methodology Preparation Blueprint Build Award FFP Task Order No. 1 Transition / Cutover Go Live FFP Task Order No. 2 Option with Fixed Unit, Not-To-Exceed, or +/- XX% Pricing for Design thru Go-Live* HYBRID PRICING T&M Task Order No. 1 FFP Task Order No. 2 IV & V RFQ=Request for quote, RFP=Request for proposal, SOO=Statement of objectives, FFP=Firm Fixed Price 74

Price for Performance Table Tied to Methodology Phase: Baseline Price Tables Aligned With Methodology

Price for Performance Table Tied to Methodology Phase: Baseline Price Tables Aligned With Methodology Blueprint Services to be Performed by Contractor Deliverable(s) Duration (or due date) Acceptance Criteria Payment Upon Acceptance Perform Process & Functional Gap Analysis and Document Proposed Resolutions. Detailed Gap Analysis Report including proposed resolutions. 4 weeks. The documented deliverable shall conform to the format and structure of the sample attached as Attachment D-6. $42, 500 Sample Performance-Based Holdback Deliverable Change Management Plan Deliverable Price $100, 000 Payment Upon Acceptance $90, 000 10% Holdback $10, 000 Performance Scorecard Summary Payment Based on Performance Scorecard Exceeds. $15, 000 Meets. $10, 000 Does not meet. $0 75

Government Duties Avoid Assumptions • Assumptions are a common cause for confusion, failure, delay

Government Duties Avoid Assumptions • Assumptions are a common cause for confusion, failure, delay and avoidable change orders. • Force clarity of buyer duties and scope conditions as early as possible. • Establish list of expected buyer duties in RFQ/RFP and obtain bidder validation or expansion of list in proposals (including government personnel needed—by role and cost). • Identify buyer duties, by milestone or deliverable, and across all phases. • Don’t expect vendors to volunteer resolution of assumptions—they’ve been used for many years. Examples of Language to Use • “Provide a Project Manager who will … (or) Provide staff resources who …” • “Provide all hardware, software …” (or) “Provide office space, telecommunications, …” • “Provide documentation of business processes …” (or) “Document data and database file structure …” • “Perform data and file cleanup on legacy systems…” (or) “Stage legacy system data for conversion …” • “Conduct User Acceptance test …” • “Limited hosting is restricted to hardware, security, connectivity, networking aspects of IT environment. ” Milestone Services to be Performed by Contractor Deliverable Detailed Deliverable Description Buyer’s Duties 76

SPECIAL TOPICS (IF TIME PERMITS) 4. Software Source Code Escrow Prepared by Do. D

SPECIAL TOPICS (IF TIME PERMITS) 4. Software Source Code Escrow Prepared by Do. D ESI | August 2014

Overview • Source Code is the human readable form of software as written by

Overview • Source Code is the human readable form of software as written by the Publisher while Object Code is the machine readable form delivered to customers. • Object Code protects the Publisher’s IP. Source Code may be needed by Customers under certain circumstances (e. g. , Publisher goes into bankruptcy) to maintain licensed software. • An escrow agreement with a neutral third party gives Publishers and Customers assurance that their respective interests are protected. • The escrow agreement specifies the events which could trigger a release of the Source Code to the Customer. • The license Customers obtain to released Source Code is usually limited to a right to use it for maintenance and enhancement of their production system. 78

Source Code Escrow—Balancing Interests 4. Escrow Agent Es d u n So di en

Source Code Escrow—Balancing Interests 4. Escrow Agent Es d u n So di en t t) en (in 3. 2. Publisher s C a e pd rc g U clu 5. e v od r E C ge ce rig ur y T So ed b 4. m ea cr Es Ag el ow e ) od tes Ag re e (R e m e re cr ow ec x E nt e ut 1. 4. Ex e cu t 6. ed 4. Object Code Escrow Required EULA Executed Licensee / Beneficiary Escrow Agreement Executed 79

Source Code Escrow Considerations • • • Custom Software < 2 Years in the

Source Code Escrow Considerations • • • Custom Software < 2 Years in the market Mission Critical Low market share Low number of installations Software Type & Mission • • • COTS > 5 years in the market Not mission critical High market share Large number of installations Publisher Longevity & Stability >5 years. ………. >15% of Sales. … High. …… Moderate. ……… High. . …………… Balanced. . . Years in Business Net Income Earnings per Share Price-to-Earnings Ratio D&B Rating License v. Service Revenue . . …. . . < 2 years. . . < 5% of sales. . ………. …. Low. . ………. … High. . …………. . Low …. . High license v. service 80

5. PREPARING FOR THE ACQUISITION Building a Team; Gathering Requirements; Issuing a Solicitation; Creating

5. PREPARING FOR THE ACQUISITION Building a Team; Gathering Requirements; Issuing a Solicitation; Creating a Negotiating Strategy. Prepared by Do. D ESI | August 2014

Acquisition Process Flow ACQUISITION LIFE-CYCLE Build the Team Requirements / Market Research Strategize Issue

Acquisition Process Flow ACQUISITION LIFE-CYCLE Build the Team Requirements / Market Research Strategize Issue Solicitation Evaluation & Negotiation Contract Management / Issue Resolution Acceptance 82

5. 1 BUILDING THE TEAM Prepared by Do. D ESI | August 2014

5. 1 BUILDING THE TEAM Prepared by Do. D ESI | August 2014

The Government Team & Their Involvement in the Process 84

The Government Team & Their Involvement in the Process 84

Key Software License Negotiation Players Software & Services Sellers Publishers Resellers Integrators Do. D

Key Software License Negotiation Players Software & Services Sellers Publishers Resellers Integrators Do. D PM & Technical Team Software Product Managers Contracting Officers Government Software & Services Buyers 85

Sales Process As Aligned to Do. D Acquisition Process Software Sales Process Do. D

Sales Process As Aligned to Do. D Acquisition Process Software Sales Process Do. D Acquisition Process • Identify Customer Requirement • Determine Requirement Exists • Provide Product Data • Gather Data on Requirements Fit • "Sell" the Customer on Products • Determine How Much Customer Can/Will Pay and Products • Establish Best Solution for Requirement • Identify and Work any $ or Terms Issues • Establish Budget and Funding Sources • Establish "Must Have" • Determine Acquisition Vehicle Ts & Cs and $ Ceiling • Negotiate Price and Ts & Cs • Determine Contract to be Used • Execute Order • Negotiate Price and Ts & Cs • Ensure all Programs Delivered • Obtain Approvals and Sign Contract Order • Accept Products Note: There are hundreds of variables in each Process 86

5. 2 GATHERING REQUIREMENTS Prepared by Do. D ESI | August 2014

5. 2 GATHERING REQUIREMENTS Prepared by Do. D ESI | August 2014

Requirements Fit with Acquisition and Contracting ACQUISITION LIFE-CYCLE Build the Team Requirements / Market

Requirements Fit with Acquisition and Contracting ACQUISITION LIFE-CYCLE Build the Team Requirements / Market Research Requirements Document Strategize Issue Solicitation Evaluation & Negotiation RFP / RFQ Determine Solution Fit % & RICEF Needs Contract Attach to Contract / Warranty for License and SI Contract Management / Issue Resolution Use to Resolve Conflicts / Defects (Software v. SI) Acceptance Use in Acceptance Tests for Software and System Integration 88

What Are Requirements? – The identification of your issues under current scenario – The

What Are Requirements? – The identification of your issues under current scenario – The end-goal of the system or solution you seek – Detailed functionality and capabilities you need to achieve your end-goal system or solution The Definition Depends on the “Definer” – Commercial Buyer’s Definition • One document with many purposes and applications – Seller’s / Offeror’s Definition • The details vendors need in order to give a price and terms to deliver a solution – Government Buyer’s Definition • Many documents required in the acquisition process 89

What Are Requirements in our Everyday Lives? Two sample shopping lists from a spouse

What Are Requirements in our Everyday Lives? Two sample shopping lists from a spouse – reasons why conflicts can arise when written poorly Shopping List A: – Eggs – Milk – Cheese – Soda Shopping List B: – 12 Organic Brown Eggs from Trader Joe’s – One gallon of Rosenberg’s skim milk with expiration date of no earlier than 4/30 – One-half pound of Land ‘O Lakes American Cheese as long as it’s under $5 per pound – Two 12 packs of 12 ounce caffeine free Diet Coke in cans 90

How Would this Shopping List be Expressed in Government? Shopping List C-1: – 12

How Would this Shopping List be Expressed in Government? Shopping List C-1: – 12 Organic Brown Eggs from Trader Joe’s – Organic 7 CFR § 205. 2 (Terms defined) – Trader Joe's – FAR 8. 002 (Required Sources of Supplies and Services, Priorities for use of Government supply sources) – FAR 9. 104 -1 (Responsible Prospective Contractors, General Standards) – FAR 19. 502 -2 (Total small business set-asides) – One gallon of Rosenberg’s skim milk with expiration date of no earlier than 4/30 – FAR 6. 302 -1(c) (Only one responsible source and no other supplies or services will satisfy agency requirements, Application for brand name descriptions) – 7 U. S. C. 4502(e)) (Dairy Production Stabilization Act of 1983) – FAR 32. 904 (f) (Determining payment due dates, Food and specified items) 91

How Would this Shopping List be Expressed in Government? Shopping List C-1: – One-half

How Would this Shopping List be Expressed in Government? Shopping List C-1: – One-half pound of Land ‘O Lakes American Cheese as long as it’s under $5 per pound – FAR 6. 302 -1(c) (Only one responsible source and no other supplies or services will satisfy agency requirements, Application for brand name descriptions) – 7 U. S. C. 4502(e) (Dairy Production Stabilization Act of 1983) – FAR 32. 904 (f) (Determining payment due dates, Food and specified items) – Two 12 packs of 12 ounce caffeine free Diet Coke in cans – FAR 6. 302 -1(c) (Only one responsible source and no other supplies or services will satisfy agency requirements, Application for brand name descriptions) – Soda cans 10 U. S. Code § 2533 (Requirement to buy certain articles from American sources; exceptions [Berry Amendment]) 92

How Would this Shopping List be Expressed in Government? Shopping List C-2: – Groceries

How Would this Shopping List be Expressed in Government? Shopping List C-2: – Groceries (the other end of the extreme – vague and non-specific) 93

Why Are Requirements Important? – Pitfalls and problems that can arise • If you

Why Are Requirements Important? – Pitfalls and problems that can arise • If you don’t know or cannot describe exactly what you need, you won’t know how to get it, who to get from, or how to tell when you get it. • Inadequate competition • Increased time to award due to confusion and ambiguity • Ambiguity translates to increased risk to offerors which drives up cost • Acquired supply/service doesn’t meet government’s needs – Requirements will determine: • The best solution • Correct quantity • Product / License type • Acquisition approach • Negotiation strategy 94

Why Are Requirements Important? – If you don’t know your requirements, then stop and

Why Are Requirements Important? – If you don’t know your requirements, then stop and go figure out your requirements and why you are going to spend money. Don’t spend the money until you know your requirements. – If you don’t do an excellent job on a PWS, SOO, SOW, PSOW, etc; how do you expect a vendor to deliver what you want and need – One method is to have an internal group (not associated with your acquisition) review you requirements and draft their response based on what you wrote. – Remember the “Four Corners of the Contract” rule – you only are entitled to what you put in the Contract/PWS. – One of the top Problems in LPTAs is poor Requirements. 95

Why Are Requirements Important? • Pitfalls of misunderstanding a requirement – Long standing legal

Why Are Requirements Important? • Pitfalls of misunderstanding a requirement – Long standing legal principle – “Ambiguities will be construed against the drafter” – Delays the solicitation and award process – Results in costly claims and performance issues after contract award • Invest the time up front to get the requirement right and avoid all the scrap and rework after contract award • “The best contract in the world can not fix a poorly worded, under funded requirement”, Brig General Slinkard 96

Team Approach to Defining Requirements – Skills needed – Experience needed – Representative of

Team Approach to Defining Requirements – Skills needed – Experience needed – Representative of (what groups? ) – Government / contractor mix – Number of people – Parameters / Guidelines / Principles – Project Management disciplines: • goals, meetings, agendas, status, issues log, timeline 97

COTS Enterprise Software License ESL pre-award processes include four phases, with internal ESL strategy

COTS Enterprise Software License ESL pre-award processes include four phases, with internal ESL strategy and vendor agreement discussions operating concurrently 1 Strategic Vendor Analysis Strategic Vendor and Roadmap Analysis & Roadmap (SVAR) 2 b 2 a ESL Strategy & Analysis 3 Vendor Agreement Framework (VAF) Conversations Acquisition Activity Concurrent Execution Major Activities: q Preliminary Demand Signal Research and Data Collection q Vendor & Market Analysis q Near / Long Term Strategy Identification q Preliminary Projected OEM Savings Ranges q Preliminary Funding Analysis Primary Output: OEM Analysis and Strategic Roadmap Major Activities: q Strategy ID & Analysis q Internal Requirements Review & Identification q Funding Analysis & Review q Initial Deal Structure / T&Cs / 2 b EULA Definition q Program and Command I/O High-Level Deal Review q Initial Negotiation Planning Primary Output: Internal Customer Requirements & Funding Documentation Major Activities: q Vendor Framework Element Identification q Vendor Relationship Alternatives Analysis q Demand Signal / Installed Base Review q Vendor Rough Order of Magnitude (ROM) Review & Financial Analysis q VAF Mapping to Acquisition Elements Primary Output: § Vendor Agreement Framework § Acquisition-focused Business Case Analysis Major Activities: q Finalize Deal Structure /T&Cs / EULA q Acquisition Package Development q Final Negotiation Planning q Cost Analysis, Negotiations, and Award Primary Output: § Acquisition Package § Deal Analysis § Enterprise Agreement 98

5. 3 ISSUING THE SOLICITATION Prepared by Do. D ESI | August 2014

5. 3 ISSUING THE SOLICITATION Prepared by Do. D ESI | August 2014

5. 4 PREPARE THE NEGOTIATING STRATEGY Prepared by Do. D ESI | August 2014

5. 4 PREPARE THE NEGOTIATING STRATEGY Prepared by Do. D ESI | August 2014

Creating a Negotiating Strategy • Evaluate the parties – Recurring negotiation versus one-offs –

Creating a Negotiating Strategy • Evaluate the parties – Recurring negotiation versus one-offs – Is competition still a factor or has the vendor been selected - the Pfizer story – Relative strength and leverage of the parties – Establishing face-off strategies • Identify and prioritize the issues – Assuming a commercial transaction, price is only one issue – Take a comprehensive view of the issues from the perspective of both parties • Establish objectives & alternatives – Assign target values (desired outcome – objective) for both qualitative and quantitative issues – Create one or two back-up positions for every important issue • For example, Ts and Cs might require alternative language – Is there a BATNA in case it is needed? 101

Creating a Negotiating Strategy • Find Zones of Agreement – Establish a walk away

Creating a Negotiating Strategy • Find Zones of Agreement – Establish a walk away position or Reservation Price for each objective – Use the back-up positions to create a zone of potential agreement – Prepare strategies for mutual discovery of zones of agreement • Final preparation - assessing your strengths and weaknesses – How solid is our information? – Are there time limits to reach agreement? • What is the target date of award • Sellers date & Buyers Date – Are there negotiating limits imposed by law or regulation? – Conduct a senior management review • This will ensure integrity of the strategy • It will also ensure management buy-in 102

Reservation Price and The Zone of Agreement Desired selling price - 800 NO AGREEMENT

Reservation Price and The Zone of Agreement Desired selling price - 800 NO AGREEMENT POSSIBLE Minimum selling price - 400 ZONE OF AGREEMENT Maximum purchase price - 700 NO AGREEMENT POSSIBLE Desired purchase price – 300

Creating a Negotiating Strategy • Selecting the venue – – the Paris Treaty story

Creating a Negotiating Strategy • Selecting the venue – – the Paris Treaty story • Selecting the seating arrangement • Selecting a spokesperson – – the Godfather story • Establishing decorum and respect at the outset • Presenting desired outcomes – – Who goes first – does it really matter? • Using conditional agreements to make progress – – If I do X will you do Y 104

Conducting the Negotiation – the tactics of negotiating • Using intervenors and ratifiers •

Conducting the Negotiation – the tactics of negotiating • Using intervenors and ratifiers • Asking questions for fact-finding • Caucusing • Concessions • Finalizing agreement – Documenting positions and agreements (or tentative agreements) – Closing the deal – getting to a final document with signatures 105

Questions and Feedback 106

Questions and Feedback 106

Training Information on Do. D ESI Web Site Please visit the following page on

Training Information on Do. D ESI Web Site Please visit the following page on the ESI web site to: Register for ESI training Provide training feedback Request a consultation with an ESI Software Licensing SME Download training materials http: //www. esi. mil/Content. View. aspx? ID=395&type=2 10 7