COTS Software Licensing Software License Negotiations Overview 2014

2 Agenda 0800 to to 1600  Welcome, Purpose of the Class, Agenda Review  Introductions, Roles, Experience Level, Goals for Class  Software Industry Ecosystem, Key Players and the roles they play  Software Publisher Organization and Operation  Software Publisher Products and Services  Cloud, SaaS, Third Party Software and Open Source Software  Pricing Models  Key Contracts and Agreements  Source Code Escrow  Requirements  Software Implementation Service Agreements  Ordering  IT Asset Management / Software Asset Management (ITAM/SAM)  Software Self-Audit  Q&A / Departure

DoD ESI Team / Instructor Introductions 3 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 DoD 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 DoD ESI 20+ years in senior executive positions and consulting roles including DoD ESI. Previously VP at SAP, PeopleSoft, 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 DoD 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 DoD ESI 30+ year expert in software licensing for DoD 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 SmartBUY Programs and the DoD ESI Program.

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

Training Strategy for DoD ESI 5 * * * Future Enhancement

Prepared by DoD ESI | March The IT Industry

7 Hardware Software Services Global Spending (Gartner Outlook) 2011$404B$267B$845B 2012$421B$280B$856B % ‘1227%18%55% Federal Government Spending (est. using same % as Global Spending) 2012$22B$14B$44B % ‘1227%18%55% Overview: Industry Overview / Spend Analysis

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

Prepared by DoD ESI | March Intellectual Property

Overview: Intellectual Property – Protection Methods 10 Four Ways to Protect IP Trademarks protect words, names, symbols for as long as they are being used in business. Patents protect rights for inventions, up to 20 years. 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

Overview: Publisher Business Model - Traditional 11 Bug Fixes, Patches, Updates Object Code (Machine Readable) Source Code (Human Readable – Secret Recipe) Training, Implementation, Hosting Parties, Grant of License, Quantity, Duration, Permitted Use, Price, Warranty, Remedies License Agreement Maintenance & Support Services Product Development / R & D

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

Prepared by DoD ESI | March Publisher Business Model

The Publisher’s Four Primary Operating Functions Responsible for writing the software. Quality and End-Adoption are key metrics. Product Development Responsible for finding & selling applications to new customers and managing relationships with and selling to existing customers. Measured on meeting sales quotas and on customer satisfaction. Sales Primary duty is to assist customers with implementation & training. Measured on revenue, meeting project time & budget targets. Professional Services Responsible for analyzing & fixing software bugs and delivering new releases. Measured on SLAs, maintenance revenue & renewals plus customer satisfaction. Maintenance & Support 14

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

Software Sales Conditions For a 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. Conditions to Recognize Sales Revenue 16

Sales Compensation 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. Compensation Based on Commission 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. Sales Compensation Plan Incentives 17

Prepared by DoD ESI | March Reseller Business Model

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

Reseller & Publisher Relations Publisher typically offers same discounts to all resellers. Tries to be consistent and level the playing field. Rewards the Reseller with the best sales execution. Resellers usually compete on their “pass-through.” Publisher might offer volume discounts to top resellers. Large deals are “one-off” deals and reseller gets additional discount. When a reseller “finds” the sale, they are the only reseller in negotiations. In response to RFP, multiple resellers are generally at same price to all. Publisher Pricing/Discounts Assume all resellers get a 40% discount. A $10,000 list order is offered to all resellers at $6,000 cost. Reseller A adds 20%, sells at $7,200; Reseller B adds 15%, sells at $6,900. If Reseller C qualifies for a volume discount, may get an additional 5% discount. Reseller C with $5,500 purchase cost can sell at $6,600 and still make 20%. Examples: 20

Prepared by DoD ESI | March Products & Services

EnterpriseShrink Wrap Products & Services: Product Categories - Overview 22 SOFTWARE SYSTEMS BUSINESS APPLICATIONS PROGRAMMING & TOOLS DATABASES Operating Systems Utility Programs Custom Commercial Off-the Shelf Software Development Kits Open Source Middleware Windows Linux Oracle Fusion Middleware IBM WebSphere JBoss Enterprise Open Source Oracle Microsoft SQL Server IBM DB2 Sybase (SAP) Microsoft Office SAP Logistics Siebel CRM

