Finding The Track

FINDING THE TRACK

The Principles That Remain

PROJECTS FAIL. PRINCIPLES DON'T

© 2026 Gavin Mills

All rights reserved.

First edition.

The projects and stories in this book are presented,

for what they reveal about the principles behind them.

DEDICATION

To everyone who has ever taken on a project

that looked impossible from the bottom of the mountain.

To those who found the obstacles.

To those who discovered that the original plan wasn't going to work.

To those who stopped, looked again, found another track

and kept climbing.

And to everyone who has ever reached the top

only to discover there was another mountain waiting.

...And never stopped climbing.

CONTENTS:

01: UNDERSTAND

Before solving a problem, make sure all the problems are fully understood.

02: IDENTIFY

Before solving a problem, identify the constraint.

03: REFRAME

When everyone is looking in the same place... look somewhere else.

04: DISCOVER

When the path doesn't exist... the first responsibility is to discover whether it should.

05: BUILD

Once the purpose is understood... build a system that delivers the desired results consistently.

06: RECOVER

When the unexpected happens... protect the objective.

07: ADAPT

Plans are always vulnerable to reality.

08: EMPOWER

The moment people stop owning the problem... they stop owning the solution.

09: EVOLVE

The principles that work on projects... work on a life.

WHY I WROTE THIS

I've spent most of my adult life making things happen.

Some of them were good.

Some were spectacular.

Some were complete disasters.

Most were somewhere in between.

I've worked in advertising, entertainment, events and communications. I've built things, produced things, directed things and occasionally wondered, usually rather late in the process, what the hell I'd got myself into.

Over more than four decades, I've worked with different clients, different industries, different teams and very different budgets.

And then, with the passing of time, I became aware of something profound...

The problems kept repeating.

Not the projects.

The problems.

A brief that wasn't really understood.

A constraint nobody had noticed.

An assumption everyone had quietly accepted.

A good idea that shouldn't have been built.

A plan that collided with reality.

A team that stopped owning the problem.

And, occasionally, something that looked like an absolute disaster but could still be saved if you stopped worrying about what had gone wrong and concentrated on what was still possible.

I began to realise that I wasn't really learning how to make projects work.

I was learning how to deal with reality.

That distinction matters.

Because projects are temporary.

The client changes.

The budget changes.

The people change.

The technology changes.

The deadline changes.

Sometimes the entire bloody situation changes.

But the underlying problems don't seem to change very much at all.

And neither, I've discovered, do some of the ways of dealing with them.

This book started life as something much more practical.

I wanted to find a better way of explaining what I could actually bring to a conversation than sending someone another CV.

A CV tells you where somebody has worked.

It tells you what they called themselves.

It gives you dates, positions and responsibilities.

It doesn't necessarily tell you how they think when things go wrong.

And after forty years, that seemed to me to be the more interesting question.

So I started pulling together some of the things I'd learned.

Not management theory.

Not a system.

Not ten guaranteed steps to becoming a successful executive.

God knows the world has enough of those.

Just things that had repeatedly proved useful when reality refused to cooperate.

The more I looked, the more I realised that these weren't really lessons about events.

They were lessons about problems.

About understanding before acting.

About finding the thing that is actually stopping you.

About questioning assumptions.

About knowing when to abandon an idea.

About building things that work in the real world.

About recovering when they don't.

About adapting when reality changes the rules.

And about giving people enough ownership to actually solve the problems in front of them.

Nine principles emerged.

UNDERSTAND. IDENTIFY. REFRAME. DISCOVER. BUILD.

RECOVER. ADAPT. EMPOWER. EVOLVE.

I didn't sit down one morning and invent them.

They accumulated.

Some came from projects that went well.

Some came from projects that went badly.

Some came from spectacular mistakes.

A few came from things I got away with.

And some took years before I understood what they had actually taught me.

That's why the stories matter.

This isn't a career history.

I'm not going to give you a chronological account of everything I've ever done.

The projects are here because they taught me something.

Sometimes the lesson was obvious at the time.

Sometimes it wasn't.

And sometimes the most useful thing I learned was that the problem I thought I was solving wasn't the problem at all.

There is another reason I've written this now.

I've spent enough time around projects to know that failure isn't the opposite of success.

It's part of the process.

Projects fail.

Plans fail.

Ideas fail.

People fail.

Sometimes spectacularly.

The interesting question isn't whether failure can be eliminated.

It can't.

The interesting question is:

What do you do when reality tells you that your plan was wrong?

That's where the principles begin.

And perhaps, eventually, that's where they become useful beyond projects.

Because somewhere along the way I discovered something I hadn't expected.

The same principles that helped me deal with difficult projects began turning up in the rest of my life.

That is why the final principle is called EVOLVE.

But we'll get to that.

For now, let's start with the first thing I've learned:

Before you try to solve a problem, make sure you understand what the problem actually is.

Because sometimes the brief isn't the problem.

It's only the beginning...

.

The track is rearely a straight line

NOBODY'S BUSINESS

Trying to keep a business thriving

In this world of paper weight

Even for a man lion-hearted

Is bang your head, procrastinate

Fill in the right forms pay your dues

'Be concise sir' pick and choose

Then go back to the end of line

Smile and wave, you're doing fine

And now you're on the money road

Trust your partner - he trusts you

Never buckle from the load

Keep your head high, values true...

But every now and then look round

Cos if your back-up is unsound

The underdog will bite your shoe

And bring you down a peg or two!

GAVIN MILLS

CHAPTER 01 - UNDERSTAND

Before solving a problem, make sure all the problems are fully understood.

In 1994, South Africa was preparing for its first democratic election.

It was an extraordinary moment in the country's history.

For us, it was also a project.

I was appointed to develop and manage a voter-education campaign across North West Province.

On paper, the brief seemed straightforward:

People needed to understand how to vote.

We needed to tell them.

But the more we looked at it, the more obvious it became that the problem wasn't simply communication.

North West was a huge province. People were spread across towns, villages and rural communities. There were distances to cover, different languages to consider, questions about venues, accommodation, infrastructure and access.

The information had to reach people who lived very different lives in very different circumstances.

So before we started designing the campaign, we started trying to understand the environment in which it had to work.

That sounds obvious.

It isn't always.

There is a particular temptation in projects to start solving things too quickly.

A brief arrives.

A meeting is called.

Someone asks:

"So, what are we going to do?"

And suddenly everyone is producing answers.

Ideas appear.

Budgets appear.

Timelines appear.

Presentations start taking shape.

The danger is that you can end up with a beautifully constructed solution to a problem that nobody has properly understood.

I've done it.

More than once.

I suspect most people who have worked on projects for any length of time have.

The difficult part isn't necessarily finding an answer.

It's making sure you're answering the right question.

For the North West campaign, we commissioned playwright Matsemela Manaka to write the script and a respected South African musician to compose and record an original musical score.

But there was another problem.

There was no such thing as a mobile theatre.

So we built one.

Actually, we built four.

Large eight-metre containers were mounted onto eight-tonne flatbed trucks and converted into travelling theatres.

The theatres could then travel into communities across the province, taking the campaign directly to people rather than expecting people to come to us.

Four of them eventually crossed North West Province.

The solution came from understanding the problem properly.

But something else happened that I found even more interesting.

As the campaign got underway, officials from North West Internal Affairs and Planning came to our flat.

They weren't particularly interested in our theatres.

They wanted to see our maps.

The maps we'd assembled to understand the province had become useful for something we hadn't originally been trying to solve: helping determine where voting stations could be established.

We hadn't set out to create that solution.

It emerged because we'd taken the trouble to understand the environment before deciding what the answer should look like.

And that stayed with me.

THE PROBLEM BEHIND THE PROBLEM

Years later, I've come to think that many project failures begin before anyone actually does anything wrong.

They begin with an incomplete understanding of what is actually happening.

The brief might describe the symptom.

The client might describe the desired outcome.

The team might already have an idea.

But somewhere underneath all of that is the actual problem.

Sometimes it's obvious.

Sometimes it isn't.

Sometimes nobody has asked the awkward question yet.

And sometimes the problem you have been asked to solve isn't actually the problem at all.

That's why I have learned to be suspicious of the sentence:

"We know what the problem is."

Do we?

What do we know?

What are we assuming?

What don't we know?

Who sees the problem differently?

What happens outside the room?

Who has to live with the solution once we've gone home?

And perhaps the most important question:

What happens if our understanding is wrong?

Understanding isn't procrastination.

It isn't an excuse to hold another meeting.

And it certainly doesn't mean analysing something until the opportunity disappears.

It means knowing enough about the reality you're entering to make an intelligent decision about what to do next.

Sometimes that takes ten minutes.

Sometimes it takes ten weeks.

The trick is knowing the difference.

THE PRINCIPLE

Before solving a problem, make sure all the problems are fully understood.

Because the problem presented to you is not necessarily the problem you need to solve.

And occasionally, when you take the time to understand the problem properly, you discover that what looked like an obstacle is actually pointing towards the solution.

That's what happened in North West.

We thought we were building a way to communicate with voters.

We discovered we were also building a way to understand the landscape in which voting itself would happen.

The better you understand the problem, the more possibilities you can see.

THE QUESTION

What are we trying to solve that we haven't fully understood yet?

Don't rush to answer it.

Sit with it.

Sometimes the answer is where the project begins.

01 - UNDERSTAND

Before solving a problem, make sure all the problems are fully understood.

What are we trying to solve that we haven't fully understood yet?

CHAPTER 02 - IDENTIFY

Before solving a problem, identify the constraint.

In 2010, South Africa was preparing to host the FIFA World Cup.

For a country that had waited a lifetime to host the tournament, it was enormous.

For Coca-Cola, it was also an enormous project.

A leading sports management company had been commissioned to develop experiential sponsorship activations for Coca-Cola Fan Parks around the country.

My role was to assist in developing concepts that would create a distinctive Coca-Cola experience throughout the tournament.

The team assembled to deliver it was formidable.

Good people.

Good ideas.

Good production capability.

On the surface, everything looked encouraging.

But something bothered me.

There were ten Fan Parks.

Five construction teams.

And a four- or five-day window in which all ten sites had to be built.

I kept coming back to one question:

"How are they being built?"

It wasn't a question about the creative.

The creative was fine.

It wasn't a question about the people.

They were good.

It wasn't even initially a question about whether the structures could be built.

They could.

It was a question about whether they could all be built in the time available.

And suddenly the problem became much clearer.

THE THING THAT CAN STOP THE PLAN

This is one of the traps in project work.

We tend to look at what we need to add to make a project succeed.

More people.

More money.

Better ideas.

More equipment.

More time.

But sometimes the most important thing isn't what is missing.

It's the one thing that could prevent everything else from working.

The constraint.

A project can have excellent people.

Good ideas.

Enough money.

A clear objective.

A solid plan.

And still fail.

Not because any of those things are missing.

Because something else is in the way.

In this case, the constraint was brutally simple:

There wasn't enough time for the five construction teams to build all ten Fan Parks within the proposed sequence and the four- or five-day window.

Once that was identified, we didn't need a better creative idea.

We needed a different plan.

The rollout strategy was reviewed.

Construction windows were adjusted.

The teams were given sufficient time to complete the ten Fan Parks properly.

The projects could proceed.

Nothing magical happened.

Nobody produced a heroic solution.

We simply found the thing that was going to stop the plan before the plan stopped itself.

THE CONSTRAINT IS OFTEN HIDING IN PLAIN SIGHT

