Tag Archives: problem solving

Random Thoughts: Communication, Projects and Problem Solving

I have been thinking about processes… We find something – communicate – interpret – execute then either approve or revisit (PDCA). Sometimes it is true project work and other times it is day-to-day operations. When I think of how we could fail, there is a cartoon that comes to mind that I was shown in one of my MBA classes. There are different iterations of this image but they all are fundamentally the same.

Communicating effectively can be a difficult one to tackle. Half of it is the sender and then you have a receiver that needs to translate what you just said. I know I struggle with this from time to time. I have met a few people in my lifetime that have done exceptionally well with this. The common thing they do is repeat the message back. “Here is what I heard you say…” in their own words. When we write emails or issue work a lot of this can be lost. For critical to success functions we need some sort of direct communication such as an office visit or a phone call to get and give that 360 communication cycle.

While heading down this topic path, I could not resist a comical approach to how the meetings take place. Imagine all of the meetings for projects that you have been a part of. The tasks that are asked and what we are capable of doing are two very different things. Along the same lines of the cartoon above, view the video below. It is easy to see how one idea can go so many different directions and the idea never gets fully realized.

Another topic that I have been thinking a lot about since my visit to Toyota is how we problem solve. Often we have an issue, then call a problem-solving meeting, identify several things it could be, and slap a whole list of action items against it. Sort of like buckshot when you hunt. I only need to get directionally correct and I should hit the target. Sometimes the root cause is not what we really want to hear. It may not be an ah-ha moment and is something as simple as we have good processes in place but didn’t follow them. The root cause may be self-inflicted. Through the solutions phase we need to address the root cause – own our mistakes – and correct that one. That does not mean we need a jillion checks to check our checks. That only creates more work and greater opportunity for us to miss something with the extra work we created just to cover the one thing we missed. Granted checks are not always bad and can be a good precursor or way to see something failing prior to it actually halting a process. When we see the problem at its root we need to fix why that item happened which leads to lots of other symptoms or results. That does not mean we should not create contingency plans for continuity; we just need to be cognoscente as to what we are really gaining. I know I have led events where I facilitated scattershot approaches to cover everything under the sun. I would challenge us (myself included) to simply, standardize, be accountable and repeat.


Leave a comment

Filed under Lean

boots on the ground: the power of the gemba (genba)

I cannot count the number of times when I thought I knew… or was sure… how something transpired. “The employees are taking shortcuts…” Or you may have many other preconceived notions. I am sure if you have ever been in a problem solving event – many people have the real root cause even before the process has been investigated. The power of any investigation is to actually go to the scene of the crime, or where the action takes place (or took place). The Japanese term, modernized, is Gemba.

Genba (現場?, also romanized as gemba) is a Japanese term meaning “the real place.” ~Wikipedia.com

The embarrassing part is that I can recall many articles, events and stories that I have been made aware of where the employees were never talked to. No 5W+H (who, what, when, where, why and how) was ever taken from the employee perspective.  The facts though are made much clearer by actually going to the place where the action is happening. There is a reason, good or not, why things happened the way that they did. I also believe, from my experience, that people do the best with what they have and the most with what they know. Poor decisions are often result of inadequate tools, work environments or lack of training – not from deliberate attempts to “stick it to the man.” As hard as it may be to swallow, management often has a part of the problem, and it is not noticed until much later when we see symptoms. The root either grows, or the branches spread making it much more visible.

As you begin to form your hypothesis, involve team members from diverse areas including the actual people performing the work. Then go to the floor and see it for yourself; boots on the ground.

#post- .CPlase_panel display:none;

Business, gemba, genba, hypothesis, Investigation, MBWA, problem solving, Root cause
Business: General, Lean
#Business, #Gemba, #Genba, #Hypothesis, #Investigation, #MBWA, #ProblemSolving, #RootCause

Leave a comment

Filed under Business: General, Lean

Problem Solve Almost Anything – 3 Things Needed

To problem solve you do not have to have any fancy sheet. It does not take an entire event with lots of people, in every situation. Let me preface saying that if you are solving the National Debt, then you need to put the problem into perspective. This has a lot to do with a circle of influence – so keep that in mind.

