Outcomes Focused-Agility: Experience Report
Categories:
agile,
Benefits Realization,
leadership,
Outcomes Management,
Scrum,
servant leadersip,
strategy
Categories: agile, Benefits Realization, leadership, Outcomes Management, Scrum, servant leadersip, strategy
| In my recent post What? You don't know why you are doing your project? I indicated that I would do a follow-up post on examples of where I have used the Outcomes approach successfully. As you recall, the post was subtitled "Outcomes Focused Agility - Story Mapping our Strategic Intent". In this post, I'll provide two examples of where I have applied it successfully as well as provide an example of where I am currently using it with good success so far. Procure and Implement a Learning Management System (LMS) My role: had overall portfolio responsibility for guiding both the technical and business teams. The Context Several years ago I was hired by the Learning and Development group of a local government agency to help them procure and implement an LMS. They used to have all of their employees in one building. The situation was that employees were now in different cities, in different countries, and on different continents. Most PMs would view this as an IT project and would proceed to begin developing the procurement documents, and then following the procurement, getting it installed and configured for use. And if they did that within the expected 18 month timeline and $2.5M budget we had, they would have considered the project a success. However, by the measures of value that really needed to be satisfied, they would have failed. When you take an outcomes-focused approach, you start by asking why are they feeling they need to do this particular project? Ask why (along with what and how) enough times and you uncover all manner of actual need, many of which are left hidden using most project approaches. Over a period of the first 2-3 months of the engagement I helped them discover/recognize the following :
The Portfolio There were many other things we uncovered by asking why, but the above gives you a good idea of the real problems we had to tackle, which far exceeded just procuring and implementing an LMS. Using outcomes-focused agility, we were able to define the real work we had to do to make the implementation of the LMS a success for them:
We used a Services Canvas I designed based off of the Business Model Canvas to help them figure what services they offered to the rest of the organization and how they would be measured. Once we had the initial versions of the outcomes map and the Service canvas, wee would place the latest iterations of each on our wall and leave stickies and pens on a table beneath them. Most every day stakeholders and team members would walk by and spend a few minutes looking at the canvas and map and use the stickies to leave questions, comments, and ideas. This enabled serendipity across the team and stakeholders - while one person was adding stickies someone else would invariably walk by and they would then have a conversation about the map and canvas and the content of the stickies. Every few days we would collect everything and update the map and canvas and then hold additional brainstorming sessions with everyone. Both the serendipitous and brainstorming events enabled us to create a shared understanding of the why, what, how, who, when and where of our portfolio and it's various programs and initiatives with all of the required players as all of them contributed at different times and to different degrees to their creation. No one felt left out. We used Scrum on each of the initiatives including the procurement process, for doing business process design and development, and for systems integration. We also introduced the idea of using an agile approach to learning content development for the new content that would need be created for the new LMS to deliver. Without suitable content there was no need for an LMS! Having taken an outcomes-focused approach we also created the basis for value-based decisions across the entire portfolio for each of the products that would be created to satisfy each outcome. While Scrum assumes that someone else has already decided which products should be developed, outcomes-focused agility helps us determine which products have to be developed ( in this case learning content, business processes, an RFP, systems integration, etc.). It also helped us to establish the basis for value prioritization within each initiative and product so product owners knew the higher-level strategic goals that were to be satisfied. Remember products themselves are just outputs. They are not outcomes, nor do they measure the benefits of what you have done, and hence they also do not help you understand why you are creating them. They do contribute to outcomes, but they are not themselves actual outcomes. The Results Here is a summary of some of the project metrics (sufficient time has passed that I can share these):
The Learning and development group also restructured based on the new services they were now offering and the processes that supported them. The new processes and the restructuring ideas came from the people who were most affected by it - there was no need for organizational change management as it was change by engagement and with the design being done by the entire team. We managed to achieve far more real value delivery in the 18 months than was expected and for the same money, hence, we were able to deliver what they actually needed, rather than what they had originally intended of simply procuring and implementing an LMS. Build and Implement a Professional Licensure Management System My role: had overall portfolio responsibility for guiding both the technical and business teams. The Context A national professional association wanted to build a professional licensure management system. Again, this sounds like an IT project to most - after all we would be building a software product but in reality it was more complex actual scenario:
The Portfolio Using outcomes-focused agility helped us to identify:
This was way more than simply building a software product. The Results A coordinated delivery was established across multiple years covering facilities, infrastructure, hiring, product development, as well as an organizational restructuring that would enable them to stand-up and support a national professional licensure management system. Mature People, Process and Technology Capabilities My role: portfolio leadership and agility mentoring The Context The last one I'll report on is one that I am currently engaged in to mature people, process, and technology capabilities. The particular team in this case is a technical team that connects business line capabilities to one another. They have been in existence for 4 years and started out as part of a larger project. They split off into a separate team to carry on the operational side for their original development efforts as well as to do similar development work for other business lines. With the prospect of doing work for many business lines instead of just the original two, we felt that we needed to put more formality into what the team does and how it does it. We have identified four value streams to answer the four main outcomes questions as listed below:
The team sits inside of a very large IT organization, inside of a very large government department, so the work they do has a high degree of sophistication as well as being of significant consequence to the business. The team currently owns the entire development and operational support of what they build including at the platform level so we have to address topics such as:
As there are multiple very sophisticated technologies in play, it is not just enough to know what you must do, but you also need to figure out which technology is the right one to use in each circumstance. As a result, in order to determine what we must do (the initiatives) to satisfy a given outcome, we have had to create and execute initiatives whose goal it is to help us sort out our strategy for the actual initiatives to support the identified outcomes. The Portfolio By asking the four key questions above we have so far identified 40 initiatives that we need to undertake. The ones that are developing strategies for their focus areas will lead to the addition of more initiatives once they are completed. This is another of the hidden benefits of outcomes-focused agility as noted above - we can use strategy-development initiatives to both identify and define the initiatives we need to undertake to achieve a given set of outcomes on the map, even after we have already started on the portfolio - now that is the ultimate in outcomes-focused agility! We have also had to tweak some of outcomes statements as based on what we have learned in some of initiatives we have delivered on so far. When faced with such a high degree of uncertainty and ambiguity as this one presents for the team, outcomes-focused agility is proving invaluable in enabling us to do the things we need to do, rather than what we may have intended to do at the outset, across a very complex landscape. The Results - so far The fact that the goal of our work is to mature people, process and technology is not lost on us - maturing our people means constant inspection and adaptation to what we learn along the way. We are also able to adapt to new circumstances as they have emerged as we continue to do other work for the business lines. We are also advantaged by constantly iterating our overall strategy, based both on the strategy initiatives we have identified, as well as the ones that are implementing those strategies, that in some cases, we have yet to define. Another aspect of outcomes-focused agility is that it enables the portfolio team to more quickly assess the consequences of delays and changes in organizational priorities. Due to some external factors for example, we have had to revamp our outcomes delivery timelines within the portfolio. In one example, we were able to assess the consequences of deferring some initiatives to a later FY on the basis of getting less money this FY. We were able to do this assessment in less than 30 minutes! All we were given was the dollar amount that had to be deferred. Our map enabled us to make a value-centric decision as we already knew the relationships between initiatives, products, and outcomes (or results), and hence we could quickly determine which initiatives, products, and outcomes could be deferred while having the least detrimental impact on our overall strategic intent both in the short and long term. Without these maps and their details, this would have taken days if not weeks for something this large, and even worse could have led us to defer the wrong things. I have always ensured wherever possible that each of the initiatives within an outcomes map can be done within 3 months or less and that we use Scrum throughout. This incremental approach allows us to tackle complex situations in manageable pieces. It also allows us to re-vector our remaining work based on what we learn along the way. We are very definitely seeing the value of allowing emergence to guide us by tackling things in small enough chunks, that even if something turns out to not be what we expected, our investment in each one is not that great, so our risk exposure is significantly reduced. The Role of Emergence in Outcomes-Focused Agility Emergence, as I discussed in Chapter 7 of Agile Value Delivery: Beyond the Numbers, is more than just about our architectures and design as described in the principles of The Manifesto for Agile Software Development. It also applies to our understanding of the holistic messes we are solving that often contain many different problems as the examples above clearly demonstrated. In all of the above examples, it was never a single problem to be solved, nor a single project to be executed. I would suggest that this describes 99% of what we encounter in the real world, versus what is often attempted through single monolithic projects. Outcomes-focused agility directly supports this form of emergence, and also provides the context in which to story-map your strategic intent - even when you have yet to fully describe your strategic intent, as was demonstrated in the last example. Understanding emergence, and how to leverage the opportunities it uncovers, helps us to be comfortable with uncertainty and ambiguity. Outcomes-focused agility helps deal with emergence in a rational manner which then allows us to use and adapt multiple frameworks, practices, methods and techniques to achieve value-delivery. We use what is most appropriate to the context of each single problem we are solving, rather than trying a one-size fits-all approach, or even believing that we are solving a single problem, as we rarely are. One of the areas of outcomes-focused agility I have not yet attempted is to take the same focus towards the team itself - what outcomes matter to them? I hope to do some experiments with that over the coming months within my current portfolio. Benefits Realization Rather than address benefits realization under each of the above examples, I though I'd deal with it as a separate topic. For those of us familiar with outcomes-driven approaches, we know that the measure we use to determine the presence of our expected outcomes is to identify the benefits we would need to see in order to determine that the outcome was present. This is as I described it in Chapter 2 of Agile Value Delivery: Beyond the Numbers. Outcomes cannot be directly observed. They are only observable through measurable benefits. Much has recently been written about benefits realization, which is enjoying a noticeable resurgence of interest. However, without the context of outcomes-focused agility, we may end up focusing on the wrong things, and we still don't have a framework that facilitates our emergent and shared understanding in the face of ever-increasing uncertainty and ambiguity. Benefits realization by itself not enough. Conclusion Outcomes-focused Agility enables portfolio, program, and project teams to gain insights into both the magnitude,and the specifics, of what has to be done. It also provides executive levels with a high degree of confidence that we have thought things through enough at the front-end, without locking into solutions too soon, so that we can more fully create a shared-understanding of why we are doing things, and use that shared understanding to drive decision-making throughout and at all levels. An incremental delivery approach through value-streams, and their associated programs within a portfolio framework, also significantly reduces financial, schedule, and delivery risks. So we really don't have to plan or describe everything up-front. Recognizing this simple reality enables us to help the business and its customers/clients end up where they need to be, which may not be where they originally intended to be. And after all, isn't that what we all hope for? ******************************************************************************************** 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:
|
3 Steps to Agile Procurement - less time, less complexity, less cost
Categories:
strategy
Categories: strategy
|
(Originally published on LinkedIn) A number of years ago I was asked by a client to help them procure and implement a COTS product - but I had to use Scrum to do it. That being said, when I got there I was handed a 246-page RFP that a similar organization had issued for the same kind of procurement. That did not look very like it was very agile approach to me so I said ah, I won't be producing one of those! So how did do we do it? Here are the three steps: 1. Figuring out why the business needed the COTS product Step 1 was to figure out why the business though they needed the COTS product. To do that I introduced outcomes mapping (which is a variant of Benefits Mapping) to help them more clearly articulate why they were needing to do the project from a business perspective rather than from a technology perspective. The 246-page RFP document I was handed was mostly technology-focused which is why I felt we needed to avoid a similar trap. As soon as we had the first draft of the outcomes map created we printed on a 3x4 foot sheet and put it on the wall in our war room for the project (see David Maynard's excellent post on how war rooms can help any project). Having a visible map of the “why” enabled both the business and the IT teams to add details or ask questions using sticky notes anytime they walked by the map. We would then stand around the map as a team every day and review the content of the latest stickies to figure out where we needed to update our map with our now emerging understanding of the business problem we were solving. Once we agreed on what needed to be changed, we would update the map, reprint it and put the newly revised map back on the wall. This created an opportunity for serendipity for both the business and IT as they would walk by and study the map. As they stood there looking at the map this often led to others stopping as well which of course led to them to talk about the map together. These ad-hoc conversations led to some of the most insightful additions to the map. Over the period of about 8 weeks or so the big visible map of the why for the project led to the identification of:
As you build an outcomes map there are natural structures that emerge that help you categorize different parts of the map. As this picture emerges it also helps you identify what you need to do (projects/initiatives) satisfy the why you are doing it (the outcomes) 2. Figuring out what the product to be procured needed to do I facilitated the business groups in identifying the required business capability areas that the product needed to address along with capability statements within each capability area as to what they needed the product to do. This enabled them to rank each capability statement according to a scale of business importance (Very High, High, Medium, Low, Very Low). This took about 8 weeks or 4 Sprints. The business was solely responsible for these prioritizations of business importance. We created a Business Service Canvas for this step which was a derivative of the Business Model Canvas. As with the outcomes map we printed the canvas on a 3x4 foot sheet and put it on the wall for the team to use stickies to capture their additions or questions. The Services on the canvas started with those that the Learning and Development group (the business group) already provided to the rest of the organization. It then morphed into those that it would need to provide in order to satisfy the business outcomes from step 1. We then led the business team through a series of pair-wise comparisons of "buy-a-capability" for each of the statements in each priority level within each capability area as follows:
Once all of the capability statements were re-prioritized, we asked them to consider the Low and Very Low ones and whether they wanted us to include them in the RFP seeing as they had already said they were not all that important based on their assigned level of business importance. After some discussion the business decided to remove them from the RFP. This allowed us to end up with an 8-page RFP document augmented by pre-populated spreadsheets with the capability statements organized by capability area. We provided room in the spreadsheets for the vendors to fill in their actual responses which had to refer to their own product documentation that supported their statements of product fit. The vendors were not allowed to submit bound or printed responses to the RFP. Using the Business Service Canvas also helped the business identify the need for role re-evaluations based on newly realized skills gaps as well as missing roles within their organization. This step took about another 4 Sprints to get through. 3. Run the Procurement Now that we knew why we were doing the project and had a solid understanding of the what the COTS product needed to we were ready to run the procurement itself which meant:
Vendor responses to the RFP were received after being out for 8 weeks. The entire response evaluations took less than a week which included the boardroom demos for the top-3 ranked vendors. The boardroom demos also led to a switching of the initial number 1 and 2 ranked vendors which rarely happens in traditional procurements. Implementation of the COTS product took an additional six months. (Note: while some some internal delays stretched the overall delivery timeline to 18 months it was within the original expected time which was also 18 months. Without these delays we would have finished about 4 months early) Actual expenditure on the procured software was only about 2.5% of the original expectation of expenditure as we only evaluated those things that the client really needed – the business spent a mere $25,000 of the original $1 million originally allocated for the product. The vendor selection process also considered the ability of the vendor to help with an incremental deployment and use agile practices for developing the required integration with other corporate systems within the business. Use agile procurement practices means being willing to rethink the procurement process itself as well as the chosen vendor's ability to support agile practices in their product implementations. Conclusion Scrum, outcomes mapping and the Business Services Canvas, as well other practices we introduced allowed us to:
The procurement itself took less time, cost considerably less than planned (only 2.5% of the budgeted $1M), used a far less complex procurement process, and achieved the right results for the business. The project was completed within the original overall budgeted cost of $2.5M, within the same expected time-box of 18 months, yet delivered newly identified business processes, services, and additional tools (with the money saved in the procurement), none of which were part of the original project definition and scope. Have you used Scrum in a procurement? I'd love to hear how it went. |
