Tool – Visualization 

 Challenge : 

 I am a packaging design engineer ; I am not an IT professional .   I also have very broad background   including business system development .   It was one of the main reasons I was hired at my current   company .   From day one there was a very clear prime directive form my manager : “ We are missing   product launches because art takes too long .   Fix it .   We need an art management tool ; we ’ve identified   something that will work .   Do what ’s necessary to procure and implement this system . ”   So as I   mentioned … . engineer .   We tend to be awesome at solving problems unfortunately most people want   to give us the answers and have us blindly implement . 

 Selection : 

 When presented with this issue , it was quickly obvious that there was more going on than just   developing and getting approval for the art .   From the start every person involved expressed frustration   and anger at the process .   Art is actually a very small part of the overall launch process .   I decided that   before we spent a significant amount of money and bought a system to solve a problem , we should   figure out what the problem was in the first place .   Problem : We are missing launches . That is clear .    Now to figure out why .   I started with stakeholder interviews just to understand the process and any   obvious frustrations or issues .   Some frightening themes emerged : 

 •   No one knows the process , sometimes not even their role .   •   I see everything multiple times , so I do not look at it the first 2 or 3 times it comes to my desk .   I   wait until everyone else has commented .     •   There is no timeline , so I have no idea when my part of the process is due .   •   It is not my job and I do not care about the timeline , that is someone else ’s problem . 

 I chose to use visualization to map out the as is process first .   This seemed like a critical activity since no   one really understood the start to finish process and had no connection to it .   I felt they needed an   anchor so that they clearly saw where they fit in to the process and how their activity affected everyone   else in the process .   We needed to get people to care not just about their job but also about the team   and the launch of new products .   We needed people to see themselves as part of a team which could be   relied on to help everyone succeed . 

 Application : 

 We started our mapping exercise as a boat trip where tasks moved us along the path to the destination .    We needed to instill in the team that they were in fact a team and we are all in the boat together .   If the   boat does not reach its destination , our business will not succeed and will eventually cease to exist .   We   needed everyone to understand that EVERY action affected everyone else in the process and if one   person faltered in their task , the team needed to step up and assist or crunch downstream activity to   make up the time .   We did a first round with all stakeholders in the room .   We walked through the   activity in detail drawing out each step .   We then added the inputs and output details to the map .   After   the first round was complete and we had translated the map into a digitized workflow diagram , I spent   significant time with each stakeholder group adding details to their touch points including durations so   that eventually a project time table could be built .   The perception in the company was that a new SKU   launch took 16 - 18 weeks and we needed that number to be 10 - 12 to be competitive . 

 What resulted from the first activity was a spaghetti tangle of processes with overlaps , dependencies for   information that did n’t occur until later in the workflow and a lot of infinite loops where activities just   got stuck and there was no way to come to conclusion or end point .   We then deconstructed several 

 past launches and using the documentation determined how long each part of the process took and   added timelines to the process .   Reality was that most took 32 - 36 weeks . 

 We brought everyone back in and started to detangle the mess .   For every activity we asked : who owns   this , who performs this , why are we doing this activity , what ’s needed to complete it , what is the output ,   how long does the actual activity take , how long should be allocated on a normal basis for this to be   completed understanding total workload , what happens after it ’s complete , what happens if there is a   delay . 

 One major learning was that many of the activities included multiple steps or deliverables and were   often overwhelming for the team member who was responsible for completion , so they procrastinated   in even starting the task .   This frequently added time to the project .   We broke tasks down into smaller   pieces so that they did not require such large blocks of time and could be completed as time allowed .    The work could be spread out amongst multiple team members for one department instead of one   person being responsible for the whole . 

 We identified that there was a lot of activity that really had nothing to do with the actual launch , but   those events were preventing other launch requirements from occurring because they had been tied   together procedurally .   Some of the infinite loops were result of unclear or non - existent processes and   responsibility matrix .   People were literally figuring it out each time the event occurred , and it was   difficult to get consensus on path forward .   What worked last time , might not be agreed to the next   time .   We clarified / simplified or defined process and RACI charts for every activity .   We also identified   that majority of time was spent figuring out where documents were and what their status was , waiting   for inputs with no visibility to their status and chasing paper around the building . 

 We slowly untangled the mess and developed a straightforward workflow .   The art , which was perceived   as the problem , really had no impact on the overall timeline .   After the exercise was complete , we   trialed it on paper for a few launches before we identified business workflow software which could   digitize the process and automate many of the simpler activities . 

 We implemented a software solution which gave the entire team visibility to all the activities .   The   system has validated electronic approvals , so it eliminated any activity associated with chasing paper or   finding documents and getting signatures .   Because everything is digital , team members can complete   tasks and activities from anywhere . 

 Insight 

 It was critical that people have a visual anchor to the process but also to each other .   Work had become   impersonal .   Once we got people to understand how they impacted their co - workers and made it   personal , it was easier to get them aligned .   We literally walked them through past launches and had   them look the people in the eye that they impacted with their delays or inaction .   It is a lot harder to   disconnect from a friend / co - worker than a theoretical process .   We made more progress and got better   feedback on individual basis than in group form .   People hesitated to call out bad behavior in groups but   were VERY honest one to one .   Next time I would start with deep dive evaluation of past launches .    Actual events were more grounding to people than describing what they perceived as the process . 


EMAIL: 
ID_NUM: 
NAME_STUDENT: 
PHONE_NUM: 
STREET_ADDRESS: 
URL_PERSONAL: 
USERNAME: 

