Buy or Build: Using Technology to Enhance Your Program, and Associated Challenges

1. Buy or Build: Using Technology to Enhance Your Program, and Associated Challenges Anita English, Howard University Paul Woloch, University of Western Sydney WACUBO – ACUPA Conference Denver, Colorado May 6, 2012

2. BUY OR BUILD? • Our Decision to Buy: Background • As a core institutional value, Howard University (HU) encourages full deliberation of policy issues among all members of the campus community. • HU, in a mid-term accreditation review, was advised to develop a better balance between full deliberation on policy issues and timely adoption and implementation. • Chronic audit findings identified a need for centralized, current, and accessible policies.

3. BUY OR BUILD? • Our Decision to Buy: Background • Coordinated, institution-wide policy management has a strong advocate in the Senior Vice President (SVPS) and Secretary, who is the corporate secretary and custodian of official records of the Board of Trustees. • In October 2010, the SVPS’s model for an enterprise-wide policy management system was launched in the president’s cabinet meeting. • Concurrently, a search began for technology to support the balance between the institution’s core value of full deliberation with the accreditation and audit requirements.

4. BUY OR BUILD? • Search for Technology: Our Needs • Transparency in who makes policy and how. • Inclusion in the policy vetting process. • Coordination across portfolios, schools, colleges, the hospital and clinical programs. • Standardize policymaking by using templates, definitions, a policy style manual. • Employ best practices, such as policy lifecycles, benchmarking, and version control. • Use technology to make policy accessible. • Use channels of communication to ensure policy competency among stakeholders.

5. BUY OR BUILD? • Our Decision to Buy • Initially, the plan was to build: • Using in-house personnel, we were going to build a system in Microsoft SharePoint. • The workflow design required expertise that was not available in-house, so a contractor was brought in to train IT staff. • Because of limited resources, training was considered a relatively inexpensive and viable option.

6. BUY OR BUILD? • Our Decision to Buy • After the initial outlay of funds, it was clear that: • MORE TRAINING was required. • NEW EQUIPMENT was required. • MORE TIME was required to overcome the learning curve. • The plan to build was scrapped.

7. BUY OR BUILD? • Our Decision to Buy • The decision to buy came about unexpectedly: • The university hospital had recently purchased a policy management software, which received positive reviews from the hospital’s CEO. • After a demo, we determined that, while the software is designed to manage policy compliance for hospitals and clinics, it could be customized to suit our needs.

8. BUY OR BUILD? • Our Decision to Buy • In a first meeting convened by the SVPS with the Chief Financial Officer to introduce the policy process and discuss financial/business policy priorities, the need for software was discussed. • The CFO made a commitment on the spot to find the resources to support the purchase. • Within a month, resources had been identified.

9. BUY OR BUILD? • Our Decision to Buy • Given an executive initiative to merge, where possible, hospital and university policies, we opted to purchase the same policy management software used by our hospital. • We are among the first non-healthcare concerns to do so. • The software is produced by MCN Healthcare as ellucid Policy Manager and has many features that address our needs.

10. BUY OR BUILD? • Advantages of Buying • Minimal down time • Minimal IT overhead. • Customer service and troubleshooting. • Free to renew or choose another option when the contract ends. • No hidden costs. • Software and equipment upgrades are included. • Software is pre-tested.

11. BUY OR BUILD? • Advantages of Buying • We purchased a more sophisticated system than could have been developed in-house over the same period of time: • Software allows customization of workflow, approval process and policy lifecycles. • Word Search Capability. • Competency Testing. • 24/7Availability. • Accessible to University Community. • Version control. • There is no risk of losing IT institutional knowledge before or after the system is launched.

12. BUY OR BUILD? • Disadvantages of Buying • After the three-year contract is over, we will have to decide to build or buy. • Renewing may be more expensive. • In-depth knowledge of how to build a system in-house was not cultivated. • While some customization is built into the software, not all needs are met. • Users may get frustrated when the software doesn’t work exactly how they want it to work.

13. BUY OR BUILD? • Critical Elements for Success in Buying • Understand the culture of your environment and how much time you have to find a solution. • Get a critical mass of policy makers to buy into the system and ensure that these same people are willing to make the “culture shift” to use it. • Find highly-placed “guardian angels” to elevate your project’s visibility and assist with funding needs. • Consider using a vendor’s interest in breaking into the “university market” as leverage.

