Lean HR Now Available!


Yes, the frequency of posts has dropped significantly around these parts.  Now you know why.

I’m thrilled to share that my first book, Lean HR, is now available on Amazon.  I really wanted to get it ready for all of you I will see on the conference circuit this year, and we made it with a couple of weeks to spare.

I’ll have more to say about the writing process another time, which has given me more material than I would have imagined.  Did you know I have very strong feelings about page gutters and font sizes?  Because apparently I do.

So check it out if you are into that kind of thing.  The Kindle version should be available shortly.  And if you happen to pick up a copy and see me somewhere, I will totally deface it by scribbling my name on a page of your choice.

Living Pareto Charts

We’ve talked about Pareto Charts before.  They are a lot of fun.  Really.  I mean it.  But I was recently introduced to a new tool, and couldn’t wait to share it.

When you are living in a Lean world, part of your job is looking at certain metrics every day.  When one of your metrics goes off the rails, it becomes the leader’s job to determine what is causing the defect and define the corrective action.  The living Pareto chart will help you do that in real time.  Let’s take a closer look:

Count of incident is on the left side.  Reasons for defect are on the bottom.  Dates in the grid are a list of each time that particular incident occurred.  Stuck on your Gemba board, this allows you to get good data at the point of failure each time.  But even more important is that red line.  That line is the upper control limit.  If the number of incidents cross that line, it’s time to take action.

From there you have your choice of tools, of course.  Five Whys, Fishbone, FEMA, or plenty of others.  It doesn’t really matter which one you use.  But this tool lets you track how often you have a defect, what caused the defect, and tells you when it is time to act.  I love it.  And I couldn’t wait to share.

Give it a shot.  You’ll love it, too.


Pareto Charts

By a show of hands, who here knows the 80/20 rule?  Anyone?  OK, a few of you.  It’s a simple concept that is amazingly consistent.  It goes something like this…

  • 80% of your defects are a result of 20% of the causes.
  • 80% of your revenue comes from 20% of your customers.
  • 80% of your productivity will come in 20% of your working hours.

…and so on.  It’s not always perfect, but the gist of it is that there are usually a lot of little things and one or two big things that drive results.  And, in theory, it makes sense.  But how do you show it?  Enter the Pareto Chart. Named for Vilfredo Pareto, helps to illustrate this in your problem solving exercises.  Let’s take a look at an example.

Let’s look at the pieces of the chart:

  • The vertical bars represent discrete data.  Each bar is a single cause of the overall effect being examined (in this case, reasons for late arrival).  You can see the count at the bottom of the chart.  Data elements are always listed left to right in decreasing order.
  • The blue line represents the cumulative percentage, increasing from left to right.
  • The left axis is the discrete count of incidents for each cause data point.
  • The right axis is the cumulative percentage of the causes, compared to total events.

OK, so what does it mean?  Well, it’s a simple way to show that most of your issues are caused by one or two main culprits.  Building a chart like this will help you safely ignore a whole lot of little things and focus on the big ones.  In this case, most of the “late arrivals” are caused by alarm issues.  No need to worry about traffic or hot water issues.  Just deal with the big ticket items, and your results will change dramatically.

Simple?  Yup.  A bit elementary?  Indeed.  Powerful?  Sure can be.  Especially if you need to align your stakeholders and resources on a few efforts.  Visually aides are always useful in this regard especially if there is someone really passionate about traffic or hot water at the table.  Pareto charts can help you get them focused, move away from emotional debate, and get your efforts on the right track.


Lean Is Not The Enemy of Innovation

Friend of the show Kathy Duffy and I had a conversation recently about this.  After some ongoing discussions, I found the idea of Lean and Innovation being bitter enemies was prevalent enough to merit some discussion.

If you think Innovation and Lean aren’t chummy, you haven’t spent much time in a real Lean environment.  Let’s think about what makes up Innovation.

  • The introduction of something new
  • The process of creating new ideas, methods, products or services