You must know:

Where you are: What is the current situation? Is it that you cannot pay your finances timely? Continue to have XYZ happen? Regardless, you must have a starting point. Be realistic, eyes wide open, and objective. Sugar coating where you are only makes the cloud that we will call the “gap” harder to navigate.

Where you want to be: What is your vision state? If you could wave that magical wand – what would your situation look like? Congratulations, you just set a goal and have something to go towards. This would be the “X” on the treasure map, if we were thinking in those terms.

The gap: This is the unknown. The work, sweat, thinking, path taking, hypothesis making, trial and error path to the goal. Some problems will chip away as you navigate the path. Some will make you think you are in a pirate map or a survivalist type game show. Take an idea that you have which will theoretically get you closer to the goal. Depending on how big your treasure is (the goal) you may need to travel through the gap repeatedly until the ideal state is achieved.

Example: I am broke. I want to save $500.00 a month. The gap would be all of the transactions that I take on a monthly basis which account for the net balance in my account to the goal; that may be $1500 or that may be $100. Now, I would evaluate them and pick one that I want to go after. I may cancel cable, cell phones, etc. until I get there, but I eventually will chip away the distance or clear up the cloud between the current and desired states. At some point, I may have to change tactics when the “low hanging fruit” are gone. I may have to look at picking up extra hours, or a 2nd job, or [place activity here].

The point is, with a defined current state, and knowing where you wish to go – you will be able to travel paths to get there. The time it takes will vary but that is your map to figure out.

If you need help – just ask me.


Leave a comment

Filed under Business: General

Short Staffed? Work load growing? (Line Balance, Level Schedule, Time Management)

work loadI think everyone has been at the point of breaking. Work continues to be added , nothing seems to ever be taken away, and we are praying for that extra day in the work week. It does not have to be that way though. In fact your initial reaction may be right, but we should really quantify.

As with any problem that we start with, we need to determine the gap. I am guessing that the current state is that the work load supersedes what the area is currently capable of doing. The desired condition would be to have adequate staffing allowing the work to be completed, and on time. So our gap essentially comes down to workload, or required man hours per person. If your operation has standardized word and standard task times, now would be a good time to get those out. Hopefully, by going over a few tips (below) we can find an optimal solution.

Work Load Definition – Prior to conducting the meeting (referenced below), we need to create a log. I use Excel for majority of my work. The sheet should have the employees name, other department information, and the ability to write down the tasks the employees perform or take part in on a daily basis, for the total of a week. You can create whatever you would like, but we basically need to know each task (defined as anything that takes up time). I have a rough form you can download here:  TimeLog.

To see what tasks we are dealing with we must know what each employee fills his or her day with. Of course, we want to believe that everyone is fully utilized but without the data to support – we cannot really make assumptions with what could define the case and feasibility. Assemble the employees as a group and discuss the problem. State the facts, and remove the temptation for politically correct jargon. We want the employees to know that we are trying to make an educated decision about the work loads, as well as labor, which requires some analysis of each person’s time. Hiring more labor makes the operating costs go up, and could potentially impact our COG’s or increase the cost to the customer. Remember, lean is the relentless pursuit of waste removal, by determining the waste to be anything that the customer is not willing to pay for. Go over the form, and the expectations of the form. Remember, people need to know the WHY of the WHAT. They want to know what the form is, and why they are completing. Not to mention, that if you do not fill out the context – the standard they follow will vary thus, creating lots of variation in data.

Analyze the Data: Now that the employees have take the week to compile information, we need to analyze the data. We want to look for anything that stands out. I typically look for:

  • Tasks that are shared between users – Shared tasks could potentially be shifted to a single employee vs. many – based on available time of the resources.
  • Tasks that are duplicated – Look for items that many people are doing. Perhaps employee A. sends a report to a department, and employee B. sends very similar, or the same, data to department B.
  • Tasks that require lots of manual work i.e. spreadsheet updates, manually – I tend to consider anything that requires copying data from a paper copy to electronic. Things that require lots of formatting.
  • Tasks that require large amounts of time to complete – Similar to above, but it could be large data dumps from files which takes time while waiting on the system to generate.
  • Tasks that are wants, not needs – Emails, forms, or reports that have been asked for over time because the end user (usually another manager) wanted the data prepared but could access the data via the same system.
  • Anything else that stands out to you. If you notice that employees spend a lot of time reading email, and you yourself have to dig through your mailbox to find the “good ones” it may be time to audit emails and send out email etiquette. AKA – Quit SPAMMING me.

