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.

 

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.

Balance

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.

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.

Maintaining Cadence

In cycling, one of the core concepts when you are trying to maintain good “form” is the maintenance of cadence. Basically, a cyclist is most efficient when the legs are spinning at around 90 to 110 cycles per minute. The idea is that for each pedal stroke, a certain number of watts must be generated to propel the cyclist forward at any given speed. If you pedal too slowly, your legs must generate more watts and thus will tire more quickly. Pedal too fast, and now you’re burning valuable energy but not generating enough watts. Somewhere around 100 cadence/RPM is about the point of equilibrium. You could spin faster, but you’re probably burning more energy spinning that fast. Any slower, you are pushing too many watts and fatiguing your muscles more quickly.

The same goes for so many HR projects. You either spend too much time getting the strategy done (low cadence, but you run out of steam) or you spend too little time on it (high cadence, but wasted effort). If you start with strategy, I’ve seen many projects spend 6 months planning, and then either run out of budgets, have organizations reprioritize, or have projects lose focus. There is a finite amount of strategic planning you can do before you have to get down to business. This is not to say that the strategy and preparation stops, this might indeed keep going, but real life practicality and the effort of the actual implementation has to start at some point. You can only plan for so much, and after a while the project dictates and determines the realities of your actions. Instead, what I often see happening is that some organizations plan so much, that they realize they are totally unprepared or incapable of implementing the desired course of action. Instead of planning “just enough” and taking bite sized chunks, they go in realizing that there are connections to their project all over the organization, and can’t tackle all the workstreams at once – in the end abandoning many critical paths. Many vendors call this “analysis paralysis.” Yes, there is a name for it because it actually happens more often than you probably think.

On the other hand, some projects spend almost no time planning. This is probably true of the great majority of HR technology projects. There is a brief determination of need, and then you go implement functionality. With this approach, there is much wasted effort as you allow the project to determine what your governance structure is, approach, how the organization connects dots between technology, process and service delivery. Rather than having a broad view in the beginning of the project, many organizations go deep too soon, and don’t realize that there are things sitting around the sides of the project that also need attention. Unfortunately, this is true of many vendor implementations. At the end of the day, a software vendor simply wants to get you to go live, and often there are issues that go on a log for later resolution, but once you’re live, many issues get put away never to be seen again.

I’d guess that the right amount of preparation for a normal sized software implementation is in the 2-3 months range. You do indeed need to figure out what your software approach is and how the project fits into the overall technology footprint. You need to figure out how service delivery in all aspects is impacted. And you need to figure out governance. Lastly, you need to have a pretty good plan of what you are attacking, when, how and with whom. If you have a larger ERP implementation, the planning process could be a bit longer. (Vendor selections not included in these guesstimates). At the end of the day, I think the story is simply that there is Goldilocks amount of preparation that is “just right” instead of not too much or not too little.

Users First, Company Second

I feel like I always talk about change management and adoption.  When implementing a new system, I can definitely say that over the last few years I’ve seen a marked improvement in the diligence of internal implementation project managers in stressing the importance of behavioral change and end user adoption.  It is honestly so easy once you get into implementations to forget about the strategic components of the implementation and simply sit around doing functional requirements and config.  Unfortunately this is the tactical behind the project, and often minimizes the strategic.  I was pleased to see the 2.0 Adoption Community and Jacob Morgan stress this as well.

To really see successful adoption companies need to focus on the benefits of the user first and the benefits of the company second.  You can’t approach a user and ask them to change behaviors because it benefits the company.  Companies need to approach the user and tell them how it will benefit them.  This is a bit of psychological approach but it’s important.  Employees put their needs first and company needs second so if you show them how Enterprise 2.0 can help them make their job easier then they are much more likely to listen.

You also need to focus on use cases  before deploying a platform and strategy.  So for example how is someone in the marketing department going to benefit  from Enterprise 2.0 vs someone from the product development team.  You need to develop use cases for the various departments and understand what the risks, challenges, and opportunities are for each department.  Finally, you need to understand how each department is going to measure success/failure.  I’ll go into this a bit more in a future post but the point here is that everyone is going to have different needs and you must understand what those needs are.  ((Morgan, Jacob, December 21, 2009.  “Strategic Principles for Enterprise 2.0 Implementation.”))

I like the simply phrased “user first and company second.”  While I understand that the user never gets the opportunity to change behaviors if the product does not get configured, that does not change that the primary stress is to ensure end user adoption and behavioral change.  In terms of behavioral change, Jacob Morgan is absolutely correct.  You’ve heard me talk about behavioral change and the “personal win” before.  Employee’s don’t really care about the benefit to the company.  Sometimes they don’t even care about the efficiency gains they get from a process and work perspective.  It’s about some intangible personal win that they derive – sometimes it’s the participation in the implementation that they gain advantage from, or the experience in the software that is much sought after.  Either way, you have to determine what will make an employee excited and figure out how to message so that you are deploying the right messages to the right audiences.

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.

UFO’s: Unfinished Objects