Pretty straightforward.  Now let’s think about what Lean really gets you.

  • Identify new ways of performing work with less waste
  • Eliminate non-value added (busywork) to allow for more valued activities to be completed in less time
  • Identify application methods to increase throughput and productivity

Yeah, total opposites.

Look, I get that there are people who don’t understand Lean.  (Obviously not you, since you read the blog.  You get it, right?)  There is a mindset that Lean stands for “Less Employees Are Needed.”  There’s a fear that Lean means layoffs, and only the bare minimum of people will be around after.

The truth is that most companies are looking to grow, not shrink.  That means more people, not fewer.  But to do so effectively means getting rid of the busywork and letting you focus on doing things that matter to your customers.  That’s how you increase your business, that’s how you grow.  Lean helps you find that busywork so you can eschew it.

There is also the continuous improvement side of Lean.  It’s not enough to just eliminate the easy to find waste.  You have to look deeper and keep finding ways to go faster, safer and at higher levels of quality.  To do that, you have to be creative and innovative.  Just try coming up with better answers with no new ideas.

The idea that Lean and Innovation are enemies is nonsensical.  Lean and Innovation are like peanut butter and jelly.  Both good, but way better together.


From the Archives: Affinity Mapping

There are plenty of tools you can use in implementing a good idea.  And plenty of ways to generate a lot of ideas.  But how do you figure out what to do when you have a lot of ideas and only a limited resource set?  Today, we’ll look at one method to heard your cat-like brainwave, affinity mapping.

Affinity maps, also called affinity diagrams, are all about taking lots of ideas and whittling them down into manageable buckets.  The easiest way to do so is to set up your idea generation the right way from the start.  This means getting a clear understanding of the issue (think “how do we increase revenue 10% with minimal investment?”, not “improve performance!”).  As ideas are generated, put them on sticky notes and post them up on the wall to be reviewed.  It might look a little something like…

Ideally, you’re going to have at least 20 ideas on the wall.  If not, go back to the generation phase.  You need to think more before you start actions.

Next, the  ideas you have generated are sorted into these categories by the entire team, and this is the fun part, without discussion.  Why?  It helps you focus on the idea on the page, not the history (“That’s never worked before!”), the feasibility (“We’ve never found a way to do that!”) or the personal connection (“You just put that up there because you want to hire my sister!”)  It’s fine to move things that have been moved already.  It’s fine to move someone else’s idea.  Just keep going until the sorting slows to a crawl.

Not all notes will find a home.  Some ideas are real outliers.  They are often the really, really good ones.  Or the really, really bad ones.  Either is OK at this point.  If no one can figure out where it belongs, let it stand alone.  If there are clearly strong feelings about placing an idea in more than one group, don’t get hung up on it.  Make a duplicate of the idea and put it in both places.  No big deal.

Once that is done, work as a team to create a headline or summary for each group.  (Yes, it’s fine to speak to each other again.  But if you really enjoy the silence, then keep it up.)  For example, from our revenue question above, we might have groups that include:

  • Staffing
  • Product Innovation
  • Marketing
  • DSOs/Accounts Receivable
  • New Channels for existing product

When complete, your idea board will look more like this…

Now you have a mass of ideas that are somewhat sorted.  You can take the buckets and break them down further, eliminate duplicates or ideas that aren’t feasible, and work toward deciding if any of these are valid solutions to your problems.

If you’ve used this method and have additional thoughts, or if you have any questions on it, please feel free to leave a comment below!

From the Archives: SIPOC

This one goes out to my man John Nykolaiszyn.  Dude loves him some SIPOC.

SIPOC is one of the least used and least understood tools in the box.  A rudimentary understanding of it can make you look like an expert.

SIPOC stands for Suppliers, Inputs, Processes, Outputs and Customers.  It looks a little something like this…

Pretty simple, right?  The more complex versions are followed by a basic process map.  Let’s break it down and see the how and why of using it.