Now that you have analyzed the list, it is time to start moving things around if able. What can you do to move tasks that make more sense with another employee, with another department, or discontinue. Also consider the ability for automation. Spreadsheets can be linked together so that data is automatically fed from one sheet to another via datasource linking or by direct formulas pointing to cells in a sheet of Excel. Can a macro be written to complete the formatting, and sheet creation? Take a look at the tasks that take hours to run reports – what are the ee’s doing during that time? Is there a way for them to start working on something else while waiting?

You may also consider holding training seminars on systems that allow each user to get his or her own data vs. outsourcing (via your department).  How are the employees work schedules loaded – meaning do they put overtime in M-TH but leave early on Fridays? Would moving ideas around based on priority change the available time? If nothing else you could get a few dollars savings from overtime reduction. Examining the actual work schedules – do the employees come in at 8AM but reports they need are not available until 10AM on that day – and if so what are they able to do during those 2 hours? Bottom line is – question everything. You are going to move things where they fit best and discontinue what you can.

Even though you are trying to make your department run smoother with the least amount of FTE’s (labor) as possible we still must do what is right for the business. When examining the tasks the odds are that you will find reports that were handed out at one time when things were different. It may be time to re-home the process back to the originating operation. There is nothing wrong with that, and by going through this activity you will have the data to support this. During the analysis you may have “ah-ha’s” where employee A takes 30 mins for XYZ tasks while employee B takes 45 mins. It is possible that you may have a new best practice. You will want to look at both parties steps and completed task – determine the best course of action and standardize the process with OIF’s.

One thing that I do not recommend is just stopping an activity unless you are certain that it is not value added. Who did the report go to, and what activities were created from that? Make sure the customer has what they need or is educated on how to get the information going forward. There is an old thought that suggests just stopping an activity and see if anyone notices. Although, it can work, I have found more issues doing this than the reward is worth.

So, I did not give you a solution. I can’t. Each business is different, and it depends on the exact work loads as to what can be done. I have found, through research and personal experience, people will fill up the time allowed with the work load available to them. This can be confirmed by 4 tasks taking 4 hours for one person M-TH and on FR, it only takes 2 hours and the employee(s) manage to get out early. You can pick the task – but I am pretty sure that each of us could give an example of this. As always, feel free to ask questions.



Leave a comment

Filed under Business: General

Get to the roots. (Root Cause Problem Solving)

And there is the problem. We need to solve it.

Every business in existence has had a problem. Each one of the problems detour performance from optimal or desired results. So, what do
we do – try to solve the problem by some means. The approach we use can be the beginning of success or potentially failure. I am confident in this since I am going to fig1make a broad assessment – each of us have identified a problem, put something into place, observed success to only find out that later we are still experiencing the same problem. What happened? Well, either we did not solve the problem or we did not sustain the actions which remedied the problem. Those are the only two possibilities. If the problem came back, but in a different form then we have a new problem to solve. If the same problem with the same criteria exists then we go back to the later, a) we did not solve the problem, or b) we did not sustain the actionables determined at the time. So, in short, we need a solid plan of attack. To get a plan of attack we must understand the gap, or the distance from our current state to the desired state. Essentially, any problem solving is about identifying the gap, and steps needed to execute against to get there.

Identify the problem. What is the problem exactly? Specificity is critical at this point. X happens at Y for Z duration while Process A occurs. We want to have it detailed out so that anyone picking up this statement can understand the reason for this event and the impact to your business.

Assemble the team. This should be a group of people which can relate to the problem in some manner, but do not need to be directly involved. It is good to have a cross functional team, along with ad-hoc members. The team should have a leader, facilitator, subject matter experts and or operators (depending if they are one in the same), and a couple other team members that could provide insight but not necessarily a part of the home team or department. For example, I may include another department, another experienced manager, etc.  A team is not one person calling a group to the office to pound through the exercise to satisfy a required event. Many projects, such as a Six Sigma (Green or Black belt) use a team charter. The charter states the team members, the goal state, the current condition and rough time line (if applicable).

