Dysfunctional Self Service

So I’ve been away for a year and I’ve let this website go a little bit.  (I just started back up in September) I mean, if you click on any number of links, you’ll find error pages, pages that don’t load, or just pages that don’t display correctly.  Basically, letting go for a year while and applying little to no system maintenance has killed the site.  The content mostly works, but there are actually posts that will also no longer appear due to some coding that is old and out of date.  I used to be incredibly diligent when I updated the site – there is an enormous amount of custom code in this thing just because I liked playing around.  But updating the core engine (WordPress) usually meant updating the various plugins I had and then checking a couple of areas where I had customized some code and CSS.  Now, updates are rather haphazard, and I barely do any QA when I apply updates.

Imagine if this happened in HR systems.  Indeed you all know that it does.  Pretty much every client I have ever talked to has a complete mess when it comes to HR content on their intranets.  Everything and anything goes from stale-dated content, to multiple versions, to bad links.  How many of us have changed a business process and forgotten to update the documentation for it online and remove the old documentation?

For the most part, we are all really diligent about applying upgrades and patches, but horrible when it comes to the non-technology stuff.  I’d say we’re getting more aware that our supporting content sucks, but we also are doing very little about it.  Even when we implement cool technology, that does not mitigate the fact that we still need people managing and versioning our stuff in the background.

Let’s also not forget about all of our document management systems and knowledge base applications.  Far be it for me to guess, so I won’t – way more than half of my clients have employe intranet sites that have multiple versions of the same documents out there, documents that apply to policies that no longer exist, documents from vendors that are long gone, etc.  This isn’t just a systems issue – it’s pervasive in HR anywhere a process exists.

What happens is that people end up being satisfied with the process within the technology, but very dissatisfied with the process overall.  It really does not matter how much they loved <insert vendor name here> because their overall impression was that it was frustrating.  No matter how easy the technology actually was, they end up hating <insert vendor name here> because of all the stuff we didn’t do around it.  We have to be better not only about the technology, but making sure all the wraparounds and loose ends are tied up.


Missing Steps

I started my day on Monday at 4am when my cab picked me up to head to the airport.  As he missed the airport exit (how does that even happen?) I thought to myself that missing my plane would cause me to miss a series of 4 conference calls in the afternoon.  Given that it was a 5 hour flight, that would also mean that I’d wind up on the redeye later in the afternoon, but still miss the start time for my meeting the following morning.  One I realized that there seems to be very little slack in my week’s schedule.  Any one thing goes wrong, my week falls apart and I start cancelling things.  Luckily for me, I actually had to build some time for me to get to the airport early and do a call in the airport lounge (which I missed).

We often time our HR technology projects based on fictitious end dates.  Sure, there are a few out there that make a whole lot of sense.  It’s really nice if payroll implementations can go live on January 1.  It’s nice if new benefits vendors go live in time for a new open enrollment season.  But every once in a while, our CEO tells us in October that we had better have a new, global talent management system by January 1 in time for February performance reviews.  Huh?

In most of our projects, we have actually messed up our overall project timelines.  We don’t spend enough time thinking about some fairly significant parts of an implementation.  We’re all about getting the requirements blueprint down and hitting the config tables.  As you all know, I’m a big fan of prep.  When we rush into implementations, there just isn’t enough time to reengineer our processes and realign what we are doing to our core HR strategies.  We find out over and over again that we’ve simply reimplemented the same processes or the same config and not made HR any better.  We find out that we didn’t spend time cleaning up our data and our reports are still horrible.

  1. Map to our mission and create actionable measurements of progress – Just because we map to our mission in the business case to implement a new system, does not mean we can stop measuring success.  Success needs to be measured before implementation, during implementation, and score carded repeatedly after go live.
  2. Improve the quality of our data – data cleansing is not always sufficient.  Yes, it’s true that we should not just import data and begin a new system with the same crappy data that we had before, but it is equally wrong to clean the data without addressing the fundamental problems that created the bad data in the first place.  More on this in the next bullet.
  3. Redesign our processes – Process redesign is not just for the sake of aligning process with the new technologies.  It’s an opportunity to address other issues within your environment.  Often, our processes are actually the cause of data issues we have.  Because we don’t use high quality data practices throughout our workflow, we end up auditing data on the back end when we catch only a fraction of the issues rather than ensuring high data quality throughout.

