ProjectConnections.

com Guideline

Problem-Solving Tools and Techniques

INTRO !CTION"

Problem-Solving Tools and Techniques

The Guideline and Template Content Starts on the Following Page

#hat 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"
$ishbone diagram" Good for identifying contributing causes, identifying contributing causes, stimulating brainstorming. #h%& 'Re(etitive )uestioning*" Good to help identify root causes. #eighing +gainst Consequences" A systematic way of laying out potential costs, ris s, benefits and rewards of various actions. #eighted Cost-,ene-it +nal%sis" !ompare quantitative ran ings for qualitative criteria for various actions. P-.-I chart" "ate plusses, minuses, and any additional interesting factors for a single given course of action. $orce--ield +nal%sis" #etermine environmental factors that will affect a course of action $ by helping or hindering $ and their relative importance.

#h% It/s !se-ul

"elying on unstructured brainstorming may not always produce the most effective or feasible ideas for a given situation. %y using some or all of the tools in this guideline, you can ensure you&re getting to the root of the problem, and even quantify difficult-to-measure criteria in order to help select the best course of action. 'ore structured decision-ma ing can also provide valuable material for later use in selling the idea up the chain of command, justifying e(penditures, or getting buy-in from the involved or affected parties.

0o1 to !se It
)ollow the basic steps presented in this guideline in order to determine root causes and assess possible solutions. #epending on the comple(ity and impact of the problem, your problem solving team may be a formal committee or an ad-hoc gathering. !omple( 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. *ither approach is valid+ the steps presented here are fle(ible and general enough to produce results without being unduly restrictive. ,hen putting together a team to solve a problem, whether it&s just grabbing a few people for a quic meeting, or constructing a formal effort, ma e 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 wor ing environment, and who have needed technical e(pertise. This may include managers, or team leads, but more often you will want to loo to the people who are actually doing the wor involved. ,hile 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 e(amples. There are dozens of other possible tools available for problem-solving teams, as well/these are among the most useful, but they are far from the only possibilities. 0ic and choose those which seem appropriate to your situation and the problem at hand, and which fit your style.

!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age 7

ProjectConnections.com Guideline

Problem-Solving Tools and Techniques

Problem Solving Tools and Techniques

