Example Reflection – Learning Launch 

 Challenge 

 I am an intern on the Structural Analysis Department on a company in my town . Currently ,   my department is facing a problem with the software we buy to do our job ( this software   belongs to an external company ) . For matters of confidentiality , let´s call this software   “ Namsys ” . Since the external company charges Namsys by its time of use , a problem that   has emerged is that the workers of my company sometimes forget to close Namsys when   they are not using it ( when they go to eat , for example ) and , because of this , on these   situations , the costs of the use of Namsys raise even if it is not being used , since it is still   opened . My team calls this extra costs “ idle costs ” since they are being produced when   Namsys is idle , or not being used . Because of this , the challenge I was given was to reduce   the idle time of Namsys to reduce the extra costs this provoked . 

 Selection 

 When I was called for this project , the initial steps of the process were already taken : they   already had the data that was needed and a brainstorming process took place after that .   After this , we decided to test one of the solutions : to create an internal software that detects   when Namsys is idle and that closes it automatically when this happens . For this , we used   the learning launching tool . To make it short , a learning launch is a fast and cheap   experiment to test an idea and to prove a hypothesis . Our goal with this idea was to see if it   was the right solution and , if not , to learn from it to deliver something better . 

 Application 

 For this first learning launch , the first thing my team did was a hypothesis that we wanted to   prove with the release of the software we were making . This hypothesis was made from the   gathered data on the previous steps on the project . We wanted to satisfy our stakeholder´s   needs and to solve their problems . When going deep into this obtained data , my team   realized that the software should not only be able to close Namsys when it was idle , but it   should also have a user - friendly interface for the workers and an autosave function for the   work they don´t save when they leave the software idle , for example . Also , the managers   wanted to have knowledge of the time each of their workers was using Namsys and how   much of this time was idle . All of these things , among others , were gathered together to form   a design criteria statement in which we were based on to make our first prototype . 

 When we launched the first prototype , the principal thing we were concerned about was that   the software was functioning the way it should . When we prove it was working the way we   want it to , we then focused on the users ( the workers of the company ) and on their   managers . We were concurrently asking them how they were feeling about the software .   This was very useful since we received very useful feedback that allowed us to work on   several more iterations that served as subsequent learning launches . The speed and   efficiency of these iterations was beneficial for the team and the company in general . This   process lasted about one month until we finally reached a functional software with which   everyone felt comfortable with . 

 Insight 

 As said before , when releasing the first learning launch , the team had some interviews and   talks with the workers and the managers that were involved in this project , which helped us   to receive useful feedback that was implemented on successive learning launches . From   these interactions , my team was able to identify new insights that were not identified at the   beginning , which helped us to improve our software . With these insights , modifications from   the user interface to the data displayed to the managers were made in a way that the product   was more useful and comfortable for everyone . In fact , with these insights , the team learned   the right ways to display data and to make a friendly user interface , for example . Small   details were important . I learned , with this process , that even if at the beginning we analyze   data , that doesn´t mean we know it all at that stage ; we can learn during the execution and   we can get new insights as we make prototypes of our idea . 

 Approach 

 Since the internal software that was made by my team had to accomplish several tasks that   were identified on the first stages , our team focused on doing everything for the first iteration ;   that means , we tried to cover everything that the project needed on the first learning launch   hoping there was nothing to correct and that everything would go perfectly . However , as   stated before , this did not occur , and we had to iterate until we got to a final product . I   honestly think that was a mistake we made and something I will do differently for other   projects . The fact that we made a big project at first made us do big changes that took   several time after the first iteration . On this course I learned that it is better to do small   learning launches that are fast and cheap , so maybe the best thing we could have done   here was to divide the project in some logical parts and release it one after another ,   correcting what was needed . This could have saved us a lot of time and resources . This is   something I learned on this course and I experienced during this project . 


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: Example Reflection – Learning Launch 

 Challenge 

 I am an intern on the Structural Analysis Department on a company in my town . Currently ,   my department is facing a problem with the software we buy to do our job ( this software   belongs to an external company ) . For matters of confidentiality , let´s call this software   “ Namsys ” . Since the external company charges Namsys by its time of use , a problem that   has emerged is that the workers of my company sometimes forget to close Namsys when   they are not using it ( when they go to eat , for example ) and , because of this , on these   situations , the costs of the use of Namsys raise even if it is not being used , since it is still   opened . My team calls this extra costs “ idle costs ” since they are being produced when   Namsys is idle , or not being used . Because of this , the challenge I was given was to reduce   the idle time of Namsys to reduce the extra costs this provoked . 

 Selection 

 When I was called for this project , the initial steps of the process were already taken : they   already had the data that was needed and a brainstorming process took place after that .   After this , we decided to test one of the solutions : to create an internal software that detects   when Namsys is idle and that closes it automatically when this happens . For this , we used   the learning launching tool . To make it short , a learning launch is a fast and cheap   experiment to test an idea and to prove a hypothesis . Our goal with this idea was to see if it   was the right solution and , if not , to learn from it to deliver something better . 

 Application 

 For this first learning launch , the first thing my team did was a hypothesis that we wanted to   prove with the release of the software we were making . This hypothesis was made from the   gathered data on the previous steps on the project . We wanted to satisfy our stakeholder´s   needs and to solve their problems . When going deep into this obtained data , my team   realized that the software should not only be able to close Namsys when it was idle , but it   should also have a user - friendly interface for the workers and an autosave function for the   work they don´t save when they leave the software idle , for example . Also , the managers   wanted to have knowledge of the time each of their workers was using Namsys and how   much of this time was idle . All of these things , among others , were gathered together to form   a design criteria statement in which we were based on to make our first prototype . 

 When we launched the first prototype , the principal thing we were concerned about was that   the software was functioning the way it should . When we prove it was working the way we   want it to , we then focused on the users ( the workers of the company ) and on their   managers . We were concurrently asking them how they were feeling about the software .   This was very useful since we received very useful feedback that allowed us to work on   several more iterations that served as subsequent learning launches . The speed and   efficiency of these iterations was beneficial for the team and the company in general . This   process lasted about one month until we finally reached a functional software with which   everyone felt comfortable with . 

 Insight 

 As said before , when releasing the first learning launch , the team had some interviews and   talks with the workers and the managers that were involved in this project , which helped us   to receive useful feedback that was implemented on successive learning launches . From   these interactions , my team was able to identify new insights that were not identified at the   beginning , which helped us to improve our software . With these insights , modifications from   the user interface to the data displayed to the managers were made in a way that the product   was more useful and comfortable for everyone . In fact , with these insights , the team learned   the right ways to display data and to make a friendly user interface , for example . Small   details were important . I learned , with this process , that even if at the beginning we analyze   data , that doesn´t mean we know it all at that stage ; we can learn during the execution and   we can get new insights as we make prototypes of our idea . 

 Approach 

 Since the internal software that was made by my team had to accomplish several tasks that   were identified on the first stages , our team focused on doing everything for the first iteration ;   that means , we tried to cover everything that the project needed on the first learning launch   hoping there was nothing to correct and that everything would go perfectly . However , as   stated before , this did not occur , and we had to iterate until we got to a final product . I   honestly think that was a mistake we made and something I will do differently for other   projects . The fact that we made a big project at first made us do big changes that took   several time after the first iteration . On this course I learned that it is better to do small   learning launches that are fast and cheap , so maybe the best thing we could have done   here was to divide the project in some logical parts and release it one after another ,   correcting what was needed . This could have saved us a lot of time and resources . This is   something I learned on this course and I experienced during this project .
### Output: 