If we miss a step, it does not mean we don’t go live.  Nor does it mean that our implementation was not any good.  However, it might mean that our long term success is suboptimal.  For HR to have continued credibility with upper management, we have to do all the steps that it takes to create long term success.

Please Don’t Do It

I have to admit that I spend more time in airports than I would like to admit.  This means that I spend some time in airport bathrooms where a very disturbing event happens with unbelievable frequency.  I’d say that about every other trip to the bathroom, someone is in there talking on the phone.  I don’t mean listening to a conference call while on mute.  I mean ON THE PHONE TALKING!  I’ve heard people talking on the phone while in a stall!  (seriously guys, GROSS!!)  Perhaps it’s rather mean of me, but whenever I see this, my immediate reaction is to flush the closest toilet three times in immediate succession.  ((I’m also the guy who walks down the aisle on the plane and feels perfectly comfortable exclaiming, “whoever that is, you gotta stop farting!”))

Here’s my “please don’t” list based on preventable stuff I’ve seen in the past year:

  • Don’t outsource and think that everything will be handled.  Retain some key people.  You outsourced transactions, not strategy, so keep a retained strategic organization at the very least.
  • Don’t implement without doing some high level process design first.  If you feel like being a taker of any and all process flows your vendor is going to give you, then so be it.  But chances are you do have a legitimate business requirement that will drive better adoption if you implement it, and chances are also that your vendor can handle it.  If you wait to look at processes until implementation, it’s probably too late.
  • Don’t think that automation and self service is the same as usability.  They are not.  We are often so pleased with ourselves that we moved another transaction to the web that we have completely forgotten that the overall organizational impact is negative.  If we didn’t craft the transaction the right way, we may have decreased data quality, and we probably increased the overall organizational burden to complete the transaction.
  • Don’t think you’re special.  Every organization thinks they are unique.  Let me tell you, you really are not.  If all of you were unique, Software as a Service would not exist.  ERP would be king and every organization in the world would be driving major customization to make things work.
  • Don’t give up on the culture.  I remember an agricultural company that employed migrant farmworkers and needed to automate benefits enrollments to the web (about 8 years ago).  HR was determined that these workers could not possibly have computers let alone internet connections.  In the end, they got a 60% on-line enrollment rate, seriously modifying their expectations.  Remember, these are migrant farm workers.  When we think culture or politics is too much of an obstacle, realize that it is not.
  • Don’t forget that the technology is the smallest part of the implementation.  It takes all our time and costs a whole lot of money, but the end of the story is not about the technology, but the processes you built around it and how you deployed it.  The technology does not solve anything – it allows HR to solve whatever issues are out there with new tools.

I could probably go on and on, but this plane is about to land.  If I’m ever on the phone with you and I hear 3 flushes in quick succession, I’m hanging up on you.

Understanding HR Data Governance

We bought my wife a new bike this weekend.  She is not usually a bike rider, and the last time I took her out riding with me, she swore never to go riding with me ever again.  I suppose that one does not necessarily realize this if one does not have sufficient self awareness or awareness of the surroundings when in college, but it’s been about 15 years since my last bike ride with her.  This time around, rather than trying to take her out on (what I guess were) fairly advanced mountain biking trails, we decided that we would buy her a bike for cruising around town – a bike to have fun on, but certainly not to go fast on.  Today was my first bike ride with her, and we decided to head out to San Francisco’s new Chinatown over on Clement street to buy some dim sum.  We then proceeded to the Golden Gate Park where we sat by Stowe Lake eating. 

I know that we’re all sick of talking about Data Governance, but the reality is that most of us still have not implemented it.  In fact, I’m going to go as far as to suggest that most of us don’t really know what it is, even though we execute forms of data governance in our everyday lives.