Research any history. This is not a common or traditional method for problem solving. Yet, I find it very beneficial. Remember earlier, when I mentioned issues that reappear or repeat? I have found that looking over previous problem solving data and events to be very rewarding. There have been times that I have switched the order up as well; I have performed this task upon identification of the problem.

During this step take a look at the history of this event. Has there been any problem solving or similar events around this problem? If so, look for the action items that were associated with the event. How many of the action items are still applicable – and are they still in place? What would it take to determine what it would take to put the items back into place or query as to what happened? Sometimes the solutions put into place are discontinued when new events take place. This could include, but not limited to: new crew members, new management staff, new machinery, lost standardized work, complacency since the problem “does not exist,” and so on. If you have a group formed present this data to the group for review. You may find that some of the steps of this “new” event will go quicker – but I encourage you to walk through the steps in case that the originating group was not able to correctly identify the true root cause or that the nature of the problem actually changed thus, creating a different problem.

Identify potential contributors. For each problem there are cause and effects. Many times, at this point, we are not certain which levers control which outcomes so we have several items that need to be listed out here. Some people like to use the fishbone diagram. This cause and effect diagram (which sort of resembles fish bones) allows a group of people to list potential contributors. Many diagrams use the 6M criteria galley_fishbone_01to categorize the ideas into buckets. These categories include: Man, Material, Method, Machine, Measurement, and Mother Nature (Environment). Although many issues have a root cause, it is possible that there are a sequence of events that lead to one problem. In statistics we would use multi-vary testing to identify correlation. (I will look at this in another entry coming soon.)If you have data collected, you could also use the Pareto Principle (80/20 rule) to isolate some of the key drivers. Having data at this point, will only benefit the process. It allows your potential contributors to become more of a hypothesis, or educated guess. In addition, quantity is the key. There are no “wrong” answers and the less than ideal ideas will phase themselves out over time. You have to consider that most people will not propose ridiculous ideas for fear that they will be critiqued.

Identify potential solutionsThere are several methods which can be used to identify potential solutions for the problem(s) listed. I have found that it depends on the group. I know, that is very helpful, right? Let me explain. If the group is an outspoken group, or one which has quickly moved through the phases of assembly (forming, storming, norming etc.) I will let the brainstorming take place on a white board with an open discussion. If the group is slow to respond then I would propose taking sticky notes (Post-it notes) and give everyone a stack. Tell the group to write down as many ideas for solutions as they can which come to mind. Quantity over quality, again, at this point. We want to get the creative juices flowing. After the group has listed out items, start allowing ideas to be suggested from the notes and place the notes on the board. Try to categorize them as well while posting to the board. Many good ideas will “piggy back” another idea, or come to mind from another idea.

Rank the potential solutions. There are several different methods for ranking as well. Some of the ideas could be voted on one by one, or everyone rates their “top three,” or by combining ideas you may be able to narrow down the group to a select few. After this task is completed – 2x2 matrixwe need to move to a way to attack the ideas. For this, I prefer using a 2 X 2 matrix. For this we draw out a large square with 4 sections. They have X and Y axises ranking from low to high. It could be for lowest to highest cost, length of time to implement, ease of implementation, impact to problem or area… The criteria really depends on the actual situation. Once, this is created list the ideas that have made the cut beside the 2X2. With the group’s direction place the ideas into the matrix. The goal would be to have solutions end up in the upper right quadrant. These ideas are the ones that the group will go after first. The lower left are the costly or difficult solutions. It could be the solution – but less likely if you are truly critiqued the ideas.