I've learned to look for constraints early.

Not because I enjoy finding problems.

Quite the opposite.

Finding the constraint early is one of the best ways I know of avoiding a much bigger problem later.

And constraints aren't always obvious.

Sometimes it's time.

Sometimes money.

Sometimes access.

Sometimes legislation.

Sometimes technology.

Sometimes the availability of one particular person.

Sometimes it's a decision that somebody hasn't made.

Sometimes it's a dependency buried three levels down in somebody else's plan.

And sometimes the constraint is human.

A team doesn't have authority.

A client can't make a decision.

Someone is protecting an idea because they created it.

Someone is afraid to say that the plan isn't working.

The danger is that we often discover these things only after we've built the rest of the project around them.

By then, the constraint isn't simply a problem.

It's an expensive problem.

There is another distinction I find useful.

A constraint isn't necessarily something that makes a project impossible.

It's something that limits the choices available to you.

Once you know what it is, you can work with it.

You can change the sequence.

Change the resources.

Change the design.

Change the timing.

Change the route.

Sometimes you can even change the objective.

But until you've identified the constraint, you're often just moving pieces around and hoping they fit.

That isn't project management.

That's rearranging deckchairs.

The lesson from the Fan Parks wasn't that we had discovered a clever construction technique.

We hadn't.

It was much simpler.

We found the thing that could stop the plan.

And because we found it early enough, we could change the plan before it became a failure.

That distinction has stayed with me.

A great deal of good project thinking isn't about having the perfect plan.

It's about understanding why the plan cannot survive.

Protect that first.

Everything else becomes negotiable.

THE PRINCIPLE

Before solving a problem, identify the constraint.

Not every problem needs to be solved.

Some need to be removed.

Some need to be worked around.

Some need to be accepted.

And some need to change the plan itself.

But first you have to know what you're dealing with.

THE QUESTION

What is the constraint that could stop this?

Find it early.

Because once you know what can stop the project,

you know what you have to protect.

02 - IDENTIFY

Before solving a problem, identify the constraint.

What is the constraint that could stop this?

CHAPTER 03 - REFRAME

When everyone is looking in the same place... look somewhere else.

The Klein Karoo National Arts Festival in Oudtshoorn was an annual festival, and one of South Africa's major cultural events. In 1997 and 1998, the years concerned, M-Net was a top-tier sponsor.

Our department was tasked with finding ways to leverage that sponsorship.

At first, the opportunities seemed obvious.

The theatres.

The venues.

The performance spaces.

That was where the audiences were.

That was where the performances happened.

That was where the brand could be associated with the festival.

It all made perfect sense.

Which was precisely why I started looking somewhere else.

THE STREETS

Oudtshoorn itself was the environment through which thousands of people moved during the festival.

They arrived by car.

They walked through town.

They travelled between venues.

They went to restaurants.

They shopped.

They waited.

They gathered.

The festival didn't stop at the doors of the theatres.

It spilled into the town.

So we rigged hundreds of custom-made M-Net streetpole banners throughout Oudtshoorn and along the roads leading into town.

The result was simple.

We painted the town "M-NET".

The sponsorship wasn't confined to the places where the performances took place.

It became part of the environment surrounding the festival.

The following year, other sponsors had recognised the value of those streets.

The opportunity we'd found had become obvious.

So once again, we looked somewhere else.

THE OBVIOUS IS OFTEN INVISIBLE

There's an interesting thing that happens when enough people look at the same problem in the same way.

Eventually, the way they're looking becomes invisible.

Nobody says:

"This is how we have decided to see the problem."

It simply becomes:

"This is the problem."

We inherit definitions.

This is where the audience is.

This is what the customer wants.

This is how the industry works.

This is what the product is.

This is what the competition does.

This is how we've always done it.

And once those assumptions become embedded, they can be surprisingly difficult to see.

Not because they're necessarily wrong.

Because nobody is questioning them anymore.

Reframing isn't about being different for the sake of being different.

It isn't looking for the cleverest alternative just so you can say you found one.

And it isn't ignoring the obvious because the obvious is somehow boring.

Sometimes the obvious answer is the right answer.

The skill is recognising when it isn't.

That's when you step outside the frame.

Instead of asking:

How do we make this sponsorship more visible inside the festival?

you might ask:

Where does the festival actually exist?

That is a different question.

And a different question can produce a completely different answer.

CHANGE THE QUESTION

I've found that some of the best opportunities I've encountered weren't hidden particularly well.

They were sitting in plain sight.

What was hidden was the assumption that prevented people from looking there.

That's why reframing matters.

You don't necessarily need a new idea.

Sometimes you need to change the way you are looking at the existing one.

A product may not need a new market.

It may need a different definition of the customer.

A difficult process may not need more resources.

It may need to be redesigned around the actual objective.

A problem that appears expensive may become much simpler when you stop asking how to solve it in its current form.

And sometimes an opportunity is sitting just outside the boundaries everyone has accepted without ever discussing them.

The Oudtshoorn experience was relatively simple.

But I've carried the principle with me because it applies far beyond sponsorship.

When everyone is looking in the same place, there is a good chance that something important is being overlooked somewhere else.

Not always.

But often enough to make looking worthwhile.

And perhaps that's the real discipline:

Not automatically rejecting the obvious.

Just refusing to assume that the obvious is the whole picture.

THE PRINCIPLE

When everyone is looking in the same place... look somewhere else.

Reframing isn't about making a problem more complicated.

It's about questioning the frame in which the problem has been presented.

Sometimes the answer doesn't require a better solution.

It requires a better question.

THE QUESTION

Where is everyone looking — and what might they be missing?

Look at the problem.

Then look around it.

The opportunity may simply be outside the frame.

03 - REFRAME

When everyone is looking in the same place... look somewhere else.

