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:
|
Value-centered Decision-Making
| Excerpt from The Adaptive Strategy Framework Guide 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 thinking and its accompanying models rely on the notion that we can use the past to predict the future. This was the era of 3 to 5-year business plans. Change was slow, and at times imperceptible, and the problems they faced were mostly discrete. Secondly, organizations are now operating in a world of volatility, uncertainty, complexity and ambiguity (VUCA). Additionally, customers expect more awareness and responsiveness by businesses that provide them with products and services. A VUCA world means that organizations now face holistic messes rather than discrete problems. Traditional hierarchies are intrinsically ineffective in 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 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 must 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 increasingly shorter while the window of stability following Value delivery is immediately followed by the next set of challenges. Solving holistic messes requires holistic solutions that recognize both the objective (goal-based) and subjective (perception-based) perspectives of value:
Being value-centered enables teams of individuals:
Having clearly defined values and principles at an organizational level that also supports agile thinking creates the framework for cogent and coherent value-centered decision-making across an organization. Clearly defined organizational values + organizational principles + agile thinking = making good decisions across the organization. Do you or your organization practice value-centered decision-making? ******************************************************************************************************** How to contact me:
Want to engage me and my friends:
|
The Leaders Role in the Sustainability of their Organizations
| In our recent book on Organizational Agility we talked about the fact that organization's which exhibit agility are sustainable over the long run. We used W.L. Gore as an example of a sustainable company due to their four culture principles that Gore called freedom, fairness, commitment and waterline. A waterline situation at Gore involves consultation with other associates before undertaking actions that could impact the reputation or profitability of the company and otherwise "sink the ship.” Gore is sustainable because of these four principles and because no one person can take an action that would sink the company. Leaders need to understand the role they play in the long-run sustainability of their organizations. A sustainability focus from a leadership perspective needs to address the following:
****************************************************************************************** How to contact me:
Want to engage me and my friends:
|
A question for leaders: can you coddiwomple?
|
(originally posted on LinkedIn) It's Sunday morning, and as I am apt to do on weekends while drinking my morning coffee, I spend the first hour or so wandering through Facebook, LinkedIn and Twitter seeing what my connections have been up to over the past few days. This morning I saw a post on Facebook by a old friend of mine on the definition of coddiwomple. Ever had that moment where you see a description of something or you a come across a word that succinctly summarizes something for you? Coddiwomple is one of those words for me. For those who have read my recent book on Organizational Agility or my Adaptive Strategy Framework Guide or my first book Agile Value Delivery: Beyond the Numbers, attended any of our webinars, read any of my previous posts, or is an member of my LinkedIn group know that I write a lot about uncertainty and the fact we live in a VUCA world. Living in a VUCA world means that we cannot use the past to predict the future which is a basic assumption behind most strategic planning exercises that try to lay out a vision for the next 3-5 years. Couple this with the fact that our window of opportunity is now often measured in months not years and that is by windows of stability that are measured in weeks instead of months, leaders of every organizational size and in every sector are challenged more that ever to learn how to be adaptive. They need to learn to base their decision-making on what they and their people do next based on what know today they did not know last month or even last week. Does that mean that strategy execution is now a crap-shoot? No. What it does mean is that we can no longer assume that we can simply make a plan and work the plan. It means leaders and their teams need to do strategic iteration as opposed to strategic planning as I describe in my Adaptive Strategy Framework Guide. Being able to prioritize what you and your teams do next means you need to have some sort of destination in mind, a vision of the future. This enables you to move towards that destination, however vague it may be, in a purposeful manner. By taking an adaptive approach to how you realize strategic goals and objectives also means that you may in fact end up at a slightly different destination that what you originally envisioned. And that's ok as it will be where you need to be, which is not necessarily where you intended to be. Being where you intended to be as opposed to where you need to be is failure - it means you executed to a strategic goal where all the signs along the way meant you were going in the wrong direction, yet you and your teams chose to ignore the signs anyway. So, as a leader, can you coddiwomple? ****************************************************************************************** How to contact me:
Want to engage me and my friends:
|
