Engage People Using a Benefits Map

Businesses typically care about only three things: 1) Increasing Revenue, 2) Reducing Cost, and 3) Cost Avoidance.  But it isn’t always easy to connect the work to one of these three outcomes.

Reducing scrap.  Reducing lead time.  Decreasing accidents.  Making quicker decisions.  These are things it is easier to connect to our work.  These are outputs.

So how do the outputs tie to the outcomes?  That is where a benefits map can help.

The benefits map takes the deliverables of the work (on the left) and ties them to the outcomes (on the right) by way of the outputs (in the middle).

Properly designed work has known deliverables.  Getting to how theses deliverables are going to change known metrics connects them to the outputs.  Then it is working with the customer to think about how changing those outputs will create a better outcome for the business.

The last step is to quantify the benefit to the outcome.

There are two positives to this method.  The first is the team has to stop and think about how the work will benefit the business.  Just the awareness alone creates teams that more in touch with how they are affecting the business.

The second is the people doing the work become more engaged int he work.  They can see a visual of how they are making an impact.

Understanding how your work is helping the business is a key component in employee engagement.  The Benefits Map is a simple but effective tool to help engage people.

Advertisement

Who is Your Real Customer?

Lean is focuses on adding value for the customer.  But, who is your real customer?

Many groups will talk about supporting another group within the organization.  The focus is on making the internal customer happy.  Delivering what they need and want.

Internal customers are important.  As a supplier, the focus should be on delivering what the internal customer wants.  But, they are not your real customer.  The real customer is still the end user or the consumer of the organizations product or service.  That never changes.

Even if a group never touches the value added processes making the product or service, the group should be focused on the end customer.  As the group works with the internal customer, questions should be asked if what the internal customer needs/wants lines up with adding value for the end customer.

Common thought is it’s not the support group’s job or position to ask because the internal customer group is assumed to already know what is being asked for is adding value.

Amazon.  Zappos.  Danaher.  Safelite.  Organizations that have figured out it is EVERYBODY’s job to focus and ask questions about what adds value to the end customer have a significant competitive advantage.

Are You Stuck in Neutral?

Seth Godin’s blog “The Cost of Neutral” is a short but insightful post.  The quote to take away from the blog is this:

Not adding value is the same as taking it away.

This is a driving point to the lean methodology.  You can’t stand still or you will get passed by someone who is improving and adding value for the customers.

Leaders and managers may not be directly involved in adding value to the product or service, but that does not mean they aren’t responsible for driving value creation.  Leaders add value by engaging employees in ways that will help them continue to add value for the customer.

People and companies can’t afford to be stuck in neutral.

Problem Statement…Got One?

Defining the problem well is a very important step in solving any problem.  Yet, in coaching problem solving, problem statements are very rarely written well or even understood.

There are five components to a well written problem statement:

1. What is under performing?
2. What is the actual performance?
3. What is the needed performance?
4. Why does this need to be addressed?
5. What will be affected by solving this? (Safety, Quality, Delivery, Cost, Morale)

Example: Number of critical software issues in testing was 13 and needs to be at 0 because the software can not be released until the critical issues are resolved which delays the cost savings and increased revenue of using the new software.

(Color coded to show the components of the problem statement).

There is a clear understanding of what is wrong, where the performance needs to be and why it is important.

As a team works on solving this problem, they can always bounce their root cause and potential countermeasure against this statement to see if they are delivering on what is important.  The team always knows how they are affecting the business (reducing cost and increasing revenue).

“The software has too many issues to release,” is not a good problem statement.  What kind of issues?  How many?  What are the repercussions of the issues?

This is the type of statement that I see way too often.  As you can see, there are too many questions to get a clear understanding of the problem.

A well written problem statement will get a solid problem solving process started on the right foot.