Why am I doing this?

SIPOC is a great tool for the times you are called in to help someone else fix a problem.  If you have no background with the process, this is where you start.  It’s also a good place to start when the process owners can’t verbalize exactly what they do or how they do it.  The components are pretty straightforward.

Suppliers:  Upstream.  Who do you get things from?

Inputs: What do you need to get the work done?

Process: What is it, would you say, that you do here?

Outputs: What has to happen for you to be “done”?

Customers: Downstream.  Who cares about this process working correctly?

How detailed does it have to be?

Not detailed at all.  The SIPOC is a starting point, not a “fix-it” tool.  Here’s an example of one for talent acquisition:

The nice thing about starting with the SIPOC is that is will prompt discussing with the team around who and what are really involved.  For instance, in the above example, we have only three customers listed.  They all make sense, and they are the people that we often think of as customers of talent acquisition.  And we are likely to build our process to serve them.

As a facilitator, though, your role is to challenge that assumption.  So you might ask “What about the candidates?  Are they customers, too?”  Of course they are.  But if they aren’t listed, you won’t be designing the process for them.  And if the process owners don’t realize it, you need to help them figure it out.

Is that it?

Almost.  We also like to have a high level process map, just to get an idea of what gets done.  This is not a detailed Visio map.  It is a very simple version.  For example:

Easy, right?  But this is the starting point for deep dives.  Remember, this tool is most useful in a situation where you come in with little to no knowledge of the process.  You will eventually want to do a more detailed process review, but this will get you started.

OK, so I made a SIPOC.  Now what?

Once you have a basic understanding of the process and the elements, you can start working on the issues.  But don’t toss the SIPOC aside.  I find them to be most useful stuck on the wall where they are always visible.  If nothing else, you will want to keep that customer list in front of you as work to improve and redesign a process.  That list will help you remember who you are working for, and will often help in decision making when you reach a tough question.

Little’s Law

Um…not Chicken Little. That’s totally different.


Play around with Lean long enough, and it is bound to happen.  Someone will ask you to do math.  It’s ok.  You can handle it, I promise.

Lean is about reducing waste, increasing speed and efficiency.  The end result should be faster completion of tasks.  How do you know if it is working?  Well, you measure it, of course.  In the manufacturing world, you can grab a stopwatch, walk the line, and see how long it took to produce a particular widget.  Excellent.  The transactional world is a bit different, though.  That’s where Little’s Law can help.  Here’s the formula…

Amount of WIP (Work In Process)

Lead Time =  ———————————————–

Average Completion Rate

Let’s break that down, shall we?

Lead Time

The answer to the “how long does it take?” question.  This is the metric we want to drive down.  You may also see this called “Takt Time.”  It tells your client how long they should expect to wait between submission and fulfillment.

Amount of WIP (Work In Process)

The number of items on which you are working.  Any task you have touched is WIP.  (You can read more about WIP here.)

Average Completion Rate

How many of these tasks did you complete in a day/week/month/year.  A simple counting exercise.  You may not know how long it really takes you to complete a talent development session, but you probably know how many you did last week.

Nothing too scary here, right?  So what does it mean?  First, if gives you a solid foundation on which you can start to calculate how long those tasks actually take.  Second, it tells us that to improve your cycle time, you have to either increase the completion rate or reduce the WIP.  If we go way back to our discussion on the Process Equation, you’ll recall that we aren’t likely to change the completion rate (the Y in this case) without changing something about the steps in the work (the set of Xs).  That takes time.  But the WIP is totally in our control, as we have discussed.

It’s worth noting that your cycle time starts when any given request enters WIP.  Work in the holding queue isn’t WIP, so the clock starts when you touch the request.  Some of you may be crying foul at this idea.  If I don’t count the time a request waits for me to work on it, of course I’ll finish it in less time.  Yup.  And you’ll do it in such a way that you free up the time you spent trying stay organized, and you can focus on production.  That time adds up to more work completed, which also drives down cycle time.

