Applying the Cheat Code

I’m pretty hopeless in most games.  There are always levels, other people to compete against, and too many tasks to get done.  Inevitably, I run out of patience before I reach the top state, or I realize I’m not very good at the game and I just give up due to incompetence.  The wonderful thing about many games is the “cheat code.”  The cheat code often gives a specified commodity that might be useful in helping a player reach that top state.  The cheat code might come in the form of unlimited gold to but things, extra power for killing things, or even the ability to jump levels.  My only hope is the cheat code, the lame player’s way to the top.

Wouldn’t it be wonderful if we could apply a cheat code in our work lives?  If there was one, it can’t possibly be as simple as a game where you just google to see if a cheat code exists.  In real life, cheat codes are incredibly hard to find, but perhaps they do exist somewhere.  In the world of technology deployments, we certainly know what are NOT cheat codes.

  • Lift and shift deployments.  Let’s say you have a user experience problem and you want to implement a new core HR system and have much better cloud systems that employees interact with.  The reality is that you will end up with a much better UX, but when your employees log into the new system, they are not going to be any happier with the experience if you did a lift and shift implementation.  Simply going in and changing the technology without any of the other foundational factors really does not help you.  It turns out that other factors like your process design, your portal and content management, and your approval chains are still an obstacle.  Let’s say for example an employee has moved homes.  The fact that they still can’t find documentation in the portal that tells them an address change is only the first step, and payroll/state tax changes might need to happen, or how benefit pans are impacted is still a problem.  Sure, getting into a more beautiful system might give them incremental happiness, but it’s not enough to overcome the significant shortcomings in your overall program.
  • Radical technology transformations only.  In addition to #1, many organizations do radical technology transformations and completely forget the amount of change management they will need, or they defund the change management work stream after the first change order comes in.  It’s always sad to see an organization that has spent millions of dollars implementing technology that users don’t adopt because there was a poor change strategy.  Often there is nothing wrong with the technology, or the processes.  But when a user finds something hard the first time because they were not coached on the new process, the repeat user is hard to come by.
  • Saving costs by changing your processes only.  At the end of the day, you do have to realize that your users really are dissatisfied with your technology too.  Yes, they do hate the process because it takes too long and involves too many people that don’t matter to the outcome, but the interface is terrible and hard to navigate.  I’ve seen company after company implement new processes on top of really old technology and then wonder why the end users still complain.
    The moral of the story here is that people (change), process and technology all matter, and it’s hard to have huge successes if you don’t transform all of these three components together.

The good news is that there actually are some valid cheat codes.

  • Cloud.  Wait, didn’t we just say that you can’t just do technology alone?  Yes we did, but the facts are that today’s best cloud technologies allow organizations not only to shift cost and headcount resources in a highly efficient manner by removing in-house technology management, but process design is simply so much easier than it was with legacy platforms.  We’ll still need to remember to have good change management, but cloud really also makes adoption easier since the UX is so significantly better than older platforms.  Compared to legacy on-premise software, cloud platforms accelerate people, process and technology components and serve as a game changing cheat code.
  • Crowd.  I’m not seeing crowdsourcing in HR yet, but I think it’s a major cheat code for whoever can figure it out first.  We have build such huge and costly infrastructures around shared services, but today’s social technologies combined with metadata/tagging structures have the ability to let end users manage their own inquiries with the corporate cloud.  Imagine the employee who moves homes and asks the corporate crowd what to do, and receives multiple answers from the crowds with links to the address change function in HR, payroll tax forms, and benefits enrollment.  HR now plays the content curator role rather than the source of all content.

The thing to remember is that these cheat codes only are available for a short period of time.  At some point, everyone else figures what the cheat code is and everyone has the advantage.  The early adopters can leverage an advantage for a few years, while laggers suffer higher costs, lower adoption, poorer UX, and slower processes for years to come.

The Evolution of Standardization

So my wife has been on a homemade donut kick lately.  That’s right, every weekend I get to sample another dozen donuts.  Those of you who read often know that my constant struggle to stay fit must work really well when there is a new batch of donuts sitting around the house every Saturday morning.  We’ve got the chocolate dipped, the glazed, the orange glazed.  She says she is going to try a custard filled next.  I’ve sampled a quite a few dough recipes so far.  It started pretty poorly.  She tried to source a recipe off of some random website that sounded reasonable.  The dough turned out to be a bit too firm and chewy.  Therefore, the next go was from an authoritative cookbook by a guy who is a famous executive pastry chef and happens to have a cookbook exclusively about donuts.  This went a bit too far, and the dough was possibly too airy.  Not to be too Goldilocks, but my wife then blended the recipes until she found just the right combination of (turns out it was milk content).  She went from kinda random, to expert driven, and finally figured out somewhere in the middle was going to actually work out.

We’ve been experimenting with the idea of standardization for decades, but more so in the last 15 years as our organizations have gotten more global and those global populations have kept increasing.  The evolution started with zero standardization.  it was really step one as global organizations just did whatever they wanted to.  There were shadow HR systems everywhere, country specific processes, and inconsistent delivery to the business.  Local HR organizations provided generally adequate service to the business, but corporate HR organizations couldn’t get simple head counts let alone anything that was actually useful.

Many organizations have moved to the next stage of evolution, the corporate mandate.  Corporate HR organizations tried to make some sense of this mayhem by implementing core HR systems and mandating that all countries around the globe had to have their employees entered into the common HR system.  This did nothing except ensure that country HR double entered employee data but kept their own individual way of processing transactions.  In almost all cases, the shadow systems (usually spreadsheets) still existed.  The problem is that most organizations think that there is a way to make the corporate mandate work, when really this is as much a failure as the mayhem that existed before.

