Problem Solving Tools

ProjectConnections.
com Guideline
Problem-Solving Tools and Techniques
INTRODUCTION:
The Guideline and Template Content Starts on the Following Page
What This Is
A series of steps and techniques for generating and analyzing ideas for solving a problem at hand. These approaches can be used on a variety of project-related problems, from specific technical issues such as particular failure modes seen during testing, to team process problems such as unproductive meetings, to macro-project issues such as being consistently behind schedule.
Included tools:
Fishbone diagram: Good for identifying contributing causes, identifying contributing causes, stimulating brainstorming. Why? (Repetitive Questioning): Good to help identify root causes. Weighing Against Consequences: A systematic way of laying out potential costs, risks, benefits and rewards of various actions. Weighted Cost-Benefit Analysis: Compare quantitative rankings for qualitative criteria for various actions. P-M-I chart: Rate plusses, minuses, and any additional interesting factors for a single given course of action. Force-field Analysis: Determine environmental factors that will affect a course of action by helping or hindering and their relative importance.
Why Its Useful

Relying on unstructured brainstorming may not always produce the most effective or feasible ideas for a given situation. By using some or all of the tools in this guideline, you can ensure youre getting to the root of the problem, and even quantify difficult-to-measure criteria in order to help select the best course of action. More structured decision-making can also provide valuable material for later use in selling the idea up the chain of command, justifying expenditures, or getting buy-in from the involved or affected parties.
How to Use It
Follow the basic steps presented in this guideline in order to determine root causes and assess possible solutions. Depending on the complexity and impact of the problem, your problem solving team may be a formal committee or an ad-hoc gathering. Complex or critical efforts may require several meetings and detailed process investigation, whereas simple difficulties may be resolved in the matter of an hour or two using selected tools. Either approach is valid; the steps presented here are flexible and general enough to produce results without being unduly restrictive. When putting together a team to solve a problem, whether its just grabbing a few people for a quick meeting, or constructing a formal effort, make sure you enlist the right people to help. The best problemsolving teams will include people who understand the process(es) and politics involved, who are familiar with the working environment, and who have needed technical expertise. This may include managers, or team leads, but more often you will want to look to the people who are actually doing the work involved. While the tools in this guideline are presented in a roughly chronological fashion, you do not necessarily have to use the tools in this particular order, or even to use all of them. This format serves mainly to provide a good, basic problem-solving strategy, and to illustrate the use of these tools with more practical examples. There are dozens of other possible tools available for problem-solving teams, as wellthese are among the most useful, but they are far from the only possibilities. Pick and choose those which seem appropriate to your situation and the problem at hand, and which fit your style.
Copyright 2004-2007 Emprend Inc. / ProjectConnections.com. Permission for Members use on their projects. See our Terms of Service for information on PMO/group use and corporate subscriptions.
Page 1
ProjectConnections.com Guideline
Problem Solving Tools and Techniques

