Reflection

Mind Mapping

A tool from this course that I have used before is Mind Mapping. I used Mind Mapping to help

solve a problem at a plant at which I previously worked. I was having trouble communicating specific  tasks to various cross-functional groups with enough time to support production. The task at hand was  the effort to find a new scheduling/planning tool that would be able to give all the cross-functional areas  the detail and notice they needed to complete their required activities. The tool that was currently being  used was not satisfactory and was causing issues. Since I am not an expert in what every cross-functional  area in a manufacturing plant specifically needs, I used Mind Mapping as a way to map out the wants  and needs of the final users of the tool.

Selection

Mind Mapping was the method I selected for several reasons, the first reason being this was not

my initial attempt at updating the scheduling process. Previous attempts had been met with push-back  from the stakeholders. I had tried to fix the tool in a way that I thought was positive but the change was  not adopted by the other stakeholders. Secondly, there was a large and diverse group of stakeholders at  the plant and I did not know exactly what every one of them required. Finally, I needed a way to think  this project through clearly with some kind of feedback before spending the large amount of time  necessary to redesign the tool.

Application

The application of the Mind Map to this problem was fairly straight-forward as outlined in the

course lectures. The process started by taking the old version of the tool and gathering a group of cross-  functional stakeholders. I held a weekly review meeting to follow up on issues and problems from the  group. The group was able to provide a long list of issues with the current tool that I had been tracking. I  also compiled some information from the stakeholders’ requests and complaints from their emails.

I was able to sort through the issues and come up with a list of common issues. From this list, I

was able to start building my map. Using the common issues list as a guide, I was able to go back to  weekly meetings and start posing “what if” questions to the group. This was the start of the segue from  the “what is” phase to the “what if” phase of the design process. By posing these questions from the  group’s feedback, I was able to diagnose the key points that needed to be updated or completely  changed. The mapping process gave me a list of possible changes that were of high value to the group of  stakeholders without costing me the time and effort it would have taken to build a completely new  model and repeatedly change it.

Change of Approach for Next Time

Here is where I would have liked an additional feedback loop like the one in the plan outlined by

Sandra Mata. Adding the step of working with users to make the jump from issues like, “It’s hard to  understand some of the long term data” to “Keep it more simple. That data isn’t really used,” would  have been helpful. I feel there could have been additional layers of understanding added in that step  that I may have missed, making those jumps on my own based on the most commonly pointed-out  issues that came up in my cross-functional meetings.

This takeaway learned from the formal process would be a new addition to what I have used in

the past. Even though the process I implemented was fundamentally the same as the one outlined by  Sandra Mata, there is always room to grow and expand. Points of additional feedback can help grow  the Mind Map and expand the criteria that could be a big time-saver once I got into the actual design  process of the overall scheduling format.

Insights from the process

From this process I did find some major takeaways that were different than I had expected. I

assumed details would be key but simplicity was overwhelmingly what was requested.  I also assumed  reducing changes was important but live information was what was desired. The process made it clear  that I did not know everything I needed to know at the outset and by jumping right to the design step, I  would have wasted time and money for the plant. Taking the additional time to map out a plan and  better understand the design is totally worth it.


Reflection Mind Mapping A tool from this course that I have used before is Mind Mapping . I used Mind Mapping to help solve a problem at a plant at which I previously worked . I was having trouble communicating specific tasks to various cross - functional groups with enough time to support production . The task at hand was the effort to find a new scheduling / planning tool that would be able to give all the cross - functional areas the detail and notice they needed to complete their required activities . The tool that was currently being used was not satisfactory and was causing issues . Since I am not an expert in what every cross - functional area in a manufacturing plant specifically needs , I used Mind Mapping as a way to map out the wants and needs of the final users of the tool . Selection Mind Mapping was the method I selected for several reasons , the first reason being this was not my initial attempt at updating the scheduling process . Previous attempts had been met with push - back from the stakeholders . I had tried to fix the tool in a way that I thought was positive but the change was not adopted by the other stakeholders . Secondly , there was a large and diverse group of stakeholders at the plant and I did not know exactly what every one of them required . Finally , I needed a way to think this project through clearly with some kind of feedback before spending the large amount of time necessary to redesign the tool . Application The application of the Mind Map to this problem was fairly straight - forward as outlined in the course lectures . The process started by taking the old version of the tool and gathering a group of cross- functional stakeholders . I held a weekly review meeting to follow up on issues and problems from the group . The group was able to provide a long list of issues with the current tool that I had been tracking . I also compiled some information from the stakeholders ’ requests and complaints from their emails . I was able to sort through the issues and come up with a list of common issues . From this list , I was able to start building my map . Using the common issues list as a guide , I was able to go back to weekly meetings and start posing “ what if ” questions to the group . This was the start of the segue from the “ what is ” phase to the “ what if ” phase of the design process . By posing these questions from the group ’s feedback , I was able to diagnose the key points that needed to be updated or completely changed . The mapping process gave me a list of possible changes that were of high value to the group of stakeholders without costing me the time and effort it would have taken to build a completely new model and repeatedly change it . Change of Approach for Next Time Here is where I would have liked an additional feedback loop like the one in the plan outlined by Sandra Mata . Adding the step of working with users to make the jump from issues like , “ It ’s hard to understand some of the long term data ” to “ Keep it more simple . That data is n’t really used , ” would have been helpful . I feel there could have been additional layers of understanding added in that step that I may have missed , making those jumps on my own based on the most commonly pointed - out issues that came up in my cross - functional meetings . This takeaway learned from the formal process would be a new addition to what I have used in the past . Even though the process I implemented was fundamentally the same as the one outlined by Sandra Mata , there is always room to grow and expand . Points of additional feedback can help grow the Mind Map and expand the criteria that could be a big time - saver once I got into the actual design process of the overall scheduling format . Insights from the process From this process I did find some major takeaways that were different than I had expected . I assumed details would be key but simplicity was overwhelmingly what was requested . I also assumed reducing changes was important but live information was what was desired . The process made it clear that I did not know everything I needed to know at the outset and by jumping right to the design step , I would have wasted time and money for the plant . Taking the additional time to map out a plan and better understand the design is totally worth it .