Where is everyone looking — and what might they be missing?

CHAPTER 04 - DISCOVER

When the path doesn't exist... discover whether it should.

When I was originally hired at Ogilvy & Mather Johannesburg, I was appointed Special Projects Manager.

It was a slightly unusual role.

Clients occasionally approached the agency with opportunities that fell outside its traditional services. On this occasion, my job was to investigate them.

Not to make them happen.

Not to make them disappear.

To discover whether they could become reality.

That distinction turned out to be rather important.

Because an interesting idea is not necessarily a viable business.

One of the opportunities involved establishing an in-house fashion design academy together with a boutique-within-a-boutique retail concept for a leading fashion brand.

It was an interesting idea.

So we investigated it properly.

What would it require?

How could it work?

What would the operating model look like?

What would it cost?

What would be needed to make it sustainable?

The investigation resulted in a practical roadmap, implementation options and detailed costings.

And the answer was, essentially:

It could work.

But it would cost considerably more than the client had anticipated or was prepared to invest.

So the project never went beyond feasibility.

The second opportunity came from KFC.

They wanted to explore bringing Gladiators to South Africa — or developing a local equivalent.

Again, it was an exciting proposition.

Again, we investigated.

Could it work?

What would be required?

What would the model look like?

What would it cost?

What would make it viable?

Once again, the investigation produced detailed costings, implementation options and a practical action plan.

And once again, the project didn't proceed beyond feasibility — again as a result of financial considerations.

Neither outcome was a failure.

Both had answered the question they had been commissioned to answer.

That seems obvious now.

It wasn't always obvious to me.

THE ATTACHMENT TO AN IDEA

Around the same time, a brilliant friend of mine reminded me of something I've never forgotten.

His name was Bones.

He was studying in London at the time — art, marketing, or something along those lines. I can't remember exactly.

What I do remember is that he was brilliant.

He was also funny, cocky and a bit of a loudmouth.

Rather like me.

Apparently, they had a particularly good lecturer who had given the class a demanding assignment.

Bones had spent hours — probably weeks — sweating blood to get his project together.

The following day, the students would be handing their work in for evaluation.

Bones was proud of it.

Understandably.

He had invested time in it.

He believed in it.

He had made it.

And then came the presentation.

Three minutes in, the lecturer stopped him.

He took the work from Bones, paged through it, tore it up and threw it onto his desk.

"Utter rubbish!"

Bones was on his feet, baying for blood, until some of the other students restrained him.

In the lecturer's office, Bones was told that he had no chance of failing the course — both Bones and the lecturer knew that. But that was not why he had acted as he did.

The lesson was something else.

Success is seldom simply about being good enough.

It was about being strong enough to fail.

The lecturer told him:

"You have to be prepared to burn your babies."

I never forgot it.

THE ATTACHMENT TO AN IDEA

It's a brutal expression.

It's also an extraordinarily useful one.

Because we become attached to things we create.

An idea starts in our head.

We develop it.

We work on it.

We improve it.

We cherish it.

We defend it.

Other people start recognising it as our idea.

Eventually, questioning the idea can feel strangely personal.

And that's when things become dangerous.

Because the objective of a project is not to prove that your idea was right.

The objective is to achieve the desired outcome.

Those are not always the same thing.

Sometimes the idea needs improving.

Sometimes it needs changing.

Sometimes it needs abandoning.

And occasionally, it needs setting fire to completely.

The difficult part is recognising which is which.

Discovery therefore isn't simply about finding ways to make an idea work.

It's about being prepared to discover that it shouldn't.

That's a very different mindset.

If you've already decided that the idea must succeed, your investigation becomes a search for justification.

You'll find reasons.

You'll find possibilities.

You'll find ways around the obstacles.

You'll become increasingly clever at defending something that perhaps shouldn't exist.

But if the question is genuinely:

"Should this exist?"

then the answer can be yes.

Or no.

Or not yet.

Or not like this.

All four are useful answers.

I've come to think that one of the most valuable things you can give a project is permission to die.

Not because failure is desirable.

Because resources are finite.

Time is finite.

Money is finite.

Attention is finite.

And if an idea has no viable path forward, continuing to protect it simply because someone loves it can prevent something better from taking its place.

That's why those two feasibility projects mattered to me.

They didn't produce two new businesses.

They produced something just as valuable:

certainty.

We knew what the opportunities would require.

We knew what they would cost.

We knew what would make them viable.

And the clients could make informed decisions.

The projects had done their job.

THE PRINCIPLE

When the path doesn't exist... the first responsibility is to discover whether it should.

Don't confuse commitment with stubbornness.

Don't confuse persistence with attachment.

And don't confuse abandoning an idea with failure.

Sometimes the most professional thing you can do is discover that the path isn't there.

Then stop looking for ways to force it into existence.

Burn the baby.

And move on.

THE QUESTION

Are we protecting the idea — or are we defending our babies?

That's a difficult question.

Especially when the idea is yours.

But sometimes answering it honestly is the difference between protecting your ego...

and protecting the objective.

04 - DISCOVER

When the path doesn't exist... the first responsibility is to discover whether it should.

Are we protecting the idea — or are we defending our babies?

CHAPTER 05 - BUILD

Once the purpose is understood...build a system that delivers

I came to event production by a slightly unusual route.

I came from dancing.

From theatre.

From entertainment.

Before I knew much about event management, I knew something about audiences.

I knew what it felt like to walk onto a stage and have people sitting there waiting for you to give them something worth watching.

I knew that people don't pay to see the mechanics.

They pay for the entertainment — and the experience.

They don't care how the scenery was built.

How the lights were rigged.

How many people are working backstage.

They care about what happens when the curtain goes up.

That distinction became increasingly important when I moved into event production.

I didn't yet know all the tactics and mechanics of the business.

