10
LEARN
“The illiterate of the 21st century will not be those who cannot read and write, but those who cannot learn, unlearn, and relearn.”
Alvin Toffler
What if your companies' DNA was organized to take all the outputs it generates, and use them as inputs? How could you take the outputs, whether it is products or all means of data generated from the business and use it to learn, evolve, and innovate?
This is exactly what companies like Amazon, Google, and Facebook are doing well. The growth trajectory of these companies is pumped by a continuous feedback loop of learning, experimentation, and innovation. In the case of Amazon, they evolved from selling online books to a leading retailer of almost everything, to electronic devices, web services, media, food, and a host of other related products and businesses. These companies were born and flourished in a fast‐changing DANCE and disruptive world, so they inherently know that learning is the key to organizational agility and survival.
If you look back at the history over the past century, the companies that have survived in the long run like IBM, GE, and Procter & Gamble have all survived because they also have learning and evolution in their DNA. Like IBM, which has evolved from products to services in the 1990s, to cloud, mobility, and security in recent years, unlike Blackberry, Motorola, Nokia, and many others that did not learn and sense, respond, adapt, and adjust quickly enough.
According to Richard Foster of the Yale School of Management, the average lifespan of a company decreased from 67 years in the 1920s to just 15 years today. He estimates that 75 percent of S&P 500 companies will be replaced by new ones by 2027. To survive, learning must be a part of the organizational DNA, so it can evolve and mutate based on changing conditions.
But the challenge is that most companies are not organized to learn; they are set up to execute. As Harvard Business School Professor Amy Edmondson points out in Table 10.1, the difference between the two are the characteristics necessary to cultivate learning into the DNA.
Table 10.1: Organizing to Execute versus Organizing to Learn
Source: Adapted from Rotman Magazine, Winter 2015, Amy Edmondson, Thought Leader Interview, by Karen Christensen.
| Organizing to Execute | Organizing to Learn |
| Confirm and follow rules | Experiment and solve problems |
| Objective—choose among defined options | Empirical—experiment through trial and error |
| Learning before doing | Learning from doing |
| Did YOU do it right? | Did WE learn? |
| Separate expertise | Integrate expertise |
| Drive out variance | Use variance to analyze and improve |
| Works when path forward is clear | Works when path forward is not clear |
TRADITIONAL PM AND PMOs ARE NOT ORGANIZED FOR LEARNING
Project management and PMOs, as you can imagine, are typically setup to execute and have more of the characteristics of the left side Table 10.1. The traditional mindset is that you are supposed to follow the rules, do it right the first time, and drive our variance, and failure is not an option. This does not cultivate the right conditions for learning, which requires the opposite environment of experimentation and trial and error.
Of course, project management and PMOs always emphasize lessons learned, continuous improvement, and maturity, but they continue to struggle, as they are not setup for success.
Need for a New Perspective
Cathy has been preparing for her upcoming project closeout. One of the items on her checklist as the project manager is lessons learned. She has it scheduled on the calendar and invited key project stakeholders to the lessons learned meeting. She has asked her team to send her ideas for the presentation. She gets a few e‐mail responses, and a couple of days before the meeting she works on her slide deck. She is happy that the PMO has provided a template for the lessons learned. As she works on her presentation, in the beginning, she struggles with what to list, but then she can remember all the typical challenges and lists things like more planning, more resources, need for sponsor involvement, timely risk management, greater communication, and team building. She delivers her lessons learned presentation. There are a couple of questions, and she provides good examples. Everybody seems to be happy. Now, she can check this item off, and officially close out the project and look forward to the celebration party!
Sound familiar? Well, you could cut and paste things like more planning, more resources, need for sponsor involvement, timely risk management, greater communication, and team building, and you don't need to do another lessons session because every project has very similar lessons.
So what are the problems the above scenario highlights?
The lessons learned was a cursory exercise, so that she could check it off that it was done as a part of the PMO process. There was no real reflection or lessons here. Why did she wait until the end of the project, how come lessons were not documented throughout the project? There were probably many lessons lost as they were not captured at the right time. Once they are filed, they are seldom looked at again; people don't even know where to find them. Even if they find them, the lessons are generic bullet points without any context, and not actionable. You might review all the project artifacts and documentation, but they may not tell the whole story, particularly the wealth of tacit knowledge and insights that are not easy to harness.
What about Continuous Improvement and Maturity?
Continuous improvement of process is good, but it is not enough. Improve not only the process but also the work. Not just improve but evolve and innovate. Continuous improvement is a single loop, you improve the same thing, over and over, which may not be relevant in a changing world. Continuous innovation is a double loop, where you learn and evolve to create something new and better.
As we have discussed in previous chapters, you can be mature but not necessarily smart. You may have well‐defined, standardized, repeatable processes, but in a DANCE and changing environment, they may not necessarily be applicable. You are organized to execute, but not to learn and evolve. In fact, it can promote a false sense of security that you have reached a certain level of maturity and have an advantage.
To address this, you need to rethink and ask the right questions to cultivate the operating system (OS) of the organization for learning: How do we utilize agile principles to reflect on how to become more effective and adjust based on empirical observation? How do we treat failure? Do we encourage experimentation and trial and error? How do we make failure survivable?
LEARNING FROM FAILURE
“Good judgment comes from experience; experience comes from bad judgment.”
Nasrudin, thirteenth-century wise fool of Sufi lore
In one of the reflective moments in his book, The Lean Startup, Eric Ries at one point shares a painful moment of self‐doubt. The entrepreneur has just recounted the very early days of one of his startup companies, which scrapped its initial strategy and product after realizing they were fatally flawed. Thousands of lines of code, which Ries himself had written during the past six months, is thrown out as the company pivots to a new strategy based on customer feedback. He writes:
Would the company have been just as well off if I had spent the last six months on a beach sipping umbrella drinks? Had I really been needed? Would it have been better if I had not done any work at all?
There is … always one last refuge for people aching to justify their own failure. I consoled myself that if we hadn't built this first product—mistakes and all—we never would have learned these important insights about customers. We never would have learned that our strategy is flawed.…
For a time, this “learning” consolation made me feel better, but my relief was short‐lived. Here's the question that bothered me most of all: if the goal of those months was to learn these important insights about customers, why did it take so long?
Ries ultimately realizes that he had wasted time doing things that didn't uncover what created value for customers. They had followed agile development methodologies that prized efficiency but had used them in the service of building out product features it turned out no one wanted—which in turn were an outgrowth of incorrect strategic assumptions. What he and his team should have done, Ries writes, was only what was necessary to illuminate what customers value. By learning that, the organization could change its strategy and the scope of projects to something that will drive real success—not just on‐time, on‐budget and within‐scope projects. He writes:
I've come to believe that learning is the essential unit of progress for startups. The effort that is not absolutely necessary for learning what customers want can be eliminated. I call this validated learning. … As we've seen, it's easy to kid yourself about what you think customers want. It's also easy to learn things that are completely irrelevant.
Think about how this definition of progress overturns old ideas familiar to project managers and their teams. Progress has traditionally meant moving from one project phase to another while remaining on schedule and within budget. Progress can and should occur, in this old framework, by simply executing the plan approved by the organization.
In contrast, Ries argues that teams must avoid wasting their time and the company's money by learning what customers want as soon as possible. (Systematically eliminating wasteful processes is at the heart of “lean” manufacturing techniques pioneered by the Toyota Motor Corp.; Ries's book adapts this concept to the startup context.) If that means throwing out the original plan—and forcing the original project to “fail”—so be it. The sooner that failure occurs, the better.
And the sooner organizations can learn to embrace these kinds of failures—the kind that illuminate flawed assumptions about how customers work and the world works—the better. This sort of shift to embrace learning through failure, to build a culture of learning, isn't easy. At most large organizations, there is a deeply embedded culture reinforcing old conceptions of “success.” Leaders have effectively trained project managers and PMOs to only execute solutions to the problems they have defined. But today, as the environment companies compete in changes rapidly, PMO and project leaders must always be mindful of whether they're solving the right problems. If discovering the company is focused on the wrong problem, or is imagining a problem that doesn't exist, means “failing fast,” then so be it. Such failures should be rewarded for not only avoiding wasted time, energy and money but for developing organizational intelligence—for teaching the organization how it must adapt itself to the world as it really is.
NASA hosts “My Best Mistake” website a collection of stories told by project managers and knowledge practitioners in the NASA Community. Each story tells how the author learned a lasting lesson from a mistake. (https://km.nasa.gov/tag/my‐best‐mistake/)
As painful as failure can be, it is often how innovations occur. We all love the idea of creative bolts of lightning striking genius inventors, or of a brilliant CEO like Steve Jobs pointing his teams in the right direction from day one. Reality is far more complicated and painstaking: Jobs was more like an editor, rejecting and refining ideas and designs until Apple had arrived at true innovations. Referring to SpaceX, the space transport company he founded, Elon Musk once said, “Failure is an option here. If things are not failing, you are not innovating enough.”
If an organization can't learn to fail quickly and thoughtfully, it will fail to learn. And if it fails to learn today, then someday in the future some big lessons will be forced upon it—to the detriment of its bottom line. It is also important to point out that the “failing fast” mantra has become fashionable, and people get carried away, without truly understanding it. As Marc Andreesen, a Silicon Valley entrepreneur, investor, and software engineer remarked in a podcast interview, “It is not about failing fast but succeeding in the long run. They are not the same thing.”
One way to succeed in the long run is by making failure survivable.
HOW TO MAKE FAILURE SURVIVABLE
If you learn something from a failure, it's not truly a failure.
In Adapt: Why Success Always Starts with Failure, author Tim Harford pulls back the curtain on how success in the business world really works. Major companies do not rise like a rocket to take over the world. In fact, although “few company bosses would care to admit it,” Harford writes:
The market fumbles its way to success, as successful ideas take off and less successful ones die out. When we see the survivors of this process—such as Exxon, General Electric, and Procter & Gamble—we shouldn't merely see success. We should also see the long, tangled history of failure, of all of the companies and all of the ideas that didn't make it.
Harford explores an idea that resonates and further elaborates one of the central themes of this book of a shift from a mechanical to an organic approach. Modern organizations have much in common with the biological process of evolution. In that process, the fittest variations of a species pass on their genes to the next generation, while the unfit die. In the realm of business, we tend to imagine brilliant leaders as pushing grand successes, but in fact, success usually emerges gradually, in fits and starts. Failure is a normal part of the process of creating improvements. Harford writes:
Selection happens through heredity: successful creatures reproduce before they die and have offspring that share some or all of their genes. In a market economy, variation and selection are also at work. New ideas are created by scientists and engineers, meticulous middle managers in large corporations or daring entrepreneurs. Failures are culled because bad ideas do not survive long in the market place: to succeed, you have to make a product that customers wish to buy. … Many ideas fail these tests, and if they are not shut down by management they will eventually be shut down by a bankruptcy court. Good ideas spread. … With these elements of variation and selection in place, the stage is set for an evolutionary process; or, to put it more crudely, solving problems through trial and error.
PMOs can be a crucial part of this “trial and error” process— they should promote adaptive planning and execution based on lean and agile ideas of experimentation to put out minimum viable products (MVPs) to seek rapid customer feedback, learn, and adjust. PMOs should also be part of the self‐correcting process by which failing ideas are “shut down.” The PMO can play a much bigger role than simply flagging failures to executive sponsors and other senior leaders to ensure that fatally flawed projects are put out of their misery as quickly as possible.
Based on data and analysis, the PMO can point out that success just isn't in the cards for some projects. It's not an easy thing to do. As we have discussed in previous chapters, it is hard to make tough decisions and kill projects in flight. But healthy organizations build self‐criticism and adaptive mechanisms into their DNA to avoid becoming a lumbering giant that blindly walks off a cliff. With its unique inside‐out position—it has insider project knowledge, while still being outside the team and its sponsoring department—a strong and valuable PMO should have the authority and independence to call out hopelessly off‐course projects when it sees them.
PMOs can add real value by skillfully helping teams, and organizations more broadly, learn from the failure. This means going beyond the normal lessons learned process of documentation. It means reminding teams that a “failed project” isn't a failure if the organization learns something. It means highlighting lessons learned from a failure, or highlighting a capability that came out of a failed project.
This amounts to nothing less than helping project managers and their teams reconceive what “success” is and what the goal of projects is. If a PMO can enable learning from failures to help teams across the organization improve, so much the better.
Traditionally, PMOs (and project managers) are risk‐averse: They view risks as threats. The scariest risk of all, of course, is that the entire project is worthless to customers: they won't flock to a new product or service, or they'll have no use for new features. But if a project's projected benefits are useless to the customer, then everyone will be better off realizing this risk as quickly as possible: the customer won't feel misunderstood and insulted, the project team won't feel demoralized after a stretch of hard work, and the organization will avoid wasting money.
The PMO, then, should work to help teams understand that it is a good thing to realize these kinds of risks because they offer crucial chances to learn. All risks should be reconceived as opportunities, in a sense—opportunities to winnow out the bad ideas and advance toward the true innovations that will ensure long‐term survival.
Beyond making failure survivable, how could you take it further and exploit it to become better and stronger from it? Nassim Taleb, in his book, Antifragile: Things that Gain from Disorder, explains:
Some things benefit from shocks; they thrive and grow when exposed to volatility, randomness, disorder, and stressors and love adventure, risk, and uncertainty. Yet, in spite of the ubiquity of the phenomenon, there is no word for the exact opposite of fragile. Let us call it antifragile. Antifragility is beyond resilience or robustness. The resilient resists shocks and stays the same; the antifragile gets better.
Without realizing our methods and approaches are designed to make our environment, and projects weaker, we cannot withstand the DANCE and impact of risks and variances. Project managers and PMOs should question how you can design your project environment to add stressors and variability so that the teams can learn and grow stronger from it.
THE DNA STRANDS OF LEARN: 7 C's OF CULTIVATING A LEARNING ENVIRONMENT
Figure 10.1 lists the 7 C's of cultivating a learning environment and PMO. Think of these learning elements as the strands that enable the DNA to evolve and mutate based on changing conditions.
Figure 10.1: The DNA Strands of Learn—The 7 C's
Culture
Making failure acceptable and learning from it is easier said than done; it is a cultural issue, and it is going to need a mind‐shift to foster and cultivate the right conditions for it. We have discussed tips of how project managers and PMOs can get started to learn from failure and make failure survivable. Another dimension is how to foster a learning environment and culture, where there is a desire, passion, and excitement for learning.
In her book Fierce Conversations, Susan Scott writes: “Burnout doesn't happen because we're solving problems, it occurs because we're trying to solve the same problem over and over.”
Project managers know that every project is unique, but still feel like they are solving the same problem over and over. What if project managers and PMO could foster a culture where every project is viewed as a unique learning opportunity, and they treat execution as learning? Moving beyond execution to studying how to make it better. In a Rotman Magazine interview, Amy Edmondson explained why it's so important to adopt a mindset of “execution as learning”:
Execution as learning means getting work done while being highly engaged in the process of finding ways to do it better. Its defining attribute is the integration of constant, sometimes unremarkable, small‐scale learning into day‐to‐day work. … In these cases, workers see the work as an interesting puzzle at all times.
We tend to think of learning and execution as separate entities: you get your work done, and you do your learning offline. … But that isn't how it works anymore in a fast‐paced field of any kind: you need to be constantly learning.
If we all approached projects as interesting puzzles, as interesting learning experiences, then “solving” them can become more engaging. And setbacks, or outright failure, won't be as personal and painful. Instead, they'll be opportunities to gain insights into what the customer wants or shortcomings in organizational capabilities.
Of course, a learning culture has to involve more than simply changing how we perceive projects and their execution. They have to create the right atmosphere using gamification, competition, and contests to create an environment where learning is cool, fun, and rewarded.
Another element of a learning culture that is overlooked is to create an environment where it is OK to slow down, question, and reflect. When project managers spend their days running from one fire to another, without any time to stop and think, to step back and assess whether a project no longer makes strategic sense or has some other fatal flaw, a culture of learning isn't likely to flower.
Rather, the ability to learn grows out of dedicated time for reflection and mindfulness for introspection and after‐action reviews. Too often, the “lessons learned” process isn't successful because people don't (or can't) stop and think to take it seriously. “Learning” becomes a rote exercise before team members head off to another project, never to look backward as we saw with Cathy's scenario above.
Contrast this with the company contracted to restore the Acropolis of Athens, upon which the Parthenon and other ruins from the fifth century B.C. stands in Greece. The leader of that project scheduled regular times for work stoppages, allowing team members to reflect and think carefully about any mistakes made.
Building this kind of practice into project execution is how a culture of learning can truly develop within an organization. Ideally, individuals are asking questions without fear of embarrassment or reprisal, sharing information, seeking help, experimenting (within reasonable boundaries), and seeking feedback. All of this is what learning is made from. We shouldn't only celebrate project successes—we should celebrate learning in all its forms as a sign of organizational health and progress.
To cultivate a learning culture, explore ways to promote execution as learning, make learning fun and rewarding, and inspire questioning and reflection.
Curiosity
“I have no special talents. I am only passionately curious.”
Albert Einstein
Traditional cultures suppress curiosity and questioning where you are supposed to stay within the boundaries. In today's DANCE‐world that is in a constant state of flux, curiosity is essential to remove the blinders. Project and PMO leaders need to spark an insatiable sense of curiosity and questioning to deal with increasing ambiguity and uncertainty.
They need to normalize and encourage curiosity. In his book, A More Beautiful Question: The Power of Inquiry to Spark Breakthrough Ideas, Warren Berger reveals how highly innovative businesses are fueled by employees' ability to ask fundamental, game‐changing questions. Noting that Google is at the leading edge of how companies are trying to transform the workplace into a “learn‐place,” Berger writes:
The company established Google University as a platform for bringing in guest lecturers, then went a step further in creating Googler to Googler, a program in which Google employees host in‐house classes to teach other Google employees. Not surprisingly, there are courses on technical or business skills, but the curriculum also includes courses on public speaking and parenting. Former Google engineer Chade‐Meng Tan even teaches a course on mindfulness (useful in helping one to step back and question).
Part of cultivating a hunger for learning and curiosity among employees involves shifting the organization's culture away from an expert mindset. This is not easy; to prove their value, many people feel the need to assert their expert knowledge in front of colleagues (or at least their boss). Project managers are as guilty of this tendency as anyone else, along with PMO leaders. It's a natural and understandable instinct, especially in a competitive environment.
But if everyone believes they already know all that they need to know to succeed—well, you can see how vulnerable this would make any organization to change. As Epictetus said, “It is impossible to begin to learn that which one thinks one already knows.” This is why humility is such a valuable quality: it opens up the space for curiosity and helps people shift away from an expert mindset to become comfortable in a learning mindset.
Ultimately, when curiosity is in the air, and a normalized and palpable aspect of an organization's culture, complacency will be less common. There will be a degree of comfort with ambiguity and dealing with the unknown. More questions will be asked, and answers won't be defensive. They will be willing to try new things. It is important to drive toward applied curiosity. Only application of curiosity will open new doors and drive innovation.
Capture
Learning is an inherently cumulative act. We build on knowledge we already have to develop more sophisticated ideas, more advanced skills, and wisdom. Learning is impossible with a functioning memory bank.
So imagine an organization that has no memory bank, no ability to remember what went right and what went wrong. It would fail quickly. Conversely, organizations with robust mechanisms for capturing and disseminating lessons learned learn from mistakes, avoid repeating failures, and recalibrate their activities toward higher‐value goals that align with the operating environment.
At least that's the theory. Knowledge management, document repositories, and collaboration tools to capture project artifacts are a foundational aspect, but not enough. Although the tools have gotten much better, the challenge always has been how to capture the tacit knowledge and insights that are hard to codify in a database. As I noted earlier, the traditional approach to lessons learned—capture them at the end of a project and file them away for other teams to digest before embarking on a similar project—rarely works in practice. It's also inadequate: Why wait until the end of a project to think seriously about what went wrong?
Following are ways that next‐generation project and PMO leaders can elevate their lessons learned approach to effectively harness and apply lessons learned.
Feedback Loops
First, feedback from customers and stakeholders needs to be captured and tracked in an ongoing fashion. At every opportunity, feedback loops should be built into the project lifecycle. Solid stakeholder management practices are just the starting point; feedback elicited from stakeholders (especially the customer) needs to be immediately distributed to the team as necessary so project plans can be appropriately recalibrated. This sort of course correcting should be constant.
But there are less orthodox approaches available beyond this kind of positive feedback loop. And they stem from the recognition that feedback loops are often inadequate in highly disruptive industries. The whole idea of feedback is to learn from experience and analyze actual performance in relation to planned performance. But when the future isn't necessarily linked to the past, feedback approaches can come up short.
That's why it is important to distinguish between single‐loop and double‐loop learning. Academic Chris Argyris coined the term double‐loop learning in his book, Teaching Smart People How to Learn. He explains the difference using this analogy: A thermostat that automatically turns on the heat whenever the temperature in a room drops below 68°F is a good example of single‐loop learning. A thermostat that could ask, “Why am I set to 68°F?” and then explore whether some other temperature might more economically achieve the goal of heating the room would be engaged in double‐loop learning.
The repeated attempt at the same problem, with no variation of the method and without ever questioning the goal, as opposed to changing the mental model on which a decision depends is double‐loop learning.
In Chapter 8, I discussed the example of Kumar, who seems to be caught in a never‐ending loop of fixing bugs, without questioning why the bugs are occurring in the first place. He was getting feedback, which kept him in the recurring loop. Designing the right feedback approach is critical to learn and evolve. Also, Chapter 8 described how metrics and measurements are mechanisms for feedback.
Feed‐forward
Feed‐forward approaches address a temporal disconnect by guiding leaders to make choices by working backward from an anticipated future. The most well‐known feed‐forward technique is scenario building, wherein different future scenarios for an organization are around possible futures with varying kinds and degrees of uncertainty. The appeal of this approach to any team tasked with charting an organization's strategy is obvious, but the technique can also be leveraged by PMOs engaging project teams, or a project leader engaging his or her team. How could the organization's context shift during the course of the project in ways that undermine its promised benefits? How might the assumptions driving the project's business case be proven wrong? The idea is to help people be comfortable with asking challenging questions and the ever‐changing business environment.
Retrospectives
Retrospectives are an approach that is used in agile methodologies to reflect on how to become more effective and adjust behavior and processes accordingly. Retrospectives are designed to primarily address three questions at the end of each iteration—what worked well? What did not work well? What actions can we take to improve our process going forward? A key principle of making the retrospective work is to separate the people from the process. The emphasis is on the principle that “regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew, at the time, their skills and abilities, the resources available, and the situation at hand.”
There are many variations of making retrospectives more engaging, interactive, and meaningful. Starfish is one example where you sketch a starfish on a flipchart with five sections—keep doing, less of, more of, start doing, and stop doing—and the team reflects and writes down ideas on stickies and sticks them in appropriate sections on the chart. Another one is to write the acronym PANCAKE on the flipchart, which stands for what puzzles, appreciation, news, challenges, appreciation, knowledge, and endorsements, and the team reflects on these as a part of the retrospective.
Another variation of the retrospective is a futurespective that flips the focus from reflection to prediction. It is a virtual journey into the future to question what would we need to accomplish our goals.
Pre‐mortem
Pre‐mortems also flip the normal script. While retrospectives are held after the iteration or lessons learned are conducted after the project is closed, they are more like post‐mortems. Pre‐mortems are conducted before the project has begun—and assume it has failed. Matthew Syed describes it in his book Black Box Thinking:
With this method, a team is invited to consider why a plan has gone wrong before it has even been put into action. It is the ultimate “fail fast” technique. The idea is to encourage people to be open about their concerns, rather than hiding them out of fear of sounding negative.
The pre‐mortem is crucially different from considering what might go wrong. With a pre‐mortem, the team is told, in effect, that “the patient is dead”: the project has failed; the objectives have not been met; the plans have bombed. Team members are then asked to generate plausible reasons why. By making the failure concrete rather than abstract, it alters the way the mind thinks about the problem.
According to celebrated psychologist Gary Klein, “prospective hindsight,” as it is called, increases the ability of people to correctly identify reasons for future outcomes by 30 percent.
Storytelling
Lessons learned documents tend to be full of bullet‐point lists of tips and links to templates and tools—and teams searching for wisdom often encounter similar lessons across many different projects. In other words, the lessons learned can feel generic and therefore useless, which means that over time teams will stop bothering to even look through documents for anything pertinent—and then walk blindly into avoidable project challenges.
Done right, lessons learned should provide deeper knowledge and insights. They should answer these questions:
- What worked? What did not work? Why?
- Who else has tried this approach before?
- Who are the expert resources who are good at this kind of project?
- How were the key challenges overcome?
- What led to end user and customer satisfaction?
- Based on the experience, what would they have done differently?
- What were the pitfalls to watch for?
To be effective, avoid the bare bones of bulleted lists. Instead, dress lessons learned up in a narrative style to offer context and background. Organizations like NASA, the World Bank, and many others use stories to gather and share project lessons learned. Project managers get to reflect, compose, and share their real‐life experience on the project in a natural way and in the form of a story. Valuable tacit knowledge that cannot be captured in a formal report can be harnessed in a story.
The following are examples of tips from a lessons‐learned document:
- It is important to identify hidden stakeholders.
- Stakeholder management should be performed throughout the project life cycle.
Here is the story after transforming these points into a lessons‐learned anecdote:
As we got into the crucial stage of project execution of breaking ground to dig the tunnel, we had to stop work unexpectedly because a stakeholder showed up, and who we had failed to identify in our stakeholder management process. Guess who the stakeholder was? It was a red viper snake, which is an endangered species. Due to the strict environmental laws, the project was stopped until we could relocate the snake's nest. We had the resources committed, and the delays cost the project over US$225,000, pushing the schedule back by a week.
Effective stories have a high learning value. They do not have to be long or be high drama—they can be simple and to the point. Generally, lessons‐learned stories should focus on the mistakes made and show how they were corrected, with an explanation about the alternative and why it worked.
There's a role for the PMO to play here: it can host a storytelling session instead of formal post‐project reviews and a lessons‐learned session. The ultimate goal of any lessons learned process is simple: get people to read and remember them. That is how organizations avoid repeating failures. So instead of lessons lost by having projects continuously fall into the same holes, use stories to harness lessons learned and transform them into lessons applied.
The Learning Question
Any of the lessons learned, storytelling or coaching should include what Michael Bungay Stanier deems the learning questions, “What was most useful to you?” In his book, The Coaching Habit, he explains that people don't even really learn when they do something. They start learning, start creating new neural pathways, only when they have a chance to recall and reflect on what just happened, and the learning question helps prompt that.
Community and Collaboration
Learning—at least in the context of an organization conducting team‐based work—is inherently social. Building a culture of learning and curiosity, and encouraging the capture, and sharing of lessons learned: All of this is only possible if employees feel they are part of a meaningful community. As we discussed in Chapter 7, the PMO can be instrumental in building a sense of community. Instead of the PMO being at the helm and disseminating top‐down prescriptions and the right way of doing things, it becomes the facilitator. It recognizes the effectiveness of informal structures to promote learning and sharing of knowledge.
If you think about it, this way of harnessing and disseminating institutional knowledge and lessons learned is healthier and more sustainable that the traditional PMO‐as‐expert mode. In some ways, it's harder because the PMO's role isn't as formalized. But it can be a powerful paradigm for connecting diverse people in meaningful ways that foster knowledge sharing and the real learning of lessons. You can start small by sponsoring lunch and learn sessions and grow the learning community organically with more activities and events over time.
Project teams are by definition collaborations, and inevitably they develop their own learning culture to move the project forward. As we discussed in Chapter 7, modern matrixed organizations are full of disconnects. In global organizations employing tens of thousands of people, people find themselves seemingly trapped in a silo and cut off from the rest of the company. There are real structural obstacles facing anyone who wants to connect someone with certain expertise to explore potential collaborations. Think of all the wasted energy and talent, all the missed opportunities for learning and knowledge advancement in such compartmentalized organizations.
The PMO can work to connect people in ways that spark collaborations. It can implement tools that automatically connect individuals to relevant experts across the organization—even if they're outside their network of contacts or business division. Knowing who to ask in a large organization is no simple task. It may involve long searches and frustrating dead ends. This is where collaboration tools like Starmind, which uses artificial intelligence to automatically route any employee's question to the right expert within your organization can be effective. New hires, seasoned experts with knowledge gaps, shy employees—all get their answers from the best source.
It allows employees to easily answer questions posed by employees anywhere in the world and promote learning in real time across borders, sharing knowledge and best practices. Among Starmind's global clients, employees in another country answer 70 percent of their colleagues' questions. Spanish telecommunications company Telefonica is one of those clients. It wanted to build a culture of collaboration, so it fully integrated Starmind into its employee portal under the name “DigitalBrain.” The result, according to Starmind, is that expertise is now available to everyone, everywhere, all the time. Expertise moves “freely and neutrally through the organization. Old inherited structural barriers are erased.”
Next‐generation collaboration platforms break down obstacles to learning, connecting people across silos and stimulating learning that can prevent duplicative projects and unlock creativity and innovation.
Curation
“Curation is the ultimate method of transforming noise into meaning.”
Rohit Bhargava, Non-Obvious 2017
We live an age of information overabundance. Every day, we're bombarded with information from a growing array of devices and applications connecting us to more and more, and we don't even have time to look up from our devices. One role that has emerged is the role of curators in many fields to make sense of all the noise into meaningful choices. This is a great opportunity for the next‐generation PMO to be the curator—to identify, organize, and share lessons, ideas, best practices, tools, and apps. They can curate as well as actively search for the best in class in each of these areas that might be useful to the community.
As a curator, the PMO ought to be regarded as the essential go‐to resource for all things related to project management and strategy execution. Museum curators do more than just create exhibits; they also work to grow the institution's permanent collection of art. In the same way, a PMO should do more than just hold up best practices and lessons learned to whoever knocks on its door for help. Its leaders should fan out across the organization hunting for new approaches to strategy execution, innovation, knowledge sharing, and collaboration.
Correcting (Self‐Correction and Application)
There is a tendency to overestimate the role of planning beforehand, and underestimate the role of correction, after kick‐off. As Rolf Dobelli in his book The Art of Good Life points out, “As an amateur pilot I've learned that it's not so much the beginning that matters but the art of correction following take‐off. After billions of years, nature knows it too. As cells divide, copying errors are perpetually being made in the genetic material, so in every cell, there are molecules retroactively correcting these errors. Without the process of DNA repair, as it's known we'd die of cancer hours after conception. Our immune system follows the same principle. There's no master plan because threats are impossible to predict. Hostile viruses and bacteria are constantly mutating, and our defenses can only function through perpetual correction.”
Constant course correction and readjustment after take‐off is critical, but there is another important lesson we can learn from aviation. Statistically, flying in a plane is safer than driving a car. How did it come to pass that it is safer to rise tens of thousands of feet above the ground than to drive down the street? The short answer: the application of lessons learned. Aviation regulators and the airline industry created incredibly robust processes that pilots and crew members must follow before takeoff. After each flight, they document what happened. All details, including any malfunctions and how airline employees responded to them, are put in a massive anonymous database that is accessible to all airlines. Anyone can see anything—the flow of knowledge is unimpeded between airlines and their pilots. Think about how you can emulate this in your environment and promote radical capturing, sharing, and transparency across projects. Not just sharing, but cultivating a culture that it's OK to fail, as long as we can learn, apply, and evolve from it.
At Google, there's a rule: It's OK to fail, but not in the same way twice. In other words, you're expected to learn from mistakes. The challenge is that you may address some of the issues with lessons learned discussed above and do a decent job of capturing lessons learned, but they are of no use if they are not applied. Often people are demotivated about lessons learned because there is an underlying perception that it is a fruitless exercise. They are demotivated because the belief is “What's the point, we already know the lessons … but we can't do anything; the organization is not set up or ready to apply them.”
To apply the lessons and help prevent repeat failures the organization or the PMO has to ask the right questions to uncover what went wrong and what can be done to change processes to avoid mistakes or build self‐correcting mechanisms. In his book Seeking Wisdom, Peter Bevelin explains how to ask the right questions to avoid repeat failures:
How can we create the best conditions to avoid mistakes? How can we prevent causes that can't be eliminated? How can we limit the consequences of what we want to avoid? How can we limit the probability of what we want to avoid?
The goal is to methodically interrogate the failure to understand what contributed to it and why, and how those factors can be eliminated or avoided. Table 10.2 offers a series of questions to ask, depending on what someone is trying to avoid repeating.
Table 10.2: How to Avoid Repeat Failures
Source: Adapted from Peter Bevelin (2007), Seeking Wisdom.
| What to Avoid | Cause | Antidote |
| What were the mistakes? | Why did those happen? | What are the major risk factors? How do specific errors evolve? What factors contribute? |
| Stupidity/irrationality | Big idea that helps explain and predict? | What is rational? How can I create the best conditions to make good decisions? What can be eliminated or prevented? |
Checklists
One tool for preventing repeat failures and applying lessons learned is simple and familiar: the checklist. Overtime, the learnings can be harnessed to build and improve checklists for repeatable processes. As pointed in Chapter 9, Harvard Medical School professor Atul Gawande makes the case that checklists can help avoid repeat failures.
In highly specialized fields such as medicine and aviation, it doesn't matter how well trained and intelligent a surgeon or a pilot is—inevitably, something will fall through the cracks because the systems to be managed and procedures to be executed are so complicated. This is why airlines embed so many checklists in their day‐to‐day flight operations: to prevent inevitable human error.
In his book, Gawande notes that a five‐point checklist implemented by Johns Hopkins Hospital in 2001 nearly eradicated central line catheter infections in the intensive care unit, preventing more than 40 infections and 8 deaths over a period of 27 months. He notes the successful use of checklists in skyscraper construction projects.
The possibilities are limitless—checklists could potentially incorporate items to stave off all the failures that have bedeviled organizations in prior years. If team members can recognize their fallibility and see checklists as powerfully simple tools for preventing repeat mistakes, progress is assured.
CONTINUOUS INNOVATION
Moving from Continuous Improvement to Continuous Experimentation, Iteration, and Innovation
The traditional notions of learning and maturity focus on continuous improvement, which is important but not enough. The assumption is that you are improving the same thing over and over to gain efficiencies and get better. In a constantly changing and disruptive world, continuous improvement is like running better and faster, just to stay in the same place, whereas continuous innovation is a double loop, where you learn and evolve to create something new and better.
To get ahead, you have to evolve from continuous improvement to continuous innovation. You take the outputs you generate, and turn the data and learning from it, as inputs for innovation. As Shane Parrish, an influential blogger and founder of Farnam Street Media, discusses in an interview, “The outputs of Amazon are now becoming the inputs, and that's how they just keep getting better and better. They are quick to adjust, and that's part of the reason that they are so dominant.” Another point to emphasize is that the learnings have to also include an outside‐in customer perspective. As Shane continues, “They have a ‘customer first’ mindset that allows you not to have an ego. I think the feedback loop model is much better, where you remove people's egos and focus on the customer instead.”
A PMO's job is never done—and its leaders should relish this fact. New employees will always be coming and going; new teams will be assembled and disbanded, new lessons learned will be collected and distributed. All the while, the organization's external context is changing, along with—hopefully—its strategy and project portfolio. Ultimately, the value of that portfolio derives from the amount of innovation it contains.
Traditionally, at a basic level, the PMO has existed to help an organization hold itself to high standards. When looked at from the C‐suite, it's a complex, multifaceted quality control mechanism. But in today's competitive landscape, the PMO must be more than just a purveyor of best practices that allow the organization to improve project delivery. It must go beyond mere incremental improvement to drive continuous innovation with a customer‐first orientation.
Meta‐Learning
One person who has spent much of his career dedicated to the study of learning in many different forms is the author, entrepreneur, self‐proclaimed “human guinea pig,” and popular podcaster Tim Ferris. In one of his books, The 4‐Hour Chef, he distills a meta‐learning technique for learning any skill, which should resonate with project and program managers. The four‐step process is simplified by the acronym DiSSS:
- Deconstruction. “What are the minimal learnable units, the LEGO blocks, I should be starting with?”
- Selection. “Which 20 percent of the blocks should I focus on for 80 percent or more of the outcome I want?”
- Sequencing. “In what order should I learn the blocks?”
- Stakes. “How do I set up stakes, to create real consequences, and guarantee I follow the program?”
Why this is particularly important for project management is because project managers are trained and supposed to be good at the first step of deconstruction and breaking things down. They can leverage the other three steps of selection, sequencing, and stakes in not just learning but also effectively planning the project or program. By using these steps, they can quickly learn to maximize outcomes, by selecting the right tasks and sequencing them in an effective way, while focusing on the right stakes and stakeholders.
“In times of change learners inherit the earth; while the learned find themselves beautifully equipped to deal with a world that no longer exists.”
Eric Hoffer, author, social philosopher
DEVELOPING LEARNING INTELLIGENCE
Use the following questions to reflect and explore ways to develop learning intelligence:
- Are we more organized to execute or organized to learn? How can we shift and balance more toward learning?
- How can we change the perception and use failure as a learning opportunity?
- How can we cultivate a learning culture?
- How can we build better feedback loops?
- How can we encourage teams to speak up if a project is doomed to fail?
- How can we adapt lean and agile approaches for reflections and lessons learned?
- How can we get experts to share?
- How can we reward sharing and learning?
- How can we become the curator of ideas, best practices, and lessons learned to create meaning from noise?
- How can we improve the taxonomy of knowledge management systems?
- How can we better utilize collaboration platforms?
- How can we inspire and promote curiosity to create an infectious learning environment?
- How can we make failure survivable and build course correction in project management processes?
- How can we create the best conditions to avoid mistakes?
- How can we prevent causes that can't be eliminated?
- How can we limit the consequences of what we want to avoid?
- How can we limit the probability of what we want to avoid?
- How can we better organize the study of errors?
- How can we apply metrics to measure learning as a unit of progress?
- How can we build community and collaboration to promote sharing and learning?
- How can we move from continuous improvement to continuous innovation?
- How can we leverage and improve meta‐learning and accelerated learning techniques?
KEY TAKEAWAYS
- Project management and PMOs are setup and organized to execute, not necessarily to learn. There is a difference between the two. To cultivate the right conditions for learning requires experimentation and trial and error, which is the opposite of follow the rules, do it right the first time, drive out variance, and failure is not an option.
- Failure—or to be precise, the ability to learn from failure—is an essential part of success in today's turbulent and fast‐changing business world.
- Making failure acceptable and learning from it is easier said than done; it is a cultural issue, and it is going to need a mind shift to foster and cultivate the right conditions for it.
- Build feedback loops and double‐loop learning to ensure that you are not stuck in a repetitive attempt at the same problem, with no variation of the method and without ever questioning the goal, as opposed to questioning and changing the mental model to learn and evolve.
- PMOs should promote adaptive planning and execution based on lean and agile ideas of experimentation and trial and error, to seek rapid customer feedback, learn, and adjust.
- PMOs should aim to make failure survivable, with a focus on course correction and avoiding mistakes.
- To develop learning intelligence, the PMO must develop and promote the elements of learn—the 7C's: culture, curiosity, capture, community, collaboration, curation, and continuous innovation.
- Go beyond traditional lessons learned to adapt agile approaches like retrospectives, futurespectives, pre‐mortems, storytelling, and other techniques to better harness and share lessons learned.
- Don't forget to have a customer‐first and customer‐success orientation to learn and evolve from the outside‐in.
- Continuous improvement is not enough; you must strive for continuous innovation. The PMO's highest calling ought to be to cultivate learning, to adapt, evolve, and innovate, for that is what is necessary to survive today, beyond flawless execution processes.