In The Path to Enlightenment (and Desired Outcomes), Alexandra Chapman discussed the importance of mental models, and proposed the idea that mental models we have adopted from construction projects have significantly impacted how we undertake projects of other kinds, not necessarily for the better. She now picks up the theme with the second of her posts.


As we are on the path to enlightenment, perhaps we should start with a definition of that word.

Enlightenment means the act of enlightening or the state of being enlightened.

Helpful? Not really. The problem is that there are some terms – like “enlightenment”, where the definition doesn’t enlighten you much. You need to see the word used in context.

A similar issue exists with the word getting lots of attention in project circles – “Outcomes”. While “Outcomes” are the flavour of the month in discussions on everything from:

  • new models of project delivery, to
  • new roles for project managers, to
  • remediating issues caused because projects lack clear outcomes

you could put twenty people in a room, and they would all earnestly debate how important “outcomes” are to project success. Yet, they would all be talking about entirely different things because the word doesn’t mean the same to everyone.

We need to provide both context and a definition to define the meaning of “outcome”. We will do that in this post.

When does a project end?

Let me start with context by telling you a story from 1995. I was developing an IT strategy for the Australian operations of a US $7billion engineering company. In a conversation with the IT manager, he mentioned that:

“Of course, our delivery model [for building iron-ore mines] is very different from most because we do EPCMO rather than Turnkey”.

dominik-vanyi-Mk2ls9UBO2E-unsplash_editedHe went on to explain that in “Engineer, Procure, Construct, Manage and Operate” that they would build (dig?) the iron ore mine and then operate it for a period. They would then hand it over to the client as a fully operational site when it reached the agreed level of performance, for example, so many tonnes per day.  

EPCMO seemed natural to me because that was what I had been doing in my early career in the bank. Indeed, there was no other model. As IT people, we worked closely with the bankers, delivered new customer products and moved them into production. (Don’t worry, we were not perfect in those days, we just had a set of very different problems).

In the time before Agile, we had agile (with a little “a”)

In 1982, the General Manager Banking wanted to introduce different service charges for different types of customers. After weeks of discussions, she was frustrated dealing with the newly appointed PM looking after the Hogan banking package. He was herding her down the bank’s freshly adopted waterfall development pathway: feasibility, requirements, business case, project etc. for a project to “turn on” the specialist pricing module the bank was not yet using. That would have taken at least a year, so she came to see me.

I spent an hour asking questions about the types of service charges she wanted, the formulas and pricing tiers and so on. With my knowledge of the package and retail banking operations, acquired by working so closely with the bankers, I said, “you don’t need the pricing module if we give you Option-A, but if you want Option-B, then you will”. I explained Option-A could be implemented with a few new entries in an existing parameter table, would take about 30 mins to set up and about a day to test.” The GM was happy to trade a few bells and whistles to get a faster implementation, as that was “good enough for what the bank needs right now.” Note, the GM Banking was effectively acting in the role we now call product manager.

What is the Turnkey model?

Hearing the contrast between the project endpoint described for EPCMO and Turnkey was the first time that I became conscious that there were different models for when a project should end!

What is Turnkey? The name comes because it describes a project where “the customer, upon receiving the product, just needs to turn the ignition key to make it operational, or that the key just needs to be turned over to the customer”.

For Turnkey, the end-of-the-project is something ready to turn on but not yet operating. Then the business takes over to create an operational business-as-usual environment out of it. There is a variant of Turnkey – “build to order” – with a similar handover process.

For relatively simple projects and for most construction projects, the level of effort between “ready to turn-on” and “fully operational to an agreed level of performance” can be quite minor. The road is built; you cut the ribbon and drive down it. The building gets built; you get the keys and move in.

If you think back to the dawn of the personal computer era, you may recall that the hardware came in a brett-jordan-DbfAMPWyzUw-unsplash_editedbox, you had to unpack it and then spend about a day loading the operating system onto it with floppy disks.