What I did know was how to think about people.

What might make them stop?

What might make them look?

What might make them want to stay?

What might make them come back?

Those questions turned out to be rather useful.

IF THE PEOPLE ARE ALREADY THERE...

I was asked to develop a national summer campaign for Vodacom.

I conceived and created Yebo Summer.

The brief was to connect the brand with South Africa's busiest holiday beaches during the summer season.

The obvious solution was a travelling entertainment roadshow.

Take the show to the people.

Set it up.

Create the experience.

Pack it away.

Move to the next beach.

It was familiar territory for someone coming from entertainment.

But I started thinking about the problem differently.

If the people were already going to the beaches...

why move the show?

That question led to the creation of the VodaShack.

Instead of taking one activation from beach to beach, we established permanent activations on selected beaches for the entire holiday season.

The idea was simple.

Be there.

Every day.

Become part of the environment rather than simply arriving in it.

BUILDING IS MORE THAN MAKING

This is where I think the word build can be misleading.

We tend to think of building as the physical act.

Construct something.

Put the pieces together.

Make it work.

But a good system is more than the things it is made from.

It is the way those things work together.

The VodaShack wasn't simply a structure on a beach.

It was a system for delivering an experience.

The location.

The timing.

The entertainment.

The team and site management.

The brand.

The environment.

The reason for being there.

And, importantly, the fact that it was there consistently.

That consistency matters.

A great idea that works once is interesting.

A system that can deliver the desired result repeatedly is much more valuable.

I've always been fascinated by the difference between something that works and something that works reliably.

Anybody can get lucky.

You can have the perfect weather.

The perfect crowd.

The perfect performer.

The perfect day.

But if the project depends on everything being perfect, you've built a fragile system.

The real test comes when conditions aren't perfect.

Can the experience still work?

Can the team still deliver it?

Can the audience still get what they came for?

Can the system be repeated tomorrow?

And the day after?

That's when building becomes more than construction.

You're building reliability.

There is another lesson I carried from theatre.

The audience shouldn't have to know how hard it was.

They shouldn't see the cables.

They shouldn't hear the stage manager shouting.

They shouldn't know that somebody arrived at five in the morning because something wasn't working.

They see the curtain go up.

And hopefully, for a little while, they believe that everything happened exactly as it was supposed to.

That's not deception.

That's the job.

The machinery is important.

But it isn't the reason people came.

They came for what happens when the machinery works.

That is equally true of business.

Customers don't necessarily care how complicated your internal process is.

Employees don't necessarily care how clever your organisational structure looks.

Clients don't care how many meetings it took to produce the solution.

They care about the result.

So build accordingly.

THE SYSTEM BEHIND THE EXPERIENCE

A useful question when building anything is:

What has to happen consistently for the desired outcome to occur?

Not:

What can we build?

Not:

What can we show?

Not:

What can we sell?

But:

What has to work?

Once you understand that, you can start deciding what the system needs.

Sometimes that will be elaborate.

Sometimes it will be remarkably simple.

The cleverness isn't in how complicated you can make it.

The cleverness is in knowing what doesn't need to be complicated.

The VodaShack didn't require us to keep moving the show.

It required us to recognise that the audience was already there and not going anywhere.

So we built around reality rather than trying to move reality around us.

THE PRINCIPLE

Once the purpose is understood... build a system that delivers the desired results consistently.

Don't confuse the thing you build with the result you are trying to achieve.

The structure is not the experience.

The process is not the outcome.

The machinery is not the purpose.

Build what needs to work.

Then make it work reliably.

THE QUESTION

Are we building something people want — or simply building something we know how to deliver?

Because the easiest thing to build is often the thing we already know how to build.

The harder question is whether it is actually what the situation requires.

05 - BUILD

Once the purpose is understood... build a system that delivers the desired results consistently.

Are we building something people want — or simply building something we know how to deliver?

CHAPTER 06 - RECOVER

When the unexpected happens... protect the objective.

Some problems can't be prevented.

They can only be solved.

A major international mining consortium was hosting its biannual management conference in South America.

I was commissioned to produce the opening film.

The brief required travelling with the client to South America and interviewing senior executives from across the organisation.

The interviews were central to the production.

So, naturally, I did what any responsible producer would do.

I bought a new lapel microphone.

The day before we left.

Everything was tested.

Everything appeared to work perfectly.

During filming, I noticed that the monitors on my camera were going apeshit, but the sound through my headphones seemed fine, so I presumed it was probably just a compatibility problem.

Needless to say, I was so wrong.

The interviews were done.

With the interviews in the can, we flew back to South Africa while the executives went back to running their businesses.

Then we listened to the recordings properly.

Every interview sounded like Donald Duck.

Every.

Single.

One.

Not slightly odd.

Not a little distorted.

Donald Duck.

The kind of moment when a producer realises the whole thing is about to go down in flames.

THE PLAN IS DEAD. NOW WHAT?

Re-recording the interviews wasn't an option.

Gathering all those executives together again would have been impossible.

The production schedule wasn't going to move.

The conference wasn't going to move.

The problem wasn't going to disappear because we stared at it.

And there was nobody to blame.

The only question that mattered was:

How do we save the project?

That's an important moment in any project.

Because once something has gone badly wrong, there is a very natural temptation to look backwards.

Who did it?

Why wasn't it checked?

Why didn't somebody notice?

What should have happened?

All perfectly reasonable questions.

And sometimes they need answering.

But not yet.

First, you have to save the thing.

So we stopped looking at what had gone wrong and started looking at what was still possible.

Through the client, we managed to source print-out copies of all the speeches from the originators within forty-eight hours.

Working with a talented sound engineer and a Spanish-speaking member of the client's management team, we first cut and restructured the interviews into the final message.

The words we needed were still there.

The story was still there.

