Overcoming the Known Unknowns by Applying “Learning Launch”                                    May 30, 2020

Yogi Yates

Challenge: Describe your challenge, including all relevant information.

The company I consult with has been trying to move toward the Agile methodology for project management,  initially through the software engineering group and slowly expanding to other parts of the business. The  main challenge that I encountered as a change management consultant is that, where software developers  have used Agile for most of their career, most of the engineering disciplines favor the waterfall approach. As  a result, project teams struggle with the notion of iterations and sprints when they are used to having the  entire project plan in place before starting. In order to adapt the change management planning approach, I  first had to get the project teams comfortable with the Agile methodology.

Selection: In your own words, briefly describe the tool you selected (e.g., what it is and why you  selected it for your challenge -- including any appropriate video lecture references).

In my initial assessment of the problem, I identified two key issues: first, familiarity with Agile was not  consistent or uniform across the project teams, and in an engineering organization, that level of ambiguity  and open-ended planning creates more than a little bit of angst. Second, the adopted methodology for  change management across the corporation is heavily anchored in waterfall processes, and is, all by itself,  very rigid and bureaucratic. To bridge the knowledge gap and begin moving in the direction of a more Agile  approach, I selected the Learning Launch tool as a way to test some assumptions and possible approaches  without creating unwarranted disruption with the ongoing project efforts.

Application: Describe how you applied the tool you selected to your challenge (e.g., what you did and  how the tool was applied effectively or ineffectively).

In selecting the Learning Launch approach, I had to think of a quote from Donald Rumsfeld, former Secretary  of Defense, “… there are known knowns; there are things we know we know. We also know there are  known unknowns; that is to say we know there are some things we do not know. But there are also  unknown unknowns -- the ones we don't know we don't know.”

The uncertainty that is inherent in the Agile methodology is not comfortable for aerospace engineers,  but walking them through the process of identifying the "known knowns" and the "known unknowns" in  terms of current and future application of the work helped to temper this. By guiding the project team  through the discussion and answering the questions: "What do we know? What do we not know? What  do we need to know? How do we learn what we need to know?" I was able to get them to actively  reshape the project approach, and embrace the idea that what we were really working on was a product  that has customers internal to the organization, not a project that would be launched and checked off of  a list.

We knew why we had been tasked to create the in-house capability to support knowledge management  and to facilitate access to a repository of data. What we could not have anticipated, but where we  suddenly had a use case to test from start to finish, was how COVID-19 and the need for information  about its effect on our business would drive adoption of the capability we were building. It also forced  the project team to realize that there was much that was unknowable as an entire body of knowledge  was being created in real time. To see how this would inform our approach to the project, we launched  a pilot initiative specifically focused on COVID-19 response, and observed the level of interaction,  engagement and contribution to the knowledge base that was possible without any direction.

As a result of this testing and observation, the project team realized the need to continue with the  baseline project as originally specified, but with a built-in flexibility to adapt and rapidly create  communities of practice where the type of interaction and knowledge sharing that would happen  anyway could be harvested and captured for the future as well. And the project team acknowledged  that it was essential to adopt an Agile mindset to allow the product to evolve with the needs of the  business.

Insight: Describe the insight you gained from applying the tool you selected to your challenge (e.g., how  an insight affected your thinking about the challenge and about design thinking more broadly).

I have worked in organizational development and change management for over a decade, and most of that  time has been spent with engineers and software developers. The most significant observation I've made  through these years of consulting and with this project in particular is that, with engineers, it is very difficult  to overcome the need for certainty. Acknowledging the inherent tension between the known and the  unknown, and helping the project team see this as a call to action to think differently about scoping the  project and testing different approaches, made it possible to guide the shift to a new mindset and an  iterative approach to the project.

By proving that the modified version of our project and change model was able to flex to the immediate and  unanticipated needs of the business, and in the process to become an incredibly valuable resource to the  organization, we were able to reach a level of comfort with the unknown, allowing for the possibility of co- creation of solutions based on the real-time needs of our internal customers.

Approach: Describe what you might do differently next time -- applying the same tool you selected or a  different one -- and the reason(s) why.

In a strange way, it was fortunate that the pandemic forced us to challenge our assumptions about the true  purpose and potential of the knowledge management capability we were developing. I feel that the Learning  Launch approach enabled the project team to grapple with the ambiguity of the situation and test tentative  solutions that they may not have been willing to experiment with in a normal "business as usual" situation.  Ultimately, it turned out that the emergent communities of practice needed a slightly different version of the  product we thought we were creating, and through the testing and observation process we were able to  achieve a "Yes, and" solution: the team stayed true to the original requirements while building adaptive  capability that could flex to the future.

The other tool I would have considered using for this project team is Journey Mapping earlier on in the  process, to better understand how the tools and capabilities would be used through the lens of our diverse  internal customer groups. Through our observation of the communities of practice that emerged during the  crisis, we were able to "reverse engineer" the journey of our users, but in our initial work on the scope and  capability design, we would have benefited from these additional perspectives much earlier in the planning  stage.