Data Governance basically consists of three things:

  1. How we make decisions about data,
  2. How we define the data,
  3. How we execute processes that involve data.

To start, I really needed to make a decision about riding a bike around the town with my wife.  While I might enjoy the fast and aggressive weekend rides, spending time with my wife in a way that we both would enjoy was paramount.  The next step was to define the type of bike we’d get her – in this case, not a race worthy mountain or road bike, but a street type of a bike.  Finally, we needed to head out and ride at a pace and in a style that would keep her interested, in this case, food and the park.

The HR data governance structure begins with an organizational structure that allows us to make good decisions.  Usually this is a committee or set of groups that escalates what the needs are and how to deal with them. 

We then need to define the data.  Thinking that as we reach across multiple HR systems in a variety of global countries and regions, that we can easily define data might be naive.  Each system has their own definition and countries have widely varying approaches to data as well.  Without a common understanding, it’s next to impossible to have a resultant set of data outputs and outcomes that is reliable.

Lastly, we need to reformulate all of our data processes in a way that is consistent with our data definitions and maintains our quality standards.  Data governance and the definitional process is a predecessor to any HR process, but without HR process, the purpose of data governance (data quality and access controls) is a promise that cannot be kept.

At the end of the day, HR data is an enabler, and we have all experienced HR data that is so messy that it no longer enables anything.  Data Governance is the solution to this problem, but it comes with multiple components, each of which must be implemented for an overall governance program to have any use.

Up In The Air – Boarding Theory

Many of the people I know have watched a film called “Up in the Air.”  Indeed, I suppose it was a popular file garnering several Oscar nominations.  (I have no idea if it won anything as I don’t watch the Oscars.)  Several people have told me how personal the film was, and other than the whole “affair thing” I’d have to say that I agree.  I’ll take a moment to point out that I am nowhere close to 10 million miles either.  However, there were certain points of the film that as I watched it (on a 4 hour flight of course) I chuckled to myself and realized that I do the same thing.  ((ok, I admit that I copied this intro from another post on the same movie))

At one point in the film, Cloony and Anna (someone or other) are passing through the security lines and he chooses the line with the Japanese businessmen.  While she accuses him of being racist ((perhaps I should define racism sometime, but I’m not sure this blog is the right place)), Cloony’s character explains about his choice.  The Japanese on one hand seem to like slip-on shoes, while the other security line had children or something or other.  Having passed through the security line just this morning, there is absolutely no doubt in my mind that I go through the same type of decision making process both before and during the security experience.  You see, even though I have many shoes with laces, I only own one pair that is slip-on.  These are my “airport shoes.”  God forbid that I would have to spend time taking off my shoes and then tying them back up when I should be running to my gate (for which I’m inevitably late for).

As I approached the ID checker with my driver’s license today, I quickly scanned the people in line in front of me.  Two lines, does everyone look like they travel?  Do they look like they know what they are doing?  Anyone with children?  Anyone look like they are from Idaho taking their first trip in 10 years?  Yes, I am that absurd and will happily deal with all your criticisms for it as it gets me through the security line seconds or minutes faster.

At the end of the day, my experience is all about process – usually a set of processes stacked end to end.  If I fail any one of these many airport processes, I’m annoyed and my entire user experience is diminished.  I have a regular driver that takes me to the airport (he is NEVER late), I check into my flight and scan seats on my phone while in the car, I print my boarding pass when I get to the airport, get through security as quickly as I can, head to the airport lounge where I don’t want anyone standing in front of me to check in, and then to the gate where again, I want to board early.  I have optimized my airport experience as much as possible from and end to end perspective, but I have also optimized each individual sub process such as the security line.

This is really no different from your HR service delivery end users whether it’s self service, a call center or dealing with an HR business partner locally.  The difference is that your end user customers don’t have as much flexibility in customizing their experience.  However, the same can be said for them – any failure in the end to end process inevitably taints their perception of the entire experience, not matter how trivial that taint was.