The problem was that the voices we'd recorded were unusable.

So we changed the way we delivered the message.

Instead of pretending the original plan was still possible, we protected what actually mattered.

The objective.

The film still had to communicate the message.

The executives' contribution still mattered.

The conference still needed its opening film.

The original method had failed.

The project didn't have to.

RECOVERY ISN'T RESTORATION

I think that's an important distinction.

When something goes wrong, we often talk about getting back on track as though the objective is to restore the original plan.

Sometimes it is.

But sometimes the original plan is dead.

Trying to resurrect it simply wastes more time.

Recovery isn't necessarily about putting everything back the way it was.

It is about asking:

What must survive?

The schedule may have to change.

The design may have to change.

The technology may have to change.

The people may have to change.

The method may have to change.

Even the deliverable may have to change.

But somewhere inside all of that is the reason the project exists in the first place.

Protect that.

Everything else is negotiable.

This is where experience becomes useful.

Not because experienced people never make mistakes.

We do.

Not because experienced people can predict everything.

We can't.

It's because, after enough things have gone wrong, you become slightly less surprised when something else goes wrong.

You stop expecting the plan to protect you.

You start expecting reality to test it.

And when it does, you don't necessarily need to panic.

You need to ask:

What have we still got?

What remains usable?

What can be changed?

Who can help?

What matters most?

What absolutely cannot be lost?

Those questions move you forward.

Blame doesn't.

There's also a strange freedom in accepting that the original plan is sometimes gone.

Once you stop trying to save the plan, you can concentrate on saving the purpose.

That's what happened in South America.

We couldn't save the recordings.

We couldn't recreate the interviews.

We couldn't change the conference.

So we stopped trying.

We saved the message instead.

And somehow, with a lot of ingenuity and a little bit of “kick Donald Duck into touch” mindset, we got the job done.

THE PRINCIPLE

When the unexpected happens... protect the objective.

Some problems can't be prevented.

They can only be solved.

And when the original plan is no longer possible, the most important question isn't:

How do we get back to where we were?

It's:

What must still be achieved?

Find that.

Protect it.

Then find another way forward.

THE QUESTION

If the original plan is no longer possible, what is the objective that must still survive?

Everything else may be negotiable.

The objective isn't.

And if, occasionally, the result involves turning Donald Duck back into a senior mining executive...

well, that's part of the job too.

06 - RECOVER

When the unexpected happens... protect the objective.

If the original plan is no longer possible, what is the objective that must still survive?

CHAPTER 07 - ADAPT

Plans are always vulnerable to reality.

Two years later, the same international mining consortium would visit South Africa for its next biannual management conference.

Following the first day's sessions, guests would be treated to a stunning silver-service dinner as the sun set over the Atlantic Ocean from one of the Western Cape's most beautiful natural settings.

The dinner was to take place beneath beautifully appointed nomadic tents on the private beach at Oudekraal.

It was going to be spectacular.

Months of planning had gone into creating the experience.

And we had done the groundwork.

Weeks before the event, I had recced the beach.

We had obtained the necessary permissions.

The beach and the surrounding area we required had been exclusively booked for our event.

Everything was in place.

THE LITTLE MAN ON MY SHOULDER

The Friday before the event — the Monday evening — I drove past Oudekraal beach.

I was alarmed to see a massive stage deck and viewing tower occupying centre-stage, on my beach.

A bit of a red-flag moment.

So I went back to the hotel to check and make sure.

Yes, we had exclusive access.

Yes, the beach was booked.

Yes, everything was apparently in order.

So I carried on.

Monday morning came.

My team went to load in.

The stage was still there.

But not just a stage.

A monstrous, massive stage.

PA towers.

A viewing deck.

All directly between our guests and the sunset — and I still didn't know!

I had been at the hotel getting the conference going.

The conference had started brilliantly and I was in a great mood, heading for the beach.

Just as I was leaving the hotel, I thought:

Maybe I don't have to go.

My team was there.

Everything was in place.

Maybe I could just go back to the hotel and chill.

I phoned my project manager.

He told me everything was hunky-dory.

“Don't bother. Relax.”

But I've always said I have a little man on my shoulder who pulls my ear like a maniac when shit starts surfacing.

He was screaming:

GO TO THE BEACH.

So I went.

And you can imagine my face when I saw thirty tons of rusted scaffold sitting exactly where my VIP guests were hoping to watch a magnificent sunset.

I looked at my project manager.

“And that stage?”

He looked at me.

“Yeah. What about it?”

Wrong answer.

I learnt that the structures belonged to a previous event.

Industrial action had halted their removal.

I started making calls.

Who did the structures belong to?

Who was responsible for removing them?

What had happened?

I called the Parks Board.

I spoke to the people involved.

And one by one, I heard essentially the same response:

“Yes, you're right.”

We had the permissions.

We had the booking.

We had exclusive access.

And then:

“But what exactly would you like me to do?”

And that was the moment I realised something.

Thinking outside the box wasn't going to be enough.

The bloody box had to go.

GETTING ON WITH IT

My site manager looked at me and shrugged.

“There's not much we can do.”

There was.

But getting angry wasn't going to move a stage.

The structures had to go.

That wasn't a discussion.

It was the objective.

The rigging crew responsible for dismantling the structures were still on site.

They were waiting to be paid.

I made a simple offer.

They asked me where to stack the gear.

I told them I didn't care, as long as it wasn't visible around my beach for 500 paces.

The dismantling began immediately.

By mid-afternoon, half the crew stopped.

They needed to leave to catch their buses.

I said I understood and they were welcome to leave.

Pity I couldn't pay them because the job wasn't completed...

but I understood.

Then I turned to the rest and upped the offer.

No one left.

The work resumed.

By five o'clock, the beach was spotless.

That evening, our guests watched the sun disappear into the Atlantic.