We’ve also gone down the road of “the only modifications to standard processes will be for local compliance needs.”  Basically, we’ve told the local HR organizations that the local practice is not acceptable and we’re not going to cater to them unless there is a law involved.  Personally, I can’t think of much that less engaging.  Some things make sense, like if we’re transferring an employee, it should not be that different across the world.  Especially if transfers are across country borders, we really do want some consistency.  But when we get to things like how managers work with employee performance or the allocation of spot bonuses, there will often be some local flair that could be important.

What I’ve found is that the corporate HR mandate is just as dysfunctional as the mayhem of no standardization.  This is because the corporate mandate does not solution for local needs in any way, or even admit that local needs might be different.  It’s a totally selfish view by corporate HR organizations that the need of central authority, consistency, governance and data override everything else.  If we treated our personal relationships this way, we’d have no friends.  Luckily, we seem to have some sons socially in our personal lives.  Not so much in business though.

Here’s my solution.  At the end of the day, it’s about the business.  We need to let the in-country businesses decide that they can standardize and want to standardize.  This actually means de-standardizing for them.  In some cases, it’s as simple as providing them with the localizations they need (and that we promised them for compliance reasons, but for some reason we never came through on that promise).  In other cases, it’s giving in on the one extra level of approvals they want for the salary increase process.  In simple terms though, you almost never get what you want by mandate, you get it by partnership.

These days, the new HR systems all pretty much come with packaged localizations, so it’s not like the old days when you had to purchase the country pack and install the thing.  I’ll admit I’m not a fan of massive process customizations for every country – this becomes impossible to manage.  I’m really not a fan of anything other than the minor token tweak.  What we’ve found over time however, is giving in on one or two battles that are genuinely important to the local business will leave you from ten other battles that could have happened.  At the end of the day, it’s about finding that middle ground that gets you the desired results for both corporate HR and the local business at the same time.

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.


Engaging Testers

Testing is one of those things that I would not only be bad at, but I would rather loath to do it.  The infinite detail of what the task entails along with the endless permutations that are possible makes testing seem like an impossible task to me.  I really just can’t focus for as long as it takes.  Thankfully, I’ve always had people who could actually execute the tests for me instead of actually being forced to do more than a few myself.

In a recent round of user testing, I was astounded by the differences in participation rates based on the total preparation before the testing sessions.  For one group of testers, blind initiations were sent out  having not contacted the testers beforehand in any way.  Obviously, the participation rate for these invitations was far less than 50% – I actually think it was closer to 25%.

For a second group of testers (in a different country), testers were initially contacted to briefly explain the request before invitations were sent to those who had time.  After the invitations were sent, follow-up calls were done to revalidate who was showing up and why we needed them.  The day before testing, we sent out emails with the materials they would need.  Obviously, the participation rate for these testers was far higher.  Given that we asked testers before sending calendar invites, you can imagine that we had a 100% acceptance rate.  (ok, there were 3 tentative).  What is surprising though is that we actually had a 100% show rate on over 30 testers, which I think is unheard of.

All I’m really saying here is that when most of us are doing testing for a new implementation, we go through a lot of effort to execute it and get feedback.  UAT is especially important because it’s your last opportunity to create engagement with a small population of end users, and get change management feedback to help target messaging.  There would seem to be a fairly minimal amount of effort to get great feedback versus doing slightly less work but getting pretty mediocre results.


Switching Gears

A long time ago, I used to work for ADP doing pre-sales.  We had great relationships internally with services and implementation, but nonetheless it always seemed to come up that we didn’t always sell with the full lens of reality.  On the other hand, I’d say that we came up with some pretty cool solutions to some pretty tough problems.  In today’s world, I’m generally thought of as a strategist.  I do lots of planning type of work whether it’s strategic 3 year plans, some implementation planning, or just some business case writing.  My current project (depending on when this posts), is a global implementation of a new core HR system for which I had a major hand in writing the business case.  I’ll start by saying that I’m really not suited for implementations, but the experience is quite eye opening.

There is no blame for anything that happens in pre-sales here.  For this current project, we had probably one of the best consultants available both from functional and technical resources.  The problem that happens in pre-sales is that you don’t actually have finalized design yet, so all discussions are really quite hypothetical.  “So how would the application perform ABC?”  “Well, there is option 1, or 2, or 3.”  And of course if we wanted to solve for problem XYZ, there are solutions 7, 8, and 9.  Where the hard part comes in is that while all of the presented solutions are not only possible, but implementationally viable, mixing and matching does not always work.  Solution 2 might be dependent on implementing position management, and solution 3 might not work with solution 7.

When I was with ADP, there was sometimes the thinking that we threw things over the fence.  First of all, I think this happens with all vendors.  Second, I don’t think we ever really threw things over that proverbial fence.  Instead, we just didn’t know what a client was ultimately going to do, so we presented all the possible options.  In a sales cycle, you really don’t have the time to go into every nuance of every solution, and most of the time you have consultants like me driving tight timelines and moving discussions forward before “analysis paralysis” occurs.