This will require you to create a baseline cycle time based on your WIP capacity.  Otherwise, you will be comparing an unlimited WIP to a limited one, which are not the same thing.  Don’t get caught up in that.  Lean Accounting goes through the same thing when first starting.  You are changing your measurement system and your work system.  You can’t compare the old system to the new one with metrics that only apply to one of them.  Try, and you’ll get some messy, misleading data.

You have to change your way of thinking, and start measuring differently.  I promise you though, you’ll see a difference as you use the WIP queue and measure your cycle time consistently.  Get your quick wins here, then start pulling apart the Xs of your Average Completion Rate.  This is a great tool to help you understand your workload and get it under control.  And remember, measuring your cycle time isn’t just a good idea.

It’s the law.


Crack the WIP

WIP is a fundamental Lean concept, and in general is the biggest obstacle to productivity in your life.

WIP, or Work In Process, is the queue of emails, call, requests, forms, approvals, and other assorted minutiae of your daily routine.  WIP encompasses all the work that is on your plate at any given moment, regardless of how much attention you can spare.  As humans, we have a limited about of GAC (give-a-crap) to go around, so we have to make decisions on the fly about how to parse it out.  We also know that the more important work often gets pushed aside to deal with the loudest demands.  It’s suboptimal, but it’s life.

Wouldn’t it be nice to have a little more control?  Of course it would.  But to get there, you have to take a path that is a bit counterintuitive.

To make your life easier, you need to reduce the WIP.  You can’t control the requests for your time in most cases, but you can set up a system to control the flow of the requests.  And believe it or not, doing so will help you work faster and reduce the time it takes to get to each request.  But that’s another post.

Your filter will require a few things.

Define Capacity

There are some fancy formulas you can use to calculate your optimal workload.  But for the sake of simplicity, think about how many tasks you can actually do at any given time.  For example, I’ve talked with recruiters who tell me they can work on twenty requests at a time, but more than that slows us down.  This is part of that counterintuitive mindset I mentioned.

Think of your work like a highway.  Plenty of research has shown that a road has a certain capacity at which it can optimally function.  Adding just one more car slows everyone down.  That’s why you see stoplights for cars entering the highway in areas with high congestion.  They are controlling the cars entering the road, which are essentially WIP.  They are items in transit from point A to point B.  Adding too many slows down each item.

What’s your capacity?  We’ll talk about those formulas another time.  For now, just realize you can’t do everything at once, and trying to do so will hurt each and every item in queue.

Selection Criteria

So if you don’t work on everything at once, how do you know where to start?  It’s probably fair to say that not every request you receive is of equal value or need.  Some are more time sensitive, some may have a greater impact on the organization, so may just be really difficult.  It’s up to you to determine how you handle each of them, and which one needs your attention.

You can’t evaluate them individually to decide how to queue them, though.  The moment you do so, they are WIP, which defeats the purpose.  Not to mention the fact that the time you spend evaluation is waste.  And that’s not OK.

Instead, you need to establish selection criteria, your own personal triage unit.  For a handy tool, refer back to the piece on building a Weighted Decision Matrix.  Build your criteria and add the weights.  Don’t forget Time In Queue.  Otherwise there is work that might never get done, and that’s not likely to make for happy customers.  In the end, you should have a simple tool that will tell you which item enters your WIP next.

One more thing, though.  People are not WIP.  A customer standing at your desk can’t be asked to stand to the side until you have capacity for one more thing.  Lean is about providing value to your customer.  They get your attention.  That’s why we don’t run at 100% capacity.  But that’s another discussion as well.

Holding Area

So you’ve figured out how much you can handle, and which items you will work on next.  What about the rest?  Where does it go?  Where is this “queue” we keep talking about?

