Project Management

The Agility Series

by
The Agility Series focuses on agile and agility across the organization not just in software and product development. Areas of agility that will be covered in blog posts will include: - Organizational Agility - Leadership Agility - Strategic Agility - Value Agility - Delivery Agility - Business Agility - Cultural Agility - Client Agility - Learning Agility

About this Blog

RSS

Recent Posts

Guiding Principles for an Adaptive Organization

Reflections on 40 Years in IT - Agile by default!

InfoQ Podcast Interview of me on The Agility Series, Cultural Agility, and more

You might be a management red-neck if…

Strategic Debt  — What it is and how to avoid it

What is Cultural Agility and why does it matter?

Categories: agile, agility, culture, leadership

Image result for cultural agility

Now that the New Year is off and running, we will be getting started on the next book in The Agility Series which will be on Cultural Agility. So what exactly is Cultural Agility and why does it matter?

Within the agile space much has been said and written about creating/enabling an agile culture or a culture of agility. Here's one definition I came across for an agile culture that pretty much sums it up: 

An "agile" culture (with a lower-case "a") is one that has adopted a style, approach, and community that is tolerant of failure, willing to test hypotheses, and able to adjust to changing market conditions as deemed necessary.(1)

But is that the same thing as cultural agility? Apparently not.  There are multiple definitions out there such as:

Cultural agility is the mega-competency which enables professionals to perform successfully in cross-cultural situations. Culturally agile professionals succeed in contexts where the successful outcome of their jobs, roles, positions, or tasks depends on dealing with an unfamiliar set of cultural norms—or multiple sets of them (2)

And this one:

Cultural agility is the ability to understand multiple local contexts and work within them to obtain consistent business results.  For today’s global organizations, cultural agility is the new competitive edge. While individual capacities are important, successful organizations build an institutional level of a global mindset and skills for effectively coordinating, negotiating and influencing across boundaries. (3)

While there are many other definitions, all seem to be focused on the fact that organizations may operate in different locales and need to be culturally aware (3) or there are many different cultural groups that may exist inside of your local organization (2). Most organizations that I have dealt with in recent years have an incredibly rich set of international cultures resident within them. This trend is increasing. And to me, that's a good thing.

I would take culture a step further and say that modern organizations need both an agile culture, and their people need to be culturally agile. My hypothesis is that the former provides focus for developing the shared values and principles that guide our collective actions, while the later helps us understand how we personally interpret and apply those shared values and principles, which will necessarily affect how we interact with those who are culturally different than we are. I feel both perspectives are crucial to success in modern organizations. I think it also fits with my humanist tendencies. Wikipedia defines humanism as:

Humanism is a philosophical and ethical stance that emphasizes the value and agency of human beings, individually and collectively, and affirms their ability to improve their lives through the use of reason and ingenuity as opposed to submitting blindly to tradition and authority or sinking into cruelty and brutality.

For those who may be wondering, this definition is not, for me, an anti-religious stance. It's more focused on the idea that we really all do need to get along if we are to create vibrant and long-lived organizations. We also need to be able to draw on the collective wisdom of all rather than on the ideas of just the few people at the top. 

The two books in The Agility Series so far have been guided by the ideas provided by people from Australia, Great Britain, Canada, USA, Singapore, France and Belgium. As these two were by invitation-only to be a member of the Wisdom Council for each book, we are planning to open it up for the remaining seven books in the series so that we can have an even greater mix of countries and cultures represented.

What better book to start doing that than with the next one we are tackling on Cultural Agility?

Want to explore what cultural agility means to you and why it matters?

To join in our next adventure in agility, look out for a post in a few weeks when we officially launch our first round of questions for the third book in The Agility Series on Cultural Agility. If you want to read the first two books in the series, go to www.mplaza.ca and download Organization Agility and Leadership Agility to get you into what we have explored so far. I have removed the pricing on Leadership Agility so it's now free to download!

Want to have a say in the questions we'll be asking in Round one?

Jen Hunter and I will be giving a presentation at PMIOVOC on January 25th at noon called Best decision yet: Aspiring together to co-create global wisdom! If you are in the Ottawa area, come join us as we let you in on how the Series came about. You'll also get a chance to provide input to the set of questions we will use in the first round of ideas gathering for Cultural Agility! Hope to see you there!

PS: also come join the conversation on our LinkedIn Group 

(1) https://www.quora.com/What-is-Agile-Culture

(2) http://www.culturalagility.com/

(3) http://lexicon.ft.com/Term?term=cultural-agility

