So far on Alexandra Chapman’s Path to Enlightenment (and Desired Outcomes), she’s discussed the invisible mental models that drive how we do projects (Part 1), and the need to shift to Outcomes as the model for the end of a project (Part 2). In Part 3, it’s time to muse on the past and how it shapes the future through Path Dependency. Perhaps, you too will have an epiphany?
Epiphany is an “Aha!” moment when a character is suddenly struck with a life-changing realisation which changes the rest of the story. Often, an epiphany begins with a small, everyday occurrence or experience.
Let’s start by summarising our journey so far.
For most projects, what the business does not want is a Turnkey deliverable ready to “turn on”. Rather, what the business does want are Desired Outcomes:
The future business-as-usual operational environment when it is working “just right” (or “well” or “well enough”)
We carefully craft Desired Outcome statements so that everyone is clear about what the future looks like. These statements define the overall Desired Business Outcomes, and the subset that the project is to deliver before the business then takes over to deliver the remainder of the outcomes.
We laid out some principles for how to craft outcome statement in Part 2 so that they clearly
answer the question “what do we intend to achieve?
The new measures of project success
Now we are able to articulate what we intend to achieve out of the project – Desired Outcomes, Benefits and Measurable Value – we can change the mental model of how to measure success for our project:
Success – is measured by delivery of the agreed outcomes, benefits and value (for an acceptable cost and time)
Another mental model inherited from construction is to measure project success by the traditional Iron Triangle – cost, time and specification. When we use these measures to control the project, not only are we are looking in the rear-view window, we are also measuring success by the inputs to a project, which when you think about it, is absurd. Or dumb. Maybe both.
It’s a bit like building your new dream home and once you have moved in, celebrating success because, “we used all the bricks and timber we bought, and it matches the drawings exactly.” Instead, intuitively, we know we are successful when we achieve our desired outcomes.
“Our new house is a real home and will meet our life needs for many years:
– My partner & I can relax, unwind and enjoy being with our family,
– We have space to care for our elderly parents,
– The kids and all their friends have space to play and be noisy.”
The reason why historically we have used time and cost as a measure of success is that for construction projects, these measures are a reasonable proxy for the successful completion of the project.
For a new road, or a multi-story building, most of the outcomes, benefits and value are realised once construction is complete, and you drive down the road or move into the new building. If ten out of twenty miles of road are laid, and the project has used around 50% of the materials estimated, that is a good indication that you are likely to finish the rest of the road within the plan and not overrun.
And the reason why controlling the inputs is so important is because, while project managers cannot create value if it was never there in the project in the first place, they can destroy value and investment returns if the project overruns.
Indeed, one of the things that TOP teaches is
“No hero, guru or project manager can save a project that is ill-conceived, miss-conceived or just plain dumb, which btw describes far too many, if not most projects.”
So, finishing to the predicted (and the predictable) time, cost and specification is critical and the reason why it is crucial to monitor them. But per our new mental model for measuring success, cost is now the servant, not the master.
And so we come to Critical Path; another mental model adopted from construction project management.
What is Critical Path
Critical Path is such a fundamental term in the project lexicon that it has now crossed over to become commonplace in non-project domains. At the risk of teaching you all how to suck eggs, let’s start with a definition.
A critical path – is determined by identifying the longest stretch of dependent activities and measuring the time required to complete them from start to finish.
The critical path of the project determines how long the project will take to finish. Project activities are linked in a network of parallel or sequential activities with start and finish dates to calculate the project completion date. The activities that determine the completion date are said to be “on the critical path”, and it changes as tasks are completed early, late or on time. That is, the critical path is dynamic.
For construction projects, managing the critical path is, well, critical!
It’s part of the essential modus operandi for project managers. If the concrete pour on the slab is late, the columns for the next floor will be delayed and so on. The aim is to make continuous adjustments to avoid a cascading late delivery. With the advent of PC-based project management tools, managing the critical path became far easier:
- tracking how the critical path moved as dates and resources altered;
- modelling how to add resources to decrease the time taken; and
- managing the consequences of any slippage etc.
However, construction projects differ from other types of projects such as software projects and business transformations in a crucial way.
The start-to-end constraints for completing tasks that drive construction projects are far less important in other project types. Indeed, for most of the projects that I have worked on in my career, one could tackle 90% of the tasks simultaneously, and one could work on most of the tasks in any order. So critical path is not nearly as important for these types of projects.
But something else is important:
- High performing project managers intuitively know that there is a best sequence to work on tasks, that makes the project easier to deliver and progress more visible and attainable. They mull over what is to be completed and work out that “once this bit is working just right, “then that bit will be easier” and “then this bit will be a piece of cake. So, while tasks could be undertaken in any order, they are sequenced in the best order based on the project manager’s expertise.
- Decisions have consequences, and yet frequently decisions are made on projects which lead the project in the wrong direction and the only way to correct them may result in backtracking to get to the right direction. Indeed, it is the quality of the decision making by business and technical leadership which distinguishes all the most successful projects from the also-rans.
In 2012, I was reading one of the best economic newsletters in the world from John Mauldin (free and I can highly recommend it), for the first time that I came across the term “path dependency”.
As I read about the concept, which I already knew of intuitively, I had my epiphany. “Path Dependency” was the term I needed to explain to executives and project professionals, why “the right decisions” and “the right sequence” are so important for project success.
What is Path Dependence
Path Dependence – explains how the set of decisions and options possible at any point and for any given circumstance is limited by the decisions one has made in the past, even though past circumstances may no longer be relevant.”
Path Dependency is a concept tacitly understood by most people. Each decision either opens up options or closes them down. Every decision you make determines what you can and cannot do, both now and in the future. Where you are today on any project is the cumulative result of a series of decisions. Each of the path-dependent decisions locks your project into a future where you either can or cannot ever get to where you intend to go.
Implicitly, we know when we are trying to get to a destination, there is a right (or wrong) place to start the journey from.
The informal definition of path dependency
That Famous Irish Joke
A tourist asks one of the locals for directions to Dublin.
The Irishman replies: ‘Well Sir if I were going to Dublin, I wouldn’t be starting from here.’
A neat example of path dependency in daily life is your choice of smartphone. This thought-provoking article here explains what they have in common with pesticides. Another fun example of path dependency explains why a horse’s arse determined the dimensions of the space shuttle booster rockets.
Managing path dependency
When Path Dependency is clearly understood, documented and managed, we make far better decisions. The Project Governance team can thoroughly think through each decision in terms of the longer-term impacts before making it.
A company was constructing a new quarry. One of the outcomes in the business case referred to “lowest-cost supply to the metropolitan market”. One of the deliverables specified the rail line to be constructed to transport gravel from the quarry.
The project was just about to commence constructing the rail line when the Steering Committee noted that the route chosen for the rail line, while the cheapest to build, was steeper. A quick re-assessment confirmed it would not be the lowest cost to operate. Once built, the siting of the rail line would be practically impossible to alter.
The Steering committee decided to spend a little more to reroute the line so that it would be the cheapest to operate over the 50-year life of the quarry. Incidentally, as the rail line construction was on the critical path, this change increased both the time and cost of the project.
But the Steering Committee made the change confident that it would deliver the project’s “lowest cost to operate” desired outcomes.
In the case above, guided by achieving the outcomes, the Steering committee made a conscious decision to change the rail line, knowing that it would cause the project to overrun on time and budget. By the standard measures of project success, this project would be deemed a failure, and yet it delivered what was important to the business and was considered to be a resounding success.
When simplistic decisions are made without taking account of path dependency (e.g. “just reduce this item”), we can cause massive value destruction. Sometimes, a decision will be made, and due to the path-dependent implications, the project will never be able to deliver what is intended. It would be better to stop the project altogether.
Path dependency also changes the mental model for how we should assess scope changes. Now, we evaluate them, not just for their impact on the project’s time and cost, but also on “what path-dependent impacts will this change have on the project’s ability to deliver the outcomes”?
Creating an outcomes Path dependency Roadmap and narrative
Once you have crafted your outcome statements, you can link them into a simple diagram to show how the outcomes will be realised over time. This example below shows how a bottom-up minor improvement turned into a major strategic transformation project for a retail bank.
Once you have drawn the roadmap, you can “hop” from outcome to outcome to create a story of how the future will be realised. One of the things that such a roadmap makes clear is that, while you could work on most of the outcomes shown, starting in the lower left and getting traction on those outcomes creates a momentum that makes the whole project easier and delivers outcomes earlier.
Unlike Critical Path, the journey to the future doesn’t change by throwing resources at the project. Indeed, sometimes a much smaller team, highly focused on early outcomes can be far more effective.
A few paragraphs excerpted from the Roadmap Narrative that was crafted to support the map
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…”
When we have one complete accurate central and timely “source of truth” for signature and authority data (1), this enables us to simplify and standardise all the processes which use this information (2), which then makes it easier and less costly to make changes to systems to provide access to authority information to the staff who need it(5).
If we don’t simplify and standardise the processes in the branches and TPC (2), then it will still be possible to make the system changes to provide the online access, but it will most likely cost more simply because there will be more process and transaction variants to change (5).
So, to be able to welcome all customers with the same consistent, fast, professional service (8)
- We need staff to be able to quickly and easily check signatures in the background (6)
- And we need a single cheque encashment process, for all accounts, and to eliminate the parent/ non-parent branch processes (3)
- And we need to be able to reallocate wasted time in the branches to the identification of customer needs, or other value-adding activities (7).
Creating an Outcomes Path Dependency roadmap:
- Shows you where to start and where to focus your initial efforts
- Provides a delivery sequence to a list of outcomes
- Validates the logic and completeness of the outcomes
- Validates the correctness of the outcomes
- Enables value optimisation as it shows the consequential impacts of any proposed changes
- Demonstrates benefits delivery prerequisites and when they can be delivered
- Enables effective scope and decision management at the governance level
- Provides an immediate answer to “What is this project all about?”
The narrative turns the Path Dependency roadmap into a story. The narrative:
- validates the logic of the roadmap – does it make sense?
- can work forwards saying, “Because we have…, then we can…”, or
- Can work backwards saying, “In order to…we need to have…”
- Can also explain more clearly a “the do-nothing” option.
Together, the Outcome Path Dependency Roadmap and its supporting narrative communicate the story of what the project intends to achieve and how the future will be realised over time. The roadmap and the narrative also make clear to everyone what the journey will look like and where we are now. It gives those independent of the project a quick understanding of what the project is all about, what it will deliver and how.
Finally, the single page of the roadmap and one-to-three pages of the narrative become the shareable artefacts that enable the organisation to shift from tacit (implicit) to explicit (codified) knowledge.
Now, everyone is literally on the same page.
In the next post
We will discuss hierarchical decomposition as a discovery mechanism for working out how to execute the project. We will talk about why the idea of taking a big thing and breaking it into little things to work out how to build it works really well for buildings and roads, but not so well when you are creating business processes or implementing new products.
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.