Leaders Inspire through Stories
| Excerpt from my upcoming book Leadership Agility: Enabling Sustainable Organizations Stephen Denning’s book The Leader’s Guide to Storytelling is a field guide on how leaders can use stories to motivate, build trust, transmit organizational values, get teams working together, share knowledge, tame the grapevine, and create a shared vision. Leaders who rely on charts and graphs to communicate fail to recognize that organizations are made up of people and that leadership is first and foremost about people. No great achievement was ever realized because a leader gave an amazing PowerPoint presentation. Great leaders inspire people to action. They do so by the way they communicate the story that describes their vision. Leadership is not about technical things. A leader’s ability to create a shared purpose is the requisite step for their organization to create a shared future. Creating a shared future needs a good story. In The importance of storytelling for social change, Simon Hodges argues that Stories engage people at every level – not just in their minds The role of a leader therefore, is to inspire their people to action towards a shared purpose so they can create a shared future together. This is not an exercise that is routine, meaningless, or void of emotion. It is values-based. It relies on the most basic of human characteristics to want to contribute to something meaningful that is bigger than ourselves. The stories that leaders tell helps to frame the collective understanding of the organizations they lead, the vision they have, and the future they want to create. ******************************************************************************************** How to contact me:
Want to engage me and my friends:
|
What? You don't know why you are doing your project?
| Subtitle: Outcomes-focused Agility - Story Mapping our Strategic Intent I am going to make a bold statement. More than 50-60% of project managers don't know why they or their project teams are doing their projects. How can I possibly say that? Surely there are charters and project plans with backgrounders and scope statements? Maybe there are. But that does not mean they know truly know why the project is being done. Why say that? Numerous studies over the years have shown project failure rates of 50-60% (some studies are higher and some are lower to be sure). Likewise, where software development projects are concerned, it is estimated that 60-70 per cent of features built are never used or rarely used. Both of these statistics (and others) point to a lack of clarity on why the project is being done in the first place; The sponsors, the teams, the PM, and others really don't have a clear articulation of why they are doing it. Another factor is that most projects are proposed - that is, someone has an idea for a project, they then write a business case or lobby the executive ranks to get it approved. Some even tie it to strategic goals or objectives. But that still does not mean they know why it is being done. Projects focus on Outputs Most project management books, when they distill the essence of project management, will show a diagram similar to the one below. Some project management practices may also refer to the Activity box as Tools and Techniques, but the premise is basically the same; Inputs are consumed through some form of Activity to produce Outputs which are the project’s deliverables.
While this model is simple, it is focused on the wrong things. It does not answer a very important question – why is this project being done? Focusing on why establishes the desirable Outcomes that the project would create if it were successfully completed. Agile approaches are not immune from this phenomenon as they also start with the Outputs (i.e. deliverables, products, features, etc.) and then identify the activities and inputs needed to create them. The difference between traditional and Agile is in what the activities are and how they are accomplished. But it still does not answer the why questions. Interestingly, normal business operations and projects both focus on using inputs to activities to create out-puts. Ditto for business processes work. None focus on knowing why. Outcomes – The Source of Why Outcomes Management enables organizations to define and use specific indicators to continually measure how well services or programs are leading to the desired results. Outcomes Management is used extensively in health care (it did start with Florence Nightingale after all) and the not-for-profit sectors. For IT, it was articulated in the book “The Information Paradox” by John Thorpe of DMR in 1998. Before the book was published I was working for DMR and we were taught the Benefits Realization approach (based on what was in the book) as part of being consultants. It was also embedded into the “ValIT Framework” from the IT Governance Institute, with John Thorpe as the lead author. Some of the questions we can ask ourselves and our Business colleagues to help us identify desirable outcomes include:
There are two important ideas to understand about Outcomes – their type and their timing which we look at next.
The first two types of Outcomes are ones that are desirable – that is they have a positive effect. The last one is an undesirable Outcome type that we would wish to avoid. There are everyday examples in the non-project world of Outcomes that are bad and unintended. For example, introducing a new species into a habitat to overcome one particular problem with another non-native species can lead to the new species becoming equally invasive and also destroying native species’ which clearly was not an intended consequence and is not desirable. We try to maximize the first outcome type, hope we get some of the second type, and try to avoid the third outcome type entirely. Outcomes Timing and the Outcomes Map
The Outcomes Map as illustrated above highlights that Outcomes may be delivered at different points in time as follows:
An Outcomes Map is premised on helping us answer the why question which helps us to identify the Outcomes that we desire to achieve. The possible Outcomes Types (Good and Intended, Good and Unintended, or Bad and Unintended) that were described in the previous section can occur as any of the above timings (Immediate, Intermediate or Ultimate Outcomes). Assumptions and Risks are also important to know. Risk Management does not go away because we will be applying Agile approaches – but some of the Risk Management practices we will employ will be different than those used with traditional project Management. Mapping Outcomes is Counter-Intuitive A counter-intuitive feature of an Outcomes Map is that you actually create it by starting on the right and working backwards to the left:
An Outcomes Map is one of the most important Products that a team will create on their way to understanding why so they can deliver Value that matters. As we create the Outcomes Map we also create the following artifacts:
But that's a lot of Work! For those who think this is a lot of work, what we have essentially described is a diagram and some spread-sheets that are developed iteratively and incrementally and then updated as the portfolio of projects move along towards completion. It fits very well with the ideas of simplicity, time-boxing, and focusing on Value that are fundamental principles for Agile thinking. The Outcomes Map with its associated artifacts is a reviewable and updatable Output throughout the execution of the portfolio during Agile Value Delivery. It also adheres to the basic Agile tenet of being driven through empiricism – we let the facts we uncover during execution guide us. Same for our Outcomes Maps - as we understand more, we get to update those as well. Conclusion The Outcomes Map and its artifacts also enable the Business and the Portfolio Teams that have to deliver to quickly and effectively:
Projects that are initiated in this way are purpose-defined as they are tried to specific Outcomes and their associated benefits. This approach also means we don't need to do a business case or benefits case at the individual project level as they literally fall into our laps - knowing which Outcome a project is being stood up to contribute to means we know which benefits it will be enable. Have you ever used this practice? In the next post I'll provide some examples of where I have used this practice to identify the people, process, technology, facilities and organizational structure implications of major transformations before any real work was actually done. It also supports what I call Outcomes-Focused Agility which helps us to story-map our strategic intent. But then, would the post have caught your eye if I had used that title? ******************************************************************************************************** How to contact me:
Want to engage me and my friends:
|
The Edge of Chaos: Missed it by that much...
|
Previously published on LinkedIn.com As a child growing up in the sixties and early 1970's one of my favorite TV shows was "Get Smart" (1965-1970) with Don Adams as Maxwell Smart from Control. Max and Agent 99 were constantly fighting the villains from Chaos. Invariably Max's bungling led to losing the small battles along the way to Chaos after which he would utter the iconic phrase "missed it by that much!" By the end of most shows Max, Agent 99, and Control would win out over Chaos (actually it was mostly Agent 99 (Barbara Feldon) that outsmarted Chaos). It's a great metaphor for the world that most leaders and their organizations now find themselves in as they face the chaos of accelerating change coupled with ever increasing ambiguity and uncertainty. Some are trying to control the chaos from afar with multi-year plans while others are trying to exhibit control at the edge of chaos. This concept is also at the heart of complex adaptive systems (CAS) theory which states that in order to harness change with no anarchy, CAS strives to maintain a balance between the completely ordered, “frozen” regime and the completely disordered, chaotic regime, which is known as operating on the “edge of chaos” (McKelvey, 1999). The "edge of chaos" is also where we need to be in order to manage at the pace of change. Does this mean that we always should expect to be successful? Of course not. In Agile we talk about the need to inspect and adapt which is based in empiricism - we adjust based on what we now know based on what we just did. When operating at the edge of chaos it is highly probable that we will miss the mark occasionally. We will, as Max Smart would say, have "missed it by that much!". And that's OK. In a prior post on Being a Servant Leader I talked about the role of a leader in creating a safe environment for their teams to experiment and try new things without fear. When operating at the edge of chaos failures will occasionally happen. It is not that they will happen, it is that how we react to them that matters. Do we follow our Agile ways and inspect what happened and why and then adapt and adjust based on what we find or do we start apportioning blame? Based on the accelerating nature of change in the modern world can we afford to do anything else but inspect and adapt? To do otherwise would actually put us over the edge rather being on the edge. Inspect and adapt is one of the ways in which we can bring order to the edge of chaos. Inspect and adapt does not mean pressing on in the face of overwhelming evidence that something is not working. We don't know what we don't know. It is through doing that we uncover the things we don't know. In Agile we call this emergence. Most typically, emergence has been contextualized to the concepts emergent architecture or emergent design. But it also applies to the problem space as well - we devote Chapter 7 of our book to the different types of emergence. Inspect and adapt, when considered as part of an emerging understanding and clarity around the problem we are trying to solve, can enable us to respond in more considered ways to what we now know that we did not know previously. This leads to the main point of this post. Leaders will often afford their teams the ability to fail and recover but not always themselves. This kind of bravado can be dangerous to both you and your organization. So it is important that you also have the courage to acknowledge when you miss it by that much in front of your teams. This level of transparency, rather than leading to a perception of weakness, will actually embolden them to also operate at the edge of chaos. Your stature as a leader will increase if you do. Continuing to exhibit control at the edge of chaos by inspecting and adapting to your emergent understanding of the problem will enable you to eventually overcome the current chaos so you can move on to the next set of chaotic challenges. As a leader, do you allow yourself to fail and acknowledge it? Are you willing to say "I missed it by that much!"? |
Strategic Iteration versus Strategic Planning
|
When I was first introduced to the phrase “strategic planning” in the early 1990’s I recall asking myself if it meant that the act of planning itself was strategic. I tend to do that with phrases that I feel contain contradictions – like business analyst for example – business analysis is an activity that many of us do on a daily basis and sometimes multiple times a day. So why is it seen as role? But I digress. When I visualize strategic planning I see the thick binder containing all manner of grand visions and statements as the end result. Each year's annual strategic plan joins the strategic plans from years past; on a shelf that no one dares to look at for fear of having to open one of them and actually read it. Strategy is a concept that emerged in military planning over many millennia and was essentially made up of setting some objectives, gathering intelligence, and using that intelligence to make informed choices about likely courses of action. Of course as was famously attributed to Dwight D. Eisenhower the approach was limited but useful, In preparing for battle I have always found that plans are useless, but planning is indispensable Strategic planning in corporate settings is based on the premise that we can use the past to predict the future. But is that realistic? Defining and delivering on vision and strategy has been a hit and miss proposition for most organizations for many decades. The reason for this is twofold. First, the world is not like it used to be. Traditional management and its accompanying models relied on the notion that we can use the past to predict the future. This was the era of 3-5 year plans. Change was slow, and at times imperceptible, and the problems were mostly discrete. Organizations are now operating in a world of volatility, uncertainty, complexity and ambiguity (VUCA). Additionally, customers expect businesses to be more aware of and responsive to their needs. Secondly, organizations now face holistic messes rather than discrete problems. Traditional hierarchies are intrinsically ineffective at enabling the speed of decision-making required to lead at the pace of change. We don’t know what we don’t know and we have to stop the pretense that we do. Rod Collins, in his forward to our book Agile Value Delivery: Beyond the Numbers said: “Handling these holistic messes has more to do with having the ability to rapidly adapt to ever-changing customer expectations than with minimizing variances in a fixed plan.” Handling holistic messes requires whole-of-organization approaches. These approaches encompass iterative strategic direction setting, execution, validation, and adaptability. It requires a mindset that embraces emergent thinking. The window of opportunity to deliver Value into business operations has gotten shorter; the window of stability following Value delivery is immediately followed by the next set of challenges that have to be solved. Strategic iteration (or iterating strategy execution) recognizes that we cannot use the past to predict the future. Increasingly, many are starting to recognize that we need to adjust how we view strategy:
That is, we need to move from the perspective of doing strategic planning as an annual exercise to doing strategic iteration as a continuous activity that involves everyone, and then focus our attentions and efforts on what we are actually observing as opposed to what we hoped might happen. A high school guidance counselor once told me what he would say to his students at the end of a session where he had to have a conversation about problematic behaviors “awareness is an awful thing “ – once you have been made aware of something you never become unaware of it again. We no longer live in a world of slow and imperceptible change when strategic planning as a corporate exercise was incubated and when most people felt the problems we faced were mostly discrete. We now live in a world of rampant change and holistic messes. There, you are now aware. So what do you think? Time to ditch strategic planning for strategic iteration? |
