Developing an OS – Learning lunch 

 Challenge & Selection 

 The tool I applied is the learning lunch , which basically consists on testing a prototype of the   final product idea with the stakeholders in order to improve / modify the idea and reach the   best final product possible . 

 I work for a consultancy firm based in Barcelona and the challenge was to ensure that the OS   that was developing another IT partner for our client was perfectly adapted to the final user   needs . The OS basically consisted on an integrated system for a production company ( stock   management ; cost assignment to departments ; sales rapport etc ) . The usual approach for this   type of projects basically consists on developing completely the system , with the IT   department involved on the OS development , before the final user sees it . Even though it ’s   true that the technology department of the firm guides all the process , they are not the final   users , and their concerns do n’t always coincide with the concerns of the final users , that ’s why   we decided to apply something very similar to the concept of learning lunch : test the different   prototypes of the OS with the final users before the software is completely developed in order   to ensure that the final solution perfectly suits the user needs . 

 Application 

 I am going to describe briefly the way we structured the project using as example the main   department of the firm . 

 The first thing we did consisted in identifying which was going to be the final user of each one   of the different modules of the OS . The most important module was the production module ,   since this was the department with the highest number of workers and the less willing to   adapt the way they were working to the system , so the system must fit perfectly the workers   main needs . 

 Secondly we selected a small group of representative workers among the production   department and we set up a meeting with them on a friendly environment ( not on the small   meeting room where usually this meetings take place , but in the big conference room with   coffee , juice , tee and biscuits , where almost never go ) and we let them try the different   functionalities ( stock registration , registration of hours dedicated to each project etc ) of the   system as it was developed in that moment . On that meeting , the workers identified many   things that were n’t working the way they expected to . For example : The registration of hours   required introducing the code of the project they were working on , and many times the   worker does n’t know this code or , in the initial stages of the project , it has not even been   created . 

 After the meeting , we analyzed the comments and the feelings given for the workers ,   translated them into possible solutions ( in the registration of hour example , we proposed to   insert a searcher where the workers could find the code of the project by introducing words   related with the project itself ) and we gave those solution to the partner that was developing   the OS . 

 Once the developer implemented the solution we proposed we met again with the workers   and repeated the whole process three times before reaching the optimal solution . 

 Insight 

 I thing that the way we conducted the project ( showing the system to the workers even it   was n’t completely developed and taking into account their concerns into the development   process ) gave us the possibility to provide a final solution that fit the workers need almost   perfectly and needed minimum adjustments .   Because of that , the client was highly satisfied   with the OS he ended up with and we also saved the costs and time of introducing major   changes once the development is finalized ( which usually are much higher ) . 

 I think that involving the stake holders on the early stages of the development is generally an   excellent way of improving the solution you ’re selling to the client and preventing future ( and   more expensive ) costs . 

 Approach 

 I think that if we developed the OS we would try to take into account workers concerns even   before starting the development process , as we learned on the “ what is ” lectures . Probably if   we had done that , this solution would have been better designed from the beginning and we   would n’t have needed to readjust the prototypes so many times 


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: Developing an OS – Learning lunch 

 Challenge & Selection 

 The tool I applied is the learning lunch , which basically consists on testing a prototype of the   final product idea with the stakeholders in order to improve / modify the idea and reach the   best final product possible . 

 I work for a consultancy firm based in Barcelona and the challenge was to ensure that the OS   that was developing another IT partner for our client was perfectly adapted to the final user   needs . The OS basically consisted on an integrated system for a production company ( stock   management ; cost assignment to departments ; sales rapport etc ) . The usual approach for this   type of projects basically consists on developing completely the system , with the IT   department involved on the OS development , before the final user sees it . Even though it ’s   true that the technology department of the firm guides all the process , they are not the final   users , and their concerns do n’t always coincide with the concerns of the final users , that ’s why   we decided to apply something very similar to the concept of learning lunch : test the different   prototypes of the OS with the final users before the software is completely developed in order   to ensure that the final solution perfectly suits the user needs . 

 Application 

 I am going to describe briefly the way we structured the project using as example the main   department of the firm . 

 The first thing we did consisted in identifying which was going to be the final user of each one   of the different modules of the OS . The most important module was the production module ,   since this was the department with the highest number of workers and the less willing to   adapt the way they were working to the system , so the system must fit perfectly the workers   main needs . 

 Secondly we selected a small group of representative workers among the production   department and we set up a meeting with them on a friendly environment ( not on the small   meeting room where usually this meetings take place , but in the big conference room with   coffee , juice , tee and biscuits , where almost never go ) and we let them try the different   functionalities ( stock registration , registration of hours dedicated to each project etc ) of the   system as it was developed in that moment . On that meeting , the workers identified many   things that were n’t working the way they expected to . For example : The registration of hours   required introducing the code of the project they were working on , and many times the   worker does n’t know this code or , in the initial stages of the project , it has not even been   created . 

 After the meeting , we analyzed the comments and the feelings given for the workers ,   translated them into possible solutions ( in the registration of hour example , we proposed to   insert a searcher where the workers could find the code of the project by introducing words   related with the project itself ) and we gave those solution to the partner that was developing   the OS . 

 Once the developer implemented the solution we proposed we met again with the workers   and repeated the whole process three times before reaching the optimal solution . 

 Insight 

 I thing that the way we conducted the project ( showing the system to the workers even it   was n’t completely developed and taking into account their concerns into the development   process ) gave us the possibility to provide a final solution that fit the workers need almost   perfectly and needed minimum adjustments .   Because of that , the client was highly satisfied   with the OS he ended up with and we also saved the costs and time of introducing major   changes once the development is finalized ( which usually are much higher ) . 

 I think that involving the stake holders on the early stages of the development is generally an   excellent way of improving the solution you ’re selling to the client and preventing future ( and   more expensive ) costs . 

 Approach 

 I think that if we developed the OS we would try to take into account workers concerns even   before starting the development process , as we learned on the “ what is ” lectures . Probably if   we had done that , this solution would have been better designed from the beginning and we   would n’t have needed to readjust the prototypes so many times
### Output: 