Challenge : Describe your challenge , including all relevant information . 

 I work in a software firm that develops and hosts applications for many large banks and businesses . Occasionally , these applications have outages ( due to bugs in the code , resource contention , network issues , or larger AWS outages ) . 

 Whenever a major outage occurs , multiple teams get involved and the process can get disorganized very quickly . Our support team gets involved to solve the issue , the engineering team gets involved to dive into the code base , our cloud team gets involved to check on AWS and any network issues . All of these teams are communicating via email , chat , on support cases , and JIRA tickets . Issues can also span multiple time zones with different people from different teams working on the same issue . 

 As a result of the disorganization , it takes longer to resolve an issue . Management has no visibility so they keep interrupting work to ask for updates . Sometimes , certain important questions are not asked ( since everyone assumes someone else already asked it ) . 

 Selection : In your own words , briefly describe the tool you selected ( e.g. , what it is and why you selected it for your challenge -- including any appropriate video lecture references ) . 

 For this issue , we selected Learning Launch since we already determined What Is , What If , and want to move on to the What Wows . As Andreas Schmitz discussed in Week 4 “ Learning Launch Tool ” , we wanted to test out a hypothesis and learn from a small application of a possible solution . 

 Application : Describe how you applied the tool you selected to your challenge ( e.g. , what you did and how the tool was applied effectively or ineffectively ) . 

 We knew that a lot of the problems stemmed from decentralization . All the information was scattered , and the different stakeholders all had varying levels of access to the information . We wanted to try centralizing the information into one google doc that we called an “ Incident Management ” document . 

 In order to keep the launch small ( and fail faster if needed ) . We started out with a very loose template . We then tried out the document in only a few incidents . After each incident , we would hold a postmortem to look at the results of the learning launch . 

 The Incident Management document was a big success . One of the areas that we did n’t anticipate was the fact that the new process made working on multiple incidents at the same time much more manageable . Recently , we had a series of outages on multiple customer applications at the same time , and not only did we resolve each of those issues quicker , it also helped juggle resources 

 between multiple issues ( as the same experts were often needed at multiple places at the same time ) . 

 Insight : Describe the insight you gained from applying the tool you selected to your challenge ( e.g. , how an insight affected your thinking about the challenge and about design thinking more broadly ) . 

 After applying this tool , I realized that solving large issues does n't always require strong buy - in from leadership . As we implemented the learning launch in just a few situations in the beginning , we did n’t get much pushback . Later , as we applied it in more and more scenarios , we were able to demonstrate value to leadership before asking for their blessing to make it a standard practice . 

 Design thinking is really helpful in keeping everyone focused on specific solutions to problems , instead of getting bogged down by concerns about a new way of approaching things . If we had tried to do a hard launch from the beginning , we would have encountered a lot of resistance , and the idea may never have been implemented . 

 Approach : Describe what you might do differently next time -- applying the same tool you selected or a different one -- and the reason(s ) why . 

 This was a very successful implementation of a learning launch , as well as design thinking in general . However , one thing that I would change if I had the opportunity to redo the way we approached this problem is how many stakeholders we involved in the beginning of the process . While we had strong buy - in from leadership , we encountered resistance from certain stakeholders who were not involved in the learning launch when we later started using the Incident Management document as a standard practice . 


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: Challenge : Describe your challenge , including all relevant information . 

 I work in a software firm that develops and hosts applications for many large banks and businesses . Occasionally , these applications have outages ( due to bugs in the code , resource contention , network issues , or larger AWS outages ) . 

 Whenever a major outage occurs , multiple teams get involved and the process can get disorganized very quickly . Our support team gets involved to solve the issue , the engineering team gets involved to dive into the code base , our cloud team gets involved to check on AWS and any network issues . All of these teams are communicating via email , chat , on support cases , and JIRA tickets . Issues can also span multiple time zones with different people from different teams working on the same issue . 

 As a result of the disorganization , it takes longer to resolve an issue . Management has no visibility so they keep interrupting work to ask for updates . Sometimes , certain important questions are not asked ( since everyone assumes someone else already asked it ) . 

 Selection : In your own words , briefly describe the tool you selected ( e.g. , what it is and why you selected it for your challenge -- including any appropriate video lecture references ) . 

 For this issue , we selected Learning Launch since we already determined What Is , What If , and want to move on to the What Wows . As Andreas Schmitz discussed in Week 4 “ Learning Launch Tool ” , we wanted to test out a hypothesis and learn from a small application of a possible solution . 

 Application : Describe how you applied the tool you selected to your challenge ( e.g. , what you did and how the tool was applied effectively or ineffectively ) . 

 We knew that a lot of the problems stemmed from decentralization . All the information was scattered , and the different stakeholders all had varying levels of access to the information . We wanted to try centralizing the information into one google doc that we called an “ Incident Management ” document . 

 In order to keep the launch small ( and fail faster if needed ) . We started out with a very loose template . We then tried out the document in only a few incidents . After each incident , we would hold a postmortem to look at the results of the learning launch . 

 The Incident Management document was a big success . One of the areas that we did n’t anticipate was the fact that the new process made working on multiple incidents at the same time much more manageable . Recently , we had a series of outages on multiple customer applications at the same time , and not only did we resolve each of those issues quicker , it also helped juggle resources 

 between multiple issues ( as the same experts were often needed at multiple places at the same time ) . 

 Insight : Describe the insight you gained from applying the tool you selected to your challenge ( e.g. , how an insight affected your thinking about the challenge and about design thinking more broadly ) . 

 After applying this tool , I realized that solving large issues does n't always require strong buy - in from leadership . As we implemented the learning launch in just a few situations in the beginning , we did n’t get much pushback . Later , as we applied it in more and more scenarios , we were able to demonstrate value to leadership before asking for their blessing to make it a standard practice . 

 Design thinking is really helpful in keeping everyone focused on specific solutions to problems , instead of getting bogged down by concerns about a new way of approaching things . If we had tried to do a hard launch from the beginning , we would have encountered a lot of resistance , and the idea may never have been implemented . 

 Approach : Describe what you might do differently next time -- applying the same tool you selected or a different one -- and the reason(s ) why . 

 This was a very successful implementation of a learning launch , as well as design thinking in general . However , one thing that I would change if I had the opportunity to redo the way we approached this problem is how many stakeholders we involved in the beginning of the process . While we had strong buy - in from leadership , we encountered resistance from certain stakeholders who were not involved in the learning launch when we later started using the Incident Management document as a standard practice .
### Output: 