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

Challenges

Anita English, Howard UniversityPaul Woloch, University of Western Sydney

WACUBO – ACUPA ConferenceDenver, 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/7 Availability.

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

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

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)

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

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

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

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

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

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

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

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

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

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

TO BUILD OR NOT TO BUILD

• Q. Are we still satisfied with our decision?• A. Yes in terms of the product, but building

again .....?

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)