Thus far on our Path to Enlightenment (and Desired Outcomes), Alexandra Chapman has discussed the invisible mental models which drive our current project methods in Part 1. In Part 2, she argued the need to shift to an Outcomes delivery model for projects. In Part 3 we discovered how path-dependent decisions made in the past shape our future options. Now it’s time to investigate the hierarchical decomposition thinking processes we use to discover the unknown future and then deliver it.
Hierarchical decomposition is a fundamental model in project delivery
The concept of hierarchical decomposition is another mental model that we have inherited from projects. Indeed, a search will bring up all sorts of scholarly articles on the subject. Hierarchical decomposition underpins another fundamental project model – the work breakdown structure.
“A WBS . . . is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organises and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the project work.” PMI Learning Library
For construction projects, hierarchical decomposition is a tried-and-tested approach that works well.
Once you have set the outside parameters for the project you are building, you can then decompose each component into smaller and smaller pieces until you have covered all the dimensions of the project. This approach makes it easy to design, quantify, estimate and then schedule the build. The discovery process in the design phase means that as you go down into the detail, document what you are building and then plan out how to build it, each element becomes clearer. You can also start building the major elements while making provision for some elements for which you complete the detailed design later.
The reason why hierarchical decomposition works so well for the design and construction of physical assets is that, by their very nature, once you have made one decision or choice, the next available choices or options are inherently limited. For example, if you decide to build a multi-story office building, the very first decisions made, e.g., reinforced concrete, the number of stories, size of the floorplate, ceiling height, then limit the other choices that are possible.
Early attempts at a new model for strategy execution
The same hierarchal mental model is also the basis of many strategy execution methods. The strategy-to-projects-to-results process is often depicted as a linear sequential process. You do step one, then step two and then step three, and so on. Within a step, items are ‘decomposed’ into their constituent parts for development, so that they can be assembled to deliver the desired result.
However, TOP’s early work on strategy execution in the 1990s with major organisations made clear that what worked in theory, did not work in practice.
In 2004, I attempted to create a diagram to outline a slightly different model for what happens when you define a transformation plan for an organisation. (I present it “unvarnished” so you can laugh!)
For projects such as business change projects and major software implementations, the discovery process was visualised as more complex than the hierarchical top-down decomposition process used in construction projects. For these projects, when you got down into the detail, you would discover that some big-picture decisions did not work, and these would then need to be revised. (Note, I accept that this rework does happen somewhat for construction projects, but not quite to the same degree.)
Effectively this diagram represented the idea that you start with the big picture and then go down into the detail. And that you iterate from top-to-bottom, and then bottom-to-top multiple times before you finally get to the level of clarity you are seeking. Iterations were a standard part of the process.
Nice and tidy so far?
But then I thought, in real life, with major transformation and IT software projects, there can be far more backtracking on work already completed. As you switch from overview to detail and back, you change your mind, discover things that don’t quite fit. You discard some elements entirely and go back to first base reworking both the big picture and the detail.
So, I created a slightly amended version of the diagram to represent this. (Ok, I’ll admit this is still embarrassing.)
However, as anyone who has ever designed a wireframe for an app, or indeed, redesigned their kitchen knows, what really happens is that you start with an idea, work down to the nth detail and then find you cannot make the big-picture work. So, you scrap that concept, start again, work down into the detail, rinse-and-repeat.
So, what the real-life process looks like is this.
Construction projects work with hard technology and materials to produce something physical. Business transformation projects and software projects are different in that they create non-physical things such as processes, organisational structures, software etc.
But there is another reason why hierarchical decomposition and Work Break Down do not work so well for business transformation projects and software projects.
It all comes down to differing levels of degrees of freedom.
Degrees of freedom and why it matters
The degree to which our choices are limited by other choices already made is described by the mathematical concept of “degrees of freedom”.
The formal definition of Degrees of Freedom:
. . . refers to the number of values in a study that are free to vary.
Let us use the age-old problem of odd socks to gain a practical understanding of degrees of freedom and how reducing it makes things simpler.
Many years ago, a lady got married. She gained not only a wonderful husband but also three strapping stepsons and vast quantities of odd socks. Determined to be a good step-mum, she spent Sunday evenings in front of the TV, like Sisyphus, matching socks.
To speed the matching process, she reduced the degrees of freedom by first sorting socks by colour, as once a black sock was chosen, the next possible choice to find its mate could only be from the black pile.
But a better solution was needed. The desired outcomes defined were “to eliminate forever the need to match socks, ensure that everyone always had the socks they needed for school or sport, and all were happy with their socks.” Luckily, all boys had the same size feet.
The solution? Donate all existing socks and replace with 15 pairs of four types of exactly the same socks: black, brown, white and footy. Washed socks were placed loose in four tubs in a central location so the boys could grab them as needed. Socks were never matched again!
In the above example, reducing degrees of freedom simplified the sock problem out of existence.
For construction projects, it is the comparatively fewer degrees of freedom that enables hierarchical decomposition to work. Inherently, as construction projects progress from start to finish:
- The options for the design and the build reduce as each major decision is made, i.e., choose reinforced concrete and eliminate structural steel as an option.
- The amount of work-to-complete reduces during the design discovery phase, as each element of the hierarchy is decomposed and detailed.
- The planning of the build to physical constraints automatically defines the sequence of tasks.
However, for most strategic initiatives or business change projects, the degrees of freedom – options and choices – are far greater in the early stages and remain that way for far longer. Almost all of “this” will go with “that”.
For a business transformation project:
- The discovery process evolves slowly at first as initially, many options seem plausible. It is only after you have done enough iterations into the detail you can see the big-picture elements clearly enough for options to be eliminated. You may abandon many big-picture options in the early stages after detailed analysis. There finally comes an “aha” moment when things seem simpler.
- During the design phase, there may be too little clarity about some options for you to decompose that element. You may have to move forward with “unknown unknowns”.
- The order with which you schedule and undertake tasks has so few start-to-end constraints that theoretically, you could do most tasks in any sequence. So, working out how best to sequence the project tasks and schedule requires a different approach.
Hierarchical Decomposition and Work Breakdown are not much help. We need to add some new mental models to wrap around these approaches. We need:
- A new model for thinking through ideas so that you can get them from concept to realisation.
- A new model for discovering all the change activities required to execute the idea and bring it into reality.
- A new model for sequencing the change activities to maximise the perceived progress and results and which allows you to start work even when you don’t have all the answers.
What do we need to do?
1. Adopt a fractal thinking process and mindset.
“Fractals are infinitely complex patterns that are self-similar across different scales. They are created by repeating a simple process over and over in an ongoing feedback loop.”
Fractal thinking is an iterative approach, where you work through a step-by-step analysis at the overview level and then repeat it at a more detailed level, seeking alignment (and mismatches) between overview and detail.
With fractal thinking, you work top-down and bottom-up through many rapid cycles. The first pass down can be similar to hierarchical decomposition. However, it differs from it in one key aspect.
With fractal thinking, your aim is not to think through the “whole project” to the same degree at the very beginning. You focus consciously on the most important areas, as these set the boundaries for all other choices and decisions. You aim to discover:
“What are the critical areas that we must get right for this idea or project to work?” and,
“What do we need to know so we can move forward? Do we scrap the idea or move it to the next stage?”
After several iterations from overview to detail and back again, you may abandon some elements, even go back to the drawing board. Once the big picture and the detail aligns, you will have eliminated choices/ options that initially seemed viable. You can then use hierarchical decomposition as the final pass for completeness.
The fractal thinking process looks a bit like this:
Defining the Desired Outcomes is a fractal process.
For all projects, regardless of size, framing the Desired Outcomes statements and then planning how to deliver them is a fractal process. It oscillates between the big picture and the detail, and you also go backwards and forward. Gradually clarity and precision come as you rework previous efforts. The techniques used and the questions asked are the same regardless of whether you are working at the strategic level or the to-do list level.
Usually, it takes about 12 iterations over around 21 days to craft a clear set of outcome statements. Some of the outcome statements will survive through the iterations from 1 to 12, and some will change profoundly. Once you have drafted a version of the outcome statements, you can then use these to draft the path dependency roadmap to show the relationship between the outcomes; the narrative then explains and tells the story in more detail.
In Part 3, we showed you an example of an Outcomes Path Dependency Roadmap. That project was an example of how the fractal thinking resulted in a relatively small IT systems upgrade becoming the trigger for a major transformation of operation of the retail branch network:
In 2005, the banker asked for help with the business case, because she was struggling to justify the cost of implementing a new way to verify signature and authority checks at the teller counter; the value of the time saved did not justify the upgrade costs. One of the outcomes defined was:
“5. All staff who require it have online access to up-to-date signatures and authorities for all their accounts from their desktop.”
After applying the fractal thinking process, the Ahaa was “we can use this to transform the way customers bank with us, so they bank with the bank rather than with a home branch”. This was a significant competitive opportunity.
Using fractal thinking does not replace hierarchical decomposition. You can and should do both. The value comes when you compare and contrast the insights from both perspectives.
The mindset change to fractal thinking comes when you adapt all the project processes for all phases of the project to use the same iterative discovery process.
2. Reverse-engineer outcomes to identify change activities
To deliver outcomes, you need to identify all the activities required. For that, you supplement the standard Work Break Down planning processes with outcomes planning techniques. The Reverse Engineering process uses the same fractal thinking concepts to work from overview to detail in multiple iterations. It looks like this.
The process starts with the draft Desired Outcome statements. You then document a very detailed definition of what the current state is, “warts and all”. By describing the current state in meticulous detail, it forces you to consider small and large things that would otherwise be overlooked by the normal hierarchical planning process. Then you walk backwards – from the future to now – asking the questions:
- What do we need to do to implement?
- What do we need to do to prepare?
- What don’t we know that we need to clarify? And finally,
- What do we need to make the change sticky and sustain it?
Each iteration of the Reverse Engineering process will cause you to refine the outcomes statements, the path dependency roadmap and the narrative. Each iteration of the Outcome statements will highlight new change activities. The aim is to identify all of the change activities that are required to deliver each outcome.
Then the standard project management processes to build the schedule take over. The list of activities generated by the Reverse Engineering process will be much more “messy” in terms of content and granularity compared to that produced by the more traditional hierarchical discovery process. They will need more sifting, sorting and grouping to create logical packets of work.
The patterns you see in the activities produced by Reverse Engineering can give clues as to the best project approach. In the earlier bank example, there were a large number of “clarify” activities. These made clear that far more investigation was needed before the project could get underway.
3. Use Path Dependency to sequence the delivery
For many transformation projects, there are few start-to-end constraints to determine how to define the schedule. However, when you examine how high performing project managers establish a project schedule, you can see that these PMs “know” that there is a way of ordering the project such that “once this is working just right’ then “that becomes easier” and so on. You see they have intuitively applied path dependency concepts to schedule the project even though they may never formally have been aware of the concept.
Once you know how to define outcomes and a Path Dependency Roadmap, you can use these to supplement the standard approaches of WBS and start-to-end scheduling of tasks.
When projects are intentionally planned this way, the successful delivery of early outcomes can deliver “quick wins” that can make a material difference to the project and reinforce the momentum for change.
In our earlier bank example, the Path Dependency Roadmap was used to set the overall strategy for the project. These were the first few outcomes from that roadmap.
Reverse Engineering the outcomes produced so many “clarify” activities and “unknown unknowns” that, as the narrative explained;
Getting the “single source of truth” is so essential to the value proposition for this project, that if we can’t achieve it cost-effectively and reasonably quickly, there is no point in undertaking any major re-organisation of how the branches operate or undertaking any changes to processes or systems. Without it, this project falls into the category of “nice idea but…”
The bank decided to run a “Proof of Concept” project over a short period with two to three representative branches to test out the feasibility of delivering these five outcomes. From the learnings, the bank would gain solid information to assess if the larger project to transform hundreds of branches was viable. They would also have accurate data to support estimates and the value calculations and would be able to create a repeatable model for converting each branch to the new world.
In Part 5, the final post…
We will take stock of all the project mental models we have discussed so far and summarise what needs to change for projects to deliver value.
Is Co-founder and co-creator at Totally Optimized Projects. Her mission is “to leave a legacy of tools for clear thinking and for solving complex problems, and to see TOP adopted as a global movement.”
Early in her career in the 1980s, she was an IT Projects guru implementing enormous banking software packages for Australian and UK banks. Profoundly frustrated at the way the IT-centric way projects were undertaken, she switched to strategy execution in 1988 after completing an MBA at Cranfield School of Management.
In 2007, she sketched the first version of the Value Equation™ diagram on a whiteboard.