The Agility Series

This is a bit of a different post for me.

My partner and I have crafted a set of Guiding Principles for an Adaptive Organization which I invite you to comment on in this thread.

The final version will be posted for download at www.AdaptiveOrg.com under a Creative Commons license.

All contributions whose comments are used in some way (meaning either directly or caused us to think about something differently) will be recognized in the final release.

So what would you change, drop or add?

Here are the principles (we thought ten was a nice round number): 

1. Act with intent through clearly defined and transparent strategic priorities that are reviewed and adjusted based on the evidence and through collaboration inside and outside of the organization

2. Recognize that becoming and remaining an adaptive organization is not a project, it's hands-on, with live experiments and adjustments until it becomes the way of organizational life

3. Have fully engaged and clear-the-path leadership

4. Recognize shared values and principles are the necessary ingredients for people to create and sustain aligned personal and organizational purpose and adaptability

5. Recognize true organizational sustainability and resilience can only be achieved by becoming adaptive in action and in thought – we do (act) so we can train the adaptive muscle in our brain

6. Have a strong focus on clients/customers and engage them directly to establish overall strategic priorities, and to achieve specific initiative goals

7. Hire and promote the creative and productive power of gender-balanced, intellectually, and culturally diverse teams at all levels

8. Create and support a fail-forward safe environment

9. Provide collaborative workspaces that can adjust to the needs of people and the organization over time

10. Recognize that organizational policies exist to support the achievement of organizational and client/customer desired outcomes. When there is a conflict, the outcome wins

These principles support one another equally in achieving mastery as an adaptive organization

Fair warning....this is a self-indulgent piece that probably only matters to me. If you find it interesting. Yeah! If not. Yeah!

It's hard to believe that 40 years ago, on January 3, 1978 was my first day of work.

In December 1977 I had completed my degree in Computer Science at the ripe old age of 19 (we only went to Grade 11 in high school at the time). I had done my entire degree on punched cards, except for one course in APL.

One of my university professor's claim to fame was that he was the first to have created a graphical rendering of an egg...so naturally he taught graph theory. As he was one of the cool dudes, he occasionally hung out with us wanna-be-cool students on weekends doing what we all did in the 1970's - I hear it will be legal in Canada next summer. :) Fun times.

I chose the Forest Gump theme as, looking back, I feel a bit like the Forest Gump of the IT and computer industries - I have watched an entire industry unfold before my eyes and got to participate in what has been probably the most tectonic shift in the history of technology and work.

To put it in perspective, when I graduated in the fall of 1977:

• Apple Computer was just over a year old and Microsoft was only 2 years old
• The home computer market was in its infancy and was mostly hobbyists experimenting with kit computers like the Heathkit H8
• The first spreadsheet (VisiCalc), word processing (WordStar) and presentation (Bruno later called HP Draw) software were still more than a year away
• The internet was still 15 years away (though it was invented in 1989)
• Computer Science was only established as its own department at my alma matter the following year

As we approach 2018 we're talking about quantum computing, AI, deep learning, Apps, self-driving cars, digital services, and cyrpto-currencies. Quite a shift indeed.

So here's what I saw and experienced over the past 40 years (what follows is rather long because...40 years is a really LONG time):

1978-1990