I’m not sure who first coined the term “shelfware.”  Most of our IT departments have all sorts of stuff we have purchased that we intend to implement but just haven’t done so yet.  Or we have implementations that we have abandoned, or we have technology and strategy roadmaps that are mid way through because we ran out of funding, or got stopped by a temporary glitch we didn’t have the mental will to push through.  All in all, we have too much in the way of “shelfware” whether it’s actual software or just projects sitting around.  And we don’t finish enough of them.

As a consultant, I’m always glad for the role I have.  To be completely honest, I’m a strategist (whatever that means).  I’m not good at the detailed stuff – testing and QA always drove me crazy, and I’m a really bad coder – because I like shortcuts and don’t like to figure out where I missed a semicolon.  In one sense, I’m really glad I don’t usually have to stick around for the implementation of what I come up with.  It’s nice to hand off to people at application vendors or system integrators to run an implementation because they are much better at that stuff than I am.  At the same time, it’s incredible to me the amount of strategy projects that get held up or never get going after I leave.

In most cases, organization’s are just not staffed well enough to handle additional project loads.  The realities of day to day operations cause them to lose focus, and these organizations also seem to have issues with using external consultants to do implementation work.  Granted it’s the most costly way to go, but it’s also the easiest way to maintain your focus on the plan.  Internal PMO organizations don’t usually like to play around with HR stuff, and that’s a shame.

Lexy Martin had a post a while back about unfinishable objects.

