Do you have someone on the team that has been there longer than anyone else and knows the secret path to positive results? Whether we are talking about executive or operational teams, these members have the operational knowledge that the rest of the team needs to be successful. While we cannot connect to the Matrix and download everything they know, we can do something similar that will provide growth for everyone that chooses to participate.
The greatest benefit of using mentors is the transfer of knowledge from an experienced professional to an inexperienced protégé. There may be a basic understanding of what is going on, but it is the old guys who have already made the mistakes that know the nuances of their system. This transfer can only be successful if the receiver is ready for and open to the new information.
I feel some organizations may not have mentoring due to the innovative nature of their work, and how someone “did it” 10 years ago does not matter. That is until ideas began to be built on other ideas and now the organization is forced to document everything or keep someone around that knows the old system. At some point the innovation must move into the mainstream where it can be adapted and replicated.
When I began in my first formal process improvement role, I did not have a mentor and I had to feel my way around in the dark (while making lots of mistakes) until I started doing things right. When it was time to start the mass building of “belts”, I knew that to be successful, those new belts would need some help to get through the process faster. It was a workable system, but I wonder how much more those candidates would have learned if we were not holding their hands the entire time?
As you mentor others, are you directing down the path, or are you asking questions to make the protégé think about and consider the potential impact of decisions? Are they learning enough to walk the journey alone when you are no longer available? We have see the results of this condition when the charismatic leader leaves the organization and performance declines.
Each protégé is a little different and we cannot treat all of them the same. Would Anakin have turned to the dark side if Obi-Wan had not been as cryptic in his approach? Wisdom comes from practice, not from following an old man on some darn fool idealistic crusade. There should be discussion, a decision, execution, and then back to discussion. These conversations can follow a simple formula: what happened, what was supposed to happen, why did it happen, and then how do you respond to the results?
Thinking with tools, techniques, and tips to help you with Lean Transformation in the office.
Friday, May 23, 2014
Monday, May 19, 2014
When Good Ideas Go Bad
In my experience, groupthink is a behavior that can sink an improvement project if not caught and stopped early. Groupthink is where there is group pressure to ‘go along’ with the decisions of the group or the beliefs of the group. This can start with ill-defined problem statements, scope, and/or goals, and the team will stay on the wrong path if assumptions are not tested or questioned. Keeping charter information simple and validating the problem statement can go a long way control groupthink. Validation is accomplished through using process timelines or data that is reflective of the problem statement.
Another method to reduce groupthink is to use a balanced functionally diverse team. Members bring their own perspective of the problems and causes to the team and if functional diversity is not present, then the natural group will have the numbers to force their perspective on the other team members. Using balanced teams with one or two members from each function can prevent groupthink.
My favorite cause of groupthink is when one "expert on everything" arrives and begins to tell everyone how to think. Many will go along to get along because they are afraid of making someone mad or they do not want to be seen as a non-team player or because they are introverts that are uncomfortable speaking up. As a project lead my first method is to take them off to the side and tell them to knock it off. If it continues I have called them out in front of the team, which usually sends them into the stratosphere. If I still do not see the behavior I am looking for I will send them back to their work group and let the boss know that I'm not interested in baby-sitting their problem child. I have not had to do this very often because we use ground-rules for team member behavior that are discussed during the kick-off of the project while everyone's Supervisor, the Project Champion and General Manager are in the room.
This type of behavior can show up at any time during the project whether it is executed through weekly team meetings or kaizen style locked in a room for a week. When the behavior arrives a the end of the week when everyone is tired and ready to go home, the aforementioned expert will begin to implement her solution. Another method to overcome is to provide everyone with a number of votes or rating system to use across different possible solutions. I have had good results with this style and will continue to use it in the future.
Ultimately setting the expectations for team behavior must be established early (and often). If you are on a team and you begin to recognize groupthink, it may be time to become the voice of dissension.
Another method to reduce groupthink is to use a balanced functionally diverse team. Members bring their own perspective of the problems and causes to the team and if functional diversity is not present, then the natural group will have the numbers to force their perspective on the other team members. Using balanced teams with one or two members from each function can prevent groupthink.
![]() |
| ummm, no. |
My favorite cause of groupthink is when one "expert on everything" arrives and begins to tell everyone how to think. Many will go along to get along because they are afraid of making someone mad or they do not want to be seen as a non-team player or because they are introverts that are uncomfortable speaking up. As a project lead my first method is to take them off to the side and tell them to knock it off. If it continues I have called them out in front of the team, which usually sends them into the stratosphere. If I still do not see the behavior I am looking for I will send them back to their work group and let the boss know that I'm not interested in baby-sitting their problem child. I have not had to do this very often because we use ground-rules for team member behavior that are discussed during the kick-off of the project while everyone's Supervisor, the Project Champion and General Manager are in the room.
This type of behavior can show up at any time during the project whether it is executed through weekly team meetings or kaizen style locked in a room for a week. When the behavior arrives a the end of the week when everyone is tired and ready to go home, the aforementioned expert will begin to implement her solution. Another method to overcome is to provide everyone with a number of votes or rating system to use across different possible solutions. I have had good results with this style and will continue to use it in the future.
Ultimately setting the expectations for team behavior must be established early (and often). If you are on a team and you begin to recognize groupthink, it may be time to become the voice of dissension.
Monday, April 28, 2014
Idea Transformation
How to make an "idea" person into an "implementation" person?
Sometimes you are minding your own business watching the clouds float by, working on another marketing presentation, or on a date with that special person in your life, and then POW!!! You are hit so hard that it gives you a shiner on your driver's license. The Idea Fairy has shown up to occupy the brain space you were using to focus on what was in front of you. If you know whats good for you, you will write the idea on a napkin so you can put your focus back where it belongs. Even better if you have a bright idea notepad (handy-dandy notebook?) that you carry around.
![]() |
| "Life's tough when you're stupid" |
If you have spent some time observing your behavior, you may have determined during the day when you are at your most creative state and when you are at your most productive state. I am an early morning thinker and a rest of the day doer with a brief blast of creativity late in the day. Find your thinking time and space and pull out the idea assault from the day before and think about what you want to accomplish. This is a dreaming phase to help you characterize the idea; write as much as you can about the end state.
![]() |
| What does your idea look like?? |
WARNING!! The next step is where our excited idea holders begin to fall off the rails on the way to Awesome Town. As boring as this sounds, you need to plan the implementation of your great idea.
- What stuff (material or data) do you need to start with
- What kind of people help do you need
- What do you need to learn
- Do you need some money to make the idea happen
- How are you going to market the idea
- How much time do you need (or can you take) to implement this great idea.
If you are in the middle of a kaizen event and someone is hit in the head by the Idea Fairy, you can use a simple form to capture the idea that can help with implementation like the one below. She will show up at the most inopportune of times demanding respect and acknowledgement. Capture the idea, stick it to the process map or fishbone diagram and move along until you are ready to evaluate the idea.
![]() |
| There is DOWNTIME from the 8-Wastes!! |
During implementation of the great idea, stop and look at the plan for changes that may need to be made and talk with your team members or mentor about the progression. Is it coming together like you dreamed about days or weeks ago? If you suffer from Not-Invented-Here (NIH) Syndrome, I recommend that you get over yourself. No, I'm not kidding.
While this is an over-simplified version of what project managers do, it will take some practice before you are doing it right. Remember that each failure is a stepping stone to success. Don't give up, and learn as you move through your Journey.
Also remember that great ideas can come from little brothers. Thanks Jeremy!
Monday, March 3, 2014
Lean Thinking - Make Value Flow Part 2
Making change is hard, but there are some models whose purpose it is to provide markers that shows the way. These different road-maps take us to different destinations depending upon which journey we are on. The criteria are specific, but easy to follow based on your current state.
PRODUCTIVITY IMPROVEMENT
Here we have our old friend DMAIC (Design-Measure-Analyze-Improve-Control) that is the umbrella for quality improvements based on statistical analysis tools developed in the '30s through the 1970s. The model helps us to Define the problem, Measure how well the process is performing, Analyze for the root cause(s), Implement methods and practices to overcome the root cause(s), and finally Control our ability to backslide to the old and comfortable ways no matter how chaotic they are.
Here we have our old friend DMAIC (Design-Measure-Analyze-Improve-Control) that is the umbrella for quality improvements based on statistical analysis tools developed in the '30s through the 1970s. The model helps us to Define the problem, Measure how well the process is performing, Analyze for the root cause(s), Implement methods and practices to overcome the root cause(s), and finally Control our ability to backslide to the old and comfortable ways no matter how chaotic they are.
PROCESS DESIGN
If you are executing in the DMAIC model and one of the root causes is "we do not have a process", or you have been tasked to figure out how to do this new thing, then you may have found an opportunity to design a new process using DMADV (Design-Measure-Analyze-Design-Verify). This should not be two dude's "Excellent Adventure" where you mess up until the boss finally accepts your new process because she is tired of your rock coloring game. If y=f(x), then you need to figure out the important x's, or stated another way, stop guessing what color she wants for the rock.
First find out who are the customers and what do they want about the product you are designing your process around, this is also called Voice of the Customer. Do you have a large audience of customers? Perhaps a well constructed survey would be best. How about commandments from your company that your process must exist within or government regulations with which you must comply? These would be the Voice of the Business.
Next, when you have collect this information, you can construct the Critical to Customer Requirements and Critical to Business Requirements. Since "Critical" means measurable, we have the basis of performance. No more needing to guess about the color of the rock she wants.
Now you can design the process that creates what is needed, how it is needed, in the amounts needed. Simple right? Probably not, especially if you think a complex solution proves just how intelligent you are. Let's go with a solution that is as simple as it can be. When designed and you have made a few rocks, do they align with the critical requirements? If the answer no, then you are not finished. Keep trying, you are almost there. When the process is working as it should, document your process, someone will be expected to execute it later.
SOFTWARE DESIGN
The Software Development Life Cycle is a specific model used in the execution of software projects. Keep in mind this is for implementing the solution that should be backed up with validated root cause analysis (remember the complexity thing earlier?). The phases are Analyze, Design, Develop, Test, and Finalize; these should seem somewhat familiar in the DMADV model.
Agile is a customer-centered methodology where all the players are gathered together, complaints and good ideas are collected, prioritized, and executed in a group environment. This is supposed to decrease the cycle time as everyone is together during the development and testing phases. Scrum is a type of Agile where the prioritized activities are worked in Sprints using improved planning techniques. This is an over-simplified explanation, but has shown to be effective when used appropriately.
WRAPPING IT UP
In the end we are trying to make our products flow better. If we can design processes with less waste and variation, then achieving Return on Investment is faster. Buy-in from our internal and external customers are important to our success in the future and our focus is still on the 4P's.
If you are executing in the DMAIC model and one of the root causes is "we do not have a process", or you have been tasked to figure out how to do this new thing, then you may have found an opportunity to design a new process using DMADV (Design-Measure-Analyze-Design-Verify). This should not be two dude's "Excellent Adventure" where you mess up until the boss finally accepts your new process because she is tired of your rock coloring game. If y=f(x), then you need to figure out the important x's, or stated another way, stop guessing what color she wants for the rock.
![]() |
| Our Friend the Quality Function Deployment. 3 days? Bah! |
First find out who are the customers and what do they want about the product you are designing your process around, this is also called Voice of the Customer. Do you have a large audience of customers? Perhaps a well constructed survey would be best. How about commandments from your company that your process must exist within or government regulations with which you must comply? These would be the Voice of the Business.
Next, when you have collect this information, you can construct the Critical to Customer Requirements and Critical to Business Requirements. Since "Critical" means measurable, we have the basis of performance. No more needing to guess about the color of the rock she wants.
Now you can design the process that creates what is needed, how it is needed, in the amounts needed. Simple right? Probably not, especially if you think a complex solution proves just how intelligent you are. Let's go with a solution that is as simple as it can be. When designed and you have made a few rocks, do they align with the critical requirements? If the answer no, then you are not finished. Keep trying, you are almost there. When the process is working as it should, document your process, someone will be expected to execute it later.
SOFTWARE DESIGN
The Software Development Life Cycle is a specific model used in the execution of software projects. Keep in mind this is for implementing the solution that should be backed up with validated root cause analysis (remember the complexity thing earlier?). The phases are Analyze, Design, Develop, Test, and Finalize; these should seem somewhat familiar in the DMADV model.
Agile is a customer-centered methodology where all the players are gathered together, complaints and good ideas are collected, prioritized, and executed in a group environment. This is supposed to decrease the cycle time as everyone is together during the development and testing phases. Scrum is a type of Agile where the prioritized activities are worked in Sprints using improved planning techniques. This is an over-simplified explanation, but has shown to be effective when used appropriately.
WRAPPING IT UP
In the end we are trying to make our products flow better. If we can design processes with less waste and variation, then achieving Return on Investment is faster. Buy-in from our internal and external customers are important to our success in the future and our focus is still on the 4P's.
Tuesday, September 24, 2013
Process Entitlement
We are all entitled to something, aren't we? How about some peace and time to think before the fire-fighting begins? Probably not. That is unless we have thoughtfully designed our processes to perform at a specific level. Short cycle time, high quality, just a few people touching the product, and we do not leave the day with a backlog larger than we can emotionally handle. How often does this happen in your operations?
Profitable and Customer Satisfying processes do not happen accidentally or magically appear just because someone has the specials letters on their resume (MBA, MBB, SSBB, CQE, PMP, ETC). These processes also do not "just work" because the right people are in the right place at the right time (Process Heroes). It does not matter if we are using manufacturing or business processes, we should be able to receive predictable and profitable performance no matter which well trained and qualified person is sitting in that chair at that time.
When you start measuring your processes you will probably find that the performance is not what you expected and you will have that sinking sensation. Stop and breathe, this is normal to feel some level of anxiety once you have swallowed the red pill and it will pass as soon as you start to think about how to begin analyzing for root causes and implement solutions to address those root causes. So logically, if your process just happens because you throw a contract or database at the team then you will have the performance (good or bad) that just happens by chance. If you have your Process Heroes in place you may have decent on time delivery or quality with rework and inspection, but performance will not be predictable.
Profitable and Customer Satisfying processes do not happen accidentally or magically appear just because someone has the specials letters on their resume (MBA, MBB, SSBB, CQE, PMP, ETC). These processes also do not "just work" because the right people are in the right place at the right time (Process Heroes). It does not matter if we are using manufacturing or business processes, we should be able to receive predictable and profitable performance no matter which well trained and qualified person is sitting in that chair at that time.
![]() |
| Our Process Hero Saves the Day! |
Our Process Heroes can only go for so long, and remember what Dr. Tyrell told us, "The light that burns twice as bright can only burn for half as long" (Yes! It's that important!). When we burn out our Process Heroes we have to rely on people to inspect quality into our products, and Dr. Deming had something important to say about that too.
This change begins like most others, measure the results of the things going though your system. This could be airplanes, circuit boards, decisions, grades, reports, or sales of widgets. Are you receiving the results of your process that you are Entitled to receive?
This change begins like most others, measure the results of the things going though your system. This could be airplanes, circuit boards, decisions, grades, reports, or sales of widgets. Are you receiving the results of your process that you are Entitled to receive?
Friday, June 14, 2013
The Assumed Permanency of the Things We Create
We assume that what we create will live forever. This week I got the chance to volunteer in the Moore, OK cleanup. The destruction was awesome (in the traditional great and fearful way).
The same can be said of our relationships and processes. There is always the possibility that something comes along and transforms our creations. We are only human.
But the most important thing to remember and act upon is that we are a community. We watch out for and protect each other. That is why we are here.
Monday, April 29, 2013
New Learning With Costs
I have been away from the Lean blogosphere this semester and focusing on AC 626 - Cost Accounting for Managerial Decision Making. While I have done this type of work as an Industrial Engineer, I think this class tied together some loose ends that I was not aware that were swinging in the breeze. While I will try to not geek out on you I think this has enhanced how I look at the impact that reducing cycle time has on your operations and eventually your customer, no matter what method you choose to use.
I think in this case Work-in-Process absorbs so much time and energy (that you have to pay someone to worry about) and the fact that our complex systems are not helping us reduce the cost of operations, we "enhance" the links between our employees and our systems with further complex processes. This has a direct effect on unit cost and, if not managed correctly, will make us run our operations into the ground. I think we have seen this with the automobile industry. Why do we reward poor performance with bail-outs and loans that will never be repaid?
While I do not aspire to do Lean with all the cost improvements that we can eat, the focus is still cycle time and unit cost is a reflection on doing the right things right and making the right decisions. In future writings I will address these with deeper detail.
In the mean time let you mind be aglow with whirling, transient nodes of thought careening through a cosmic vapor of invention!
Ditto.
I think in this case Work-in-Process absorbs so much time and energy (that you have to pay someone to worry about) and the fact that our complex systems are not helping us reduce the cost of operations, we "enhance" the links between our employees and our systems with further complex processes. This has a direct effect on unit cost and, if not managed correctly, will make us run our operations into the ground. I think we have seen this with the automobile industry. Why do we reward poor performance with bail-outs and loans that will never be repaid?
While I do not aspire to do Lean with all the cost improvements that we can eat, the focus is still cycle time and unit cost is a reflection on doing the right things right and making the right decisions. In future writings I will address these with deeper detail.
In the mean time let you mind be aglow with whirling, transient nodes of thought careening through a cosmic vapor of invention!
Ditto.
Subscribe to:
Comments (Atom)