The hardware and software were the Turnkey deliverables. By the end of the day, with a great deal of luck, you finally had what you intended when you bought it – a working personal computer you used to write documents, build spreadsheets and so on. You got your desired outcomes.

At some point, the suppliers had the lightbulb moment as to what their customers really wanted and provided PCs ready-to-use out of the box.

Remember too, this era from the ‘80s was the start of the packaged software environment, where instead of developing applications in-house, with all the attendant skills, issues and risks, organisations started to buy-in a solution. The nonsense mantras of that era were “use the software vanilla” and “change the business to suit the software”. The ‘80s was also the period where the big accounting firms moved into IT services to deliver software solutions. So, they wanted a neat project endpoint where they could deliver on their contract and then “get the hell outta there”.

And that is how the Turnkey model came to be adopted.

The big explosion

What became apparent very early on, is that turning over an ERP system as a turnkey project is not at all like handing over a building or a bridge.

There is a massive difference in workload required to move from an installed software package to an operational asset, which is what the business actually wants. Naively, business managers thought they would just start using the software. Instead, they found was it was not easy to achieve a properly operational function – Finance, Accounts Payable and Receivable etc. The assumption was, once the staff were trained in the system, they would just “know” how to do their work.  In fact, the new software triggered the need to build new processes, a specialist skill the business lacked.

I describe this as “the big explosion” project delivery model. The end of the project would come, there would be a handover or post-implementation period, then the project team would disband (or continue on to do everything that had been thrown into Phase 2). The business areas would be left to try and get their environment working again. Sometimes that could take months or even years.

One Utility client we worked with some years ago was left, after the big-name project team handed over, with an operational environment that simply did not function. There was so little trust in the GIS asset data the field staff felt unsafe maintaining the power grid. It took three months to work out an approach to fix the mess and nearly a year to implement it. Outcomes around “trusted data” were the start of the journey.

Figure 1















To address this handover issue, the big services firms moved into “Change Management”, bolting on change readiness surveys, training and job function reorganisation, policy and procedures.

The negative consequences of the Turnkey model

Just a few of the negative consequences of the Turnkey project model include:

“Change” was seen as a separate stream, rather than part of the project. Implementation in the business areas was not coordinated by the PM, and often not costed as part of the project
Benefits and value realisation were seen as happening post-project, rather than something that could commence from the day the idea was conceived. In many cases, improvements in the business could be realised even while the systems work was underway. We have seen projects where early banking of benefits paid for the whole project
Process design of the end-to-end process, including all the steps that flowed between staff and the system, simply was never done. Broken processes left the business hiring excess staff to cope with the overload while overstretched managers attempted to fix processes on the fly.
There was no clear mechanism for working out the Minimum Viable Product to operate. Requirements would be moved to “Phase 2” without any understanding of the likely impact on the departmental workload. We have seen projects that proudly came in on-time and budget, but where the business areas had to hire an extra 50 staff to cope.

Desired Outcomes as the endpoint for projects

It is pretty apparent to anyone working in the projects domain that the business does NOT want an ERP system! What they really want is working processes underpinned by accurate and timely information and staff who have all they need to do an excellent job serving the customers. That means we need to shift the project endpoint from Turnkey to Desired Outcomes.

Now we have explained the context in which we used “outcomes”, we can create a definition:

Desired Business Outcomes – define the business-as-usual operational environment when it is working just right [1], and answer the question “what do we intend to achieve?”

Project Outcomes – are a subset of the overall Desired Business Outcomes, operating to the level of performance that has been agreed by the business and the project team for it to deliver.

[1] Note depending on the circumstance, “working well” or “working well enough” might also be acceptable.

For many years, we trained executives with one of the biggest brick manufacturers in the world in Project Governance. For this client, we coined a metaphor to explain the difference between Turnkey and Desired Outcomes.

Rather than a “brick making factory”, an Outcomes Project delivers “a factory making bricks” operating to the levels agreed for the project team to handover. The project outcomes are a subset of the overall end business outcomes, e.g. the project may get the factory working to 6000 bricks per week and then, over time, the business will increase this to 12,000 bricks per week.