*********************************************************************************

How to contact me:

Want to engage me and my friends:

We also offer classroom training for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)

 

Posted on: January 15, 2017 12:40 PM | Permalink | Comments (5)

Outcomes Focused-Agility: Experience Report

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 :

  • They had no experience, tools or process for developing on-line course content
  • They had no content management system
  • They had not considered what new services as a Learning and Development group they would need to offer their internal clients once the new way of delivering learning content was in place
  • They had not considered the governance of learning within their organization and what that meant to how they approached employee development

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 identified 4 additional value-streams that had to be addressed on top of the one to enable learning delivery management (the role of an LMS fits in that value-stream)
  • We uncovered that five different software products were needed and not just the LMS
  • We realized we had to design new processes for governance, learning content design and development, learning content management, learning management delivery (where the LMS was actually used), and talent management

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):

  • Planned:
    • $1M to procure an LMS
    • Projected total 10 year license cost $9.8M
    • 200+page RFP document was expected based on what a similar agency had done to  recently procure an LMS
    • Do this in one project
  • Actual:
    • $25K to procure the LMS which was only 2.5% of actual budget that was to be used for procurement
    • Projected 10 year license costs were $75k
    • An 8 page RFP document that explained the RFP process was used to drive procurement along with other tools we developed for the exercise - no vendor was allowed to submit paper-bound responses - only electronic response were permitted
    • RFP and vendor evaluations including board-room demos only took 5 days to select the winner
    • There were 7 initiatives that had to be completed as part of a portfolio within a total of 5 separate value streams
    • The portfolio was completed within the 18-month original window and the $2.5M budget

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:

  • There were 12 regulatory bodies, the national association, and an examining agency all of whom had to be factored in to whatever was created
  • The national association only had a few employees up until taking on this initiative
  • They had no real internal infrastructure or hosting capabilities

The Portfolio

Using outcomes-focused agility helped us to identify:

  • Ten separate value streams
  • The need to add new physical facilities, procure network infrastructure, new hosting services, etc.
  • The need to stand-up an entire new organization to support and operate the eventual systems and infrastructure
  • The need for  pathfinder projects to standardize the licensure process across the various licensure bodies, to gain experience with the support model that would be needed,  and to investigate required self-assessment capabilities for those seeking licensure
  • Instead of just one software development project, we identified 27 separate initiatives across 10 separate value streams - in essence  a portfolio with 10 separate programs

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:

  • How do we govern it?
  • How do we build it?
  • How do we operate it?
  • How do we sustain it?

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:

  • Business and technical governance
  • Architecture
  • On-boarding of new portfolios
  • All facets of DevOps
  • Systems management
  • Business activity management
  • Re-platforming
  • Migrations of existing products to newer platform technologies

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:

  1. Send me an e-mail directly
  2. Follow me on Twitter: @cooperlk99
  3. Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

  1. Check out our LinkedIn Group
  2. Check out our learning portal: www.MPlaza.ca - lots of free stuff plus some great courses on Scrum  and PRINE2 Agile. Go get The Adaptive Strategy Guide and Organizational Agility while you are there - both are FREE.
  3. We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details
  4. We also offer classroom training  for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)

 

Posted on: December 18, 2016 12:41 PM | Permalink | Comments (8)

Leaders Inspire through Stories

Categories: agile, leadership, strategy

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
but in their emotions, values and imaginations

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:

  1. Send me an e-mail directly
  2. Follow me on Twitter: @cooperlk99
  3. Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

  1. Check out our LinkedIn Group
  2. Check out our learning portal: www.MPlaza.ca - lots of free stuff plus some great courses on Scrum  and PRINE2 Agile. Go get The Adaptive Strategy Guide andOrganizational Agility while you are there - both are FREE.
  3. We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details
  4. We also offer classroom training  for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)

 

 

Posted on: October 15, 2016 11:56 AM | Permalink | Comments (3)

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:

  • Why do we want to affect the current situation and what would a new set of outcomes look like?
  • What will it look like when we achieve the desired solution or outcome?
  • Why do we want to affect current behaviours?
  • Why are we doing this?
  • What benefits would we get if we achieved a particular outcome?
  • How will we measure the benefits?

There are two important ideas to understand about Outcomes – their type and their timing which we look at next.
Outcomes Types
There are three basic types of Outcomes that can be achieved from any action we can take as shown below:

  • Good and Intended: Ones that we planned for and intended to happen
  • Good but Unintended: Ones that we did not plan for, but that have a positive effect on the organization or its Customers/Clients
  • Bad and Unintended: Ones that we did not plan for and that have a negative effect on the organization or its Customers/Clients

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
Outcomes also have different timing. One of the concepts that was introduced by Thorpe in his 1998 book was the Results Chain (aka Outcomes Map) as shown below:

The Outcomes Map as illustrated above highlights that Outcomes may be delivered at different points in time as follows:

  • Immediate Outcomes (yellow): Immediate results that flow logically from the activities and Outputs. They represent the change brought about by the existence of Outputs created through the activities. That is they accrue and are observable immediately upon delivery of a particular Output from a Project.
  • Intermediate Outcomes (purple): Events or results that are expected to lead to the End (or Ultimate) Outcomes, but are not themselves an “End”. These may also include characteristics relating to the quality of the service provided to clients, such as accessibility, response time, and overall satisfaction.
  • End (or Ultimate) Outcomes (green): The consequences/results of what was done – the Ultimate Outcome is the highest level of change that can be achieved, it is the change of state that a project or set of projects in a programme or a portfolio had hoped to achieve. They are the highest level of Out-come that can be reasonably attributed to the project in a causal manner, and is the consequence of one or more intermediate Outcomes having been realized. These outcomes are the raison d'être for the project and are required in order to achieve the Strategic Outcomes of the organization

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:

  • The Ultimate Outcomes are defined first and help us answer the why questions
  • We then start to identify the Intermediate Outcomes that would precede an Ultimate one and continue working to the left until we can no longer identify any more
  • We then start to identify projects that we would need to undertake to achieve the identified Out-comes (whether Intermediate or Ultimate) - this is how we define a Portfolio or a Programme of related Projects
  • Project identification is where we typically uncover the Immediate Outcomes

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:

  • An Outcomes Register that provides basic descriptive information about the Outcome such as a their Type, Timing, and their Owner (i.e. who is responsible for tracking and reporting)
  • A Projects Register that provides basic descriptive information about the projects that will need to be executed and their sequence along with links to the Outcomes they are intended to support
  • A Benefits Register that provides basic descriptive information about the Benefits that would be achieved such as their Type, Timing, and Owner as well how they will be measured and how often they will be measured. Benefits are the Key Indicators that enable the Business to determine that the desired Outcome are being achieved. Benefits therefore are a Leading Indicator for Outcomes

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:

  • Answer the Why questions
  • Know the relationship between Projects, Benefits, and Outcomes
  • Know the order in which Projects ought to be done
  • Know the consequences of not doing a particular Project or of deferring it until later by seeing which Outcomes would be delayed or foregone
  • Gain insight into the relative size of what is being considered

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:

  1. Send me an e-mail directly
  2. Follow me on Twitter: @cooperlk99
  3. Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

  1. Check out our LinkedIn Group
  2. Check out our learning portal: www.MPlaza.ca - lots of free stuff plus some great courses on Scrum  and PRINE2 Agile. Go get The Adaptive Strategy Guide and Organizational Agility while you are there - both are FREE.
  3. We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details
  4. We also offer classroom training  for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)

 

Posted on: October 13, 2016 07:17 AM | Permalink | Comments (5)

Value-centered Decision-Making

Categories: agile, leadership, strategy

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:

  • When an organization looks upon Value in the subjective sense it is said to be value-based
  • When an organization looks upon Value in the objective sense it is said to be value-driven
  • When an organization looks upon Value in both senses simultaneously it is said to be value-centered

Being value-centered enables teams of individuals:

  • to do the right things for the right reasons
  • in the right way
  • to achieve the right results
  • at the right times

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:

  1. Send me an e-mail directly
  2. Follow me on Twitter: @cooperlk99
  3. Connect to The Agility Series Webinar Channel

Want to engage me and my friends:

  1. Check out our LinkedIn Group
  2. Check out our learning portal: www.MPlaza.ca - lots of free stuff plus some great courses on Scrum  and PRINE2 Agile. Go get The Adaptive Strategy Guide and Organizational Agility while you are there - both are FREE.
  3. We provide coaching and mentoring in Agile and Scrum for public and private sector clients. Contact me for more details
  4. We also offer classroom training  for Scrum.org courses plus other agile and Scrum training (http://bssnexus.com/education/)

Posted on: October 12, 2016 07:01 AM | Permalink | Comments (2)
ADVERTISEMENTS

"All progress is based upon a universal innate desire on the part of every organism to live beyond its income."

- Samuel Butler

ADVERTISEMENT

Sponsors