Products & Services: Product Categories – Business Applications 23 EnterpriseShrink Wrap Definition Comprehensive set of software capabilities for an enterprise. Usually addresses mission- critical business requirements. Provides significant flexibility but requires extensive configuration. Focused on a purpose- specific set of capabilities— often a tool or an administrative application. Can be used across an enterprise, but usually not mission-critical. Examples of Applications Financial accounting Logistics HR Microsoft Office—Word, Excel, PowerPoint Adobe—Acrobat, Reader, LiveCycle Designer, Distiller Trend Micro—Office Scan Examples of Publishers SAP Oracle Microsoft Adobe

Prepared by DoD ESI | March Products and Services: Cloud and Software as a Service (SaaS)

Timeline to Cloud/SaaS 25

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

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

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

Licensing Considerations – SaaS vs. Perpetual Perpetual One-time upfront payment License to use in perpetuity (no term) Right to physical custody Customizations discretionary Infrastructure & data security control Data ownership & custody control SLAs for support response Normally hosted on-premise by organization Control timing of upgradesSaaS Subscription-based pricing License to use only while subscription is current (term) Remotely accessed service Customizations limited No direct security control No direct data ownership & custody SLAs for support & availability Normally hosted off-premise by provider Limited control of upgrade timing 29

Reasons for Using Cloud Computing Aside from the OMB mandate, what are key business reasons for deploying to the cloud? –Cost reduction –Speed & flexibility –Greater mobility –Easier collaboration –Heightened security Each of these factors may be valid, but we should examine them in detail. 30

How Do We Measure Cost Savings? SaaS licenses generally provide all software and services needed to operate a business application, including: –Application & Related Software Licenses –Maintenance (fixes, patches, upgrades) & Support –Infrastructure & Facilities How can you tell whether corresponding internal costs will be avoided or go away? How do you know a SaaS cost is lower than an internal cost for an item? Since you may license a variety of applications from a variety of SaaS vendors, do the economies of scale from each vendor outweigh the aggregate internal economies if you hosted all those apps on premise? 31

Other Factors to Consider About Cloud Benefits Flexibility –Switching SaaS vendors could be less costly than switching perpetual vendors, but… …would it be as easy to switch providers as it would be to switch ERP SaaS 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? 32

Other Factors to Consider About Cloud Benefits Heightened Security –Even if all infrastructure is outsourced, does it make sense to outsource data security? 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? 33

Prepared by DoD ESI | March Products and Services: Maintenance & Support

Basics of Maintenance & Support Services Maintenance generally refers to two aspects of licensing software: – Developing, receiving, and applying patches and fixes designed to address software bugs. (Publisher develops; customer applies.) – Developing, receiving, and applying new or upgraded releases of licensed software. Maintenance fees are used by Publishers to fund development of fixes and new releases. Maintenance Software Support refers to processes for addressing apparent software deficiencies/malfunctions with the goal of identifying/correcting them. Support issues are often due to lack of training or other user issues. Most Publishers offer increasing levels of support at increasing prices. Support 35

Maintenance 36 Fixes & Patches (1.0.1) Updates (1.1) Upgrade / New Release / Version (2.0) License Maintenance & Support Product Development / R & D 1. Support Levels and Process (Who receives, diagnoses, and fixes problems?) 2. Issue Severity Levels 3. Response Times Version 1.0 Functional performance of product Patches & Fixes (under warranty) during warranty post warranty Support Services Product Entitlements

Software Versions Nomenclature and Numbering 37 NomenclatureDescriptionNumbering 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) Bug Fix/Maintenance Release/Patch 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 becomes 4.2.2)

Caution: New Product/New Program Fees 38 Publishers may try to release a major change/version as a “New Product”, not included under S/W Maintenance and requiring new license fees. User Community and Industry Analysts are the best sources to track if this is perceived a fair practice and truly a new product. Watch for combining of 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).

Maintenance & Support Agreements 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 Response Time to Reported Issues 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. SLAs for System Performance Because higher SLAs can be expensive, the Customer should weigh carefully the need for quick response time or substantial availability. Selecting the Right Package 39