What changes with the outcomes project model?

The outcomes project model requires a real and effective partnership between the business and project team. For a major project, the outcomes would be defined in the business case and be confirmed between the Sponsor and the Project manager.

When we change the model of the endpoint of a project from “turnkey” to “outcomes”, much changes, for example, it changes how we measure success:

Successis measured by delivery of the agreed outcomes, benefits and value (for an acceptable cost and time)

Figure 2

Other things also change, and we will discuss these in a later post. To mention just a few here:

  • All projects are seen as “change” projects. All activities that are required to deliver the outcomes, benefits and value the project has agreed to deliver are planned and managed by the Project Manager.
  • Outcomes, benefits and value are targeted to be realised as soon as the idea is conceived. That may occur even before the Business Case is finalised.
  • The project delivers working business processes. The process design of the end-to-end process, including all the parts done manually outside the system, becomes a part of the standard delivery tasks.
  • The Minimum Viable Product to operate will be determined by the Desired Outcomes and what is need for the end-to-end processes to operate effectively.
  • All scope changes are assessed for the impact on the Desired Outcomes, positive and negative, rather than being evaluated only against cost and time.

Defining desired outcomes

To deliver outcomes you need to define them. TOP uses the term Desired Outcome for increased precision – because you might get outcomes from a project, but they may not be the ones you want!

Learning how to craft outcomes is quick when you use a few simple techniques. It is a repetitive process, and each iteration will refine the wording. Well-crafted outcome statements move you from fuzzy generalities to clarity and specificity. They also encourage debate, as this example below shows:

One of the nine outcome statements created for a major new bank system. How a single word created a debate…

6. Branch Service Staff can quickly and easily check authorities in the background, without the disruptions of locking up or leaving their desk or having to switch applications. This encourages them to apply checks consistently according to documented bank policy, or even just when they have concerns.

For the outcome statement shown, intense debate and discussion was generated amongst the Executive team over whether the correct word was “enable”, “enforce” or “encourage”. You can appreciate the impact on the system design the different words would make, and the consequential change activities required.  The Executives decided that “encourage” was the appropriate word.

When crafting outcome statements, you can make an excellent start in a morning. Our experience is that after about 21 days of musing, and around ten versions tested on others, you will end up with several carefully crafted statements with which you are reasonably happy. A small project might have approximately eight to ten outcome statements. Recently we worked with on a significant transformation project that had more than thirty.

Principles for Desired Outcome statements

TOP defines principles for crafting Desired Outcome statements. Individually, desired business outcome statements are:

  1. Specific – creating a clear picture in the mind
  2. What you want – i.e. is important to the organisation
  3. Written as a statement of fact – as if they already exist
  4. Written as full sentences
  5. Written in the present, active tense
  6. Measurable by a true/false question – can we or can’t we; do we or don’t we?
  7. Make sense to any reader – i.e. avoids jargon or shorthand
  8. Mean the same to everyone – clear specific and unambiguous. (You have to test this)

Cumulatively the outcome statements:

  1. Cover all dimensions of the project and business that are required to deliver the future
  2. Describe the future states beyond the project’s “go live” to “working”
  3. Describe things when they are working “just right”. Or “well” or “well enough”.

Outcomes statements can be framed at:

  • Project level – Desired Project Outcomes, which are usually a subset of
  • Business level – Desired Business Outcomes, which are usually a subset of
  • Strategic level – Desired Strategic Outcomes.

The statements can be finely granular or describe the big picture.

Finally, when you define outcomes for a construction project, e.g. what does this major new road look like when it is working just right”, it triggers an enjoyable thought process. Try it!

In the next post

We will continue on our Path to Enlightenment by comparing Critical Path, a widely known and well-understood concept, with Path Dependency, which is not a term commonly used in the project lexicon – even though it should be!

We will explore why Path Dependency is far more important than Critical Path for project success.

Alexandra Chapman

Alex Chapman Headshot BWIs 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.

Connect with Alexandra on Linkedin