Reflection – Learning Launch 

 Challenge : 

 I am part of a global Finance team and my challenge relates to a large system implementation   project .   My organisation is implementing a new system that will transform the end to end source to   pay process , impacting a significant number of different users across the world .   The scope of the   project is very broad impacting 8 countries and the operations process of a number of different   departments , such as Commercial , IT and Finance .   My activities on this project include learning   about new system functionality , assessing its applicability for my Company , defining global policy   changes in accordance with the agreed deadlines .   As a project team we need to make sure that we   deliver a tool with associated processes that bring improvement to the user experience of procure to   pay and delivers benefits in terms of additional functionality , ease of use and efficiency .   I am   working in the finance stream with a small number of people that need to design and deliver the   finance potions of this Project in the next 6 months .   The challenge is how to deliver the design on a   number of processes that will meet user expectations in a short time frame with tight resources . 

 Selection : 

 Design thinking is being used as part of the wider project but in terms of how we approach the   Finance workstream I have chosen the Learning Launch tool .   This is a tool that facilitates   experimentation , allowing ideas and prototypes to be tested quickly on a small scale .   This provides   learnings that allows improvement to be made to the idea and hypothesis .   I selected this for my   challenge is it provides an opportunity to experiment , test , improve and move forward to a more   improved and user centric prototype or model .     Application : 

 We applied the Learning Launch tool during the testing phase of the project 

 At the start of the project there were a lot of ideas and potential functionality that we could use and   a set of assumptions / hypotheses about what we thought users wanted and would find useful in the   day to day work .   We needed to find a way to match the functionality to the hypotheses of user   needs and want .   There was not an easy way to decide what would best suit our business and the   users and how to set up the functionality and process appropriately .   We therefore decided to take   an experimentation and prototyping approach to the testing by setting up 3 prototype phases .   We   decided on this approach so that we could initially break the tasks and work into smaller chunks and   make some quick decisions in terms of initial processes to use , test the hypotheses and design .   We   were then able to configure these based on our understanding and hypotheses of user needs , test   them and learn , pivot and tweak the configuration and process to get us closer to a best practice and   user centric process .   As we progressed through the prototyping we added more processes and also   more users into the testing so that we could test their expectations and gain their learnings , allowing   us to incorporate wider perspectives into the design of the process .   Each prototype was like a mini   go live as new users became involved in the tool design . 

 This process worked well although the only challenge remained how we could keep track of the   learnings and make sure we could adjust the process and configuration in time for the next   prototyping session . 

 Insight : 

 By applying the tool I feel we were able to better design functionality for end user purposes .   By   testing the hypotheses and expectations we had about user needs we have ended up with a more   robust system design that will actually meet their needs rather than meeting the needs as we   though they might be .   After the prototyping we removed processes that were not important to   users and redesigned others that did not meet their expectations following feedback .   For other   processes it was positive confirmation that we were on the right path and our hypotheses were   correct .   By walking in the shoes of the user and involving them to test our design we feel confident   that we will go live with a user centric tool that will meet their needs with no surprises .   Without   doing this and having the design thinking mindset I think we may have designed processes based on   an incorrect set of assumptions and gone live without testing it on the user base first .   This would   have led to a tool that did not have users at the forefront , did not meet their needs and would have   surprised us on go live with negative feedback and rework after the fact . 

 One of the harder things to keep at the forefront of my mind was that we never failed during the   prototype phases , we were merely learning , pivoting and improving .   Just because a hypotheses was   proved wrong did n’t mean we had failed , it provided an opportunity for us to actually meet   expectations where we might not have otherwise done so . 

 Approach : 

 Next time I use this approach I would try to get the learnings quicker and “ fail ” faster .   We had 3   prototype phases and were perhaps too reluctant or just learning and feeling out the process during   prototype 1 .   If we had tested more processes and had more users involved earlier I think we could   have spaced out the workload and gained insights quicker allowing ourselves more time for   redesign .   If we had packed more into Prototype 1 and 2 we would have had the learnings and not   had to rely so heavily on prototype 3 when the deadlines were tighter . 

 I would also take the learning of this approach forward to any future system projects to make sure   we can gain the insights from users and test our thinking out before going ahead with a solution that   we think is right . 


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

 Challenge : 

 I am part of a global Finance team and my challenge relates to a large system implementation   project .   My organisation is implementing a new system that will transform the end to end source to   pay process , impacting a significant number of different users across the world .   The scope of the   project is very broad impacting 8 countries and the operations process of a number of different   departments , such as Commercial , IT and Finance .   My activities on this project include learning   about new system functionality , assessing its applicability for my Company , defining global policy   changes in accordance with the agreed deadlines .   As a project team we need to make sure that we   deliver a tool with associated processes that bring improvement to the user experience of procure to   pay and delivers benefits in terms of additional functionality , ease of use and efficiency .   I am   working in the finance stream with a small number of people that need to design and deliver the   finance potions of this Project in the next 6 months .   The challenge is how to deliver the design on a   number of processes that will meet user expectations in a short time frame with tight resources . 

 Selection : 

 Design thinking is being used as part of the wider project but in terms of how we approach the   Finance workstream I have chosen the Learning Launch tool .   This is a tool that facilitates   experimentation , allowing ideas and prototypes to be tested quickly on a small scale .   This provides   learnings that allows improvement to be made to the idea and hypothesis .   I selected this for my   challenge is it provides an opportunity to experiment , test , improve and move forward to a more   improved and user centric prototype or model .     Application : 

 We applied the Learning Launch tool during the testing phase of the project 

 At the start of the project there were a lot of ideas and potential functionality that we could use and   a set of assumptions / hypotheses about what we thought users wanted and would find useful in the   day to day work .   We needed to find a way to match the functionality to the hypotheses of user   needs and want .   There was not an easy way to decide what would best suit our business and the   users and how to set up the functionality and process appropriately .   We therefore decided to take   an experimentation and prototyping approach to the testing by setting up 3 prototype phases .   We   decided on this approach so that we could initially break the tasks and work into smaller chunks and   make some quick decisions in terms of initial processes to use , test the hypotheses and design .   We   were then able to configure these based on our understanding and hypotheses of user needs , test   them and learn , pivot and tweak the configuration and process to get us closer to a best practice and   user centric process .   As we progressed through the prototyping we added more processes and also   more users into the testing so that we could test their expectations and gain their learnings , allowing   us to incorporate wider perspectives into the design of the process .   Each prototype was like a mini   go live as new users became involved in the tool design . 

 This process worked well although the only challenge remained how we could keep track of the   learnings and make sure we could adjust the process and configuration in time for the next   prototyping session . 

 Insight : 

 By applying the tool I feel we were able to better design functionality for end user purposes .   By   testing the hypotheses and expectations we had about user needs we have ended up with a more   robust system design that will actually meet their needs rather than meeting the needs as we   though they might be .   After the prototyping we removed processes that were not important to   users and redesigned others that did not meet their expectations following feedback .   For other   processes it was positive confirmation that we were on the right path and our hypotheses were   correct .   By walking in the shoes of the user and involving them to test our design we feel confident   that we will go live with a user centric tool that will meet their needs with no surprises .   Without   doing this and having the design thinking mindset I think we may have designed processes based on   an incorrect set of assumptions and gone live without testing it on the user base first .   This would   have led to a tool that did not have users at the forefront , did not meet their needs and would have   surprised us on go live with negative feedback and rework after the fact . 

 One of the harder things to keep at the forefront of my mind was that we never failed during the   prototype phases , we were merely learning , pivoting and improving .   Just because a hypotheses was   proved wrong did n’t mean we had failed , it provided an opportunity for us to actually meet   expectations where we might not have otherwise done so . 

 Approach : 

 Next time I use this approach I would try to get the learnings quicker and “ fail ” faster .   We had 3   prototype phases and were perhaps too reluctant or just learning and feeling out the process during   prototype 1 .   If we had tested more processes and had more users involved earlier I think we could   have spaced out the workload and gained insights quicker allowing ourselves more time for   redesign .   If we had packed more into Prototype 1 and 2 we would have had the learnings and not   had to rely so heavily on prototype 3 when the deadlines were tighter . 

 I would also take the learning of this approach forward to any future system projects to make sure   we can gain the insights from users and test our thinking out before going ahead with a solution that   we think is right .
### Output: 