Challenge : 

 I am the leader of a small IT operations and development team consisting of six members . Since we   are responsible for both operations and development , it is hard to plan development steps ahead ,   because a lot of the time all plans change when some unexpected problems in operations need to be   handled first . We use a ticket handling system and try to solve occurring problems as soon as   possible . Nevertheless , we all feel the need for more reliable planning , since it is frustrating and   disencouraging when software development does not seem to happen at all ; and for most of the   team members , that is the fun part of their work , while operations is more of a responsibility . 

 Selection : 

 Since we already put a lot of thought into that problem , but did not have a great idea how to solve it ,   I wanted to try the Learning Launch approach . In a learning launch ( see   https://ideas.darden.virginia.edu/the-learning-launch-how-to-grow-your-business-with-the- scientific - method for a short summary oft he method ) , a fast and cheap implementation of one or   more experiments or prototypes is used to test an idea or an assumption . The key idea is to learn and   reshape the experiment or prototype based on the results until it fits . In contrast to a lot of   discussion we already had , this sounded like a promising approach where all team members could try   and afterwards rate different solutions and find out what works and what does not . 

 Application : 

 Since the team is already small , it did not make much sense to test only with a smaller number of   team members . The goal was to gather different ideas how to organize our daily and weekly work to   make sure that there is enough time for software development . We soon agreed that in general two   days per week for each team member would be great . We came up with three different approaches : 

 -   2 fixed programming days : we reserve two days a week ( we chose Tuesday and Thursday ) for   programming work only ; only truly critical tickets would be handled , everything else should   be postponed to the next day 

 -   Fixed programming time each day : we reserve three hours per day ( 10:00 – 13.00 ) for   programming work only . 

 -   2 programming days for everyone , but distributed over the week , so that at least 2 team   members handle incoming tickets . 

 We tested these three approaches , each for one week . 

 Insight : 

 The Learning Launch approach was really effective in trying the different ideas . Due to the short   duration of a week per test , everybody was really motivated to try it and to stick to the rules . 

 During the process , it became clear that we needed a better management of organizing incoming   tickets . A lot of time was spent with the selection and agreement on who , how and when handled   and solved a ticket . 

 Although the three - hours - per - day was somehow the easiest to stick to , most team members felt that   the time slot was too short to really get something done . The idea of 2 - fixed - programming - days   showed the great team spirit that occurs when all team members work together . Nevertheless , it   was difficult to observe the rules of “ only programming ” , especially with external meetings and other   interruptions . The last approach was a bit difficult to implement , since certain team members   working on the same project should be able to work together , but it worked surprisingly well . All 

 team members reported , that it made a big difference that they did not have to monitor tickets and   felt really free to do their work . 

 In the end , we implemented a forth version : one fixed programming day ( where only one team   member has to monitor the tickets ) and the rest of the week the programming and ticket handling   days are distributed . 


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 : 

 I am the leader of a small IT operations and development team consisting of six members . Since we   are responsible for both operations and development , it is hard to plan development steps ahead ,   because a lot of the time all plans change when some unexpected problems in operations need to be   handled first . We use a ticket handling system and try to solve occurring problems as soon as   possible . Nevertheless , we all feel the need for more reliable planning , since it is frustrating and   disencouraging when software development does not seem to happen at all ; and for most of the   team members , that is the fun part of their work , while operations is more of a responsibility . 

 Selection : 

 Since we already put a lot of thought into that problem , but did not have a great idea how to solve it ,   I wanted to try the Learning Launch approach . In a learning launch ( see   https://ideas.darden.virginia.edu/the-learning-launch-how-to-grow-your-business-with-the- scientific - method for a short summary oft he method ) , a fast and cheap implementation of one or   more experiments or prototypes is used to test an idea or an assumption . The key idea is to learn and   reshape the experiment or prototype based on the results until it fits . In contrast to a lot of   discussion we already had , this sounded like a promising approach where all team members could try   and afterwards rate different solutions and find out what works and what does not . 

 Application : 

 Since the team is already small , it did not make much sense to test only with a smaller number of   team members . The goal was to gather different ideas how to organize our daily and weekly work to   make sure that there is enough time for software development . We soon agreed that in general two   days per week for each team member would be great . We came up with three different approaches : 

 -   2 fixed programming days : we reserve two days a week ( we chose Tuesday and Thursday ) for   programming work only ; only truly critical tickets would be handled , everything else should   be postponed to the next day 

 -   Fixed programming time each day : we reserve three hours per day ( 10:00 – 13.00 ) for   programming work only . 

 -   2 programming days for everyone , but distributed over the week , so that at least 2 team   members handle incoming tickets . 

 We tested these three approaches , each for one week . 

 Insight : 

 The Learning Launch approach was really effective in trying the different ideas . Due to the short   duration of a week per test , everybody was really motivated to try it and to stick to the rules . 

 During the process , it became clear that we needed a better management of organizing incoming   tickets . A lot of time was spent with the selection and agreement on who , how and when handled   and solved a ticket . 

 Although the three - hours - per - day was somehow the easiest to stick to , most team members felt that   the time slot was too short to really get something done . The idea of 2 - fixed - programming - days   showed the great team spirit that occurs when all team members work together . Nevertheless , it   was difficult to observe the rules of “ only programming ” , especially with external meetings and other   interruptions . The last approach was a bit difficult to implement , since certain team members   working on the same project should be able to work together , but it worked surprisingly well . All 

 team members reported , that it made a big difference that they did not have to monitor tickets and   felt really free to do their work . 

 In the end , we implemented a forth version : one fixed programming day ( where only one team   member has to monitor the tickets ) and the rest of the week the programming and ticket handling   days are distributed .
### Output: 