Prepared by DoD ESI | March Products and Services: Open Source & Third Party Software (TPS)

Open Source Code 41 How Publishers Use Open Source – Some are well-known stand-alone apps (e.g. Mozilla Firefox, Apache, Linux, OpenOffice, etc.). They can work in concert with other applications without becoming embedded in copyrighted applications. – Other applications (or chunks of functionality) have found their way into products published by commercial software companies who copyright their applications and sell licenses. – In both cases, Publishers of copyrighted software must use caution to avoid violating the Open Source standards and license provisions.

Contract Concerns with Open Source Code & Third Party Software Maintenance & Support – Since Open Source is collaboratively developed and peer reviewed, there might be no formal infrastructure for providing fixes, patches, enhancements and updates. – Possibly no formal support organization to assist with diagnosing/fixing problems. License Rights and Intellectual Property – Open Source licenses can require sharing of enhancements or derivative works. – “Encapsulation” can be used to isolate Open Source code from copyrighted IP. – 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. 42

Prepared by DoD ESI | March Pricing

License Models – Overview Pricing is typically driven by the software license model Software Licenses can be classified in many different ways. One approach is to look at licenses along several dimensions as follows: – Duration-based (the duration of time that you may use the license) – Use grants – Pricing models/Units of Measure to determine the price you pay Some of these dimensions may overlap; for example, a subscription license may be thought of as a time horizon as well as a pricing method. The dimensions presented are designed to provide a convenient way of analyzing the key elements of licenses. There may be other equally valid approaches for categorizing licenses. 44

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

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

Purchase Scatterplot 47

Purchase Scatterplot 48

Product Price Benchmark Reports (Private SPM Site ) 49

Prepared by DoD ESI | March Contracts & Agreements

Agreements Involved in COTS SW Life-Cycle 51 Maintenance & Support Contract Contracted Assurances License Usage Rights For extended protection, choose either: (or) Performance Warranty: Initial Period of Coverage Training Services Hosting / Service Level Agreements (SLA)

Agreements Involved in COTS SW Life-Cycle TermDefinitionApplicability LicenseA set of rights granted by a Publisher to use Publisher’s software.Apply to all. Maintenance A set of services Publisher can sell to Customer for the on-going development and delivery of software fixes and product upgrades. If Maintenance & Support apply, then Assurances do not. Support A set of Publisher services for receiving reports of software malfunctions, analyzing cause, creating fixes and delivering them to Customer within agreed upon time frames. If Maintenance & Support apply, then Assurances do not. Warranty The contractual duty of Publisher to correct product defects, usually limited to certain kinds of defects and for a specific time period. Apply to all. Assurance (Microsoft) New software versions, deployment planning services, 24x7 phone and web support, end-user training, unique desktop technologies and more. If Assurances apply, then Maintenance & Support do not. SLAs Service Level Agreements Usually structured as a combination of conditions and performance, for example, all reported high priority performance issues will be addressed within 4 hours. Individually established. 52

Prepared by DoD ESI | March Contracts & Agreements Software Source Code Escrow

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

Source Code Escrow—Balancing Interests 55 Licensee / Beneficiary Publisher Escrow Required 2. EULA Executed 1. Object Code 3. Escrow Agreement Executed 4. Escrow Agreement Executed 4. Escrow Agreement Executed 4. Escrow Agent 4. Source Code (including Updates) 5. Source Code (Released by Trigger Event) 6.

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

Prepared by DoD ESI | March Requirements & Contracting

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 58

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 Two sample shopping lists from a spouse – reasons why conflicts can arise when written poorly 59 What Are Requirements in our Everyday Lives?

Shopping List C-1: – 12 Organic Brown Eggs from Trader Joe’s – Organic 7 CFR §205.2 (Terms defined) – Trader Joe's – FAR (Required Sources of Supplies and Services, Priorities for use of Government supply sources) – FAR (Responsible Prospective Contractors, General Standards) – FAR (Total small business set-asides) – One gallon of Rosenberg’s skim milk with expiration date of no earlier than 4/30 – FAR (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 (f) (Determining payment due dates, Food and specified items) 60 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 (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 (f) (Determining payment due dates, Food and specified items) – Two 12 packs of 12 ounce caffeine free Diet Coke in cans – FAR (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]) 61 How Would this Shopping List be Expressed in Government?

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

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 63

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

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 65

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 66