I remember back in the day when ERP implementations would last for years – things would come up, we’d switch directions, something else would come up, we’d backtrack because the application didn’t work the way we expected it to.  Reflecting on my own experience, I realize how much we could not have known in the sales cycle, and what that meant for the implementation.  Implementation consultants have a really challenging job.  “But you guys told us we could do option 3!”  “Ok client, but you didn’t tell us that you wanted 1 job code for the entire company.”  (I’m kidding about that one)

Once we have requirements and design, I have a whole new respect for how implementers get around to explaining how the whole application actually works with all the nuances of each functional component.  I’ve always loved how sales consultants can dance around solutions for a system that if completely fictitious at that point, but am equally amazed at watching implementers dance around requirements once they start to solidify.  Hats off.


Rules of the Road

Every time I go to another country, I’m amazed at how tame driving in the US actually is.  People here obey lane laws, there is a fairly strict code of right of way (even if half the drivers don’t truly understand it), and for the most part people are patient.  For those of you unbelievers, think about it this way: even though most of us roll through stops signs, if there is a 4 way stop, we’ll wait our turn.  Compare this to driving in other countries, whether in Thailand, India, Mexico, ah hell, let’s throw Rome in there for kicks.  Compared to the good ‘ol US of A, it’s utter mayhem out there.

Take for example the simple act of staying in your own lane.  In many countries, if you have 2 motorcycles or scooters hanging about, they are going to squeeze into the tightest spot possible.  There is a good chance they are not going to stop at signs and lights, but just roll through if there is any opportunity at all.  What ends up happening is the minor road anarchy that occurs means everyone is on the lookout, weaving, and dodging everyone else.

I’m absolutely convinced that a disciplined approach to driving actually yields not only more speed, but also less effort and increases in safety.  If you stay in your lane, perhaps you can’t squeeze 50 motor vehicles into a space the size of a dime, but you can be far less worried about what is going on around you.  Therefore, the elimination of risking killing those around you means significantly less stress (effort), far fewer accidents that will cause a full stoppage, and of course, the overall speed of the road increases from 30 miles per hour to 60.

The same goes for business process (y’all knew this as coming).  Mayhem causes stress, more risk for full stoppages, and actually slows things down.  Many of you will react with, “But we don’t have mayhem in our organization, we’re just not as disciplined.”  I’m here to deliver the bad news – that’s mayhem folks.

My first ever manager after college used to tell me the same 2 things over and over again:

  1. There is right and there is wrong, and there is a lot less grey than we thing there is.
  2. If it’s really right, it’s actually right 100% of the time without deviations.  Stick to your guns.

Ok, I might not be as sold on the idea that there is very little grey, but I certainly think we make exceptions far too often.  We allow our business partners to sway our processes, to have one-off reports, to feel like we have to be at their full service, beck and call.  We forget that the COE half seriously states that people are the most important asset in the organization.  We allow for “The Business” to make us feel that maximizing our processes around people and talent will get us that one huge sale.  But we forget that enforcing the discipline of our HR practices will yield larger long term results than just that one sale.

Mayhem is bad.  It one of those truths that is fundamental to our universe unless you are a physicist (when chaos is a cool thing).  But being disciplined is hard – to do what we know to be right, not deviate, and grow our HR practices takes true leadership and purpose.


The Pain Threshold

Lance Armstrong was a US National Champion and a World Champion long before he ever won seven (eight?) Tours de France.  The man was always known in cycling circles as the next big gun in US cycling.  In one race (San Diego I think), we were riding a horrifically fast pace, many of us in the pack heckling Lance often simply because he was a captive audience, when he just decided to ride away from us for a while to get a workout in.  Severely humbling.  He was known as a big, strong guy.  The guy who won that world championship was a guy who could sprint, a guy who had incredible short term bursts of power.  But he was never going to win the Tour de France.  That was, until, he got cancer.  Cancer did a couple things to him.  First, he lost a crapload (technical term) of weight and it transformed him into a leaner version of himself, but tapping into the same level of power that could now get him of 5 mountain passes in the Alps instead of just the last 500 meters of a race at 50mph.  Secondly, it taught him to experience pain in a way that he would never experience again.

I’ll be honest, these days when I’m on the bike, the barrier for me is not usually my legs or my lungs.  If I have a few rides under my belt, I’m really pretty good.  The problem is all mental.  I’m not in college anymore and I really don’t like pain.  There are times I’ll be doing an extended climb and one of my riding buddies will “attack” and while I often could follow, something in the back of my head says, “nah.”  I could follow the lead, but I know it will be painful.

Transforming HR is really, really hard work.  For much of the readership, it’s not just hard work for us, it’s even harder work for the employees we would deploy to the effort.  When our execs chose to switch out the payroll system, guess who gets to work long hours in December prior to a January 1 go-live?  We deal with a lot of pain to implement systems, both in effort as well as cash, and the ROI is not always financially obvious, but to get to the top of that hill, it’s something we have to commit to, and something our staffs need to commit to.

In understanding the work behind HR transformation, there are a few things to remember:

  • People actually don’t like change.  When you change their processes, they will resist doing something different than what they have done from years.  It’s not that they don’t want to support better processes, but a certain amount of fear arises when they are unsure how well they will perform in the new environment.
  • People resist making others change.  HR transformation is just that – we are changing ourselves.  But teams often protect people internally realizing that friends will lose jobs, or be forced to make unwanted shifts and compromises.
  • We get to do multiple jobs for a significant amount of time.  Not only are we going to have real jobs to do, but there will be project roles as well.  I don’t care if you bring an army from one of the large consulting firms, the internal team is going to be burdened with more work.
  • Outsourcing done right is hard.  Organizations don’t remember the depth of retained organizations that are needed, SLA’s need to be formulated to be specific and measurable, and internal staff are resistant to seeing their jobs performed differently than how they did them themselves.