They never knew there had been a stage on the beach that morning.

THE AUDIENCE DOESN'T NEED TO KNOW

And that, in a strange way, is one of the things I have come to appreciate about producing anything.

The audience should see the result.

They don't need to see the panic.

They don't need to know how many conversations took place behind the scenes.

They don't need to know that the plan nearly came apart.

They simply need to experience what they were promised.

Our job is just to get on with the show.

There really is no business like show business, in all its wonderful forms.

But there is something else in this story.

We had done the planning.

We had done the recce.

We had checked the permissions.

We had booked the space.

We had even noticed the warning sign.

Yet reality still found a way to put a massive stage between us and the sunset.

That is the uncomfortable truth about plans.

You can do everything properly and still find yourself standing in the middle of a problem that wasn't supposed to exist.

The answer isn't to abandon planning.

Quite the opposite.

Planning gives you the confidence to recognise when reality has changed the rules.

The important question then becomes:

What has changed — and what hasn't?

In Oudekraal, almost everything about the circumstances had changed.

The beach was occupied.

The previous event hadn't been dismantled.

The schedule was under pressure.

The people responsible for the dismantling had their own problems.

But the objective hadn't changed.

The guests were still going to watch the sunset.

The sunset was where it was supposed to be.

The plan had changed.

The experience hadn't.

THE PRINCIPLE

Plans are always vulnerable to reality.

You can plan carefully.

You can check everything.

You can get the permissions.

You can anticipate problems.

And reality can still walk onto the stage and change the rules.

The answer isn't to fight reality.

It's to recognise what has changed...

and adapt.

Because the objective may remain exactly the same.

Only the route has changed.

THE QUESTION

What has reality changed — and what hasn't it changed?

Know the difference.

Then get on with the show.

07 - ADAPT

Plans are always vulnerable to reality.

What has reality changed — and what hasn't it changed?

CHAPTER 08 - EMPOWER

The moment people stop owning the problem... they stop owning the solution.

After leaving Ogilvy & Mather, I launched my own event production company.

Don't Forget George Events & Productions.

DFG.

It happened rather more suddenly than I had planned.

The final Christmas season of the millennium was approaching.

I was in Cape Town on a recce for the new Yebo Summer campaign when, sitting in the executive lounge at the airport with a couple of post-production scotches under my belt, my phone rang.

It was Karen, one of my star project managers.

She was in tears.

Shortly after I had joined O&M, Promotional Campaigns changed MDs.

Mignon, the new MD, was a stunning lady, and her and I worked brilliantly together.

She was one of those people under whom a company seemed to fly.

But regrettably, she left, to be replaced by a dipshit, and things changed.

To say her replacement and I didn't see eye to eye would be an understatement.

One of our recurring battles concerned ownership of my department's billing.

I wasn't particularly interested in the politics or even the incentives.

I simply liked being responsible for my own channels, my own clients and my own people.

By the time Karen called me, the tension had reached breaking point.

Alan, the new MD, had been questioning her about me.

Was it true that I smoked weed?

Was I a loose cannon?

Wouldn't it be better if my department fell under him?

I had never made much of a secret of the fact that I smoked weed.

It wasn't exactly a state secret in the advertising industry.

But that wasn't the point.

My staff were being put in the middle of something that had nothing to do with them.

I was sitting in an executive lounge.

It was Friday night.

I'd had a couple of scotches.

I felt strangely executive.

So I did what any perfectly rational senior executive would do in that state.

I phoned Alan.

I gave him a mouthful.

And I resigned.

Then I went home.

Saturday came.

Then Sunday.

And somewhere during those two days the alcohol wore off and reality arrived.

Oh fuck.

I had a house.

I had responsibilities.

And I no longer had a job.

MAESTRO GAV

I had been toying with the idea of starting my own company.

I had even designed a logo.

Apparently, I was now going to need it.

Vodacom agreed to become my first client.

The first problem was cash flow.

I had an incredible contract but no cash, and I was kicking off a multimillion-rand project.

I registered DFG.

Then I went to Nedbank's Epsom Downs branch.

I wanted to open a business account.

There was one small problem.

I had no money to put into it.

I told the manager I would have more than R500,000 within ten days.

Ten days later, after receiving a cheque for approximately R2 million from Vodacom, I phoned.

I told him I was on my way to collect a printed cheque book, finalise the account, arrange credit cards and withdraw R50,000 cash.

When I arrived, it was almost comical.

The manager started explaining that this wasn't how they normally did business.

I reminded him that I had arrived with a R2 million cheque in my hand.

Two hours later, DFG had what it needed.

DFG was unleashed on an unsuspecting South Africa.

And then something rather interesting happened.

The company grew.

As the business grew, so did the projects.

I loved the creative process.

Whenever an idea needed improving, I'd step in.

Around the office it became something of a joke:

“Make space for Maestro Gav.”

I thought I was raising the standard.

I wasn't.

Without realising it, I was teaching my team that the final answer would always come from me.

People stopped owning the problem.

They waited for me to solve it.

The mistake wasn't theirs.

It was mine.

THE PROBLEM WITH RESCUING PEOPLE

This is one of those lessons that is much easier to see in retrospect.

I thought I was helping.

If somebody came to me with an idea that wasn't quite right, I'd improve it.

If a piece of work wasn't good enough, I'd fix it.

If a problem was getting difficult, I'd step in.

And because I was good at it — or at least thought I was — it was very easy to justify.

I wasn't taking control away from people.

I was helping them get to a better answer.

Except that, gradually, something else was happening.

They stopped trying to find the answer themselves.

Why would they?

If they knew Maestro Gav was eventually going to arrive and sort it out, there was very little incentive to wrestle with the difficult bits.

I had created a dependency without intending to.

I had become the solution.

And in doing so, I had become part of the problem.