Today, the end user experience can be automated and made more efficient from a large cadre of technical capabilities.  Pop screens that alert call center reps to caller information have been around for ages, and the implementation and integration of HR knowledgebase to information governance is steadily becoming more prominent.  The knowledgebase information is becoming more available through tier 0 tools, and when tier 0 is not the right solution, case tracking at the end user level can be available.

I’m going to continue wearing slip-on shoes to the airport, only because I know it saves to 15 seconds.  It might seem trivial, but it’s those little things that make a difference in the end user experience.

The “Other”

Why can’t we get along with payroll?  What makes them so different?  It really does not matter when Payroll reports up to HR and when they report up to Finance.  There always seems to be some friction.  Often we like to think that they are just “different” people.  HR people are strategic and nurturing and outgoing.  Payroll people, well, are like accountants.  They are introverts, task oriented, and live in a cube with a spreadsheet.  It’s true that there may be some substance to the stereotypes, but at the end of the day, it’s not the type of people we are that causes friction, but our different and unique work experiences.

The payroll experience is definitely one of structure.  There are specific rules that one must comply with, specific deadlines, and all of this must be driven by high quality data.  HR would like to think that we abide by the same philosophical rules of compliance and process and data quality, but I don’t think our HR world operates in quite the same sphere of severity that payroll does.  Lets face it, there is much less flexibility in interpretation for getting your taxes right versus your EEO reports (you simply can’t go “undeclared” for taxes).  payroll processes means that if an employee is not in the system when they run paychecks, or if a timecard is still wrong, that payroll still has to run.  When HR talks about data quality, we’re often not sure how many people are even employed in the organization on any given day.  If payroll if off by $1 for every employee, they will get a mean-spirited phone call for 90% of the population.  When we can’t run an accurate headcount, our executives sigh and give us a $1M project to figure it out.

Our core values might be the same, but their consequences are drastically worse when they don’t perform.  We don’t like to admit it, but we are the cause of so many of payroll’s problems.  There is always another new hire, or some off cycle spiff that has to get processed.  Because payroll data is often downstream from HR data from a process perspective, and we don’t understand payroll’s consequence severity, we are not always tolerant of their deadlines and rigid processes.

So be nice to your payroll people.  They might be downstream from HR from a data process perspective, but from an employee engagement perspective, payroll is one of our key influencers.  Nothing makes employees unhappy faster than bad payrolls.

Support versus Change, Evolution versus Revolution

Jacob Morgan wrote a piece about adoption a while back, and he had a pretty interesting concept around supporting business process as opposed to change management.  This is really quite new to me, as we’ve always talked about change management and behavioral change as opposed to a softer concept of “support.”

You need to speak in terms of “supporting” rather than “changing”.  “Change” implies that people are doing things wrong.  “Support” however, implies that you recognize value of their efforts and you want to help further those efforts.  You can’t walk into a company and say “you guys are idiots, everything you’re doing is wrong,” because that’s not going to accomplish anything.  ((Morgan, Jacob, December 21, 2009.  “Strategic Principles for Enterprise 2.0 Implementation.”))

There are a couple problems with this.  Often, when you’re implementing a new system rather than upgrading, you really are looking for opportunities to change the current business process.  While we often implement on top of old process because we didn’t do the proper amount of future state visioning prior to kicking off the implementation, the purpose of the implementation is usually to fix the old system or process.  Seldom is it that we are spending millions on the implementation of a new product to simply support, enhance and bolster the existing.

I’m not sure you can’t walk into a company and say “you guys are idiots.”  We’ll, that’s not how I do it, and rarely do I think anyone is an idiot.  But it’s pretty common that I know their process has room for fundamental change and in most cases, they are hiring me because they know it too.  Same goes for implementing software, they usually know they need the help.

I’ll admit that the same does not go for the end user.  The end user does not see business process at the same level that corporate sponsors of these projects do, and often do think that all is ok.  But they also don’t necessarily see the opportunities that lie in leading practices around the HR industry either.  This is where adoption really occurs, is the end user and helping them get to a point of understanding that not only is this better for the organization, but also where the enhancements that will help them grow also.

I don’t think we are usually “supporting” or “evolving” their current business state.  I think usually we are trying to change things up.