Often when we deploy and new system that has the opportunity to be transformational, we focus too much on the external.  We train managers, communicate to employees, figure out who the main audiences are that we need to convert.  We assume that our own people are already bought in.  All I’m saying, is we can spend some time to look internally.  Give them some love and attention.  Encourage and motivate them.  Otherwise you’ve got a Justin at the top of the hill looking down, wondering where the hell I am and why I didn’t make it up there with you.  It was just too much pain.

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.

Nucleating agents for change

Interesting thing about water.  You can pretty significantly influence the temperature at which water freezes  simply by introducing an agent to it.  But there are other times when water actually should freeze, when it is pure and below the freezing temperature, but that water can be held in a liquid state at just below the normal freezing temperature until a nucleating agent is introduced.   We’ve seen in it a variety of environments whether it’s in movies or what not.  I remember a recent mythbusters show (for those of you who watch discovery channel in the U.S.) where they were able to keep a liquid in the liquid state, but once the first ice crystal was introduced, a rapid chain reaction occurred and the rest of the liquid formed into ice in seconds.

HR is much the same.  Any time you are introducing change to the organization, there are times where change happens naturally, and other times when change has to be strongly influenced.  Unfortunately for us, we need those nucleating agents more often than not.  The problem is that we don’t always realize until it’s too late that we needed an agent, or we didn’t know which agent to choose.

I completely realize that we are all sick and tired of the concept of change management, but all too often as I visit my clients, change is treated in the same fashion that it was 10 years ago.  We push out training programs, and we attempt to do the same type of communications.  Let’s be the first to admit to ourselves: HR has no flair for marketing.  We’re in HR partly because we are not salespeople – often times we don’t even understand salespeople.  But sell we must, and when we realize that we don’t have those abilities/competencies, it’s time to find the nucleating agents that will sell for us, and spread the word – forming ice crystals in seconds instead of… well, never.

The best nucleating agents are those who are not only already on our side, but those who are obviously influential.  There are those who have broad networks, and others who simply have the right connections to other important people.  One would think that in Human Resources, we would know who these people are – but we don’t.  In the organizations that do understand that they are not the most effective marketing arm for new rollouts, HR solicits the help of VP’s to communicate the message and brand.  In effect, we have managed to enhance our training and communications materials with and additional layer: change management by edict.  This is not to say that VP level communications are not necessary – in fact their level of sponsorship is very necessary.  But when rolling out new manager portal tools (for example), the people who are going to sell are not the VP’s, but other managers who buy into the product, decide that it is more effective than the prior state, and will selflessly market it for you.  These, indeed, are the true nucleating agents in the organization.

As sick and tired as you all are of hearing people talk about change management, it is still under-budgeted and improperly deployed.  As sick as you are of it, I’m equally sick of most of us not getting it right.  I totally understand that when we are in the throes of implementation, we’re all heads down and grinding away at table configuration and testing, but that is no forgiveness and excuse for messing up the end user rollout.  Better to get the audience right and miss a bit on the config.  So here’s me, asking yet again, find your nucleating agent.  Deploy them well.  Get buy-in and adoption in the seconds it takes to crystalize liquid when the right conditions are met.

Back to Basics

It seems to me that there has been a renewed focus on core HR.  Now I need to tell the truth, I really thought core HR was dead.  I mean, it will always be around, but with the whole industry moving on to cooler things like analytics and talent management, who cares about core HR anyway?  Seriously, core HR is core HR, how many ways can you present an employee transfer or termination process?  How many different vendors can effectively pitch OSHA functionality and expect to win?  Within reason, all the core HR vendors are pretty much on an equal playing field, for one reason or another that I won’t bother going into.

So the industry if focused on talent and analytics.  The problem is that nothing seems to work if you messed up core HR.  People deployed a nice, automated performance process 3 years ago, and they got themselves away from paper.  But at the same time, the industry told them that they didn’t get where they needed to go, and a number of reasons went into this.  First, deploying a talent process just wasn’t enough, and the vendors are madly working on the next level of functionality that will actually help us manage talent as opposed to automating a process.  Secondly however, talent management did not work the first time because we implemented it assuming our core HR systems were already healthy, and they were not.

First, Job.  There seems to be a renewed effort around job these days.  I think we’ve realized that even with all the focus on competencies as a foundational building block of talent, job is still the foundational building block of HR.  Without job, nothing else seems to work.  The problem was that we’ve been neglecting job for eons.  Ok, so that’s a stretch, but it’s certainly not uncommon for many of our organizations to have 5 times as many jobs as we need.  They are not standardized, they are redundant, and they have mismatched naming conventions.  They appear differently from country to country and business unit to business unit.  At the end of the day, a corporate organization can’t make any sense our of our jobs.  So we’ve gone back over the last few years and tried to start tightening up our job tables, which will in turn enable tighter competencies, performance, recruiting, succession, etc…  Not to mention that your analytics are worthless if you can’t use Job as one of your core dimensions in your datamarts.