Requirements Fit with Acquisition and Contracting 67 Produce Requirements Document Management / Issue Resolution Contract Evaluation Planning / Market Research Solicitation Attach to RFP / RFQ Determine Solution Fit % & RICEF Needs Attach to Contract / Warranty for License and SI Contract Use in Acceptance Tests for Software and System Integration Use to Resolve Conflicts / Defects (Software v. SI) Requirements Development & Management Process Flow Acceptance

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

Requirements Exercise 69

Requirements Exercise 70 Scenario: Existing Office Automation Tools do not Exist Break into 3 or 4 Teams – Each Team Needs at least 2 people from yesterday’s class Choose 1 of the Following Office Automation Tools: Spreadsheet Software Word Processing Software Presentation Software Take 25 Minutes to Develop High Level Functional Requirements Discuss (but do not do) a couple of Detailed Requirements for one or two High Level Functional Requirement Reconvene to the Class Take 5 Minutes to Present your Requirements and Discussion

Prepared by DoD ESI | March Professional Services Commercial Software Implementation & Integration Services

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

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

System Integration Services For Typical Commercial-off-the-shelf (COTS) Software 74 Data Base Software Legacy Systems Project Management Change Management / Training / Communications InterfacesData Migration/ Conversion Reports Secure Access Extensions / Bolt-On Apps Configuration or Development Security & Controls Testing Hardware & Networking Post- Implementation Support Business Process Reengineering Support / Preparation / Participation in Reviews / Milestone Decisions / Oversight / Certifications / Regulatory Compliance User Requirements Development

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

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

77 Price for Performance Table Tied to Methodology 77 Methodology Phase: Baseline Price Tables Aligned With Methodology 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 Deliverable Price Payment Upon Acceptance 10% Holdback Performance Scorecard Summary Payment Based on Performance Scorecard Change Management Plan $100,000$90,000$10,000Exceeds. $15,000 Meets.$10,000 Does not meet.$0 Blueprint

78 Government Duties 78 Milestone Services to be Performed by Contractor Deliverable Detailed Deliverable Description Buyer’s Duties 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. Avoid Assumptions “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.” Examples of Language to Use

Prepared by DoD ESI | March Ordering from DoD ESI BPAs / Vehicles

See Inventory and Enterprise Licenses. See Ordering Guide Overview. See COTS Software License Framework. See Software Buyer’s Checklist. Check ESI Agreements (Ltd Source) Check ESI for Inventory* Solicitation IAW Ordering Procedures in ESI Agreement NOYES NO Evaluation Award / Delivery Order Receive, Accept and Pay Fulfill Follow FAR, DFARS and local office policy YES 3 rd party (If relevant)++ Select Product Brand Follow Ordering Guide Instructions+ COTS Software Ordering Process 80 Path 1: Only one product will meet requirements *Refer to FAR and DFARS for order of precedence for use of Govt. supply sources. + Must also determine if a brand name or limited source justification is required. + + If a 3 rd party contractor is authorized to order on behalf of the government, the 3 rd party would execute the remainder of this process beginning at this step.

See Inventory and Enterprise Licenses. Not necessary to review Competition/Solicitation in Ordering Guide Overview. See COTS Software License Framework. See Software Buyer’s Checklist Award / Delivery Order Receive, Accept and Pay Fulfill Write Functional Specification Compile List of ESI and non- ESI publishers 3rd party (If relevant)++ Competition Solicitation Evaluation Check Inventory COTS Software Ordering Process 81 Path 2: Multiple product brands can meet the requirements (overview) 6 5 3

Prepared by DoD ESI | March IT Asset Management / Software Asset Management

ITAM & SAM Defined 83 ITAM (IT Asset Management) SAM (Software Asset Management) HAM (Hardware Asset Management) NAM (Network Asset Management) Policies/procedures for managing software assets in an IT environment can include license audits, upgrades, maintenance, etc.