It depends on your situation.  In some cases, such as a large department with a central workload, there may be a gatekeeper who doles out the work as you are ready for it.  Central staffing teams can work this way with a lot of success.  If you are on your own, though, you’ll need to be your own gatekeeper.  Of course, you’ll have to do it without actually touching the request.  Because that makes it WIP.

This is a great area to leverage technology to help you.  Build a request or ticket system.  Have an automated response system to let your requestor know you evaluate items as they come in and will add them to your workload to give them the optimal return time, and keep them updated on status.  If you have your selection criteria ironed out, ask the requestor to fill in the criteria so the request can triage itself.  Then take them as they come.

Yes, you’ll have to look at incoming requests occasionally.  But you don’t need to look at each one.  Use your holding area to gather them up and review them in batches.

You will be amazed, I think, at how much time you spend telling people you don’t have time to get to their request right away.  Building a queue that can triage itself and feed you work as you are ready for it will free up that time, and allow you to focus on the “value added” work of fulfilling those requests.  By reducing the number of things you are working on, you can spend more time on the real work, complete tasks faster, clear out the queue and provide a better overall customer experience.  Counterintuitive, but it works.


From the Archives: Transactional Lean

With ILSHRM11 in the rearview mirror and HR Florida quickly approaching, I thought this a great opportunity to share this primer again.  If you were in the session in Chicago, this is some extra information for you.  If you are joining the session in Orlando, this will get you in the right frame of mind.  Enjoy!

If you haven’t worked in operations or quality, Lean Six Sigma can be a daunting prospect. How does a manufacturing style apply to HR? What’s it all about? What does it mean for you and your job?

The good news is that LSS can be applied in the transactional world with great results. As part of a new effort to focus on education and tool sharing, I’d like to open with an overview of value and waste, the two primary components of any process.

What is Value?

We start with looking to separate “valuable” activities from waste. How do we define value? We don’t. The customer does. But an easy way to think about it is to imagine your customer’s reaction if your activity appeared on an invoice. For example, your customer, a hiring manager, says “find me a great mechanical engineer!” Let’s break down some of the activities in that process…

Value Added Activities:

  • define the right parameters for the job search
  • reviewing resumes
  • presenting well qualified candidates

These are important things that the manager wants to have take place. The two days that passed prior to starting the search while waiting for an approval by my manager on a form that outlines HR’s responsibility in this task is not. And no customer would willingly pay for that time.

Seeking Waste

When we start looking for improvement opportunities, we start with the classical definitions of waste. You can find these in all workplaces, all work types, and all parts of the organization. There are traditionally seven wastes:

Overprocessing – Working on a task or product beyond the customer’s specifications

Waiting – idle hands

Motion – having to turn, twist, lean or stand in order to complete your task

Inventory – as Taiichi Ohno famously said, inventory is death. Any time you have inventory, your money is tied up sitting on a shelf.

Transportation – walking from place to place or, more common, moving work-in-progress from place to place so it can be completed

Defects – mistakes, rework, or unusable final products

Overproduction – making more units than needed to satisfy customer needs

And, a special bonus eighth waste:

Underused people – whether it be idle time, lack of work or just not realizing the potential of your team members

Once you understand your process and have identified the waste, the next step is to understand which activities are truly not “value added” and work to streamline the activity, integrate or automate the process, or eliminate the waste wherever possible. As an example, here is a typical transactional event from everyday life, fast food pickup. This is, of course, an example of a process gone wrong.

  1. Arrive at restaurant (Elapsed time – 0:00)
  2. Wait 5 minutes in drive-through line (Elapsed time – 5:00)
  3. Wait on cashier to be ready for order while cashier accepts payment from another customer (Elapsed time – 5:30)
  4. Place order (Elapsed time – 6:00)
  5. Cashier reads order back (Elapsed time – 6:30)
  6. Wait in line to reach drive through window (Elapsed time – 8:00)
  7. Pay for order (Elapsed time – 8:30)
  8. Receive change (Elapsed time – 9:00)
  9. Wait for food (Elapsed time – 11:00)
  10. Receive food (Elapsed time – 11:30)
  11. Check order; If mistake found, park, return order, wait for correction (Elapsed time – 12:00, more if mistake is found)