1. Identify the problem. Use specific language that doesnt assume a solution. Good problem statements are quantitative, measurable, specific, non-judgmental, and should describe a problem that has a measurable impact. For example, if the problem is late delivery of code, you might state the problem like this: Finished code is consistently delivered 2-3 weeks after initial planning deadline, causing slips in beta implementation. The following are examples of poorly worded problem statements: Code is delivered late because of inadequate test procedures. (Assumes a cause or solution.) Programmers are delivering code too late to finish the project on time. (Places blame) Code is delivered too late. (Not quantifiable, no impact other than emotional. What is too late?) 2. Identify possible causes of the problem. There are several ways to go about this. One commonly used method is brainstorming to produce a list of potential causes. Brainstorming can be either open (where all suggestions are transparent to all participants) or closed (suggestions/contributions are submitted via anonymous contribution e.g. written on slips of paper and dropped in a hat). Either form can be a productive approach to problem solving if the group is comfortable with an unstructured approach. For some groups or problems, a more structured approach may be more valuable. You may need a more structured approach to idea generation if any of the following is true: Your group is struggling to come up with new ideas, spinning its wheels The problem is extremely complex, with many possible causes The problem involves many different departments or groups (increasing the complexity of solutions) The team tasked with solving the problem is bogged down by political issues The team tasked with solving the problem is having trouble generating alternative ideas (groupthink) There is already an underlying assumption of the cause or solution, making it difficult to explore other possibilities. Technique: Fishbone/Cause and Effect Diagrams (Ishikawa Diagram) In these situations, a Cause and Effect diagram can be helpful, by encouraging team members to explore all possible causes of the problem, no matter what point they might occur in the process. The point of a cause and effect diagram is to separate major categories that impact the process into different areas. The diagram resembles the bones of a fish. Categories frequently used in process improvement efforts are Man, Man Machine Machine, Materials and Method, however these are not hard and fast requirements. Environment is Problem sometimes included, or may Statement replace an inapplicable category. Other problems may be better examined in terms of stages of a Material Method process, or departments that touch a product or process. The exact categories are not important.
Page 2
Technique: Fishbone/Cause and Effect Diagrams (Ishikawa Diagram)
Continued
For each major category, list every possible cause the team can come up with. For each cause, draw a line stemming from the applicable main category line. For example, coding bugs would be a potential cause under Man whereas slow approval might be a cause under Method. Continue brainstorming until all possible causes have been listed. Some causes may even have sub-causes listed from their lines. The resulting diagram looks something like a fish skeleton, thus the name. A cause-and-effect diagram may be drawn over several sessions if more extended analysis is required. Man Code bugs Machine Inadequate test equip. Late code delivery Excessive time in debugging Material Method
Slow approval
Partial fishbone diagram showing some potential causes
Once the diagram is complete, select the most likely or most significant causes for further investigation. Continued on next page
Page 3
3. Make sure you are dealing with the true root cause of the problem. Once you have identified the potential key causes creating the problem, investigate to determine which cause(s) you should address in order to solve the problem. Examine the situation from all sides to be sure that you addressing a cause and not a symptom. Excessive time spent in debugging code might be a result of poorly-trained programmers, overly-complex code requirements, poor design, or unrealistic expectations (short-scheduled time). Technique: Why? Why? Why? (Repetitive Questioning) This is a simple technique that will often unearth unexpected relationships. Pretend youre a preschooler, and keep asking why until you reach the true root of the problem. The repetition of the question prompts us to dig into whats really going on. Though you will usually want to ask at least 3 times, theres no hard and fast rule ask until you get the answer that you really need. The conversation might go something like this: Team Leader: It looks like our biggest problem is spending too much time in debugging. Why could this be happening? Team Member 1: The programmers arent as careful as they should be. Theyre having to spend weeks on debugging because there are more errors than usual. TL: (Ignores the blame placed and refocuses on the issue) Why are there more errors being made than there used to be? TM2: The programmers are really overworked right now, and there have been a lot of last minute changes, too. TL: (separates the causes for evaluation) Lets talk about the first one. Why are the programmers so overworked? TM2: Weve had 4 major projects come due over the last 3 months. TL: Why werent the project deliverables staggered better? TM1: When they were scheduled, we were told everything would be fine. But theyve lost 2 programmers since then. (continuing this thread of inquiry reveals a resource allocation problem.) TL: Lets go back to the last minute changes that were mentioned. Why are those happening more often? TM3: Client A has been making a lot of additional requests and modifications. TL: Why have they been making so many requests, though? Are these new features? TM1: No, theyve mostly been additions or revisions to original features? TL: Werent those features approved during initial design? TM1: Well, the initial design review meetings were good, but the last couple of meetings several people were missing. We still havent got the signed design approval. TL: Why did we move into coding without getting that? TM1: Theyve got a firm release date for that product. We had to get started early especially since the programming department is short-handed now. While a bit contrived perhaps to the point of being Dilbert-esque exchanges like these arent uncommon. Its possible to address a problem by beating on the first obvious solution, but it may not result in long-term improvement. In this example, leaning on programmers to spend more time checking their code before debugging might make the next delivery or two a bit better, but its likely to cost a lot of overtime and burnout in the process, resulting in even more errors on even more projects and ever-increasing delays. The real problem in this scenario is resource allocation.
Copyright 2004-2007 Emprend Inc. / ProjectConnections.com. Permission for Members use on their projects. See our Terms of Service for information on PMO/group use and corporate subscriptions. Page 4
4. Construct possible solutions to deal with the root cause. Given the root cause of the problem, what are the best possible ways to deal with the situation? This may call for a bit of brainstorming again. Once you have some plausible solutions, weigh their costs and benefits, so you understand the solutions and their implications thoroughly. Technique: Weighing Against Consequences One way of doing this is represented in the chart below. For each solution proposed to address the root problem, list the following: Associated costs: These need not be in terms of actually dollar amounts (though they can be if theyre easily known). Its more likely that these would be listed in terms of what we would have to spend on to do this? Potential Risks: If this solution were implemented, what other problems might it cause? Potential Benefits: Why is this a valid idea? What is the benefit of the particular solution? For example, one potential benefit of iterative design is greater customer involvement in the process. Possible Rewards: What is the ultimate upside associated with the benefits listed. For instance, greater customer involvement has the possibility of producing higher customer buy-in to the finished design, and thus more satisfied customers. Overall assessment: Once the costs, risks, benefits, and rewards of a particular solution have been laid out, record the conclusions. Is the solution ideal, but too costly or risky to try now? Is it low-cost, low-risk, but a stop-gap that will require revisiting the problem later? Assess each solution in terms of your analysis. Weighing Against Consequences Solution
Hire 2 more programmers
Associate d costs
- Hiring and headcount - Training
Potential Risks
Can we find qualified people in time? Lost contracts or customer confidence Possibility of getting unqualified help
Potential Benefits
Restores original capacity Immediate scheduling relief Immediate scheduling relief
Possible Rewards
Might be able to find field experts Additional time to revisit design specs Might supply potential long-term hires
Overall assessment
Need to re-staff eventually, but cant do this fast enough to save existing projects Best solution for longterm scheduling, but cant sustain client risk at this time. Possibly expensive, but best solution for immediate relief
Slip dates on existing projects
None
Temporarily contract some code work to outside firm
- Contract costs - Training, possibly
Example of weighing several solutions against consequences. Blank form for this method is on Page 7.
Page 5
Technique: Weighted Cost-Benefit Analysis Another possibility is a weighted analysis based on the most important criteria for your situation. This method provides a quantitative value for qualitative criteria, for those who are more comfortable with such measures. First, list the criteria most important to your decision along the left, and each of the proposed solutions across the top. Your criteria may include things like ease of implementation, probability of success, effectiveness of the solution, or how much resistance you are likely to encounter during implementation. You may need to consider customer impact, loss of revenue, manpower requirements, cost, time to implement, morale impacts, or whatever else seems important and appropriate to your decision making process. Adapt the criteria to your particular situation, including as many as you feel important to achieve a meaningful ranking. In the Weight column, assign a percent value that reflects how important that particular criteria is to the overall decision. While this is somewhat arbitrary, it should reflect the priorities of the organization in general, and the team in particular. Make sure that your percentages add up to 100. Once you have a weighting system everyone is happy with, score each solution using a consistent number scale (e.g. 1 for a solution that does a poor job of meeting a criteria, 5 for a solution that does an excellent job). In the Weighted Score column, multiply the rating by the weight for that criterion. Total the weighted scores to see how the solutions stack up against each other and your most important decision points. Additional Hiring Criteria Ease of implementation Probability of Success Effectiveness Level of Resistance Score Weight 10% 50% 30% 10% 100%
Rating Weighted score
Slip dates
Contract help
2 4 5 1
.2 2 1.5 .1 3.8
1 2 3 5
.1 1 1 .5 2.6
3 4 5 2
.3 2 1.5 .2 4
Example of using weighed CBA to evaluate solutions. Blank form for this method is on Page 8.
Technique: P-M-I (Pluses, Minuses, Interesting Points) If preferred, decisions can also be quantified on an individual basis. A P-M-I chart is one way to go about this. The resulting rating is more arbitrary than the weighted criteria chart, but may be adequate in some situations. List all the plusses (P), the minuses (M), and any interesting points (I) that deserve consideration. Rate each item on a scale (-5 to +5 is useful) depending on its importance to the decision. The total score is achieved by totaling all the ratings; a positive score indicates a good possibility, a negative score raises red flags. Repeating this process for additional solutions may help outline their relative worth, though it can get tedious for large numbers of complex options. Option 3: Bring in contract programmers for temporary help Plus
Rapid implementation (+4) Might supply potential long-term hires (+2) Immediate scheduling relief (+5) Transparent to customer (+4)
Minus
Contract expense (-2) Could go through a few candidates getting qualified help (-4) May need to train them in our systems (-3)
Interesting
Might be able to explore long-term vendor relationship (+2) More likely to have personality conflicts? (-1)
Total Score: 7. This is a good option to explore.
Page 6
5. Be aware of any factors that may prevent success. Once youve identified a favored solution, consider the entire environment that will impact your efforts before moving to implementation. Technique: Force-Field Analysis A Force-field Analysis (also called a T diagram) works well for this. Identify all the forces in the implementation environment that will help or advance the implementation anything that favors it. On the other side, identify any forces that will hinder the implementation anything that will slow it, cause potential resistance, or create roadblocks. If desired, you can rate each factor according to how much impact it is likely to have. With this diagram, you now have an idea of what factors of resistance you need to remove or reduce (and how many) in order to make your solution implementation viable. Force-Field Analysis for Bringing in Contract Help Helps (8) (5) Programming is eager for scheduling relief (3) Management likes cheaper, shortterm headcount Hinders (-6) Programmers are often reluctant to spend time training new hires (-1) Programmer concerns about job security (feelings of competition) (-3)** Project complexity may make it harder to find qualified contractors (-2)*
* Outline less complex tasks that are easily delegated, so new contractors can start immediately. ** Reassure programming department that contractors are being treated as potential additions, not replacements.
6. Implementation. After identifying the root of the problem and spending some time on determining the most effective way to address it, you can move into implementation confident that your solution will be easier to implementor at least that youre sure what potential landmines are out there waiting for you. If you need to get management approval or obtain buy-in from teams or customers, you can use the material generated during the problem-solving process to explain why a particular solution was selected and prepare for any objections.
Blank forms for Weighing Against Consequences and Weighted Cost-Benefit Analysis begin on the next page.
Page 7
ProjectConnections.com Template
Weighing Against Consequences

