A Workday vs. Salesforce Implementation: Lessons Learned from Georgetown University

Beth Hayes, Deputy CIO and Director of Enterprise Services at Vassar College, interviews Linda Buckley, Assistant Vice President for Administrative Applications at Georgetown University, about some differences between implementing Workday and Salesforce.

The Tambellini Group has written extensively on SIS/ERP, including Workday, as well as on CRM trends and Salesforce in higher ed. You can explore Tambellini’s current reports here.

Beth: Can you tell us a bit about your role? I believe that you’re one of the first, a pioneer in higher ed, who has been involved in the implementation of both Workday and Salesforce.

Linda: I led the stabilization effort for Workday HCM which Georgetown implemented in January 2012. I then transitioned to Project Manager for Workday Financials in July 2014, followed by the enterprise-wide Salesforce project, GU360, in 2016 as the Assistant Vice President for Administrative Applications. My charge is to replace our aging enterprise administrative applications employing a “cloud first strategy.”

Beth: The Workday implementation came first and you learned to work with a cloud based system that uses a third party system implementation partner. What did your team look like for that project?

Linda: We had a team of 10-12 in-house staff, primarily business-functional analysts (75%), along with a small technical team with integrations, reporting and security expertise. Each had a specialty in their own area but also had a general understanding of the work of others on the team. They had strong business-analytical skills, a willingness to learn, and were open to change. Our team was supplemented by subject matter experts from across the business units at Georgetown. We also had 8-12 dedicated implementation partner staff.

Beth: How did you define what your team took on versus work the implementation partner did?

Linda: Our partners had expertise in Workday. They worked with us to understand our specific use cases and helped us learn to configure the system so that we would be able to support it on our own after we went live. Georgetown was responsible for defining business process configurations, testing, security, documentation, maintaining integrations with other enterprise systems, reporting and training. I’m very proud to say that after the initial go-live Georgetown was able to implement the time tracking and recruitment modules on its own and the team continues to refine the system and adopt new features.

Beth: Salesforce came next. What was different about that team?

Linda: When we undertook GU360, we designed our hiring strategy around our Workday experience which turns out to not have been the best approach. The internal GU Salesforce team is about the same size as the Workday team, but the skill set required is very different. Whereas Workday has an established data model and the key to successful implementation is understanding how to configure the system for your organization’s use cases, Salesforce is very different. With Salesforce, which is infinitely configurable and customizable, you need a team that is highly attuned to, and capable of building the data model and object structure that will best support your organization’s use cases. So the current Salesforce team has fewer business analysts—we rely on our partners in the business units to help define stories for implementation—but more technically-oriented individuals who manage profiles/permission sets, user experience/interface design, and who can develop triggers, custom objects, reports and who develop and maintain integrations using Mulesoft with our enterprise systems. And when necessary, this team also does some coding in Salesforce’s Apex language or Lightning Components to perform automation, support user interface challenges or solve unique integration needs. We also worked with an implementation team, Appirio, and also with Affinaquest who assisted with the implementation of our Advancement solution. They brought technical architects, business analysts and UX/UI designers to the project. In the case of GU360, the team composition is approximately 60% technical analysts and 40% business analysts.

Beth: What lessons did you learn about the different team makeup and skills that others should heed?

Linda: We realized the value of a Minimally Viable Product and collecting user stories and “pain points” rather than “requirements.” This is key when you are designing in a Platform-as-a-Service (PaaS) as opposed to implementing a Software-as-a-Service (SaaS). And this is the key to the differences in skill sets required. With SaaS, you don’t need to worry about the data architecture, you just need to be aware of it. For SaaS systems like Workday, you primarily need individuals who understand the business processes and reporting required. With PaaS, you have the freedom and responsibility to design the user experience and data structure; how you set up the data is the key to what you can do with the system. So you don’t need expert coders, per se, but you do need team members who can think about data, how data is used, and how it should be portrayed so that you can maintain scalability in your applications. Strong technical skills are required with a PaaS like Salesforce, whereas more business-analytic skills are needed in a Saas like Workday to ensure configuration management, integrations with other systems and the ability to create custom objects to maximize the power of the platform.

Beth: Thank you Linda! We appreciate you sharing your experience.

Want to know more about Georgetown’s student experience with GU360? Check out this video:

The views and opinions expressed in this article are those of the author and do not necessarily reflect the official policy or position of The Tambellini Group.