Challenge:

In my line of work, I find myself doing a lot of final product testing.  These tests can range from  characterization to reliability and even simple function testing.  One of the issues I run across frequently  is the results of testing often bring up more questions than they do answers.  As a result, after  continually iterated test plans, the end test plan can look way different then what was originally  requested. Thus, it becomes my challenge to return to the requester and explain the discrepancies  between how things started and where they ended up.  I began to think that maybe instead of the  constant iterations we could get a more complete picture from the beginning.

Selection:

To deal this this challenge, I have selected the tool of storytelling.  A lot of the times when I get an initial  request for testing it is something simple, such as “see if raising the temperate can increase  performance.”  Now this by itself is fairly vague.  For example, I do not know what the metric for  performance is.  Further, there are several variables that could change, and I am unaware of which  variable is the desired result.  The reason I picked storytelling is because there is obviously a larger  picture that is getting lost after it was reduced to a single problem statement.  Secondly, the data I am  returning with is lacking the context to make it really meaningful.

Application:

The first thing I did was go to the requesting manager and find out exactly what they were looking for in  term of performance.  Often in the case in the semiconductor industry, there is many steps in a process  and certain changes upstream can have major effects down the line.  I had him bring together various  stakeholders from the different steps so we could create a fuller picture of what was exactly the  performance they were looking to improve.  Once this had been settled I scheduled a meeting with all  the test engineers and engineers requesting the tests and gave them an overview of what I had heard.   We discuss what the root problem was, and what exactly were the variables that we could change to  address this.

Insite:

The incite we got from the first meeting was that we had the complete wrong picture of what we  wanted to test.  What I originally had though was just a question of temperature vs performance turn  into a much more complex issue of temperature and reactivity rate vs gas leak rate and cleanliness.  Our  original test plan would have answered the question but would not have given us such a clear answer on  how to improve the product.  From the second meeting, I was able to better communicate the overall  goals of the entire program, which lead to less confusion among the team.  This time when small  changes and tweak were made to the test plan, the requesting engineer had been told a bigger picture  story and understood right away why these changes were made.

Approach:

The tool of storytelling proved very useful in giving all groups a higher-level idea of what was going on in  the project.  This approach, however took several meetings and a lot of time to explain.  Moving forward  I would like to use visualization next time to help get all stakeholders up to speed faster.  Many of the  people on the meetings were only familiar with their own division, and had issues grasping some of the  concepts being explained.  I think a visual representation of the process as a whole would have given  them a better starting point and reduced the amount of meeting time it took to create a consensus.


Challenge : In my line of work , I find myself doing a lot of final product testing . These tests can range from characterization to reliability and even simple function testing . One of the issues I run across frequently is the results of testing often bring up more questions than they do answers . As a result , after continually iterated test plans , the end test plan can look way different then what was originally requested . Thus , it becomes my challenge to return to the requester and explain the discrepancies between how things started and where they ended up . I began to think that maybe instead of the constant iterations we could get a more complete picture from the beginning . Selection : To deal this this challenge , I have selected the tool of storytelling . A lot of the times when I get an initial request for testing it is something simple , such as “ see if raising the temperate can increase performance . ” Now this by itself is fairly vague . For example , I do not know what the metric for performance is . Further , there are several variables that could change , and I am unaware of which variable is the desired result . The reason I picked storytelling is because there is obviously a larger picture that is getting lost after it was reduced to a single problem statement . Secondly , the data I am returning with is lacking the context to make it really meaningful . Application : The first thing I did was go to the requesting manager and find out exactly what they were looking for in term of performance . Often in the case in the semiconductor industry , there is many steps in a process and certain changes upstream can have major effects down the line . I had him bring together various stakeholders from the different steps so we could create a fuller picture of what was exactly the performance they were looking to improve . Once this had been settled I scheduled a meeting with all the test engineers and engineers requesting the tests and gave them an overview of what I had heard . We discuss what the root problem was , and what exactly were the variables that we could change to address this . Insite : The incite we got from the first meeting was that we had the complete wrong picture of what we wanted to test . What I originally had though was just a question of temperature vs performance turn into a much more complex issue of temperature and reactivity rate vs gas leak rate and cleanliness . Our original test plan would have answered the question but would not have given us such a clear answer on how to improve the product . From the second meeting , I was able to better communicate the overall goals of the entire program , which lead to less confusion among the team . This time when small changes and tweak were made to the test plan , the requesting engineer had been told a bigger picture story and understood right away why these changes were made . Approach : The tool of storytelling proved very useful in giving all groups a higher - level idea of what was going on in the project . This approach , however took several meetings and a lot of time to explain . Moving forward I would like to use visualization next time to help get all stakeholders up to speed faster . Many of the people on the meetings were only familiar with their own division , and had issues grasping some of the concepts being explained . I think a visual representation of the process as a whole would have given them a better starting point and reduced the amount of meeting time it took to create a consensus .