Second, Organization.  We don’t often think about how we think about org.  Is it a financial hierarchy? Operational? HR? People manager?  When we first implemented organization in core HR years ago, we may have tied it tightly to the payroll engine, and cost centers were the priority at the sacrifice of supervisor chains.  Or we decided that an operaitonal structure made better sense and we sacrificed how HR generalists needed to interact with employees in the structure.  Whatever the tradeoff we made, we didn’t realize that a couple years later, this thing called talent management was going to assume that core HR could provide a clean structure to talent.  I’ve been to organizations where the performance, compensation, succession, and hiring managers were all different.  Who the hell was going to think of that 5 years ago?  huh?  The point is, that we’ve needed to go back to core HR and make some sense of our initial implementations.  And oh yeah, if you’re org is not clean enough to be a dimension in your datamarts – worthless again.

So the moral of the story is this:  if you’re late the the game and just getting to talent now, learn from those before you – fix core HR.  If you are not late to the game, but have not fixed core HR, go do it now.

HR Technology Deployments

I love it when consultants come in and talk to you about all the things you need to do around an implementation.  Obviously your implementer is going to do all the normal things around table configuration and testing, but they often miss some of the bigger items.  When consultants come in to talk about the other stuff, they are usually not particularly comprehensive – they like to talk about change management.  Change management is a wonderful thing, but it still does not mean you’re going to have a successful deployment, no matter how good the change program is.  There are so many things that go into swapping your HR technologies out that missing any of them could spell disaster.

  • Foundation.  I don’t know why so little time is spent on the foundation of any HR system.  Whether it’s core HR or talent management, there are some pretty big foundation issues that you should be looking at before you even think about starting an implementation.  Whether you like it or not, half of your problem with your prior system was not the system.  Half of your problem was that you screwed up the foundation, and had you gotten it right, you’d never be moving to a new system anyway.  Either you messed up the organizational structure and after that it was all downhill, or your jobs never made sense, or your security was horrible and ultimately your own poor security decisions ended up in horrific data quality.  Perhaps you didn’t really think through competencies or goals well enough when you did your first talent management implementation because the talent market was so young that nobody really knew what they were doing.  Either way, fix it now before you configure tables, because your implementer really just wants to get values in the table and stay on time – not help you figure out what the right org structure is for the next 10 years.
  • Decommissioning.  Ok, there are easy parts and hard parts.  The easy parts are reports, interfaces and data conversion.  Heck, that’s just part of any old implementation.  Of course we’re going to convert those.  But wait, did you say we’re not converting history?  How long are we going to have to access the old system for?  Does that mean we’re running reports out of 2 systems?  Wait, have we done analysis around the downstream systems and not just creating interfaces?  Listen, if you’re changing the org structure (see #1 above), you had better prepare every singe downstream system (and downstream from the downstream system) to get ready for new values or structures.  It’s not just about an interface or a report.  What you are doing is going to have far reaching impact – especially if it’s core HR.  Last thing you need to do is mess up some random headcount report that goes to the board of directors just because it comes out of a system 2 interfaces removed from core HR.
  • Implementation.  This is obviously one of the things that will get covered.  Your chosen implementer is going to be all over table configuration, and they are motivated to be on time and under budget.  That’s really where the problems comes in – you want them to be on time and under budget, but you’d also like to think that they are going to be strategically minded and help you out with other things above.  90% of the time they are not.  The cost model that your purchasing people drove them to simply won’t allow them to help you out, and even if thoy could, do you really want a group of people operating in the weeds of table configuration to also operate at the highest strategy levels?  Usually not.
  • Change Management.  Can we please get away from thinking that training and communication is all there is to change management?  Realistically, the estimate you should be using for change management should be about 20% of the implementation budget.  That’s right, if you are spending $1M on implementation, you should have a $200k budget.  When things start to get tight, the first things to go are any real hopes for change management.  If you don’t get your audience analysis and change strategy right, all you’re going to have are vendor provided training and generic communications.  Listen people, the new technology is 80% adoption and 20% everything else in the equation of success.  If you want to be successful, don’t cut the 20% of change management budgets, cut $200k out of your implementation and live without a piece of functionality.

Sorry – am I ranting?  It’s not just implementation, table configuration and change management.  You can get all of those perfect and still have a bad outcome.  In order to get it right, you have to do all of the activities, including the ones that are not totally obvious at first, and including the ones that your consultants are not trying to sell to you.

Which Version of Reality?

I’m an advocate of reality.  It’s nice when you can look at something and immediately recognize it.  In most cases, a reflection of reality is quite obvious.  When I say the word “chair” each and every reader automatically has a concept generate in their heads – some with an armchair, some with an office chair, some with a wood dining room table chair, etc.  Everyone immediately thinks of a chair.  The problem with this is that one persons chair has fabric, another is made of wood, someone else might be thinking plastic or the nylon that makes up modern office furniture.  This is actually one of the reasons why stereotypes and words can be so offensive.  In certain derogatory words, while we all subscribe to different versions of reality, some words take on realities that are predominantly negative and untrue.

From a systems perspective, we need to be particularly careful about defining realities.  Incorrectly defining reality can be problematic not only to the end user and customer audiences, but it can be problematic for downstream systems as well.  Take for example, the way that you build the organization structure in your core HR system.  There are various ways to represent reality.  For starters, there is a definitive reason there is NEVER a single hierarchy.  Financial hierarchies never really match that well to the way HR needs to create supervisor relationships.  Some of us have matrixed organizations that are especially hard to depict.  Some of us have workflow and approval processes that differ between core HR transactions, performance, compensation and succession.  Who pays for a department organizationally may not be the direct supervisor relationship.

When we chose an organizational hierarchy most HR products (not all) embed organization structure, manager structure, and security structure all in the same hierarchy.  While there might be some flexibility, your choices of using a cost structure, an operational structure, a manager structure or anything else becomes critical in how the rest of the world is going to see your company.

Your core HRMS, whether you like it or not, is the system of record for almost all of your employee data.  This means that any downstream interfaces will likely receive some hierarchy information with the employee data, and if those downstream systems don’t realize that you used (example) a manager hierarchy that is not at all reflective of the operational structure, they are going to make the wrong assumptions in setting up how they utilize that employee data.

Reality is pretty important, but we need to recognize that there are multiple versions of reality going on.  HR’s reality is not necessarily how managers perceive the organization, and it’s certainly not how finance sees it.  The solution is simple though, we just need to first recognize what our assumptions were, and second publish those assumptions very specifically.


My road bike is a custom titanium racing frame.  It was made by a guy in Montana who is probably the cleanest welder of titanium bike frames in the world, the guy’s work is just impeccable.  I don’t really need a custom bike – it’s not like my body proportions are weird or anything.  I’m a pretty average guy apparently – or so my builder (Carl Strong of Strong Frames) tells me.  However, I was starting to have some problems on the bike I had never had before.

A few years back, I was riding down a winding road in the rain with my team.  We had decided very early on that we would not go fast, but down this road we were probably averaging over 30mph, and it was wet out.  I remember feeling pretty good and very comfortable with the person in front of me – 30mph in the rain and being consistently less than an inch from having my front wheel touching their rear wheel is nothing to sneeze about.  Then in an instant, the entire world literally went to slow motion.  My rear wheel slid out in the water, I remember vividly as my bike stayed upright sliding down the road sideways as I countersteered the bike trying both to keep from crashing and not drift into oncoming traffic at the same time.  Years later, my body is still creating new scar tissue.

I had lost my balance.

I needed a corrective emotional experience, and I could not do it on my current bike.  I had forgotten how to corner aggressively, and while I could walk into any bike shop and pretty well fit on any bike my size, I needed a custom rig that was made especially for a few specific purposes.  I needed a bike that would make me corner well again and give me confidence.  Carl decided that he would lower the entire bike ((For those who know bikes, he lowered the bottom bracket height by 5 millimeters)).  This minute adjustment lowered my center of gravity by just enough that the wheels would be a significant amount stickier than any other bike on the road.  I also asked him to put the top tube of the bike exactly where my inside knee hits in a corner so that I could use it as leverage in corners. ((I point my knee towards the bike, not into the corner like most people – I use the knee to push the bike upright in a corner, even while I’m pushing on the inside of the bar to countersteer.))

Every now and again in HR, we need a corrective emotional experience.  Our customers get so frustrated with us, complain about inaccurate data, complain about cumbersome processes, ask finance to check our numbers because they think all of our reports are wrong.  Singe bad experiences in key meetings or transactions can haunt us forever, and sometimes the only fix is a new vendor or a “reimplementation.”  Sometimes the fix is spending a ton of money to show the organization that we’re fixed.  While this is not ideal, and while there are often less costly ways of straightening ourselves out, from a change management perspective, our customers sometimes just want us to get rid of the original culprit.

In the psychiatry world, they call these corrective emotional experiences.  Until you have a corrective experience, the last negative experience is just going to linger with you, and you’ll be skeptical of anything with the same roots as the single bad experience.  It’s suboptimal, but when there is no other way around it, a corrective experience might just mean throwing something in the trash and starting over.  You don’t like it and I don’t like it, but I’m just saying sometimes it’s necessary.

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.

Time to Upgrade

Today I got the following message on my browser:

Unfortunately your web-browser is from 2001, which is really, really old in web years. If you would take a moment to upgrade you will find the web has a lot more to offer.

First of all, let me point out that this was not actually my computer or any computer issued by my employer, just in case those of you who know me have any confusion over this.  On my own PC and the one issued by my employer, I run both Mozilla Firefox and Google Chrome, with Chrome as my primary browser.  Let it be known, that this is the first time I have ever seen a message like this, and I thought it was hilarious.

The second thought that came to mind was that if everything was like Google (I also use Gmail, Google Voice, Google Maps, Google Documents, Google Android, Google images for the site – I have no idea about this post’s image – I just thought it was funny (ok, stop advert)) then I would never ever get this message again.  This turned into a nice thought about SaaS.  In a true SaaS environment, you’d never have to upgrade anything individually since someone else is managing it to the latest version release for you.

What is funny is that 2001 is not only old in web years, it’s also old in HR technology years now.  Sure, you might still have some PeopleSoft and SAP sitting around (almost definitely) but I’m pretty sure you’re not on version 8.1 (I’m guessing what was out in 2001) or SAP 4.  Back in 2001, I don’t even know if we were calling “it” talent management yet.  We were still on Web 1.0, and were still getting used to the idea that the internet was going to be around for a while.

The second statement was less humor and more truth.  If I would just get up to date, my entire experience would be so much richer.  This again, is the great thing about SaaS.  While a couple organizations out there are going to semiannual or annual major releases, there are still quite a few companies that are pushing out new functionality on a quarterly basis.  While each of these does not necessarily have features that are either high impact or high need by all client populations, over time, not having those updates would have resulted in a pretty large gap in experience for your end users.  Luckily in a SaaS environment, you don’t have to worry about that.

Certainly there are obstacles to the upgrades.  Every now and then it means that you have a downstream system receiving data that has to undergo a change in the interface, or you may have applied a customization in the system that needs to be thought out.  Perhaps there is just a cost parameter that is prohibitive.  All things considered, these obstacles should have been thought through during the initial implementation cycle.  You never think about your software as “it’s so cool now that I just want to keep it this way forever, therefore I’ll put so many barriers to upgrade in that I’ll never do it.”  Instead, we think we’re doing the right thing for our organizations by allowing modifications and exceptions, but 5 years down the road we realize how much better off we would have been if we were running our users on a current version.

Implementing Smart Codes

So you’re going to implement new job codes, or department codes, or whatever.  Someone in the organization has a great idea:  “let’s make the codes smart!”  I mean, what better idea to manage the information within the code than to implant attributes within the code itself.  So you go down the road:  Job category will be digit 1, job family will be digit 2, EEO code will be digit 3, grade will be digit 4.  If you’re on PeopleSoft, I think you only have 6 digits to work with, so 4 is probably a sensible place to stop.

Wait… Perhaps digit 1 was actually the sensible place to stop.

You see, a long time ago, when we were running off of mainframe computers, and we didn’t have a robust job table to work with, it was important to capture all the attributes of the job in the code.  I mean, if you didn’t capture all that information in the code, how were you ever going to get a report on all people performing a finance function?  The only place to store a job attribute would have been the job code.  Think Dewey Decimal System.  Brilliant at the time, but would we really catalog a library that way if we could reconstruct every library in the world simultaneously?  Lucky for us, we don’t have mainframe computers anymore.

You see, today we have what are called relational databases.  They have actually been around for a very long time.  Relational databases allow us to store attributes in tables which have many fields on them.  This lets us actually use these additional fields to select and report on, rather than trying to force a report to sort on Digit 3.

Does it even make sense to include attributes in the code from a definition perspective?  Do all those attributes end up helping us manage the information?  I’m going to argue almost not at all.  There is some benefit to being able to visually recognize that a code is an HR job, but I’m not sure there is much use outside of that.  We need to utilize the table structure for what it was meant to do.

Explaining Facts and Dimensions

Fact:  A turnover rate based on a calculation

Dimension:  Historical time trend of turnover

Fact:  The number of heads in your HR database

Dimension:  The breakdown of headcount by organization

Fact:  The number of FTE’s in any given job code

Dimension:  The demographic analysis of FTE’s in job code

I honestly have no idea how many of you have ever heard of a “star schema.”  I’m not sure I ever wanted to, and I’m not sure knowing what it is called has ever really helped me out.  But somehow, I picked it up along the way (not surprising for a data warehouse and analytics guy) and every once in a while I am reminded how difficult it is to explain analytical reporting to HR people who don’t already have it.  And the simple fact is that most of us don’t really have it yet, or only have small bits in a couple of our applications.

Facts are all those things that we can quantify.  They are… well, facts.  They are the things we run ad hoc or operational reports against, and are usually the things that we have reported against for years.  They are those turnover reports, or the headcount reports.

Dimensions on the other hand, are the attributes we want to dynamically apply to the facts.  Lets say I get a turnover report.  I’d love to right click on one of the bars in the bar chart and see a historical trend for turnover.  So in this case, the dimension is time.  Or that same right click might have given me the option to see the turnover by business unit, so now the dimension is organization.  Perhaps we want turnover by age or gender instead – so now it’s a demographic parameter.

Sometimes, a data element can be a fact in one report and a dimension in another.  So age, a dimension in our turnover report, can also be a fact.  We run a report on the headcount by age groupings.  However, when we see that report, we decide that we want to know the race allocation within our 30-39 band, so now age is the fact and race is the dimension.

I have no idea if all that makes sense in text (and without actually seeing it), and I’m really avoiding trying to explain a ‘cube” which I’m fairly sure I’ve tried to do before.  But there’s a reason we talk about this stuff.  When you set up analytics, you set up these star schema first.  After you drop the data into your data warehouse, you get to create these “schema” which form the basis of your analytics.  If you don’t know beforehand how you might want to see your data, you’re going to wind up with a very limited set of dimensions and 2 months down the road, you’ll be wondering why your implementer didn’t ask you if you wanted turnover by age, race and gender.  Implementers implement what you tell them to.  It’s up to you to understand what your own requirements are.  The problem with data warehouse, is that understanding what the requirements are only happens when you understand the capabilities of the technology.

Pretty is not Useful

Not all of us have fancy business intelligence tools and cool dashboards with great graphs prepared for us in our business environments yet.  If we’re lucky, we belong to organizations that have spent millions of dollars figuring out how to get us analytics when we log into self service environments.  Or perhaps we have bought into a cool talent application tool that already had the functionality.  We’ve been prophesying that business intelligence would go directly to the manager/end user rather than having requests for ad hoc reports that would have to be processed for days before the end user ever got any data.  Even if we don’t have all the cool dashboards and business intelligence tools at our disposal, I’m hoping that many of us have used the cool image and graphing functionality in MS Office 2007.  Indeed, the software now presents all sorts of data in all sorts of new, flashy and easy to build ways.  From a consulting perspective, beautiful and sexy is a wonderful thing.

The problem is that…. well, there’s a problem.

Have you noticed that many of the charts you are getting are 3 dimensional?  From my perspective, they are beautiful, and the formatting is impeccable, but I can’t really tell where the top of the bar lines up with the axis points anymore.  Sure I can tell that the top of any bar in a bar chart is…. oh between $20-25M?  Yeah – that’s problematic.  I have a $5M effort rate.

I’m not sure what to do with the dashboards.  Managers want quick access and a visual regarding where they are and how their organization is performing.  But at the end of the day, don’t the want a data dump into Excel anyway?  (warning: data privacy problem, but that’s a different topic).

Hopefully when we build the BI environment, we were smart.  After building our flashy but not very useful graph, we spent another $100K and build the drill-through charts.  You know, the ones where you click on the indecipherable bar to get a chart that presents the real data?  What we really did was create something that was pretty to look at, and then force the manager to click to get at what she really wants.  And we paid for it.  Sounds like good, smart design based on great user experience principles to me.

Ok, I know that there will be a revolt if I actually suggest that everyone goes back to 2D charts.  We all love our flashy reports and dashboards.  But can we just make sure they are actually helpful before we publish the stuff?

Up In The Air – Packing 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.

The first of these moments occurred when George Cloony’s character looks at his Anna (I have no idea what her last name was)’s character’s suitcase and begins throwing things out of it.  I’ve gotten to the point where I have packed for 2 week international trips inclusive of 3 suits, workout clothes, extra flip flop (sandals), casual clothes, neck ties, etc… all in a convenient carryon bag.  Cloony’s character is exactly right.  The 35 minutes spent waiting for a checked bag after you land at the arrival city is a considerable amount of time each year for many travelers.  I’d guess that if I checked a bag every time I flew, I’d spend in excess of two 24 hour days in the airport baggage claim area.

In HR software terms, what I’m talking about is design, and most specifically design towards business requirements.  There is all too often a desire from the business user to define every possible element.  Division 1 wants to have 3 extra fields, while Division 2 things that their users will revolt if the “Commit” button is not located in the top right corner of the MSS form.  This is all fine, but we tend to spend time working through this detailed minutia rather than solving for the business requirement.  There are always tradeoffs to be had, and usually in the big picture, the strategic business requirement is much more desirable that forcing a few users to get used to the placement of a button, or to make do without a few fields.

Unfortunately, back in the 90’s when we were all in love with the power of ERP and how we could all manage to our individual uniqueness, we allowed our organizations to get used to dictating to us in HRIT how our applications should be delivered.  We still see it today even though re now realize that 90% of customizations are not driven by a business need, but by user preference.  In today’s world of SaaS vendors, many organizations are quickly realizing that not only are vendors creating user environments that are based on leading practice usability, but that vendor design is often better than anything customers can come up with anyway.  However, there still seems to be a sense from the user population that small design items are important, and HRIS often sees minor customizations as simply minor.

My point is this: get through the airport with a carryon.  Minor customizations seem minor, but when you try to stuff them all in a carryon, you realize you’ll have to check that bag.  You have sacrificed future upgrade ease, you’ve decided that the tradeoff for small customs is more important than business outcomes, and you’ve once again told your ultimate end user that they know more about running HR than you do.  Don’t do it, carryons are a wonderful thing.

Burnt to a Crisp

I have a friend who happens to have a particular way of ordering steaks. This is interesting for a number of reasons. First, I’m not sure how many Indian guys order steaks. Perhaps Gautam can shed some light on this for me. (I think my friend lives in Goa if that makes a difference). Second however, he orders steak in a way that just kills me every time. “I’d like it well done, really well done, like… burnt to a crisp well done.” I don’t really understand this. I mean, if you’ve cooked it this much, you’ve cooked any texture and flavor out of this thing. Why bother ordering a $40 piece of meat if you’re just going to kill it for the second and third time?

We do the same thing in HR technology. Not necessarily overcooking things, but definitely going overboard. We tend to look at the HR technology world in extremes. We’re either 100% vanilla, or we allow customization to the point of burden and we can’t support the application anymore. We like to support either lean HR processes that are sustainable and scalable, but we forget the impact on our end user customers, or we support those end user customers to such a degree that the view on sustainability and scalability is forgotten except in philosophical terms.

Unfortunately, our HR technology utilization in these terms is not usually driven by ourselves. Most often, we have a corporate philosophy that says we should take care of our customers at all costs (or take care of efficiency at all cost). We often are held hostage by those philosophies, but then 5 years down the road, we’re bought into them as well, and tell vendors and external consultants that we can’t possibly change.

In almost every consulting engagement, I do what I call a set of “sliders.” A display of extremes, and where the current state and future state lies within these extremes. In almost all cases, organizations don’t sit on either end of the extremes, but in a happy medium somewhere towards the middle. For example, in my “face to face contact vs. self service” slider, most organizations weigh in on the side of wanting to have more self service than face to face contact with their employees. However, at the same time, even HR technologists who answer my surveys intuitively know that there is a balance to be served, and that the answer is not all the way to one end of the bar, but a mix of approaches that combines both types of interaction. What is more telling, is that non HR technologists also get it, but know they have an equally hard time being centrists in practice. As I’ve built a few years of these “sliders” my experience is that organizations want to be in the middle, but the historic philosophical approach is usually an extreme, and that is a hard past to get away from.

At the end of the day, we often implement what we are most comfortable with, in a manner that continues to make us comfortable. We realize that our HR technology approach is deeply influenced by how the rest of the HR organization interacts with the enterprise, but we should also understand that we an equal or larger influencer on how HR services are delivered to the organization. I think as HR technology organizations go, we should try to start exercising some of this influence, rather than sitting back and “taking it.”

For me, I order my steaks a perfect medium. (sometimes a medium rare).