• In my first job with Newfoundland and Labrador Computer Services (that we affectionately called Knuckles (NLCS)) I did everything - requirements, analysis, design, coding, testing and deployment. So while we did not have the cross-functional team concept, as individual developers we had to have a very good understanding of all of the competencies required to get software from idea to production
• My brother-in-law, Wayne Kelloway (sadly he passed away in 1999), worked in production support at NLCS and observed that most developers, who simply threw their mess over the wall to prod, ought to have to find their own bugs and fix them in the middle of the night (like he did when the batch jobs ran and often crashed). He figured it might prod them to do better design and testing. This was 1979...DevOps took another 30 years to materialize
• Throughout the 1980's, after I had moved on to the Federal government with the Atmospheric Environment Service (aka the Weather Service) in Gander NL (the Come from Away town), I got even more exposure to the world of Dev and Ops as I was responsible for both development and operations within the Weather Centre. In 1980-1981 I was the ONLY computer guy in the office so I really was Dev and Ops. I got to do what my brother-in-law had suggested...fix my own crap at 2am! It left an indelible mark (along with some sleep-deprived weeks of my life).
• I also got to do hardware and operating systems...when the nearest vendor guy is at least 4 hours away, you become cross-functional or nothing works for long. As the office was at the airport, it's also the period I got to learn that DND radars and disc drives don't mix. We had an HP1000 with a whopping 50mb hard drive. The actuator coil that drove the read-write heads would beep every 12 sec in time to the radar sweep. We had to copper shield and ground the room to create a Faraday cage
• On the side, while I was in Gander I got to help my brother in-law introduce computers into the school system in the form of the Commodore PET. We developed software in BASIC to track students grades throughout their high-school years. We started that around 1981. We also ran an adult education class on the Commodore VIC20 teaching BASIC. I also started introducing the IBM PC to my work place in 1983.
• Cool fact: Commodore BASIC was written by Bill Gates and Paul Allen from their fledgling Micro-Soft Corporation  (later renamed to Microsoft Corporation). Commodore BASIC was the only unlimited software license ever granted by Microsoft to any company for all products regardless of the number of copies used. Commodore went on to produce literally millions of machines with various forms of Commodore BASIC and did not pay Microsoft a single cent beyond the initial licence purchase in 1976.
• On a sad note, I was still in Gander on December 12, 1985 when Arrow Air Flight 1285 went down killing all 248 passengers and 8 crew members on board, most from the 101st Airborne Division. From my office window, I watched each individual soldier receive full military honors as they were being loaded onto a plane for their final journey home. One of the saddest and most awe-inspiring events I have ever witnessed.
• In 1985 the US DoD came out with DoD-Std-2167A which is when waterfall was essentially made into a standard - and the rest as they say is history (even though the main author gave a mea culpa in 1996 and said oops...sorry about that, "in hindsight, said he would have made a strong IID recommendation, rather that what was in 2167"). So if the guy who started the mess says sorry...can we stop defending this nonsense and move on?

1990-2000

