WIPO Regional Seminar Intellectual Property, Software and E-Health

1. WIPO Regional SeminarIntellectual Property, Software and E-Health Case Study: Software Licensing Experience in UNAIDSKigali, Rwanda4 June 2010 Prepared by:S. NEWELL UNAIDS

2. First, some introductions… UNAIDS

3. 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 UNAIDS

4. 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 UNAIDS

5. To get through it, we have had to consistentlyManage for the future UNAIDS

6. 1 2 3 Why start withthe future? Learning from the past Putting things into practice UNAIDS

7. 1 2 3 Why start withthe future? Learning from the past Putting things into practice UNAIDS

8. 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. UNAIDS P.S. apologies to IP owners for shameless copying of two images from Google images to make my point

9. 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 $$$ UNAIDS

10. 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 UNAIDS

11. 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? UNAIDS

12. 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! UNAIDS

13. 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. UNAIDS

14. 1 2 3 Why start withthe future? Learning from the past Putting things into practice To manage change, I steward the future UNAIDS

15. 1 2 3 Why start withthe future? Learning from the past Putting things into practice To manage change, I steward the future UNAIDS

16. The story of my worst project ever • At my previous organization -- an electronic publishing project • Selection process lead to two options: • 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 • 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… UNAIDS

17. 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 UNAIDS

18. Mistakes are the best opportunityto learn from • In this case, the lessons were: • 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 • 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 • 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! UNAIDS

19. A few more lessons: • 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. • Avoid fixed-price contractsBecause we need iterative cycles for software development, time and materials to be kept under a maximum amount is much better. • 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. UNAIDS

20. 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 UNAIDS

21. 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. UNAIDS

22. 1 2 3 Why start withthe future? Learning from the past Putting things into practice To manage change, I steward the future Learn from bothsuccesses & failures UNAIDS

23. Practical tips on licensingin the context of eHealth draft declaration • Last October, Rwanda kindly hosted a meeting lead by WHO and theHealth 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: • Data ownership • Governments felt it important to ensure that they always maintain ownership of their eHealth data • Confidentiality & security • Governments felt the need to ensure health data remains confidential and secure • Infrastructure • To address the above, the issues of hosting infrastructure were noted as a critical precursor to software development / deployment UNAIDS

24. 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? UNAIDS

25. Can we outsource email? • Given that email is a critical service for us, here are some questions: • 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? • 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? • 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… UNAIDS

26. 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 UNAIDS

27. 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 UNAIDS

28. Example: details of the acceptance process • Process is essentially as follows: • Vendor completes delivery, e.g. of a software component, • We receive & test it to see if it is OK • We get back to the vendor to let them know of corrections • They make the necessary changes and re-submit • 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 processb) they can budget time for corrections (otherwise, you might not get what you expect!) UNAIDS

29. 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. UNAIDS

30. 1 2 3 Why start withthe future? Learning from the past Putting things into practice Sets the stage forthe way forward To manage change, I steward the future Learn from successes & failures UNAIDS

31. 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. UNAIDS

32. Last words: • Needs evolve • Technology progresses • Priorities change • Manage for the future UNAIDS

33. Questions or comments?Thank you. UNAIDS