There is a subtle difference between giving someone responsibility and giving them ownership.

You can give somebody a job.

You can give them a deadline.

You can give them a budget.

You can even tell them that they're responsible for the outcome.

But if they know that you're going to step in whenever you don't like the answer, they don't really own it.

They are borrowing it.

True ownership requires something more uncomfortable.

You have to let people make decisions.

Including decisions you wouldn't make.

You have to let them try.

You have to let them get things wrong.

You have to resist the temptation to rescue them every time you see them heading towards a mistake.

And sometimes you have to sit quietly while somebody works through a problem that you could solve in five minutes.

That can be bloody difficult.

Especially when you're convinced you know the answer.

LETTING GO

The day I stopped rescuing every idea, something changed.

They started owning them again.

The work became stronger.

Not because I contributed more.

Because I came to recognise their value...

and I finally contributed less.

That was a difficult lesson.

It meant accepting that the best answer didn't always have to come from me.

It meant understanding that somebody else's solution could be different from mine...

and still be good.

Sometimes better.

And perhaps most importantly, it meant recognising that my job as a leader wasn't to have all the answers.

It was to create the conditions in which other people could find theirs.

THE PRINCIPLE

The moment people stop owning the problem... they stop owning the solution.

You don't empower people simply by giving them responsibility.

You empower them by giving them ownership.

And ownership cannot be delegated while control is retained.

If you want people to think like owners, you have to let them own something.

That means giving them enough authority to make decisions.

Enough space to make mistakes.

Enough trust to find their own way.

And enough room for their answer to be different from yours.

THE QUESTION

Are you solving the problem — or preventing someone else from owning it?

It's an uncomfortable question.

Especially if you're the person everyone comes to when things get difficult.

Because sometimes being needed feels like leadership.

It isn't always.

Sometimes the most valuable thing you can do...

is get out of the way.

08 - EMPOWER

The moment people stop owning the problem... they stop owning the solution.

Are you solving the problem — or preventing someone else from owning it?

CHAPTER 09 - EVOLVE

Principles that work on projects... work on life.

For most of my working life, I thought I was learning how to make projects work.

I wasn't.

Not entirely.

I was learning how to deal with reality.

How to recognise and understand a problem before trying to solve it.

How to identify the constraint.

How to look somewhere else when everyone else is looking in the same place.

How to discover whether an idea deserved to exist.

How to build something that could actually work.

How to recover when things went wrong.

How to adapt when reality changed the rules.

How to let other people own the problem.

I learned all of that on projects.

And then...

life interrupted the project.

A marriage ended.

I lost far more than a relationship.

I lost my home.

My community.

My network.

For a while...

I lost my direction.

There was no brief.

No client.

No production schedule.

No team waiting for instructions.

No deadline.

No budget.

No network.

No one asking:

"What are we going to fix this?"

There was just me.

And a rather uncomfortable question:

What now?

At first, I didn't have a particularly good answer.

But somewhere in the mess, something began to occur to me.

I had spent decades dealing with difficult circumstances.

Not always successfully.

Not always elegantly.

But I had learned how to keep moving.

I had learned that reality doesn't care how good the plan was.

I had learned that sometimes the thing you thought was the problem wasn't the problem at all.

I had learned to look for constraints.

To look for opportunities where other people weren't looking.

To kill ideas I loved when they no longer deserved to survive.

To build again when something had failed.

To recover when things went wrong.

To adapt when the world refused to cooperate.

And, perhaps most importantly, I had learned that I didn't have to solve everything myself.

Those lessons had never been theories.

They had been earned.

One project at a time.

Some projects succeeded.

Some didn't.

Some never left the drawing board.

Every one of them ended.

But every one left something behind.

Not a project.

A principle.

And suddenly I understood something I had never really considered while I was busy producing things.

The work was never the thing I was building.

I was.

Every project had changed me in some small way.

Every failure had taught me something.

Every crisis had added another tool.

Every success had shown me something worth repeating.

I simply hadn't realised I was collecting them.

Now I needed them.

Rebuilding my life wasn't a project in the conventional sense.

There was no neat timeline.

No approved budget.

No guaranteed outcome.

No client waiting for delivery.

No project manager to call.

No one to blame.

No one to impress.

Just reality.

And me.

But the principles still worked.

Understand.

Identify.

Reframe.

Discover.

Build.

Recover.

Adapt.

Empower.

Evolve.

One step at a time.

Not because I suddenly became wise.

I didn't.

Because eventually you learn that wisdom is often just experience that has survived long enough to become useful.

I am still learning.

I still get things wrong.

I still occasionally make decisions at the wrong time that look considerably less clever the following morning.

Some things never change.

But I no longer believe that failure is the opposite of success.

Failure is information.

An abandoned project can teach you something.

A failed idea can teach you something.

A career can end.

A business can disappear.

A relationship can end.

A life you thought was permanent can change completely.

The question is what remains.

What can you carry forward?

What did the experience teach you?

What principle survived?

That, perhaps, is the only measure that finally matters.

Because projects fail.

Plans fail.

Businesses fail.

Sometimes entire versions of our lives fail.

But if we are paying attention...

the principles don't.

And those principles became the foundation for rebuilding my life.

THE PRINCIPLE

The principles that work on projects... work on a life.

Not because life is a project.

It isn't.

Life is messier.

Less predictable.

Much less interested in your carefully prepared schedule.

But the things you learn while trying to make something work can become remarkably useful when everything else stops working.

The projects ended.

The principles remained.

THE QUESTION

When everything changes, what remains?

Perhaps that's the real purpose of experience.

Not to prevent things from changing.

Not to prevent things from ending.

But to make sure that when they do...

something comes with you.

09 - EVOLVE

The principles that work on projects... work on a life.

When everything changes, what remains?

FINDING THE TRACK