Pause and reflect. Now, I usually pause and address the group. I summarize where we are at, with the problem solving event. We have identified the problem, researched the problem, identified potential causes and solutions as well as rank the solutions in a priority order based on group consensus. So if we solve all the items within the 2X2, which should correlate to potential contributors, does the group believe the problem will be solved; have we nailed problems/solutions that are likely to be the root cause(s)? As the leader, it may need to be revised a bit at this point before we proceed. Once the group is in agreement, we can move forward. Let us be clear, though, that you are dealing with an experiment if you will. You have likely causes, effects, and educated guesses to solutions. Failure should be considered acceptable, if learned from, and the PDCA cycle (plan, do, check, act) may come into play. That is, we may need to come back together as a group and revisit some of the steps. The key is to document, and be sure that we are executing against what has been agreed upon.

Identify Action itemsSo at this point we have things designed so that we can take action steps. Activities have been mapped out, and now we need to assign SMART goals to the potential solutions. Smart goals are specific, measurable, assignable, relevant, and time bound. List out steps that need to take place so that solutions identified can be put into place. They may include meetings, trainings, setting up tests with parameters for test and control, setting a regroup time, just to name a few. The list should include the ACTION STEP, WHO is accountable, and what date the task is expected to be completed by. The dates may be moving targets and if something needs to change be sure to update the group. Thinking in terms of a Gantt Chart format – others may need to know that the dates have moved due to … so that any dependencies can be adjusted accordingly. Set a time and date for a quick regroup to make sure that the project is still on task, and if anything new has come up. Revisit prior steps as needed.

Regroup for validation Go over the test results as to what was observed. Did the tasks get completed, and did the data indicate your steps provided favorable results? Were you able to see the “light on off” when testing your solution(s)? If process A was changed did the independent variable (test) show desired results compared to the dependent variable (control)? If you add and take away the new process – does the data support that?

As you identify working solutions it is important to start he standardization process. To change a process it is not always just as easy as “go do it.” People like to know the why of the what… they want to know the reasons for the change and the importance of the newly developed strategy defined by your team. I believe it was Covey which stated that it takes 21 days to make a habit and you are dealing, most likely, with a culture that will need to be aware and adopt the new process which will eventually lead to ownership.

ImplementationIt is important that during the standardization process all the operators have input do the creation of the living document. Some documents are called standardized work, OIF’s, job aids, work instructions, just to name a few. During this time train the operators, and allow multiple sessions for everyone to cover the new materials. A recent white paper study SIStem shown that it takes 6+ times of repetition and failure for the process to be adopted successfully by 90%+ of the people.

Create a status check. This is the MOST IMPORTANT step of any of the project steps.  For your problem to be sustained and adopted then follow up events to evaluate the status need to take place. This is both for the operators to provide any feedback for suggestions and to ensure that the root cause was really identified, solution implemented, and sustained.  One of the best ways to validate a process is to audit. Audits can come in the shape of a form, verbal and physical walk through, and examination of recent history data. I would propose that the group plans on auditing the process at 30 days, 60 days, 90 days and then on some form of longer interval. Reminders can come from systems (if you have something in place for tasks – possibly the same a many mechanics use for timely mechanical checks or PM’s). This could be as simple as an Outlook calendar reminder.

Report out of event. Once you have completed this event, determined solutions, and have observed success, a report out of the event should take place. Invite the department managers, supervisors, other management, some team mates (as applicable) and walk through the process of how you identified the problem – determined the gap and put steps in place to close the gap. Report out events are important for several reasons. It is good to show that the money tied into the resources for the test were valuable, allows other departments to consider learning from your events, as well as an opportunity to show professional growth.

LearnigsLastly, I wanted to take a moment to share a few things that I have noticed over time, in no particular order.

  1. If you give people the chance to be quiet while working in a group that is less than engaged, they will be. Call people out for idea suggestions to create or sustain momentum. Many “piggyback” ideas come from other ideas and could be lost if not captured in the group setting.
  2. A couple smaller meetings to gather the group while going over the problem solving steps is often better than one larger meeting. People will tend to get distracted with longer meetings, as most are busy outside of the current tasks you share for the project. In addition, many of the steps could require “homework” and the group will come to a stalemate without the information to proceed.
  3. Take Maxwell’s advice – it is ok to fail as long as you are “failing forward.” During the exercise it is OK to have to take steps backwards and rethink the strategy. If it was an easy problem to fix – you would not be enlisting a team for hours in a formal event setting. Be sure to document any learning that take place for history purposes. They can be put into an appendix and do not have to be shared publicly but will be accessible if the event needs to be revisiting down the road.
  4. The PDCA cycle is a process where we plan for an activity to take place, perform against the activity, check the results and act or refine based on them. The CHECK and ACT (or Status check, above) allows you to continually verify the root cause was identified and sustained.

