Build vs. Buy and the Toothpaste Dilemma

By: John Henry, Oregon State University

Have you ever been struck with how many choices we have for individual products in national chain grocery stores? A few simple needs at home leads to a simple list: apples, paper towels and toothpaste. So at the store a few Organic Gala apples find their way next to a roll of “Quicker-Picker-Upper” and on to the dental care isle. The wall of toothpaste seems to be 10 feet tall and 300 feet long. And the choices… oh so many choices! Are your teeth sensitive or do they have a little extra tarter around the edges? Do you want whiter teeth or fresher breath (or does having both diminish one)? And sometimes it just comes down to how you define yourself (i.e. your personality) – do you want to get away from the chemicals and choose the natural brand? Do you want the best for your money and trust the glossy name brand? Or do you reject all marketing attempts to control your choices and go with generic?

The toothpaste dilemma, though not a high-risk decision, does shadow other kinds of decisions like the build versus buy decision. What are the perceived costs and benefits of this decision? How would this decision reflect on my/our identity? What responsibility will I have to take on? What control will I have to give up? When it came to a new graduate admissions system the Oregon State Graduate School explored the available options and their ramifications before heading to the checkout counter.

In the Higher Education technology sphere it is sometimes easy to know that your systems are less than optimal. For example when you hear the following (from others or yourself): “That’s a great idea, unfortunately our system is not set up to do it, it would take a significant amount of resources to make that small-ish change, and we have a long list of essential updates and bug-fixes in the backlog which come first.” That was the situation when, after a change in Graduate School leadership, we decided to prioritize IT investment and we were given the task of looking for a solution to our less than optimal system problems.

Initially we only considered currently available products. During a 16 month product exploration we looked at EnrollmentRx, TargetX, GradWeb, CollegeNet, Apply Yourself (Hobson’s), Embark, Nolij Connect and Salesforce with on campus demonstrations with the first four. To be honest at that time we felt a certain degree of palatable disinterest in Salesforce (I think it had something to do with the name). The OSU College of Business had been using it for many years and were strong advocates – happily providing demonstrations and touting the benefits. It wasn’t until after a failed RFP search for an out-of-the-box solution and the experience of Dreamforce ’14 (with the pre-conference Admin training) that we started to understand the potential power of Salesforce – not just for the Graduate School but to support a multitude of functions across campus. That is to say, we had a glimpse behind the curtain of the potential campus benefits. However at the time we had more immediate concerns.

During the process of assessing our environment, our requirements and the available products we came to the conclusion that we needed a degree of flexibility which was not then available on the market. We are fond of calling our Graduate School organizational structure: “centrally decentralized.” We have roughly 80 different graduate programs across 11 academic colleges and 3 campuses (including Ecampus). The Graduate School provides a central admissions application, which nearly all programs use, each program then evaluates their applications and provides their admission recommendations to the Graduate School to validate on University standards. The trick here is that the programs span the gamut of disciplines and therefore each may need to evaluate different application materials. Since our old application system couldn’t handle sub-application types, such as programs within a graduate admission type, the programs had to find application work-arounds. In practice this often meant a confusing multi-step application process for applicants and manual multi-system application management for programs. What we needed was an uber flexible application customization management system. A vision of traveling down the build path began to develop after a thorough requirements elicitation and definition engagement with a Salesforce Partner. We further engaged a senior Technical Architect with this partner later as we developed our underlying data and security architecture.

There is much involved in the decision to build a product, and many long-reaching responsibilities to consider. One consideration is the support from executive sponsors. For example, the support from the Graduate School Dean, Brenda McComb, has been invaluable as has the interest and support from the OSU Vice Provost for Information Services and CIO, Lois Brooks as well as the OSU Provost and Executive Vice President, Sabah Randhawa. Their support has enabled us to travel the path we are on in creating a solution which fits OSU’s extreme flexibility needs. Their support is also enabling the collaboration of units across campus in one central Org – leveraging the power of University collaboration at its best. That, however, is perhaps a topic for another time.

The next time you find yourself standing in front of the wall-of-toothpaste think about how nice it would be to have someone standing there who has similar values as you and is happy to share their personal experiences with different brands. On second thought – that sounds creepy – imagine instead that you are at the Higher Education Summit making a build vs. buy decision (or any number of other decisions involved in exploring Salesforce functionality on campus) and imagine learning from others experiences in similar situations. Suddenly the toothpaste dilemma isn’t quite as daunting.