ITAM, SAM, & ITIL ITIL provides a comprehensive set of disciplines and processes for the orderly management of IT assets and services within an organization. Why Use ITIL? ITIL-based Change Management processes ensure changes to the IT infrastructure are authorized, tested, and deployed properly—thereby retaining environment integrity. Why Change Management? 84 (IT Infrastructure Library)

ITAM/SAM Repositories & Data Requirements Repositories Agreement/ContractReceiptDeployment Changes/ Modifications Summary Captures all appropriate license agreement data. Captures all license receipt information comparing receipt with license agreement. Any discrepancies should be documented and resolved. List server name or other device and location where software is deployed. Captures details regarding software updates, patches, fixes, etc. Data Input Elements Product. Version. Publisher. Vendor. Agreement date. Number of licenses. Date. Quantity. Etc. Date. Quantity. Device. location of software deployment. Date (due and actual). Quantity. Device. Location of software changes. 85

Prepared by DoD ESI | March ITAM / SAM Software Self-Audit

Software Self-Audit Goal 87

ESI Self-Audit Language N OTWITHSTANDING P UBLISHER AUDIT PROVISIONS TO THE CONTRARY, D O D MAY PERFORM AN INTERNAL AUDIT OF S OFTWARE USE AND WILL USE ITS BEST EFFORTS TO KEEP FULL AND ACCURATE ACCOUNTS THAT MAY BE USED TO PROPERLY ASCERTAIN AND VERIFY NUMBERS OF LICENSES, USERS OR SUBSCRIPTION PARAMETERS IN USE. U PON P UBLISHER WRITTEN REQUEST, D O D MAY PROVIDE AUDIT REPORTS TO P UBLISHER FROM L ICENSEE ’ S INTERNAL AUDIT RECORDS AS THE SOLE MEANS OF SATISFYING P UBLISHER ’ S REQUESTS FOR AUDIT. 88 DoD Self Audit Language:

3 Step Approach to Self-Audit 89 1 st Step What are our existing license rights granted? What Programs, number of users, servers, organizational boundaries, etc apply? 2nd Step What is our actual use (including identification of Software on record or on servers not in use)? What Programs, number of users, servers, organizational boundaries, are we using? What is the comparison of rights granted to actual use? 3rd Step

Conducting the Self-Audit Self-Audit is accomplished by the Software User using internal personnel to perform the audit under pre-established processes and methods. Audit results are reported to Internal Management and to Software Publisher. Often, a contracting officer is required to certify that the audit was conducted as established, and that the results are accurate. 90

Conducting the Self-Audit Numerous software tools are available to search networks and report software instances/usage. Yet only some of these tools are “certified” by certain Publishers. The small list of certified tools excludes many recognized, mainstream products. Many additional audit tools are well-tested, mainstream products, leaving the Publishers with no logical reason to dispute their use, accuracy, and effectiveness. 91

Conducting the Self-Audit Issues germane to self-audit and all S/W Audits include: who will perform the audit, which automated tools will be used for auditing, how results will be measured, what is the process and timeline for reporting, what is the remedy process (if any is deemed necessary), who pays for the audit, and whether or not audit results are binding (especially important for Publisher and 3rd Party Audits). 92

Typical Results of a Self-Audit Comparing actual software use to the rights granted by the terms of the contract generally yields one of the following results: 93 Common Results from AuditConsequences/Ramifications a) Compliance across the entire organization.None. b) Software acquired, but not utilized, and with no future plans to utilize. DoD might be able to save a significant amount of annual maintenance cost, based on the documented under-utilization. c) Software acquired, but utilized far less than licensed. d) Software acquired, but utilized in excess of license grants. DoD might prevent a complicated situation where the software Publisher could take vigorous actions to charge DoD for improper use. Being proactive, DoD can elect to acquire additional license rights to bring the organization into compliance, or could elect to limit usage within the organization to comply with existing license grants. e) Software utilized with no record of acquisition or license grants. DoD needs to determine if license rights exist—from previous organizations or users inherited via reorganization—and then take steps to ensure compliance by acquiring appropriate license rights, or eliminating the software use within the organization.

Questions and Feedback 94

Training Information on DoD ESI Web Site 95 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