In conclusion, I could go over this topic for hours. It is important to understand that the tools used are simply that: tools. The real work comes from the dynamics of the team to define and act. We are simply trying to close the gap for to achieve a desired state. If you have any further questions or need help walking through a process please feel free to reach out to me. You can post in the comments below, or visit the contact link within the blog.

To download the Template that I have assembled: ProblemSolvingTemplate

Best Wishes,


1 Comment

Filed under Business: General, Lean, Uncategorized

pay attention to the whiner.

“The day the soldiers stop bringing you their problems is the day you stopped leading them. They have either lost confidence that you can help them or concluded that you do not care. Either case is a failure of leadership.”

~ Colin Powell

I enjoyed this – had to share it. Then, I started to really ponder what it really means. I bet each of us could name instances where employees came to us looking for answers and although we may have helped – we dismissed it as annoying. Now, that is not to say every engagement is value added – it may be more beneficial than we think (on a surface level).
Along the same lines – can you think of a group you have been involved in or around where when someone asked a question the statements were “it doesn’t help… nothing ever gets done…” I have been involved in a variety of situations where during an employee interview or problem solving event it was discovered that the problem has been going on for sometime. In some of those cases, in particular, the employees had a “work around” developed to counter or simply live with the issues based on the perception of action against requests from employees.
A short time ago, I published a blog entry discussing intellect, and the tribal knowledge in institutions. The article was focused on capturing the knowledge of employees and putting it to good use. The opposite side of that is when we, as a leadership team (or just a TEAM), lose the confidence of the employees and we stop receiving the much needed information to keep the operations running smoothly. So not only do we miss the ways to improve the process based on operators feedback we also lose touch with what is really happening. During the problem solving events that boiled up the real facts or history behind events X only happened due to the workaround was missed. So the very issue would not have happened if the team would have kept to the work around which was only in place due to “living” with the broken process. One problem led to another. The rabbit hole only grows from there.
So my challenge to you is to take walks to the floor, and engage the teams. Take notes on what they tell you. Research the issue(s) and then provide feedback accordingly. Not every piece of information received can be acted on – but the employees should be kept in the look. If you make the statement “I will get back to you” then do just that – with whatever the information is. Even if the idea cannot be pursued, explain the facts as to why. Complete the feedback cycle.
Related articles

Leave a comment

Filed under Business: General

don’t settle – fix it

How many times does your department suffer from a support department process failure? It is easy to sit afar – and point in his or her general direction. Yet – at some point – your department is that – yours… the lack of process completion in your department still needs to be addressed. The root cause may not be your area but since you are indirectly (or directly) impacted there should be some concern.

My theory is that anomalies happen. That means, chasing every loose end may end up wasting more time

Teamwork: TEAM - Together Everyone


than it is worth. Give the department manager credit when it is due. He/She most likely are digging in the trenches or putting actions into place when a failure happens. However, I tend to shoot a quick note to the department manager and a) make sure they are aware of the impacts, b) see if they need any help, and c) just get a comfort level that things are being looked at. This is not a finger pointing session or a time to air dirty laundry. Simply put – we are all trying to achieve the same end result (and if we are not – there are more issues than a blog will resolve).

At some point when things become repeatable or several anomalies result in your department failing – it is time to step up to the plate. At this point, I would make a phone call and see what is going on. Schedule a meeting; and conduct the needed problem solving event(s). Simply accepting the issue is settling. Silent leadership models would indicate but doing nothing, we are actually doing something… non verbally it is the same as “it’s ok.” Approach the situation open minded, offer your assistance and communicate a team minded sense of urgency.

This will require a judgement call, but it is not acceptable for your team to not perform and as a manager we are charged with the responsibility to remove obstacles preventing success.

Leave a comment

Filed under Business: General