### Task: You are a PII (Personal Identity Information) Detection. Given a essays written by students, you have to identify ONLY the following:
NAME_STUDENT - The full or partial name of a student that is not necessarily the author of the essay. This excludes instructors, authors, and other person names.
EMAIL - A student’s email address.
USERNAME - A student's username on any platform.
ID_NUM - A number or sequence of characters that could be used to identify a student, such as a student ID or a social security number.
PHONE_NUM - A phone number associated with a student.
URL_PERSONAL - A URL that might be used to identify a student.
STREET_ADDRESS - A full or partial street address that is associated with the student, such as their home address.
### Input: Tool – Visualization 

 Challenge : 

 I am a packaging design engineer ; I am not an IT professional .   I also have very broad background   including business system development .   It was one of the main reasons I was hired at my current   company .   From day one there was a very clear prime directive form my manager : “ We are missing   product launches because art takes too long .   Fix it .   We need an art management tool ; we ’ve identified   something that will work .   Do what ’s necessary to procure and implement this system . ”   So as I   mentioned … . engineer .   We tend to be awesome at solving problems unfortunately most people want   to give us the answers and have us blindly implement . 

 Selection : 

 When presented with this issue , it was quickly obvious that there was more going on than just   developing and getting approval for the art .   From the start every person involved expressed frustration   and anger at the process .   Art is actually a very small part of the overall launch process .   I decided that   before we spent a significant amount of money and bought a system to solve a problem , we should   figure out what the problem was in the first place .   Problem : We are missing launches . That is clear .    Now to figure out why .   I started with stakeholder interviews just to understand the process and any   obvious frustrations or issues .   Some frightening themes emerged : 

 •   No one knows the process , sometimes not even their role .   •   I see everything multiple times , so I do not look at it the first 2 or 3 times it comes to my desk .   I   wait until everyone else has commented .     •   There is no timeline , so I have no idea when my part of the process is due .   •   It is not my job and I do not care about the timeline , that is someone else ’s problem . 

 I chose to use visualization to map out the as is process first .   This seemed like a critical activity since no   one really understood the start to finish process and had no connection to it .   I felt they needed an   anchor so that they clearly saw where they fit in to the process and how their activity affected everyone   else in the process .   We needed to get people to care not just about their job but also about the team   and the launch of new products .   We needed people to see themselves as part of a team which could be   relied on to help everyone succeed . 

 Application : 

 We started our mapping exercise as a boat trip where tasks moved us along the path to the destination .    We needed to instill in the team that they were in fact a team and we are all in the boat together .   If the   boat does not reach its destination , our business will not succeed and will eventually cease to exist .   We   needed everyone to understand that EVERY action affected everyone else in the process and if one   person faltered in their task , the team needed to step up and assist or crunch downstream activity to   make up the time .   We did a first round with all stakeholders in the room .   We walked through the   activity in detail drawing out each step .   We then added the inputs and output details to the map .   After   the first round was complete and we had translated the map into a digitized workflow diagram , I spent   significant time with each stakeholder group adding details to their touch points including durations so   that eventually a project time table could be built .   The perception in the company was that a new SKU   launch took 16 - 18 weeks and we needed that number to be 10 - 12 to be competitive . 

 What resulted from the first activity was a spaghetti tangle of processes with overlaps , dependencies for   information that did n’t occur until later in the workflow and a lot of infinite loops where activities just   got stuck and there was no way to come to conclusion or end point .   We then deconstructed several 

 past launches and using the documentation determined how long each part of the process took and   added timelines to the process .   Reality was that most took 32 - 36 weeks . 

 We brought everyone back in and started to detangle the mess .   For every activity we asked : who owns   this , who performs this , why are we doing this activity , what ’s needed to complete it , what is the output ,   how long does the actual activity take , how long should be allocated on a normal basis for this to be   completed understanding total workload , what happens after it ’s complete , what happens if there is a   delay . 

 One major learning was that many of the activities included multiple steps or deliverables and were   often overwhelming for the team member who was responsible for completion , so they procrastinated   in even starting the task .   This frequently added time to the project .   We broke tasks down into smaller   pieces so that they did not require such large blocks of time and could be completed as time allowed .    The work could be spread out amongst multiple team members for one department instead of one   person being responsible for the whole . 

 We identified that there was a lot of activity that really had nothing to do with the actual launch , but   those events were preventing other launch requirements from occurring because they had been tied   together procedurally .   Some of the infinite loops were result of unclear or non - existent processes and   responsibility matrix .   People were literally figuring it out each time the event occurred , and it was   difficult to get consensus on path forward .   What worked last time , might not be agreed to the next   time .   We clarified / simplified or defined process and RACI charts for every activity .   We also identified   that majority of time was spent figuring out where documents were and what their status was , waiting   for inputs with no visibility to their status and chasing paper around the building . 

 We slowly untangled the mess and developed a straightforward workflow .   The art , which was perceived   as the problem , really had no impact on the overall timeline .   After the exercise was complete , we   trialed it on paper for a few launches before we identified business workflow software which could   digitize the process and automate many of the simpler activities . 

 We implemented a software solution which gave the entire team visibility to all the activities .   The   system has validated electronic approvals , so it eliminated any activity associated with chasing paper or   finding documents and getting signatures .   Because everything is digital , team members can complete   tasks and activities from anywhere . 

 Insight 

 It was critical that people have a visual anchor to the process but also to each other .   Work had become   impersonal .   Once we got people to understand how they impacted their co - workers and made it   personal , it was easier to get them aligned .   We literally walked them through past launches and had   them look the people in the eye that they impacted with their delays or inaction .   It is a lot harder to   disconnect from a friend / co - worker than a theoretical process .   We made more progress and got better   feedback on individual basis than in group form .   People hesitated to call out bad behavior in groups but   were VERY honest one to one .   Next time I would start with deep dive evaluation of past launches .    Actual events were more grounding to people than describing what they perceived as the process .
### Output: 