Example Reflection – Learning Launch 

 Challenge 

 My organization is in software development industry , specialized in enterprise content management . 

 Our projects consist of implementing document management systems according to business needs 

 and rules of our customers . For that , we use our document management platform , which is capable 

 of defining different workflows for specific types of documents . 

 We had a following challenge - 

 •   The client was not having internal resources ( key users ) capable of defining 

 workflows for the documentation . 

 •   There were no clearly defined business rules for the documentation management at 

 the beginning of the project . 

 •   The documentation handling was manual or through e - mails with lots of back - and- 

 forth between employees . 

 •   In addition , it was important to have a quick win in order to boost the confidence of 

 the client 's employees involved in the project . 

 Selection 

 Client 's business processes were unclear but it was not the matter of defining them but rather 

 discovering them . Processes were somewhat in effect as there were defined business needs and 

 employees ' responsibilities . 

 One of the options was visualization that would help stakeholders to see the workflows and the 

 effects they have on the documentation being handled ( lifecycle states , approvals / rejections , 

 attachments , electronic vs hardcopies etc . ) . 

 However , as the stakeholders were previously involved in similar activities with other consultants 

 and with unsatisfying results , we concluded that the risk of saturation is too high and we should skip 

 as soon as possible to the phase where we can show actual system , even with flaws . 

 Furthermore , as we already had a document management platform which was in itself a minimum 

 viable product it was was economical to go directly to learning launch . 

 Application 

 For a learning lunch , we set up the system where users could send documents between each other 

 without any business rules as if they were using e - mail . The only rules were following : 

 •   All documents must go through document management system ( no " hardcopy workflow " ) ; 

 •   When users receives document that is not intended for him / her forwarding to the colleague 

 who is likely the right one to handle it is preferred to returning it back to the sender and 

 •   All users should process documents swiftly ( as we have not implemented any escalation 

 scheme to deal with documents not processed on time ) . 

 The last person in the process ( the one who was proclaiming document effective or send it to 

 archive ) was also in charge of defining the type of document . We assumed that this would be the 

 person who would certainly be able to classify the document by type . 

 As the documents in the system were reaching the last life cycle phase ( archive ) , our consultants 

 analyzed logs to see how the documents were circulating . 

 This way we were able to determine optimal paths ( workflows ) for different types of documents 

 through experience . 

 In future learning launches we introduced document types with workflows used from the beginning 

 of the process ( scanning ) and different roles for users . 

 In some cases it was not possible to timely define the path for some documents so users had to 

 reverse to face - to - face or phone calls to determine what should be done with the document but it 

 was also helpful for us as it has pointed to important exceptions . 

 Insight 

 Using the learning launching tool , we achieved the following - 

 •   Quick win that boosted the morale of the project participants 

 •   Showed that it was feasible to process all document through document management 

 system 

 •   Gained data for sizing different aspects of the project ( resources for scanning , need 

 for mobile solution etc . ) 

 •   Defined participants who can best contribute to the project . 

 •   At the beginning we had some expectations of how will the workflows turn out since 

 we had experience with the similar customers - the learning lunch confirmed some of 

 those and highlighted the specifics for this client . 

 Approach 

 We were very satisfied with learning lunch as a tool in this particular project but we tried not to use it 

 as a main tool in future projects as it is best suited for situations where we can not gain sufficient 

 insight from other tools . 

 It required more technical resources than some other design - thinking tool would use . 

 In one similar situation when we had to determine workflows but could not use learning lunch we 

 used modified mind mapping - users were passing " play " documents of different types between each 

 other around the conference table and we were writing the names of the participants in the process 

 on each document ( post it ) . This provide for a shallower insight but achieved in a shorter time and 

 with less resources . 


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 

 My organization is in software development industry , specialized in enterprise content management . 

 Our projects consist of implementing document management systems according to business needs 

 and rules of our customers . For that , we use our document management platform , which is capable 

 of defining different workflows for specific types of documents . 

 We had a following challenge - 

 •   The client was not having internal resources ( key users ) capable of defining 

 workflows for the documentation . 

 •   There were no clearly defined business rules for the documentation management at 

 the beginning of the project . 

 •   The documentation handling was manual or through e - mails with lots of back - and- 

 forth between employees . 

 •   In addition , it was important to have a quick win in order to boost the confidence of 

 the client 's employees involved in the project . 

 Selection 

 Client 's business processes were unclear but it was not the matter of defining them but rather 

 discovering them . Processes were somewhat in effect as there were defined business needs and 

 employees ' responsibilities . 

 One of the options was visualization that would help stakeholders to see the workflows and the 

 effects they have on the documentation being handled ( lifecycle states , approvals / rejections , 

 attachments , electronic vs hardcopies etc . ) . 

 However , as the stakeholders were previously involved in similar activities with other consultants 

 and with unsatisfying results , we concluded that the risk of saturation is too high and we should skip 

 as soon as possible to the phase where we can show actual system , even with flaws . 

 Furthermore , as we already had a document management platform which was in itself a minimum 

 viable product it was was economical to go directly to learning launch . 

 Application 

 For a learning lunch , we set up the system where users could send documents between each other 

 without any business rules as if they were using e - mail . The only rules were following : 

 •   All documents must go through document management system ( no " hardcopy workflow " ) ; 

 •   When users receives document that is not intended for him / her forwarding to the colleague 

 who is likely the right one to handle it is preferred to returning it back to the sender and 

 •   All users should process documents swiftly ( as we have not implemented any escalation 

 scheme to deal with documents not processed on time ) . 

 The last person in the process ( the one who was proclaiming document effective or send it to 

 archive ) was also in charge of defining the type of document . We assumed that this would be the 

 person who would certainly be able to classify the document by type . 

 As the documents in the system were reaching the last life cycle phase ( archive ) , our consultants 

 analyzed logs to see how the documents were circulating . 

 This way we were able to determine optimal paths ( workflows ) for different types of documents 

 through experience . 

 In future learning launches we introduced document types with workflows used from the beginning 

 of the process ( scanning ) and different roles for users . 

 In some cases it was not possible to timely define the path for some documents so users had to 

 reverse to face - to - face or phone calls to determine what should be done with the document but it 

 was also helpful for us as it has pointed to important exceptions . 

 Insight 

 Using the learning launching tool , we achieved the following - 

 •   Quick win that boosted the morale of the project participants 

 •   Showed that it was feasible to process all document through document management 

 system 

 •   Gained data for sizing different aspects of the project ( resources for scanning , need 

 for mobile solution etc . ) 

 •   Defined participants who can best contribute to the project . 

 •   At the beginning we had some expectations of how will the workflows turn out since 

 we had experience with the similar customers - the learning lunch confirmed some of 

 those and highlighted the specifics for this client . 

 Approach 

 We were very satisfied with learning lunch as a tool in this particular project but we tried not to use it 

 as a main tool in future projects as it is best suited for situations where we can not gain sufficient 

 insight from other tools . 

 It required more technical resources than some other design - thinking tool would use . 

 In one similar situation when we had to determine workflows but could not use learning lunch we 

 used modified mind mapping - users were passing " play " documents of different types between each 

 other around the conference table and we were writing the names of the participants in the process 

 on each document ( post it ) . This provide for a shallower insight but achieved in a shorter time and 

 with less resources .
### Output: 