Reflection – Learning Launch 

 Challenge 

 A project to deliver a shared analytics and analysis platform in a public organization was over a year late   with no deliverable in sight . I was an external consultant and was asked to resolve the situation . The   platform was to be used by various analysts in different departments with different areas of expertise ,   often locate in different geographical areas . Some of the inputs needed by some groups of analysts are   outputs provided by other specialists / analysts and so on . The requirements had been collected   separately from each of the groups , but they did n’t work or provoked irreconcilable contingencies   between them when consolidated across the organization .   This was not a technical issue as upper   management originally thought . We had a situation where the clients are internal to the organization ,   they are different groups of internal clients with different needs that indirectly depends on each other ,   but do not know each other and have assumptions ( probably wrong ones ) about what the other groups   needs and thus what they must do and what they need themselves . The team working on the project   could not reconcile all of this since a lot of the project deliverable ’s diverse requirements are based on   erroneous assumptions . Most of the erroneous assumptions are held by the internal clients the   deliverable is meant for . The internal clients are not only clients but also providers for other internal   client groups and must therefore know or learn what the other clients need for the project to be   successful . 

 Selection 

 In this case , the clients are internal to the organization and varied . They are part of an internal market   for data and information that the platform must provide . They must also rid themselves of their false   assumptions and learn the “ truth ” ( as Michael Neumann stated)1 about what is really needed by the various client   stakeholders . I proposed a learning launch approach . Although a learning launch is typically done by a   company to confirm or disprove assumptions about the customers , in this case the internal clients   themselves would be solicited and be part of the learning process since it is their own assumptions   about the needs of each other that must be challenged , then confirmed or corrected . 

 Application 

 Even if the assumptions of the various stakeholders were not compatible , as a first step , we delivered a   prototype which conformed to their official documented requirements even if it was doomed to fail . We   needed a shared moment of “ truth ” where the various stakeholders would witness the failure , yet they   would have to admit it complied with their requirements in order to mobilize the various stakeholder .   This early failure had to be a turning point towards a concerted effort by the various stakeholders in   getting to know their colleagues and form a shared and compatible understanding of each other ’s   needs . 

 After the first launch , the second phase consisted of a series of prototype releases every 2 weeks base of   the shared lessons learned sessions between different stakeholders based on the previous prototype 

 1 ( https://www.coursera.org/learn/uva-darden-design-thinking-innovation/lecture/F04r6/learning-launch-tool ,   Accessed in 2021 ) 

 release . Even if the stakeholder were willing to change their assumptions and “ pivot”2 , it does n’t mean   they would get it right immediately . These 2 week cycles gave the stakeholders tangible feedback on   their progression towards a shared actionable view of their requirements . It was n’t just a matter of   building a prior consensus . The consensus they built had to be actionable and work within the reality of   the work that needed to be done . This permitted a dynamic of positive incremental adjustments that   could be made successively . The 2 week cycle launches also helped in cases where some built shared   consensuses between stakeholders were too subjective and not based on facts . The erroneous   assumptions could be challenged and fail in the field right away , thus avoiding costly long - term group- think mistakes . A consensus is required , but insufficient . We had to identify what actually “ works”3 in   the field . 

 Insight 

 These successive learning launches were initially meant to discover the issues and determine clear   actionable requirements for the project . To our surprise , after around 10 weeks , the last delivered   prototype simply worked out great for all the stakeholders . It was more that just a minimum viable   product , it was what was needed as a final deliverable for all stakeholders involved . We therefore took   the last prototype , formalized and officialised it through the existing official release to production   process of the organization . The final deliverable came to be while we though we were still in discovery . 

 Approach 

 I was an external consultant on this mandate . Several projects within the organization were having   major issues and were embarrassingly late . The project we delivered with the help of the learning   launch process was the only one to be delivered among the portfolio of projects they had . I regret not   being able to include upper management in the delivery cycles as they unavailable ( probably trying to   mitigate the political fallout ) . They basically tried to throw the kitchen sink at the problem and got   various consultant to deal with each troubled project separately , hoping some of them would pan out .   The problem is that upper management did not learn from the learning launch since they did n’t not   participate in it . The people managing the other projects did not participate either and since each   project was managed in a separate silo . Lessons learned from each project were not shared or properly   communicated across them . So even if the learning launch was instrumental for delivering our project   deliverable , it was not leverage for other projects or by the organization as a whole .   Upper   management delegated , but when it comes to change that “ sticks ” , they must also be involved for   successes to be picked - up and for the organization to learn . Learning within the scope of a project is not   enough since a project is by nature a temporary endeavour . The deliverable from the project remains ,   but I doubt the good practice the project spawned took root within the organization afterwards . 

 Since then , I have always insisted for upper management involvement and commitment at clients and   organizations I have worked for . 

 2 ( https://www.coursera.org/learn/uva-darden-design-thinking-innovation/lecture/F04r6/learning-launch-tool ,   Accessed in 2021 )   3 ( https://www.coursera.org/learn/uva-darden-design-thinking-innovation/lecture/UtntA/what-wows-what-works ,   Accessed in 2021 ) 


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 

 A project to deliver a shared analytics and analysis platform in a public organization was over a year late   with no deliverable in sight . I was an external consultant and was asked to resolve the situation . The   platform was to be used by various analysts in different departments with different areas of expertise ,   often locate in different geographical areas . Some of the inputs needed by some groups of analysts are   outputs provided by other specialists / analysts and so on . The requirements had been collected   separately from each of the groups , but they did n’t work or provoked irreconcilable contingencies   between them when consolidated across the organization .   This was not a technical issue as upper   management originally thought . We had a situation where the clients are internal to the organization ,   they are different groups of internal clients with different needs that indirectly depends on each other ,   but do not know each other and have assumptions ( probably wrong ones ) about what the other groups   needs and thus what they must do and what they need themselves . The team working on the project   could not reconcile all of this since a lot of the project deliverable ’s diverse requirements are based on   erroneous assumptions . Most of the erroneous assumptions are held by the internal clients the   deliverable is meant for . The internal clients are not only clients but also providers for other internal   client groups and must therefore know or learn what the other clients need for the project to be   successful . 

 Selection 

 In this case , the clients are internal to the organization and varied . They are part of an internal market   for data and information that the platform must provide . They must also rid themselves of their false   assumptions and learn the “ truth ” ( as Michael Neumann stated)1 about what is really needed by the various client   stakeholders . I proposed a learning launch approach . Although a learning launch is typically done by a   company to confirm or disprove assumptions about the customers , in this case the internal clients   themselves would be solicited and be part of the learning process since it is their own assumptions   about the needs of each other that must be challenged , then confirmed or corrected . 

 Application 

 Even if the assumptions of the various stakeholders were not compatible , as a first step , we delivered a   prototype which conformed to their official documented requirements even if it was doomed to fail . We   needed a shared moment of “ truth ” where the various stakeholders would witness the failure , yet they   would have to admit it complied with their requirements in order to mobilize the various stakeholder .   This early failure had to be a turning point towards a concerted effort by the various stakeholders in   getting to know their colleagues and form a shared and compatible understanding of each other ’s   needs . 

 After the first launch , the second phase consisted of a series of prototype releases every 2 weeks base of   the shared lessons learned sessions between different stakeholders based on the previous prototype 

 1 ( https://www.coursera.org/learn/uva-darden-design-thinking-innovation/lecture/F04r6/learning-launch-tool ,   Accessed in 2021 ) 

 release . Even if the stakeholder were willing to change their assumptions and “ pivot”2 , it does n’t mean   they would get it right immediately . These 2 week cycles gave the stakeholders tangible feedback on   their progression towards a shared actionable view of their requirements . It was n’t just a matter of   building a prior consensus . The consensus they built had to be actionable and work within the reality of   the work that needed to be done . This permitted a dynamic of positive incremental adjustments that   could be made successively . The 2 week cycle launches also helped in cases where some built shared   consensuses between stakeholders were too subjective and not based on facts . The erroneous   assumptions could be challenged and fail in the field right away , thus avoiding costly long - term group- think mistakes . A consensus is required , but insufficient . We had to identify what actually “ works”3 in   the field . 

 Insight 

 These successive learning launches were initially meant to discover the issues and determine clear   actionable requirements for the project . To our surprise , after around 10 weeks , the last delivered   prototype simply worked out great for all the stakeholders . It was more that just a minimum viable   product , it was what was needed as a final deliverable for all stakeholders involved . We therefore took   the last prototype , formalized and officialised it through the existing official release to production   process of the organization . The final deliverable came to be while we though we were still in discovery . 

 Approach 

 I was an external consultant on this mandate . Several projects within the organization were having   major issues and were embarrassingly late . The project we delivered with the help of the learning   launch process was the only one to be delivered among the portfolio of projects they had . I regret not   being able to include upper management in the delivery cycles as they unavailable ( probably trying to   mitigate the political fallout ) . They basically tried to throw the kitchen sink at the problem and got   various consultant to deal with each troubled project separately , hoping some of them would pan out .   The problem is that upper management did not learn from the learning launch since they did n’t not   participate in it . The people managing the other projects did not participate either and since each   project was managed in a separate silo . Lessons learned from each project were not shared or properly   communicated across them . So even if the learning launch was instrumental for delivering our project   deliverable , it was not leverage for other projects or by the organization as a whole .   Upper   management delegated , but when it comes to change that “ sticks ” , they must also be involved for   successes to be picked - up and for the organization to learn . Learning within the scope of a project is not   enough since a project is by nature a temporary endeavour . The deliverable from the project remains ,   but I doubt the good practice the project spawned took root within the organization afterwards . 

 Since then , I have always insisted for upper management involvement and commitment at clients and   organizations I have worked for . 

 2 ( https://www.coursera.org/learn/uva-darden-design-thinking-innovation/lecture/F04r6/learning-launch-tool ,   Accessed in 2021 )   3 ( https://www.coursera.org/learn/uva-darden-design-thinking-innovation/lecture/UtntA/what-wows-what-works ,   Accessed in 2021 )
### Output: 