February 24, 2014 UNAIDS WIPO Regional Seminar Intellectual Property, Software and E-Health Prepared by: S. NEWELL Case Study: Software Licensing Experience

UNAIDSApril 10, 2023

WIPO Regional SeminarIntellectual Property, Software and E-Health

Prepared by:S. NEWELL

Case Study: Software Licensing Experience in UNAIDS

Kigali, Rwanda4 June 2010

April 10, 2023UNAIDS

First, some introductions…


About me…

• My name is Sima Newell

• Currently, I am the head of IT at UNAIDSChief, Technology Services Division

• I am based in Geneva, Switzerland

• I am an electrical engineer by trainingMaster of Engineering from McGill University, Montreal Canada

• I have been at UNAIDS for nearly 6 years in this position

• Prior to that, I worked at WHO (5 years), the ILO & the UN secretariat

• Before that, I worked in a .com company for several years in Canada


About IT in UNAIDS• UNAIDS is a joint, cosponsored programme of the UN (est. 1996)

• We have a global secretariat, with presence in about 90 countries

• We have over 900 staff world wide

• When I joined UNAIDS in 2004, we had no IT support in our countries, or in our regional support teams

• We have since rolled out global services to all regional support teams and nearly all our countries: Improved connectivity Global e-mail addresses Voice & video conferencing, where practicable Re-designed, collaborative intranet Global data systems Enterprise resource planning


To get through it, we have had to consistently

Manage for the future


Why start withthe future?

Learning from the past

Putting things into practice

1 2 3





1 2 3


First, because things change

3yrs

Over time: • Needs for the product evolve

• Software and technology progress

• People / project owners change

• The environment and priorities shift

What’s appropriate now just won’t be right in a few short years.

P.S. apologies to IP owners for shameless copying of two images from Google images to make my point


Second, because costs can skyrocket

Rule of thumb:

• 60 to 80% of costs are incurred

after

the first release (version 1.0) of any software

$$$


Third, because success breads great ideas

A successful product brings:

• Buy-in

• Innovation for new/increased use

• Use of the system and/or data in unforeseen ways


Most of my time is spentmanaging for the future

For software licensing, this means asking key questions:

Sourcing:• Can I buy off-the-shelf, or do we need a custom solution?• Are open source solutions viable and appropriate?

Sustainability:• What staff and resources will I need to maintain my system?• Are there license renewal costs?• Is the company reputable / there for the long haul?

Ownership:• How critical is the information in the system?• Who needs to own the system? The information? • How easily will I be able to change systems / vendors later? • How much risk is there if the vendor does not deliver as expected?


A success story:UNAIDS intranet redesign

• Old system was 10+ years old, hard to maintain, hard to add content• With strategy of going global, we needed something meaningful to country staff

Phase 1: behind the scenes:• We assessed different options and technologies and tried an open source tool• Our staff learned and became familiar with the tool and liked what they saw• We didn’t have the time or resources to launch the new tool and a whole new

system together, so: We re-built the whole intranet exactly as-was, but in the new tool When we turned it on, no-one noticed, exactly as planned!


A success story:UNAIDS intranet redesign

Phase 2: visibility & change managementFirst steps:• We ran a survey & spoke to people to find out what staff needed• We started to build components that we knew people would need

Executive change:• Our new executive director started in January ’09• One day, he met a member of our staff association in an airport• The staff rep suggested sold him on the idea of a more collaborative intranet• EXD then expected us to deliver a whole new intranet in a matter of a few weeks!

Success!• Because we were ready and had made flexible technical and licensing decisions• Because we already knew what people were asking for• We delivered a first new section in a couple weeks and the whole new intranet

within 4 months, with huge buy-in and success.





1 2 3

To manage change,I steward the future





1 2 3



The story of my worst project ever

• At my previous organization -- an electronic publishing project• Selection process lead to two options:

1. An off the shelf product that • did what we wanted, • could be deployed quickly, • at relatively low cost for a pilot

BUT was licensed on a named user basis and would cost millions to deploy to the whole organization

2. A customized solution that • could do what we wanted, • would take a little longer• would cost more up-front,

BUT would cost significantly less in the long run.

• After weighing all the pros and cons, we chose the second option, and then it all went horribly wrong…


The story of my worst project ever (continued)Problems with the vendor: We had to buy licenses from a well-known company and services from a systems integrator The systems integrator went bankrupt before we concluded the contract The people jumped ship to another, reputable, company that agreed to take on our

business under the same terms and conditions

Problems with the project: They sub-contracted without telling us They never met one single deliverable correctly, and rarely on time The second (reputable) company then also went bankrupt; the people formed a 3rd new

company and kept the terms and conditions We cut the contract and our losses, hired staff and completed the project ourselves.

Problems with the product: We discovered every corner that had been cut, and realized that to deploy globally, we

would have to re-write the whole system (months of work) In the meantime, a change of management meant that the sponsor was lost and the project

was ultimately cancelled. A few years later, the need to have electronic publishing was noted and a committee was

formed to study the issue and develop a new solution


Mistakes are the best opportunityto learn from

In this case, the lessons were:

1. Go off the shelf as much as possible. The sales manager who refused to negotiate on named user licenses was shortly thereafter fired from the company that proposed an off-the-shelf-solution

2. Use short, iterative cycles. By the time we were done, the needs had changed, executive management had changed and we were scrambling to show something for all our hard work on a need we knew was critical

3. Involve all the stakeholders & communicateThis we did well, and thanks to legal office & procurement process we had a watertight contract that gave us a clear way out and saved a lot of moneyNote: the contract exits for when times are bad, not when times are good!