14. BUY OR BUILD? • Critical Elements for Success in Buying • Examine all options to determine if there is a product that meets your needs. Consider the following: • How widely used is the option you are considering and what do current customers say about it? • In a standard contract, will there be any limitations placed on access to customer and tech support, training, system set-up? • Have a trusted IT staff member review the proposal and talk with the vendor. • Secure the Chief Information Officer’s buy-in. • If using a portal-based product, ensure that your contract provides for the capture and return of all information at the end of the contract.

15. INTRODUCTION The University of Western Sydney (1989) – a new university The importance of Policy in its development from 2000 Central Policy Office established 2002 Policy DDS application launched 2004

16. THE NEEDS IDENTIFIED • Corporate control – assertion of the primacy of University Policy • A stable policy process – e.g. ACUPA model • Approval • Consultation • Consistency, coherence, integration • Document management • Document quality • Compliance - legal • Publication - accuracy • Review • Archive and records • User satisfaction and confidence (intuitive)

17. THE CONTEXT OF POSSIBLE SOLUTIONS • The potential of using the Internet • The potential of using a database • Integrate policy workflow with publication – cradle to the grave approach • Intuitive system –maximising automation • Document management system designed for our policies

18. THE DECISION TO BUILD - 1 • High level institutional support for the organisational objectives of a good policy suite • Grant applied for and received to improve management and publication of policies • Options in terms of purchased systems quite limited in early 2000’s • Decision was more about the potential for improving and developing what had been started • General specification developed that went to selected tender

19. THE DECISION TO BUILD – 2 • Critical decision to use third party developer with experience working with UWS • In house capacity variable and occupied with other priorities • Greater design capacity and project focus • Greater control by Policy Unit • Innovative ideas especially related to web based applications • Fixed price and time frame

20. THE PROJECT • Commenced in 2002 and completed in 2004 • Delays: • competing priorities • Technical hurdles – in system editor –v- MS Word • Greenfields approach – extensive discussions – problem diagnosis • - both good and bad effects • Project is still underway – modifications continue to be made over time

21. THE ADVANTAGES- 1 • Capacity to build the tool that we wanted • Mapped to our processes, and culture (homemade - not seen as alien) • Flexibility to modify and take on ideas as we went along - customisation • Capacity to respond to end user feedback

22. THE ADVANTAGES- 2 • Not encumbered with unnecessary features • Small scale manageable product and relatively cheap • Institutional credibility and reputation • In some ways an easier process than evaluation of off the shelf

23. THE DISADVANTAGES- 1 • Pre-occupation with system development as opposed to policy development • Took much longer than envisaged • Heavy dependency on knowledge and expertise of individual staff • Opportunity cost of staff resources

24. THE DISADVANTAGES- 2 • Complexity and time devoted to user testing • Vulnerability in terms of dependency on developer • Stand-alone system, not integrated • User guides and documentation

25. CRITICAL ELEMENTS FOR SUCCESS IN BUILDING- 1 • The right staff for the task • IT support and commitment • Design and innovation capability • Project management expertise • Capacity to translate operations into systems - mapping and flowcharting

26. CRITICAL ELEMENTS FOR SUCCESS IN BUILDING- 2 • Time and Patience • Management understanding and support • Knowing what you want to achieve • Keeping it focused – keeping it small – think of apps for ipads/tablets • Maintaining control over development

27. TO BUILD OR NOT TO BUILD • Q. Are we still satisfied with our decision? • A. Yes in terms of the product, but building again .....?

28. SOME GENERAL OBSERVATIONS ON BUILD OR BUY • Bought systems: • Can be quick to implement but may lack organisational fit • Will still need customisation to reap benefits • Have more features than are needed and hence complexity for users • Tend to involve more ongoing costs (upgrades) than envisaged • Built systems: • Have worked best for very specific purposes on a small scale • Tend to take much more time to develop and deploy • Have tended to founder where the organisational control over the development has been weak • Will often include a lot of hidden costs (opportunity cost factor)