• In 1990 I moved to Ottawa (via Halifax from 1986-1990) to Ice Services (Canada's Ice Forecasting service for the Arctic, Ice Berg alley off Newfoundland, and the Great Lakes and Seaway). In the early 1990's Canada was preparing to launch RadarSat - a satellite that would transmit 7.5gb of new data/day at 10 meter resolution for our area of interest (previously we had two aircraft that flew around collecting data). Our biggest hard drive at the time was 424mb. This meant wholesale replacement of our entire infrastructure - all hardware, networking gear such as it was, and well as all of the software in the data centre and on the Forecaster workstations had to go.
• (Side note: As an employee of Environment Canada in Halifax I got to go to Sable Island for work and to see the ponies. A highlight still.)
• We looked at the magnitude of the task before us realized we needed to think differently if we were going to pull this off in 3 or so years. 1) We moved to Unix from HP-RTE and Vax VMS, 2) We decided to use C++ and object-oriented design instead of Fortran and procedural, 3) We looked for the commonality across all of our software and built what we called Global Services before we built the new applications, 4) We automated as much of the operations monitoring as we could with HP OpenView for network node management, BMC Patrol for capacity and process monitoring , and Remedy ARS for automated Incident management and initiating automated fixes
• This was the period 1992-1994...and almost fifteen years before ITIL started to become a thing on this side of the pond. We did the ops automation part in three months...when you are already overloaded, you don't over analyze things - you simply get them done and move on. Oh, and we installed the first 100mb network in the city.
• As we knew nothing about object-orientation, we bought books. Lots and lots of books by the pioneers of the day: Rebecca Wirfs-Brock, Ward and Mellor, Ed Yourdon, Tom DeMarco, Peter Coad, Grady Booch, Ivar Jacobson (who went on to co-create RUP), and James Rumbuagh. Their work in OO is what eventually led to the advent of JRP/JAD/RAD which I used in the late 1990s. It's a lot of the same kind of thinking that led to the Manifesto for Agile Software Development.
• I attended the inaugural Object-Management Group Conference around 1993 and found out that what we had called Global Services they called Common Facilities as part of the CORBA Specification. This was the precursor to Service Oriented Architecture (SOA) almost ten years later. A big difference in what we did back then, versus SOA now, is that we also had to build the inter-system communications layer mostly from scratch to make it all work. We used Kerberos for and DCE for security. These were also the very early days for the concept of open systems. We were a big proponent and made it part of our architecture.
• We also got to go visit all of our tech vendors and ask for things like 4-foot wide flat screens (the Arctic is a big place to see on one screen) - we were told we were about ten years early; We were told that a lot about what we were trying to do...we also didn't listen a lot to being told what we could not do.
• A cool thing about our visit to HP in Palo Alto was they demonstrated what the future could be like. They used to make video's of products that existed, would soon exist, were still in the labs, and those that might be possible to exist in the future. You had to guess which was which. Their example was of a little girl having a medical emergency at an accident scene and the EMS personnel using a hand-held video device to communicate with emergency room doctors; To read about what that is really like, take a peek at Estonia today (search for doctor). That was 25 years ago at HP...another cool thing about the visit was when an HP engineer walked up to me and asked "Are you THE Larry Cooper from Gander NL?" He told me that everyone who worked on the HP1000's knew about me because of the radar problem. This was over ten years after our Faraday cage...my little bit of fame :)
• Instead of our applications taking 12-24 months each to build, once we had our services layer in place, we were able to crank out the replacements in 3-5 months. It forever changed how I looked at software, design, and what was possible in short time-frames. We stood-up several small development teams (we used consultants), each with all of the required competencies, to work on the different product areas we had to tackle. Looking back now, we were pretty radical in what we did and years ahead of most everyone else. Oh, on the employee-side we were a shop of about 5 IT people. It's not the size of the team, it's the size of their ambition.
• Cool fact: In 1993 we used Usenet groups via our new Internet access to find a solution to a communications problem between a Sun Micro Systems server and Windows NT box - the answer was to turn off the timeout on the NT side and it would eventually give up and accept the connection! We got our answer in less than two hours from Usenet - the Internet was not invented by Al Gore. We replaced the MS TCP/IP stack with a third-party one to get around it. Those were the days of proprietary everything. Solving that problem allowed us to use PPP over InMarSat to send Ice charts and forecasts to Canadian Coast Guard ice breakers and international shipping in the North Atlantic. Cool indeed!
• As my time was winding down at Ice I got asked to write about our design approach as part of a book series that Auerbach Publications of NY ran at the time called the Manager's Handbook series. I had two chapters in the 1995 addendum and the 1996 full book. My first foray into writing. Three-tier architecture? We had designed and implemented an n-tier architecture with services; At the time Gartner was pushing client-server. We really didn't understand why you would want to be so limiting in your thinking on architecture
• A side-bar to this period was that I got exposed to the PMBOK for the first time. As what we were doing was so big, our leadership felt we needed some project management exposure so they hired someone to come in once a week to start educating us on the PMBOK. After about three months of these sessions, I remember looking at the mentor they hired for us, and saying "this stuff is evil!" (sorry PMI...).
• After his initial shock, he asked for my reasons; I responded with "because I can see how this can become the focus and not the thing you are trying to build"...I felt that then, and even more so now. If you look back over the past 25 years, my gut feelings have been validated many times over (not to mention the fact that in V6 of the PMBOK, for the first time, it says that the process areas are not to be seen as stages in a project).
• Not only did the project management deliverables become the focus in many organizations over what was being created (and often still is), what we viewed as the competencies that individuals and teams needed, also became roles and org structures. I was sad when that started, and became even more sad as it got entrenched. Why do we need BA and PM and architecture organizations? Aren't we building solutions in teams? What makes me even sadder? Seeing 20-somethings still being exposed to that kind of thinking. Just like waterfall, can we stop already?
• I think the only reason we were able to do what we did during that period was because we literally did not know any better - we never thought it couldn't be done, we never overburdened ourselves with unnecessary process and project management overhead, we created small teams with purpose and the right competencies, we learned the things we needed to learn when we needed to learn them, we fixed what wasn't working, we sought help outside our team when we needed it, we read...a lot, and we got our hands dirty. Sometimes being relatively young and inexperienced is a great thing as you are not encumbered by experience or doubt. Too bad so many of us lose that as we get older. And even worse, turn the younger ones into the five monkeys.
• After I left the government in the mid-1990's I got exposed to something called the IDEF Standards which refers to a family of modeling languages in the field of systems and software engineering. They were the genesis for information modelling, ER diagramming, and the BPMN stuff we see today. I bring that up, as much of what was intended in the IDEF work got lost over the years; This is especially true in the business process space, where process got confused with work instructions and procedures. It's why so very few business process diagrams are actually process diagrams.
• I started applying the design principles I had learned at Ice Services to business process design. I have since wondered how BP design in general got turned into such a mess over the past 20 years with swim-lane diagrams that occupy whole walls...what went wrong? It was such a simple concept - any more than 7 plus or minus 2 boxes on a process diagram meant you were doing it wrong... near as I can tell, most still do it wrong. And it has turned into a whole industry onto itself. Really, it's only something you do because you are doing something else (as most of these things are). It should not be a thing by itself!
• In the mid-1990's I learned about benefits realization and outcomes management. Unfortunately, when it got introduced to our federal government it became the brick that had to be created in order to get money for major-capital projects. I was at DMR (later Amdahl and finally Fujitsu) when they helped TBS set it up. At the same time as this, I also got exposed to JRP/JAD/RAD which was "rad" for a lot of people at the time, but for me was more of the same kind of thinking as we had done at Ice. As a result of both exposures, I started thinking about combing the two. I liked the start-at-the-end thinking of outcomes, and the iterative and incremental approach of building things. I didn't get to do both together for a number of years.
• In 1997 I was asked to work on the Y2K problem that everyone believed was the impending doom. I declined as I did not want to dedicate 3 years of my life to something that had no life after January 1, 2000. I had already started living what I thought the future of software would be, and I had no desire to go backwards. Lot's of my contemporaries made lots of money...and set their careers back years. My final poke at the craziness that was Y2K was to get married on January 1, 2000 - we figured if the world was going to end at least we had each other. And besides, now I can never forget how many years we have been married. What year is it?
• In 1998 I was doing what amounted to Lean (had not heard it was called Lean until years later...). We had to figure out how to improve our OEM procurement process. I guess we did a pretty good job of getting the non-value-add parts out as we saved the company $25M USD/quarter on their OEM purchases
• In 1999 I got to work on the worlds first web-enabled supply chain funded by 7 major telecom and electronics manufacturers. Recognizing that supply chains run hundreds of suppliers deep, we developed a business capability release strategy instead of a software release one. That business capabilities matter most of all, is what stuck with me ever since. We worked on the early versions of XML (a variant of SGML)...it allowed the big guys like IBM to seamlessly communicate in a supply chain with the small mom-and-pop shops. What resulted became E2Open, which still exists today