Solution Associated Costs Potential Risks Potential Benefits Possible Rewards Overall assessment
Associated costs: What we would have to spend on to do this? Potential Risks: If this solution were implemented, what other problems might it cause? Potential Benefits: Why is this a valid idea? What is the benefit of the particular solution? For example, one potential benefit of iterative design is greater customer involvement in the process. Possible Rewards: What is the ultimate upside associated with the benefits listed? For instance, greater customer involvement has the possibility of producing higher customer buy-in to the finished design, and thus more satisfied customers. Overall assessment: Conclusions. Assess each solution in terms of your analysis.
Page 8
ProjectConnections.com Template
Weighted Cost-Benefit Analysis

Option 1 Weighted Rating3 score4 Option 2 Weighted Rating score Option 3 Weighted Rating score
Criteria1
Weight2
Score
100%
1. Criteria. List the criteria most important to your decision. There are no right or wrong criteria include whatever seems important and appropriate to your decision making process, and as many as you feel important to achieve a meaningful ranking. Possible criteria include: Ease of implementation Probability of success Effectiveness of the solution How much resistance you are likely to encounter during implementation Customer impact Loss of revenue Manpower requirements Cost Time to implement Morale impacts
2. Weight. How important is each Criteria to the decision? Rate them using a percentage. Make sure all percentages add up to 100%. 3. Rating. Rate each solution on an appropriate number scale. 1-5 scales (5 being best) are most intuitive for many people. 1-4 scales can be used if everything tends to get rated in the middle. 4. Weighted Score. Multiply the Rating by the Weight percentage. Total all the Weighted Scores to arrive at a final score for that solution.
Copyright 2004 2007 Emprend Inc. / ProjectConnections.com. Permission for Members use on their projects. See our Terms of Service for information on PMO/group use and corporate subscriptions.
Page 9

Problem Solving Tools

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Problem Solving Tools

Uploaded by

Copyright:

Available Formats

ProjectConnections.

Problem-Solving Tools and Techniques

Problem-Solving Tools and Techniques

The Guideline and Template Content Starts on the Following Page

Why Its Useful

Problem-Solving Tools and Techniques

Problem Solving Tools and Techniques

Problem-Solving Tools and Techniques

Technique: Fishbone/Cause and Effect Diagrams (Ishikawa Diagram)

Partial fishbone diagram showing some potential causes

Problem-Solving Tools and Techniques

Problem-Solving Tools and Techniques

Slip dates on existing projects

Temporarily contract some code work to outside firm

- Contract costs - Training, possibly

Problem-Solving Tools and Techniques

Total Score: 7. This is a good option to explore.

Problem-Solving Tools and Techniques

Problem-Solving Tools and Techniques

Weighing Against Consequences

Problem-Solving Tools and Techniques

Weighted Cost-Benefit Analysis

You might also like