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 didn’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 doesn’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 wasn’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 didn’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)


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 )