2000-present

• After that I got to go to a start-up that was later sold to PayPal for around $900M - I only lasted 6 months before the Canadian side was shut down. It was a micro-payments solution and what was interesting in that one was being able to get new fully-tested releases out every 30 days - this was 2000-2001 so around the same time as the Agile Manifesto was being penned. We had an amazing team of 35 or so developers, architects, and testers that split into 4 or 5 different product teams who worked as one on the micro-payments solution. This was well before most people were talking about scrum or agile at scale. We did it already - though for a too-short period of time.
• Most of the early 2000's was pretty nondescript, though I did get to work with our Treasury Board on XML Standards and Taxonomies as part of the BTEP work in 2003. This was the period of Zachman and TOGAF, rampant ITIL, the PMBOK and eventually the BABOK in corporate and government IT. I spent the 2006-2009 period mostly in the ITIL space and back on the Ops side. I noticed that the more of these frameworks and methods that got added to the fray, the worse the delivery timelines became and the bigger the failures became. Gee, I wonder why?
• In 2009-2010 I had the good fortune (good fortune has happened to me a lot throughout my work life...) to be asked to do an agile procurement for a crown agency. I was hired to "procure and implement a Learning Management System". I used the opportunity as my first real chance to combine agile thinking with an outcomes focus. We started with asking a lot of why questions - this allowed us to work backwards from the business results to be achieved as we figured out where we would need to start (I have since learned this is called back-casting instead of forecasting). Counter-intuitive but completely logical. We were to use Scrum as our approach
• We used a variant of the business-model canvas that I called the Service Canvas to help the internal business group document their existing services to the rest of the business. We then used the same canvas to design the new services they would need to offer. This is how we figured out the answers to our other questions; What kinds of new business capabilities do we need to create? What kinds of tools (beyond the LMS) do we need to support those capabilities? What processes do we need to design and put in place? What's the right way to organize the teams for delivering these new services using these new tools and processes? What are the competencies they will need? Etc.
• The result of our work was astonishing - at least to me. We spent 2.5% of our original budget for the LMS procurement (yes you read that correctly), we stayed within the original 18 month timeline, and within the original overall budget; Yet, we delivered about 4-5 times the originally intended business value. We issued a 10-page RFP for the LMS and had a decision on the winning vendor within a 5-day window. The fellow in charge of procurement for the agency said we had run the best procurement he had ever seen. And we had stayed within Treasury Board guidelines at the time for a procurement.
• So why did it work? The primary reason was we had both the business and IT teams focusing on the same outcomes and working collaboratively towards them. The teams were also the ones who figured how they need to be re-organize and designed the processes they would need. I think another major factor, was that much like back in the Ice Services days, we kept the overhead to a minimum and sorted out our issues together as a team as they arose. We were also able to ask the hard questions and get them resolved. For example, IT architecture was against the chosen product as it ran on Windows instead of the "standard" of Unix. When we asked whether an "IT standard" ought to trump business need, which would have meant spending the other 98.5% of that part of the budget, we won the day. It might not be magic, but it truly is magical when it works
• Using the outcomes map we developed, we got to see how the projects that were identified would fit together in a portfolio. Each project was purpose-defined to contribute to specific outcomes. It also helped us visualize their sequence for delivery. It opened my eyes about what portfolios and programs ought to be versus what they often are - a grouping of unrelated projects organized by business line. Our projects had purpose with specific identified results they would help deliver on
• Based on that experience, in the fall of 2010 I prepared and delivered what I think was the first ever class anywhere on Business Value Management at BA World in Toronto. It kind of crystallized everything I had learned up to that point. To illustrate what had happened in the IT industry over the previous 25 years since DoD-2167A, in the first part of the course I put TOGAF, ITIL, the PMBOK and BABOK and a few others into a medicine cabinet as labelled them as the "drugs" that the IT industry pushes to overcome the symptoms of project failures. I postulated that we needed to stop using the IT drugs...and go to root cause by starting with the results we want to achieve and work backwards. Start with intent
• In January 2013 I got to participate in a Leadership Leaning Path as part of ICAgile in Boulder CO. This led to the opportunity to significantly influence the focus on Outcomes in their Business Value learning track using content from my course that I delivered in 2010 (the Business Value learning track has since morphed into a Business Agility learning track). It also indirectly influenced the Value portion of the PMI-ACP via the lead for the Business Value learning track who also contributed to the PMI-ACP
• In 2013 I helped a little bit with the Gatineau-Ottawa Agile Tour (GOAT) where David Marquet spoke about intent-based leadership. It fits quite nicely with starting from intent (outcomes/results) to determine what we need to work on when. Believe it or not, there is neurosciences behind that approach - the Reticular Activating System in the brain helps us focus on what we value most which happens to be the things we set as our goals or intent. It then filters out the things that don't matter to us and filters in the things that do. In other words it makes us more likely to achieve the things we set our intent on.
• So starting at end, and back-casting to the present, makes it far more likely that you and your team will achieve what it sets out to do and also make it far more likely you won't focus on things that are not related to that intent. Creating visual maps further enhance the RASs focus on achieving it. Now that's cool science that can help us do better at delivering results that matter
• Over the past 4 or 5 years I have been mostly focused on agility and adaptability in my work, writing books (three so far with another one in progress), teaching, and presentations.

As William Gibson said "the future is already here - it's just not evenly distributed yet".

For those who may think all of this agile stuff is new because it's your first exposure - it isn't. If you think it's only about software or product development. It isn't that either. For those who think it refers to the period AAM (after the Manifesto for Agile Software Development) - it doesn't. It was made possible by some very leading-edge thinkers over 30 years ago...people like Ed Yourdon, Peter Coad, Rebecca-Wirfs Brock, Barry Boehm and others before them like Winston Royce and W. Edwards Deming. We all build on what came before. We should remember that.

Over the past 40 years, I got to be like Forest Gump, and be present at the different stages of this still evolving thinking, and make it part of me and what I do. It`s been a blast. It still makes we want to keep being a part of it.

What do I see looking ahead? The same thing I concluded in Agile Value Delivery: Beyond the Numbers in 2015 - that in the not too distant future, we will stop talking about agile as "a thing".

The reason? Because as humans we are naturally adaptable. Once we simply recognize the inherent nature of our adaptability, we can stop trying to put unnecessary structure and process around ourselves. Once we learn to do that, we become agile by default.

Here's to the next 40!

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

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