A few more lessons:

4. Make the requirements and acceptance process clear The vendor kept arguing that we were changing requirements. Maybe over that length of time, we were. Short, iterative cycles would have helped, and having the vendor know our acceptance process before bidding would have helped too.

5. Avoid fixed-price contracts Because we need iterative cycles for software development, time and materials to be kept under a maximum amount is much better.

6. Put terms and conditions (T&Cs) up front when tenderingThis we also handled OK, from a previous (but less dramatic) lesson. We now include all the T&Cs we need in our request for proposals, and bidders are expected to comply or indicate in their bid what T&Cs they will need to negotiate.


Licensing is integrally tied to the whole project

• In our case, we chose a solution based on heavily on customization rather than licenses

• We were nervous about the cost of named user licenses

• In retrospect, with a successful and rapid pilot: The organization would probably have adopted the new system quicker The vendor would have had an interest in finding a viable solution on the

licensing for us If not, we could have continued with an affordable pilot, while looking at other

options as technology evolved


From the intranet project,we learned:

• Try to stay ahead in terms of knowing what will be needed & asked for;

• If you have software developers & you will need to turn things around quickly, open source may be an option;

• Most of the hard work is the invisible work; best to be prepared and start before you ever promise anything.

• Note: our public web site has very different needs and we have bought a proprietary content management system.





1 2 3


Learn from bothsuccesses & failures


Practical tips on licensingin the context of eHealth draft declaration • Last October, Rwanda kindly hosted a meeting lead by WHO and the

Health Metrics Network looking at eHealth acquisition policy & practice

• In this draft declaration, there are several areas that link directly to our topic of intellectual property and licensing

• Three important ones are:1. Data ownership

• Governments felt it important to ensure that they always maintain ownership of their eHealth data

2. Confidentiality & security• Governments felt the need to ensure health data

remains confidential and secure

3. Infrastructure• To address the above, the issues of hosting infrastructure were noted

as a critical precursor to software development / deployment


We also face similarissues in UNAIDS

• Current example: we are considering e-mail outsourcing, because we need Affordable 24x7 services SPAM management is becoming more and more complex We need better disaster recovery / service continuity

Can we outsource email?


Can we outsource email?

• Given that email is a critical service for us, here are some questions:

1. Data ownership: if we are not satisfied with our service provider, how hard will it be to change in the future? What will be our options?

2. Confidentiality: our email data may have quite sensitive information in it (incl. info on the HIV status of staff). Hosted on our premises, our data is subject to the privileges & immunities of the United Nations. If we host elsewhere:• Can we negotiate with the government where the data is hosted to ensure

privileges & immunities are respected?• What if the service provider changes hosting country in the future?

3. Infrastructure: can we ensure the up time & service continuity we need? Where will data be backed up and restored? If it is cloud computing, see questions on confidentiality…


Practical approach:use the procurement process

• If we decide that outsourcing will be a good approach, then we will have to tender for the service.

• When we tender, we always include:

Templates for vendors to fill in on how they meet the requirements

Details of the acceptance process we expect to follow

All the terms and conditions of our future contract


Example: meeting the requirements

• This is the type of requirements template we would include in a request for proposals.

• We may give weighting values (e.g. 1-5) to the different requirements, depending how important they are and then score the vendor on those requirements

Req. No. Requirement

Out of the box

Requires customiz-ation

Cannot meet require-ment

Meeting this requirement is more than 5% of total cost

Comments / Explanation

1System provides API to extract all data entered via web interface

2Service continuity management ensures a recovery time of less than 4 hours for 1000 mailboxes

3 Etc.456


Example: details of the acceptance process

Process is essentially as follows:

1. Vendor completes delivery, e.g. of a software component, 2. We receive & test it to see if it is OK 3. We get back to the vendor to let them know of corrections 4. They make the necessary changes and re-submit5. We re-verify and accept.

• When we prepare a request for proposals, we included deadlines for all these activities (e.g. 5 working days for us to advise them of corrections, 5 working days for them to return corrected software, etc.)

• That way:a) we are all clear about the process

b) they can budget time for corrections (otherwise, you might not get what you expect!)


Example:Terms and conditions

• We include the text:“Details of the contractual and bidding conditions are to be found in Annex II (Terms and Conditions). These provide the conditions for the submission of Proposals in response to this RFP as well as forming the basis of any subsequent Contract(s) that may be concluded in relation to this RFP.”

• Vendors indentify in their response any T&C they cannot accept.

• This annex would be the place to add T&C about data ownership, confidentiality, holding the system in escrow, how to hand over the data & system if the company changes service provider, goes bankrupt or for some other reason the contract is broken, etc.

We try to be clear ourselves up front on what we can or cannot make compromises when the time comes for negotiations.





1 2 3


Learn from successes & failures

Sets the stage forthe way forward


In conclusion

• I have shared some of my own experience with software& related licensing at UNAIDS

• Every environment is different and I know here in Africa, and in eHealth, some of the big challenges are: Infrastructure (expensive where available) Costs and sustainability Data ownership, security, confidentiality Managing various interests

• In the next session, I will hand it over to you to work in groups to go into more detail on some of these issues (ownership, confidentiality, infrastructure) based on your experiences.


Last words:

Needs evolveTechnology progresses

Priorities change

Manage for the future


Questions or comments?

Thank you.

Documents

February 24, 2014 UNAIDS WIPO Regional Seminar Intellectual Property, Software and E-Health Prepared by: S. NEWELL Case Study: Software Licensing Experience