Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


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

1 February 24, 2014 UNAIDS WIPO Regional Seminar Intellectual Property, Software and E-Health Prepared by: S. NEWELL Case Study: Software Licensing Experience in UNAIDS Kigali, Rwanda 4 June 2010

2 February 24, 2014 UNAIDS First, some introductions…

3 February 24, 2014 UNAIDS About me… My name is Sima Newell Currently, I am the head of IT at UNAIDS Chief, Technology Services Division I am based in Geneva, Switzerland I am an electrical engineer by training Master 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

4 February 24, 2014 UNAIDS 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

5 February 24, 2014 UNAIDS Of course there have been challenges Procurement Goods + services Languages / currencies Working with central procurement Infrastructure Standards that can be adapted locally Some regions have few options (e.g. VSAT) Limited competition Expectation that software should work mostly the same everywhere And, of course, licensing Goods + services Triple the desktop licenses Cost containment

6 February 24, 2014 UNAIDS To get through it, we have had to consistently Manage for the future

7 February 24, 2014 UNAIDS Why start with the future? Learning from the past Putting things into practice 123

8 February 24, 2014 UNAIDS Why start with the future? Learning from the past Putting things into practice 123

9 February 24, 2014 UNAIDS 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 Whats appropriate now just wont 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

10 February 24, 2014 UNAIDS 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 $$$

11 February 24, 2014 UNAIDS 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

12 February 24, 2014 UNAIDS Most of my time is spent managing 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?

13 February 24, 2014 UNAIDS 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 didnt 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!

14 February 24, 2014 UNAIDS A success story: UNAIDS intranet redesign Phase 2: visibility & change management First 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.

15 February 24, 2014 UNAIDS Why start with the future? Learning from the past Putting things into practice 123 To manage change, I steward the future

16 February 24, 2014 UNAIDS Why start with the future? Learning from the past Putting things into practice 123 To manage change, I steward the future

17 February 24, 2014 UNAIDS 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…

18 February 24, 2014 UNAIDS 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

19 February 24, 2014 UNAIDS Mistakes are the best opportunity to 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 & communicate This 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 money Note: the contract exits for when times are bad, not when times are good!

20 February 24, 2014 UNAIDS 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 tendering This 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.

21 February 24, 2014 UNAIDS 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

22 February 24, 2014 UNAIDS 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.

23 February 24, 2014 UNAIDS Why start with the future? Learning from the past Putting things into practice 123 To manage change, I steward the future Learn from both successes & failures

24 February 24, 2014 UNAIDS Practical tips on licensing in 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

25 February 24, 2014 UNAIDS We also face similar issues 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?

26 February 24, 2014 UNAIDS 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…

27 February 24, 2014 UNAIDS 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

28 February 24, 2014 UNAIDS 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

29 February 24, 2014 UNAIDS 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-submit 5.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!)

30 February 24, 2014 UNAIDS 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.

31 February 24, 2014 UNAIDS Why start with the future? Learning from the past Putting things into practice 123 To manage change, I steward the future Learn from successes & failures Sets the stage for the way forward

32 February 24, 2014 UNAIDS 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.

33 February 24, 2014 UNAIDS Last words: Needs evolve Technology progresses Priorities change Manage for the future

34 February 24, 2014 UNAIDS Questions or comments? Thank you.


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

Similar presentations


Ads by Google