2. Identi-% the (roblem. :se specific language that doesn&t assume a solution. Good problem statements are quantitative, measurable, specific, non-judgmental, and should describe a problem that has a measurable impact. )or e(ample, if the problem is late delivery of code, you might state the problem li e this; Finished code is consistently delivered 2-3 weeks after initial planning deadline, causing slips in beta implementation. The following are e(amples of poorly worded problem statements; Code is delivered late because of inadequate test procedures. -Assumes a cause or solution.. rogrammers are delivering code too late to finish the pro!ect on time. -0laces blame. Code is delivered too late. -<ot quantifiable, no impact other than emotional. ,hat is =too late>?. 3. Identi-% (ossible causes o- the (roblem. There are several ways to go about this. 9ne commonly used method is brainstorming to produce a list of potential causes. %rainstorming can be either open -where all suggestions are transparent to all participants. or closed -suggestions6contributions are submitted via anonymous contribution $ e.g. written on slips of paper and dropped in a hat.. *ither form can be a productive approach to problem solving if the group is comfortable with an unstructured approach. )or some groups or problems, a more structured approach may be more valuable. @ou may need a more structured approach to idea generation if any of the following is true; @our group is struggling to come up with new ideas, =spinning its wheels> The problem is e(tremely comple(, with many possible causes The problem involves many different departments or groups -increasing the comple(ity of solutions. The team tas ed with solving the problem is bogged down by political issues The team tas ed with solving the problem is having trouble generating alternative ideas -groupthin . There is already an underlying assumption of the cause or solution, ma ing it difficult to e(plore other possibilities. Technique" $ishbone4Cause and 5--ect iagrams 'Ishi6a1a iagram* 5n these situations, a !ause and *ffect diagram can be helpful, by encouraging team members to e(plore 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. !ategories frequently used in process improvement efforts are 'an, 'an 'achine 'achine, 'aterials and 'ethod, however these are not hard and fast requirements. *nvironment is 0roblem sometimes included, or may 8tatement replace an inapplicable category. 9ther problems may be better e(amined in terms of stages of a 'aterial 'ethod process, or departments that =touch> a product or process. The e(act categories are not important.

!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age 1

ProjectConnections.com Guideline

Problem-Solving Tools and Techniques

Technique" $ishbone4Cause and 5--ect iagrams 'Ishi6a1a iagram*

Continued

)or each major category, list every possible cause the team can come up with. )or each cause, draw a line stemming from the applicable main category line. )or e(ample, =coding bugs> would be a potential cause under ='an> whereas =slow approval> might be a cause under ='ethod.> !ontinue brainstorming until all possible causes have been listed. 8ome causes may even have sub-causes listed from their lines. The resulting diagram loo s something li e a fish s eleton, thus the name. A cause-and-effect diagram may be drawn over several sessions if more e(tended analysis is required. 'an !ode bugs 'achine 5nadequate test equip. Bate code delivery *(cessive time in debugging 'aterial 'ethod

8low approval

Partial fishbone diagram showing some potential causes

9nce the diagram is complete, select the most li ely or most significant causes for further investigation. Continued on ne"t page

!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age A

ProjectConnections.com Guideline

Problem-Solving Tools and Techniques

7. .a6e sure %ou are dealing 1ith the true root cause o- the (roblem. 9nce you have identified the potential ey causes creating the problem, investigate to determine which cause-s. you should address in order to solve the problem. *(amine the situation from all sides to be sure that you addressing a cause and not a symptom. *(cessive time spent in debugging code might be a result of poorly-trained programmers, overly-comple( code requirements, poor design, or unrealistic e(pectations -short-scheduled time.. Technique" #h%& #h%& #h%& 'Re(etitive )uestioning* This is a simple technique that will often unearth une(pected relationships. 0retend you&re a preschooler, and eep as ing why until you reach the true root of the problem. The repetition of the question prompts us to dig into what&s really going on. Though you will usually want to as at least A times, there&s no hard and fast rule $ as until you get the answer that you really need. The conversation might go something li e this; Team Leader: 5t loo s li e our biggest problem is spending too much time in debugging. ,hy could this be happening? Team Member 1: The programmers aren&t as careful as they should be. They&re having to spend wee s on debugging because there are more errors than usual. TL: #$gnores the blame placed and refocuses on the issue% ,hy are there more errors being made than there used to be? TM : The programmers are really overwor ed right now, and there have been a lot of last minute changes, too. TL: #separates the causes for evaluation% Bet&s tal about the first one. ,hy are the programmers so overwor ed? TM : ,e&ve had 3 major projects come due over the last A months. TL: ,hy weren&t the project deliverables staggered better? TM1: ,hen they were scheduled, we were told everything would be fine. %ut they&ve lost 1 programmers since then. #continuing this thread of inquiry reveals a resource allocation problem.% TL: Bet&s go bac to the last minute changes that were mentioned. ,hy are those happening more often? TM!: !lient A has been ma ing a lot of additional requests and modifications. TL: ,hy have they been ma ing so many requests, though? Are these new features? TM1: <o, they&ve mostly been additions or revisions to original features? TL: ,eren&t those features approved during initial design? TM1: ,ell, the initial design review meetings were good, but the last couple of meetings several people were missing. ,e still haven&t got the signed design approval. TL: ,hy did we move into coding without getting that? TM1: They&ve got a firm release date for that product. ,e had to get started early $ especially since the programming department is short-handed now. ,hile a bit contrived $ perhaps to the point of being #ilbert-esque $ e(changes li e these aren&t uncommon. 5t&s possible to address a problem by beating on the first obvious solution, but it may not result in long-term improvement. 5n this e(ample, leaning on programmers to spend more time chec ing their code before debugging might ma e the ne(t delivery or two a bit better, but it&s li ely 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.
!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions. 0age 3

ProjectConnections.com Guideline

Problem-Solving Tools and Techniques

8. Construct (ossible solutions to deal 1ith 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. 9nce you have some plausible solutions, weigh their costs and benefits, so you understand the solutions and their implications thoroughly. Technique" #eighing +gainst Consequences 9ne way of doing this is represented in the chart below. )or each solution proposed to address the root problem, list the following; +ssociated costs" These need not be in terms of actually dollar amounts -though they can be if they&re easily nown.. 5t&s more li ely that these would be listed in terms of =what we would have to spend on to do this?> Potential Ris6s" 5f this solution were implemented, what other problems might it cause? Potential ,ene-its" ,hy is this a valid idea? ,hat is the benefit of the particular solution? )or e(ample, one potential benefit of iterative design is greater customer involvement in the process. Possible Re1ards" ,hat is the ultimate upside associated with the benefits listed. )or instance, greater customer involvement has the possibility of producing higher customer buy-in to the finished design, and thus more satisfied customers. Overall assessment" 9nce the costs, ris s, benefits, and rewards of a particular solution have been laid out, record the conclusions. 5s the solution ideal, but too costly or ris y to try now? 5s it low-cost, low-ris , but a stop-gap that will require revisiting the problem later? Assess each solution in terms of your analysis. #eighing +gainst Consequences Solution
Cire 1 more programmers

+ssociate d costs
- Ciring and headcount - Training

Potential Ris6s
!an we find qualified people in time? Bost contracts or customer confidence 0ossibility of getting unqualified help

Potential ,ene-its
"estores original capacity 5mmediate scheduling relief

Possible Re1ards
'ight be able to find field e(perts Additional time to revisit design specs 'ight supply potential long-term hires

Overall assessment
<eed to re-staff eventually, but can&t do this fast enough to save e(isting projects %est solution for longterm scheduling, but can&t sustain client ris at this time. 0ossibly e(pensive, but best solution for immediate relief

8lip dates on e(isting projects

<one

Temporarily contract some code wor to outside firm

- !ontract costs - Training, possibly

5mmediate scheduling relief

"#ample of weighing se$eral solutions against consequences% &lan' form for this method is on Page (%

!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age D

ProjectConnections.com Guideline

Problem-Solving Tools and Techniques

Technique; #eighted Cost-,ene-it +nal%sis 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. )irst, list the criteria most important to your decision along the left, and each of the proposed solutions across the top. @our criteria may include things li e ease of implementation, probability of success, effectiveness of the solution, or how much resistance you are li ely to encounter during implementation. @ou 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 ma ing process. Adapt the criteria to your particular situation, including as many as you feel important to achieve a meaningful ran ing. 5n the ,eight column, assign a percent value that reflects how important that particular criteria is to the overall decision. ,hile this is somewhat arbitrary, it should reflect the priorities of the organization in general, and the team in particular. 'a e sure that your percentages add up to 722. 9nce you have a weighting system everyone is happy with, score each solution using a consistent number scale -e.g. 7 for a solution that does a poor job of meeting a criteria, D for a solution that does an e(cellent job.. 5n the ,eighted 8core column, multiply the rating by the weight for that criterion. Total the weighted scores to see how the solutions stac up against each other and your most important decision points. +dditional 0iring Criteria *ase of implementation 0robability of 8uccess *ffectiveness Bevel of "esistance Score #eight 72E D2E A2E 72E 299:
Rating #eighted score

Sli( dates
Rating #eighted score

Contract hel(
Rating #eighted score

1 3 D 7

.1 1 7.D .7 7.;

7 1 A D

.7 7 7 .D 3.<

A 3 D 1

.A 1 7.D .1 8

"#ample of using weighed C&) to e$aluate solutions% &lan' form for this method is on Page *%

Technique" P-.-I 'Pluses= .inuses= Interesting Points* 5f preferred, decisions can also be quantified on an individual basis. A 0-'-5 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. Bist all the plusses -0., the minuses -'., and any interesting points -5. that deserve consideration. "ate each item on a scale --D to FD 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. "epeating this process for additional solutions may help outline their relative worth, though it can get tedious for large numbers of comple( options. O(tion 7" ,ring in contract (rogrammers -or tem(orar% hel( Plus
"apid implementation -F3. 'ight supply potential long-term hires -F1. 5mmediate scheduling relief -FD. Transparent to customer -F3.

.inus
!ontract e(pense --1. !ould go through a few candidates getting qualified help --3. 'ay need to train them in our systems --A.

Interesting
'ight be able to e(plore long-term vendor relationship -F1. 'ore li ely to have personality conflicts? --7.

Total Score" >. This is a good o(tion to e?(lore.

!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age G

ProjectConnections.com Guideline

Problem-Solving Tools and Techniques

@. ,e a1are o- an% -actors that ma% (revent success. 9nce you&ve identified a favored solution, consider the entire environment that will impact your efforts before moving to implementation. Technique" $orce-$ield +nal%sis A )orce-field Analysis -also called a T diagram. wor s well for this. 5dentify all the forces in the implementation environment that will help or advance the implementation $ anything that favors it. 9n the other side, identify any forces that will hinder the implementation $ anything that will slow it, cause potential resistance, or create roadbloc s. 5f desired, you can rate each factor according to how much impact it is li ely to have. ,ith this diagram, you now have an idea of what factors of resistance you need to remove or reduce -and how many. in order to ma e your solution implementation viable. $orce-$ield +nal%sis -or ,ringing in Contract 0el( 0el(s ';* -D. 0rogramming is eager for scheduling relief -A. 'anagement li es cheaper, shortterm headcount 0inders '-<* 0rogrammers are often reluctant to spend time training new hires --7. 0rogrammer concerns about job security -feelings of competition. --A.HH 0roject comple(ity may ma e it harder to find qualified contractors --1.H
H 9utline less comple( tas s that are easily delegated, so new contractors can start immediately. HH "eassure programming department that contractors are being treated as potential additions, not replacements.

<. Im(lementation. 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 implement/or at least that you&re sure what potential landmines are out there waiting for you. 5f 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 e(plain why a particular solution was selected and prepare for any objections.

&lan' forms for +eighing )gainst Consequences and +eighted Cost,&enefit )nal-sis begin on the ne#t page%

!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age 4

ProjectConnections.com Tem(late

Problem-Solving Tools and Techniques

#eighing +gainst Consequences

Solution +ssociated Costs Potential Ris6s Potential ,ene-its Possible Re1ards Overall assessment

+ssociated costs" ,hat we would have to spend on to do this? Potential Ris6s" 5f this solution were implemented, what other problems might it cause? Potential ,ene-its" ,hy is this a valid idea? ,hat is the benefit of the particular solution? )or e(ample, one potential benefit of iterative design is greater customer involvement in the process. Possible Re1ards" ,hat is the ultimate upside associated with the benefits listed? )or instance, greater customer involvement has the possibility of producing higher customer buy-in to the finished design, and thus more satisfied customers. Overall assessment" !onclusions. Assess each solution in terms of your analysis.

!opyright 1223-1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age I

ProjectConnections.com Tem(late

Problem-Solving Tools and Techniques

#eighted Cost-,ene-it +nal%sis

O(tion 2 #eighted Rating7 score8 O(tion 3 #eighted Rating score O(tion 7 #eighted Rating score

Criteria2

#eight3

Score

299:

2. Criteria. Bist the criteria most important to your decision. There are no right or wrong criteria $ include whatever seems important and appropriate to your decision ma ing process, and as many as you feel important to achieve a meaningful ran ing. 0ossible criteria include; *ase of implementation 0robability of success *ffectiveness of the solution Cow much resistance you are li ely to encounter during implementation !ustomer impact Boss of revenue 'anpower requirements !ost Time to implement 'orale impacts

3. #eight. Cow important is each !riteria to the decision? "ate them using a percentage. 'a e sure all percentages add up to 722E. 7. Rating. "ate each solution on an appropriate number scale. 7-D scales -D being best. are most intuitive for many people. 7-3 scales can be used if everything tends to get rated in the middle. 8. #eighted Score. 'ultiply the "ating by the ,eight percentage. Total all the ,eighted 8cores to arrive at a final score for that solution.

!opyright 1223 $ 1224 *mprend 5nc. 6 0roject!onnections.com. 0ermission for 'embers& use on their projects. 8ee our Terms of 8ervice for information on 0'96group use and corporate subscriptions.

0age J