A Lesson in Problem Solving: Go back to school for a second, maybe even as far back as grade school, and think about solving mathematical word problems. Remember with word problems, each problem described a situation that involved numerical relationships. However, the situation and those relationships first had to be interpreted and understood. Then it was really just a matter of performing simple arithmetic computations to get the answer. But, how good were you at it?
Many of the computations were simple, and the use of algebra or formulas was not even required. The problem required that you understood and precisely spelled out the situation that was being described. Once a problem was set up properly in arithmetic, it was typically very easy. Here’s a takeoff for solving math word problems that could easily be applied to solving your customers’ problems:
- First things first, don’t try to do it alone. Do your analysis with a partner, i.e., the customer. This is a joint effort, so blasting your message in the hope that someone will understand it does not work.
- Try to do all of your thinking as part of a conversation. Communicate all of your thoughts, decisions, analysis, and conclusions. Communicate how you’re starting the problem, questions you’re asking yourself, steps you’re taking to break the problem into parts, conclusions you are drawing —everything. If you perform any mental operations, even translating an unfamiliar word or visualizing a picture of a relationship, communicate these operations. Letting each other know what you’re thinking is imperative.
- Use a step-by-step analytical procedure. Use the techniques that good problem solvers use, and break a problem into parts. Work one part accurately and then move on to the next part. Translate unfamiliar phrases into your own words and/or visualize or make diagrams of the relationships presented verbally. Simplify problems by substituting easier numbers, making a table of successive computations or referring to an earlier problem.
- Be extremely accurate. Continually check your thinking. Your thoughts should drive questions like: Is that entirely correct? Is that completely accurate? Give yourself sufficient time to address all parts of the problem. Never just give up on the problem to get a quick answer. Always try to reason the problem out.
While your customer is working through the problem, keep checking the accuracy so that you will learn to think with more precision and thoroughness. In addition, in your own mind contrast the methods with theway the problem was attacked.
- How might you break the problem downmore completely into smaller problems?
- What other steps might you take?
- How might you visualize or use diagrams or relationships to make it more effective?
- Would you work more carefully?
In other words, try to imagine ways in which you might attack the problem more effectively.
Tools used in A3
The use of statistical methods is essential to minimize confusion and to explain your story accurately in an A3. Statistics help us to understand the processes, gain control, and improve them. Not to say statistical techniques are simple, but the graphical presentation is when done correctly. Always remember your audience when creating a diagram, chart or graph. The following is an outline of some of the methods which are used in A3s. Since the cause and effect is so common, I have added a bit more description.
- Flow Chart. This is a graphical method of documenting a process. It is a diagram that shows the sequential steps of a process or of a work flow that goes into creating a product or service. The justification of flow charts is that in order to improve a process, one needs first to understand it.
- Pareto Chart. This is a commonly used graphical technique in which events to be analyzed are named. The incidents are counted by name: the events are ranked by frequency in a bar chart in ascending sequence. Pareto analysis applies the 80/20 rule. An example of this is when 20% of an organization’s customers account for 80% of the revenue, the company focuses on the 20%.
- Run Chart. A run chart is a technique that graphs data points in chronological order to illustrate trends of a characteristic being measured in order to assign a potential cause rather than random variation.
- Histogram. A histogram is a graphical description of measured values organized according to the frequency or relative frequency of occurrence. It also provides the average and variation.
- Scatter Diagram. A scatter diagram is a graph designed to show where there is a relationship between two variables or changing factors.
- Control Chart. A control chart is a statistical method for distinguishing between special and common variations exhibited by processes. It is a run chart with statistically determined upper and lower limits drawn on either side of the process averages.
- Cause-and-Effect Diagram: One of the Lean tools used to determine cause and effect is the Fishbone diagram, also known as the Cause-and-Effect diagram or Ishikawa diagram. It identifies and explores on a single chart the “five whys” technique. The aim is to work down through the causes to identify basic root causes of a problem by asking the question “Why?” five times. It appears very simple but the results are outstanding. As a result, it is used very often and should be mastered. Why would you use it?
- Allows various categories of causes to be explored.
- Encourages creativity through a brainstorming process.
- Provides a visual image of the problem and potential categories of causes
- Analyzes complex problems that seem to have many interrelated causes
One of the most important aspects of the “five whys” approach is that the REAL root cause should point toward a process. You will observe that the process is not working well or that the process does not even exist. The Business901 podcast that featured Tracey Richardson and her discussion on Problem Solving was one of my top podcasts in 2010. One of the topics we covered was the “five whys” process. I asked this question:
Joe: One of the great tools of Lean is the “Five Whys” to get to the root cause. Can you explain why you don’t use three whys, two whys, or seven whys? I mean, how did they come up with the five whys and what’s that really mean?
Tracey: Right. And it’s funny you say that because when I first started in my career at Toyota, everybody was like; “You got to have five whys!” My first question was, “Well, what if it’s only two or what if it’s three? What if you start asking too many times?” So that was one of my first questions, too, and how it was explained to me is that it’s not about five or two or 10. It’s about the thought process behind your thinking. Are you asking why? Do you need to go deeper? Do you need to go even deeper when you’re asking why?
Because most of the time symptoms are at the surface, and the root cause is normally below the surface. That’s getting into the design of the work, into the process, into the specific standardized work steps that folks are doing out there on a daily basis.
Continuing to ask why allows you to get deeper, rather than just “Oh, I’ve got to solve this today. I’ve got to hurry up and get the answer so I can make my boss happy.” That “five whys” allows you to get into the work, and that’s where the answers are, in that work.
I’ve had many A3s, hundreds of A3s, and they will vary. I might have only two whys, where I get down to the actual root cause by just asking twice. Or I’ve got examples where I’ve had 10 and you need to be aware that if you ask “why?” too many times, it changes the scope of the problem. I have several examples in class and one of them kind of talks about the alarm clock going off. I can ask why did the alarm go off? Well, the power went out. Why did the power go out? Well, there was a storm. Why was there a storm? If you keep asking why, you’re getting into things that you can’t control.
We try to say OK, where is it within the “why” chain that I can control that an effective countermeasure will address that root cause and all the symptoms or all the whys up the chain lead me back to the problem? You don’t want to go too far, because again it gets you out of the control and it changes the scope of the problem. Because if you get into asking about storms and the clouds not liking each other up in the atmosphere, then you’re counter measuring something that has nothing to do with your problem. That’s when you do the “why” test down and the “therefore” test back up through the chain to establish that cause-and-effect relationship.
Project Management: I have been a big fan of the The One-Page Project Manager
- The One Page Project Manager for IT Projects: Communicate and Manage Any Project With A Single Sheet of Paper
- The One-Page Project Manager for Execution: Drive Strategy and Solve Problems with a Single Sheet of Paper
I have not read the OPPM for IT but of course have the first one and the latter which is the OPPM for use with an A3. If you are familiar with an A3, I would recommend the original OPPM as you will find the A3 material rather basic. If you are not familiar with A3 the description of the process is quite good in the book but it does not go into the tools used to construct the A3 in much depth. The One Page Project Manager is not meant to replace a full blown project management system. It helps you identify and communicate the essential details of a project.
I think the OPPM completes the job and is a great companion to Lean and especially A3s. I utilize the OPPM with A3s slightly different than the book describes. I use the entire back side of the A3 for the OPPM. I take advantage of a little artistic interpretation of what constitutes one page. Though I have not read the OPPM for IT, I would assume from reading the Table of Contents it does not address agile practices. However, since it is basically a communication and reporting tool, it may be an ideal bridge between agile teams and management. Most managers are familiar with the Gantt style and no so much with burn charts. Using the OPPM to report progress may be an ideal crossover. I have certainly stretched the use of OPPM and managed some rather in-depth and lengthy projects with it. In fact one such project I actually reconfigured the Excel sheet to hold over 100 tasks. It is a tool that should be in anyone’s toolbox.
Below are some simple guidelines on how to develop an entertaining A3 process.
- Define the problem: What is the first thing you learned in 5th grade about writing a story? You have to have a hook! Appeal to the emotions of your audience!
- Measure: Your metrics must clearly define the problem and visually display it. Do not limit yourself to simple metrics; maybe pin the defect or the cause on the wall. If a failure causes a catastrophic condition, display visually what that means.
- Analyze: Create some drama in analyzing the problem. A typical process here would be identifying the few metrics that are vital. Create some drama in finding the root cause. Think about what may happen if you don’t find the real problem.
- Implement: We have taken the story to the critical stage; there has to be a solution. This is where everyone wants to jump in and help. We are all problem solvers but are we all MacGyvers? We have to find the best answer that addresses the root cause and is measurable. Who will be the hero?
- Control: Now is the time in the story that the problem is solved and life goes on happily ever after. Can you depict that in your storyboard? Can you show the results that prove this? Did you reach the other side of the rainbow?
Your A3 should not be a a dry report but an active document that truly makes your project come alive! Storyboarding has become a popular way of transferring the details of a Six Sigma project to a graphical representation. Very much like your child’s fifth grade science fair project. The purpose of course it gives the Six Sigma team a way to summarize their efforts and let other people outside of the team understand their efforts. On the Lean side, I think that is why A3 reporting has become so popular. It is a graphical way of displaying the project. Though we are all not visual learners the majority of us find learning by stories and pictures and diagram much easier.
“The first storyboards were originated in the Disney animation studios in the 1930’s. According to Walt Disney, the storyboard was invented by Web Smith, an animator and one the first story men at the studio. When Web planned a story, he would draw it instead of describing the action in words. At first he simply spread the drawings out over the floor of his office, but soon graduated to pinning them in order on to the walls. In this way, the unfolding story gains the valuable visual dimension. According to legend, Walt was none too happy with the innovation. He had just redecorated the offices and the marred walls in Webb’s office stuck out like a sore thumb. But Walt also recognized the order imposed by the posted drawings and the ease with which the entire feature could be analyzed and manipulated. So he ordered 4? x 8? corkboards and the storyboard was born.
Soon, every Disney cartoon for so life on the storyboard, and the board themselves moved to new departments as the project progressed. The story men would pitch their ideas to Walt on storyboard, color and sound were both added using the storyboard as reference point, etc. When Walt hijacked the studios innovators to design the attractions for Disney land, they brought the storyboard along with them. And today, it has evolved into a standard technique among the Imagineers.”
I think there should be a happy medium somewhere between the Disney storyboard and the Six Sigma storyboard. However, if you error, error toward the Disney side.
As many of you already know, the PowerPoint presentation was developed by engineers for exactly the same reason that most develop a Six Sigma storyboard, to tell the story of a project. However, the main purpose of a storyboard is to tell others outside of the team the story and maybe more importantly to depict to others what is going on inside the project as it is unfolding. Try hanging your A3s in the hallway or cafeteria much like the trophy cases in a school. You may be surprised on the amount of activity and comments that it may stimulate. Ask for comments by putting post it notes next to the storyboard. Get people engaged in the planning process not just at the end.
You may create the typical PowerPoint utilizing SIPOC, VOC, House of Quality and other Six Sigma or Lean Tools. If you are on the team ask yourself, how will you get others engaged? Consider your audience, the storyboard is not about you it is about them.
How do you create a scorecard
Capturing metrics that will provide information on the quality of the deliverables and the processes used to create the deliverables. The following process can be used to come up with the appropriate metrics on the project. This process will result in the creation of a Project Scorecard.
- Identify criteria for success. Review the objectives and deliverables in the Project Definition, as well as any other existing information that is relevant to the project. Based on this existing documentation, define what information is needed to show that the project was successful. This can be from two perspectives:
- Internal – These characteristics indicate that the project was managed and executed effectively and efficiently. These types of metrics include having deliverables approved with no more than two review iterations, hitting major internal milestone dates on time, and having a minimum amount of errors uncovered in user acceptance testing.
- External – These characteristics indicate that your project objectives were completed successfully. Examples of externally focused metrics include completing the project within approved budget and timeline, ensuring your deliverables meet approved quality criteria, and validating that the deliverables meet client expectations.
- Assign potential metrics. Identify potential metrics for each of the success criteria that provide an indication of whether the success criteria are being achieved. These can be direct, quantifiable metrics, or indirect metrics that give a sense for success criteria. For each metric, briefly determine how you would collect the information, what the effort and cost of collection would be, and what value would be obtained.
- Look for a balance. The potential list of metrics should be placed into categories to make sure that they provide a balanced view of the project. For instance, you do not want to end up with only a set of financial metrics, even though they might be easiest to obtain. In general, look for metrics that provide information in the areas such as:
- Cost
- Effort
- Duration
- Productivity
- Quality of deliverables
- Client satisfaction with the deliverables produced
- Project team performance
- Business value delivered
- Prioritize the balanced list of metrics : Depending on how many metrics you have identified, prioritize the list to include only those that have the least cost to collect and provide the most value to the project. There can certainly be as many metrics collected as make sense for the project, but there may end up being no more than one or two per category. In general, look to provide the most information with the least amount of work.
- Set targets : The raw metric may be of some interest, but the measure of success comes from comparing your actuals against a predefined target. The target may be a single value you are trying to achieve, or it may be a range. For instance, you may need to complete your project by a certain fixed date, but your actual cost might have flexibility to be within +/- 10% of approved budget.
- Add workplan detail : For each metric that remains, determine the specific activities necessary to collect and analyze the information. These activities are then added to the project workplan . This information needs to include:
- What specific data is needed for the metrics?
- Who is responsible for collecting the metric?
- When will the metric be collected and reported?
- How will the metrics be reported (status reports, quarterly meetings, metrics reports)?
- Collect and improve: The metrics will be collected on an ongoing basis throughout the project. The metrics need to be analyzed and compared to the target numbers. Process changes may need to be made based on the results of the metrics. In addition to the absolute values of each metric, it is also important to look at the trends. For instance, you may be overbudget versus your target. However, over a series of months, the trend may show that you will hit your budget at the end of the project. In that case, no corrective action may be needed.Likewise, you may have a target for client satisfaction to be a rating of four on a five-point scale. Your current rating may be a 4.1. However, if the prior ratings were 4.5, 4.3 and 4.2, then the trend is going in the wrong direction and you may want to make changes – even though you are actually above target today.
- Analyze scorecard . Evaluate the metrics you are collecting on a monthly basis to ensure they still accurately reflect the overall project status, and that they are driving the behaviors desired. If they are not, make changes as appropriate.
How do you create a scorecard content from Ten Step Project Management
Bonus Material:
Sample A3s
Submitted by: Joe Dager
Website: https://business901.com
Email: [email protected]
Twitter: @business901
Submitted by: Tracey Richardson
Website: http://teachinglean.com
Email: [email protected]
Twitter: @thetoyotagal
Submitted by: Mike Osterling
Website: Osterling Consulting
LinkedIn: http://www.linkedin.com/in/mikeosterling
Using an A3 for Special Causes – Lean for Haiti
Submitted by: Russell Maroni and Mark Graban (Lean Blog)
Website: Lean for Haiti
Submitted by: Joe Dager
Website: https://business901.com
Email: [email protected]
Twitter: @business901