The case of the overworked employees/3

Time to improve

I did a quantitative and qualitative analysis with a couple of people from the team. We shared our observations with the rest of the team. We decided to tackle three things first:

  • The discrepancy between customer satisfaction and our kpi’s
  • The unpredictability of the amount of work
  • The unpredictability of delivery for the value stream partners

The team figured that these points would help in reducing the amount of negative feedback they were getting from partners and customers alike.  If the team was short-staffed these actions would help in proving it. By working on these things it would become more fun for the partners and customers to work with the team.

KPI plummeted from 98 to 33%

The development of the on time KPI

The Kpi on lead time

The Kpi about on time delivery was really about something else.  It was measuring whether we informed customers of delays ahead of time. These delays where standard.

The discussion about changing this way of working was though. People had not started doing this out malice, but out of desperation. They understood that if we measured actual on time delivery it would lead to a huge drop in performance. It would also lead to a host of questions. It could lead to validation of what the team had been saying for years. But on the downside certain co-workers would view this drop in performance of proof that they had been lying for years.

After much talking the team decided to go for it. It was unanimous. The team lead and I decided that we would insulate the team from management responses at first. This meant the team could focus on getting the work done. In the graph above you can see what happened when we did this.

Making the workload more predictable

The team used to have one big team meeting a month. We instituted a daily team meeting. People were not happy about this at first, because it costs time every day. We (me and the team lead) put a lot of emphasis on growing as a team and helping each other. We used the daily team starts to answer the following questions:

  • Which customer deliveries did we make on time yesterday? (through visual management)
  • Which are scheduled to be delivered today? (through visual management)
  • How are the kaizens and actions going? (through visual management)
  • Were there surprises (good and bad) yesterday?

The first meetings took longer than 15 minutes. But once the team got used to it it got faster and more fun. People started to feel heard and helped. There were of course some hold-outs. During the daily meetings we gave 90% of the time to the people who were willing to try or embracing this way of work. The team lead talked to the hold-outs separately.

We asked people to keep records for a month of the following events:

  • When they needed outside help and why
  • Why certain products took longer or shorter than they thought
  • When and why the specifications were found lacking or ambiguous
  • Smart ways of working you can share with colleagues

Each day the input was analyzed. Each week we started kaizen events and just-do-it actions to reduce variation in workload and lead time.

We decided to drop the hoursheet. Keeping it up to date tended to take about four hours a week from every employee. The estimates were usually off by a lot. Some people spent a lot of time on making new estimates, others simply let the original estimate stand. There was no check with how many time they actually spent on the work. The hoursheet mostly gave a fictional account of the workload while costing four hours a week per employee.

Since the hoursheet gave some people piece of mind,  getting all employees to stop using it took some time and effort from the team lead.

We looked at the 100 item quality checklist as a list of items to improve in the value stream. The team added a lot more value to products than just these 100 items. So why were these on the list and not others?

It is because these were the ones with the highest chances of defects. About half of the items were on the list because this is where differences of opinion would occur. We analyzed the rootcause of these differences of opinion. The solutions could vary, but usually it was about specifications. We also looked at the items with the highest chances of defects.  Where we needed a budget to decrease the chance of defects we would make a business case. This way higher management could make an informed decision.

Working with value stream partners

As you can see on the left,  there was a lot to be done. We could not do it all at once. We started with the Kpi. We wanted make turning back to the old situation very hard for both the team and the value stream partners.  We discussed the timing of the rest of the improvement efforts with the team and came up with a plan. This plan we discussed with the value stream partners. These were though conversations at times,  while other people were just happy something was finally being done about the situation.

From now on we would share our list of priorities with them ahead of time. This way they could let us now if something needed to be included or put higher on the list,  without pressuring individual employees.

As said before the specifications for any product came from partners upstream in the value stream. We told the value stream partners that if the efforts were to succeed we needed to be able to improve the specifications with them.

We also talked to the other partners in the value stream. We told them what we were going to do. We told them that it would become worse before it got better. We asked for their help in reducing variation whenever we needed their helping finishing a product. During these conversations a lot more ideas for improvement were offered,  mostly about how the team asked for their help. Usually the question and urgency were not clearly stated.

We interviewed a couple of our customers. They were very understanding about how difficult the work is. They also stated that delivery dates were unclear and quality below par.  Whenever they called about a delay in delivery they were told that delivery was on schedule.

We asked them about times that they were pleasantly and unpleasantly surprised. We also asked what they would like us to focus on first. They were happy to help. They thought the team was very knowledgeable,  but not always very empathetic about the customers needs.


After their first disappointment they were very happy to help about the true state of affairs. They came to a team meeting to listen to the team. They were wondering about one thing: How did it get to be this bad? They evaluated their own role in this as well.

The end?

This improvement effort took a long time. Some results were sustained others less so. The team got extra manpower and budget to build better (poka yoke) tools. The team is now delivering on time about 85% of the time. They have more fun in their job and customers are happier.

Some things have proven to be more resilient to change:

  • The partners in the value stream. Priorities still do not always line up.
  • Specifications are better,  but not good.
  • Some people are still privately using the hoursheet to prove how busy they are.

Most people in the team have embraced this way of working. So most improvement efforts have proved sustainable. Most importantly overtime is back to being occasional instead of permanent. And people indicated that they finally feel like they are being taken seriously.

Thank you for reading this case!

More is always possible, tips and questions are welcome


Add Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.