I’ve noticed, however, that in my studio I have a few UFOs — a quilter’s term for “unfinished objects.” I like to think of myself as not a quitter — as someone who finishes what I start. The UFO from that class, I’ve decided will never be finished as originally planned at that class. And, oh my…it feels good to recognize that. I declare it totally unfinishable! Of course, I will go through some doubts: 1. Is it unfinishable because my techniques are not up to it? 2. Is it unfinishable because I didn’t like the teacher and she did not help me to excel? 3. Is it unfinishable because…. You know what, I don’t need to know the reason. What I do know is that by declaring that one effort unfinishable,I feel ever so much more creative! Plus, it frees up one of my favorite fabrics that I want to use in another quilt project that is to be a gift for dear friends.  ((Martin, Alexia, December 22, 2009.  “Giving yourself permission not to finish frees up energy – another quilting/work intersection.”  Retrived from http://lexymartin.blogspot.com on December 25, 2009.))

The first is what I already mentioned above.  Sometimes I need to plan better for an organization that is just not willing to approve an ongoing project with an external implementor.  Organizations that really want to implement SAP on their own after deciding it’s the best fit for them…. Well… perhaps it’s my fault that I only told them 9 times and not 10 times that it’s really unwise to try to do it inhouse.  That’s a bit tongue in check, but the reality is that perhaps it’s my fault that even with the best intentions, internal project teams fail to get funding that they need and just can’t handle the workload themselves.  That comes to Lexy’s second point.  Consultants often don’t provide a backup plan.  We put so much time into preparing a business case that justifies the first option that when an organization can’t implement an ERP or global service delivery model (or whatever), that we didn’t tell them what’s next.  Maybe just putting their 15 different payrolls on ADP was the right way to go, and they would have gotten funding for it.  Not to avoid any mea culpa’s that should be coming my way, but consultants don’t always have the organizational knowledge to know how well you’ll be able to navigate through the approval and funding processes, we’re almost always guided by your judgment and the judgment of the executive sponsors.  If you say you can do it, we kind of believe you.

That brings us to the last point.  Sometimes, instead of blindly plugging along in the current state, or leaving a project on the shelf and pretending you’ll get to it eventually, you just need to get back to square one and start over.  Usually, it’s not really square one, most consultants will have brought a number of good models for you to go after, and it’s just a re-evaluation of the new best fit with the new funding realities in mind.  The point is, not to let anything sit there and fester while you do nothing.  There was a good reason to tackle a project to begin with, and that reason is still there, whether it be service delivery, technology, process or anything else.  Declare it a loss, and reevaluate the project so you can get going again.

UFO’s: Unfinished Objects

http://lexymartin.blogspot.com/2009/12/giving-yourself-permission-not-to.html

I’m not sure who first coined the term “shelfware.” Most of our IT departments have all sorts of stuff we have purchased that we intend to implement but just haven’t done so yet. Or we have implementations that we have abandoned, or we have technology and strategy roadmaps that are mid way through because we ran out of funding, or got stopped by a temporary glitch we didn’t have the mental will to push through. All in all, we have too much in the way of “shelfware” whether it’s actual software or just projects sitting around. And we don’t finish enough of them.

As a consultant, I’m always glad for the role I have. To be completely honest, I’m a strategist (whatever that means). I’m not good at the detailed stuff – testing and QA always drove me crazy, and I’m a really bad coder – because I like shortcuts and don’t like to figure out where I missed a semicolon. In one sense, I’m really glad I don’t usually have to stick around for the implementation of what I come up with. It’s nice to hand off to people at application vendors or system integrators to run an implementation because they are much better at that stuff than I am. At the same time, it’s incredible to me the amount of strategy projects that get held up or never get going after I leave.

In most cases, organization’s are just not staffed well enough to handle additional project loads. The realities of day to day operations cause them to lose focus, and these organizations also seem to have issues with using external consultants to do implementation work. Granted it’s the most costly way to go, but it’s also the easiest way to maintain your focus on the plan. Internal PMO organizations don’t usually like to play around with HR stuff, and that’s a shame.

Lexy Martin had a post a while back about unfinishable objects.

I’ve noticed, however, that in my studio I have a few UFOs — a quilter’s term for “unfinished objects.” I like to think of myself as not a quitter — as someone who finishes what I start. The UFO from that class, I’ve decided will never be finished as originally planned at that class. And, oh my…it feels good to recognize that. I declare it totally unfinishable! Of course, I will go through some doubts: 1. Is it unfinishable because my techniques are not up to it? 2. Is it unfinishable because I didn’t like the teacher and she did not help me to excel? 3. Is it unfinishable because…. You know what, I don’t need to know the reason. What I do know is that by declaring that one effort unfinishable,I feel ever so much more creative! Plus, it frees up one of my favorite fabrics that I want to use in another quilt project that is to be a gift for dear friends. ((Martin, Alexia, December 22, 2009. “Giving yourself permission not to finish frees up energy – another quilting/work intersection.” Retrived from http://lexymartin.blogspot.com on December 25, 2009.))

The first is what I already mentioned above. Sometimes I need to plan better for an organization that is just not willing to approve an ongoing project with an external implementor. Organizations that really want to implement SAP on their own after deciding it’s the best fit for them…. Well… perhaps it’s my fault that I only told them 9 times and not 10 times that it’s really unwise to try to do it inhouse. That’s a bit tongue in check, but the reality is that perhaps it’s my fault that even with the best intentions, internal project teams fail to get funding that they need and just can’t handle the workload themselves. That comes to Lexy’s second point. Consultants often don’t provide a backup plan. We put so much time into preparing a business case that justifies the first option that when an organization can’t implement an ERP or global service delivery model (or whatever), that we didn’t tell them what’s next. Maybe just putting their 15 different payrolls on ADP was the right way to go, and they would have gotten funding for it. Not to avoid any mea culpa’s that should be coming my way, but consultants don’t always have the organizational knowledge to know how well you’ll be able to navigate through the approval and funding processes, we’re almost always guided by your judgment and the judgment of the executive sponsors. If you say you can do it, we kind of believe you.

That brings us to the last point. Sometimes, instead of blindly plugging along in the current state, or leaving a project on the shelf and pretending you’ll get to it eventually, you just need to get back to square one and start over. Usually, it’s not really square one, most consultants will have brought a number of good models for you to go after, and it’s just a re-evaluation of the new best fit with the new funding realities in mind. The point is, not to let anything sit there and fester while you do nothing. There was a good reason to tackle a project to begin with, and that reason is still there, whether it be service delivery, technology, process or anything else. Declare it a loss, and reevaluate the project so you can get going again.

Implementation and the “Personal Win”

We always end up talking about employee adoption whenever we are implementing anything whether it’s technology, process or anything else.  When we talk about adoption, we’re really talking change management, and in that we are talking about changing both behaviors of people as well as attitudes.  We want to convert both their minds as well as their actions on a daily and ongoing basis.

To really create change and adoption, we often talk about certain change paths we need to make inroads with.  First, there has to be leadership support.  Hey, if the leaders are not sure, there is no way we should be rolling anything out.  They need to be on board and vocal about it.  Second, employees need to feel like they have some skin in the game – like they have some form of influence in their own future.  Third, they have to understand what the benefit it.  And this benefit is not the benefit to the organization, it’s the personal benefit they derive that makes them feel like it’s worth the effort.  In some cases, the organizational benefit will be the personal win.  But lets face the facts, it isn’t always.

To really see successful adoption companies need to focus on the benefits of the user first and the benefits of the company second.  You can’t approach a user and ask them to change behaviors because it benefits the company.  Companies need to approach the user and tell them how it will benefit them.  This is a bit of psychological approach but it’s important.  Employees put their needs first and company needs second so if you show them how Enterprise 2.0 can help them make their job easier then they are much more likely to listen.  ((Morgan, Jacob, December 21, 2009.  “Strategic Principles for Enterprise 2.0 Implementation.  Retrieved from http://www.20adoptioncommunity.com/ on December 22, 2009.))

The concept of the “personal win” has been being used for years by sales people.  They realize that if you want an executive to buy a product, not only does it have to be the right thing for the organization, but the executive has to feel like they also derive some benefit.  The same goes for employees.  The personal win is not the threat of consequences if they don’t adopt the program, and it’s not usually the meager incentive compensation that is tied to performance either.  Rather, it’s how their lives are made easier, or given skills to make them more marketable, or provided with opportunities to interact with peers and supervisors.  The personal win in most cases not only makes the employee more interested in the program, but it will increase their engagement to their job.  Finding the right personal win tells employees that you’re looking out for them as well as making their jobs easier.

Jacob above is right.  We don’t usually tell people how the program benefits them.  We assume people are so engaged that telling them it helps the company is all we need.  I doubt we are really that good.  We need to target our communications better and increase our adoption and success rates of implementations.