This is how I explain my job to people … I make Workday work.
In 2012, at about this time of year, I got my first look at Workday. I was brought in for a project to assist with an iCIMS to Workday integration (remember: in those days the WD ATS didn’t exist and there weren’t a lot of people doing integration work on the system).
The project team was fairly small with just three people; a WD analyst, a WD project manager and me (aka the person who literally knew nothing of WD architecture). When we started scoping out the integration we seemed to uncover about 10 issues on some days (those were slow days) and about 30 issues on other days (those were busy days). And most of these issues, it turned out, were related to some configuration or security setting within WD. What was supposed to be a 6 week integration project turned into an 18 month project that also served as my crash course in “How to Make Workday Work.”
I’ve been on a lot of projects since then and with each project I learn something new. So here, gathered from these years of experience, are five things to be mindful of when implementing Workday:
Your implementation partner is not your partner; they are Workday’s partner
Workday has a very cultivated list of implementation partners who they approve to work on the system. Their mutual goal, of course, is to get WD set up and live as quickly and efficiently as possible. I once heard it compared to a real estate transaction; the WD implementation partner is the Seller’s Agent, not the Buyer’s agent. So while both help facilitate the task at hand, each serves their own interests. Between these two entities, a term that will get tossed around is “MVP” or minimum viable product. Now they might not say this to you … but they say it. And here is what that means for you: they’re going to do enough work to have you sign-off that it’s working, but then, once you’ve signed, the work stops (unless of course you sign a change order and pay more). They want the system to work but not always exactly how you need it to work.
Manage your timeline
This is a big one. When you start your project kick off you’re going to be establishing a timeline for getting everything done: you will have deadlines for everything. This, of course, is solid project management. However, unless your internal team has their time 100% dedicated to the implementation, those timelines will likely not work. In other words, if your internal project team members have other job functions (Payroll, Recruiting, Compensation, Benefits, etc.), the deadlines laid out in the project plan will likely come way too fast to be met. The Workbooks for loading data in to WD take a long time to populate and, in my opinion, anyone who has to fill one out for your company should really be sent sustenance and/or rewards (wine is always a good idea) on a weekly basis.
It’s YOUR system so make sure the configurations align to how you do business
One of the first meetings you’ll have is the “business process review meeting” as the implementation team who does your configuration will talk to you about how you run your business/manage HR so they can set up your “rules.” The goal of this is to assist in defining how WD will work for your specific organization. While a lot of companies take this time to revisit their internal business processes, I recommend that you first configure the system how you currently work so that everyone knows what to expect when validating the configuration. If you simultaneously map out new processes and ways of doing things while also configuring a new system, you run the risk of creating confusion. This also, unfortunately, makes it harder for users to say with confidence “it works like we intended”. Quite frankly we see this occur at close to 90% of the projects we work on which ultimately leads to unintended issues as we must work longer to get things cleaned up.
Test, Test, Test. (And then Test some more)
Everyone hates testing. It’s meticulously brain-numbing and boring, it takes forever, and you have to document everything. That being said, testing remains the optimal way to ensure you have a working system when you go live. When we’re at the testing phase on a project I tell everyone to try and break it. Really. (It’s a sandbox so it’s quite OK if they do). The reason for this is that if it can be broken in testing, that means it can be broken in production (and that is really really REALLY bad). Here’s a tip for testing: make sure you have all the different user roles test their functions. Let managers do management tasks and let employees do employee stuff. Involve as many people as you can. Not only will this ensure you have a better system post-testing, this also teaches the testers how the new system will work (bonus!)
Be at 100% before you sign-off and “go live”.
Remember that MVP (minimum variable product) phrase I mentioned earlier? Here’s where we come full circle. This is your system; you paid for it and you paid to implement. Make sure it works (100%) for you before you say it’s good to go because once you go live your implementation partner is done and gone. And when they’re done and gone that means you are the one in charge of maintaining your system. And maintaining your system includes making Workday…work.
Just like me.