Now, here’s an example of a revised process with a few minor changes and the impact:

  1. Arrive at restaurant (Elapsed time – 0:00)
  2. Wait 3 minutes in drive-through line (Elapsed time – 3:00)
  3. Place order (Elapsed time – 3:30)
  4. Wait in line to reach drive through window (Elapsed time – 4:30)
  5. Pay for order (Elapsed time – 5:00)
  6. Receive change (Elapsed time – 5:15)
  7. Move to second window (Elapsed time – 6:00)
  8. Receive food (Elapsed time – 6:30)
  9. Check order; If mistake found, park, return order, wait for correction (Elapsed time – 7:00, with fewer mistakes overall )

Notice the overall time has been reduced from twelve minutes to seven, an improvement of more than 40%.

What is that improvement worth to the business?

Intuitively we know that the improvement is significant, but the changes we suggest will have a cost to implement, so how do we quantify the value of the improvement? Here are where good metrics and valuations come into play. How much is a 40% improvement worth? Assuming a twelve minute cycle, you will be finishing five transactions per hour. If each transaction has an average sale total of $10, we are producing $50 of revenue per hour. Assuming twelve hour days for a full year, that equates to $18,250 in revenue per year.

If we reduce the cycle time to seven minutes, our hourly transactions jumps to just over eight. (We will round down for simplicity.) This brings our yearly revenue to $28,800, an improvement of nearly 60%. Simple answers, powerful results. The times in this example are clearly a “worst case” scenario for a restaurant, and are intended to show how you can apply Lean thinking in the transactional world.

What’s coming up in 2011?

This overview should set the stage for this year’s focus on on tools and learning. Moving forward, expect to see more about how to use and when to apply the very simple but powerful tools that LSS can provide.

From The Archives: Metric Waste

I’ve been working on a project to create standard processes for the global HR community with my organization for the last two years or so. One of the questions that always comes up is around measurement. How do you measure adoption rate of the processes? How do you know when people aren’t using them? And what are you going to do about it if someone doesn’t want to use them?

We’ve developed a self-assessment to see if a location is aware of the processes and if they are using them, as well as gather their feedback. But we are after more than compliance, we are after the usefulness of the processes and improvement opportunities. We can record adoption rates from there, if we really want to, but it’s all based on self-reporting, which we all know can be spotty at best.

More to the point, though, the question is why would we care? Because we would only want to invest the time and effort into measuring and reporting if it was important. Isn’t it important to know if our process are being used? More and more, I’m convinced the answer is no.

Standard processes are, in most cases, a building block toward something else. In our case, they are pre-work for an HRMS and self-service implementation. We will build upon the basic framework with regional/country adaptations that outline the changes needed for local laws, and then build out the technology and tools on top of that. The use of the standard processes is, to me, secondary. If it were the end goal, then it would certainly warrant reporting. But as an intermediate step, I’m not so sure.

As I’ve said before, new processes/tools/widgets are only going to be successful if they are better than the old version (or at least are perceived by the user to be better). If our long term deliverable, including those systems and tools, aren’t better than the manual way of doing work, we will have failed, and no one will use them. If we do present a new system that is an improvement, people will flock to it. And then the measurement of that interim point isn’t as important.

Trying to measure the success of an intermediate step is, I think, a distraction. Feedback is good, of course, but should be gathered in the context of preparing for the next step. More importantly, trying to measure usage of a manual process would be far more resource intensive than it is worth. And once you know that, why would you spend any more time working on it?

If we are building a system to the needs of the user, it should be their feedback (or lack thereof) that should matter. So keep your communication lines open, listen to them, and give them what they need.

Lean HR is using WP-Gravatar