Winning and Risk Management

There’s a highly-regarded self-coaching book called “Sail, Race, and Win”, by Eric Twiname and Cathy Foster. In the book is a neat description of how to win in a race.  They ask the reader to imagine a descending escalator, with lots of people, representing the competitors, walking up the escalator.  The goal being to remain in the same spot they started in as much as they could manage to. They can walk up to the same pace that the escalator is going down, but they can't walk up faster than that.

Since no one’s allowed to go faster than the pace of the escalator, the would-be winner will have to focus on not making mistakes rather than walking faster than the pace of the escalator.  Any mistake, no matter how momentary, will set you back a little, possibly allowing someone behind to move out in front of you.  The more mistakes and lapses you make, the more you are pushed back relative to your starting position, and relative to the other competitors.

Now since you can't go faster than the pace of the escalator, you can't make up the distance you lost by putting in extra effort. The best you can do is to make no more mistakes.  The only way you can get ahead of those in front of you is if they make mistakes.

I haven’t seen winning explained in this manner before, and despite its oddness, it has a certain valid point.  Twiname and Foster come from the world of sailing.  Perhaps the idea of not being able to outpace the escalator comes from their world, where your progress depends on the winds and the tides -- you can't go faster than what the elements or the environment allows.

The image seems rather useful when thinking about how risk impacts business.  A company cannot make more money than what its environment allows.  For example, if you are a consumer goods company, how much you can sell is moderated by the size of your market, the demand for your product, and the competitive dynamics of the industry you are in. In a market with 10,000 customers and 5 competitors, you just cannot make sales equivalent to a market of 20,000 customers.

And while you can't get ahead, you can definitely be set back.  The key to winning then becomes minimising the setbacks. From an operational basis, you are constantly being set back if your production costs are more than the competition’s. From a discrete and pulsating basis, you are set back each time a risk eventuates which impacts you negatively.  The longer and more expensive it takes you to recover, the more you are set back.  The key to winning in this case is to ensure that you minimise your risk eventuations and minimise their impacts.

You can look at risks as these setbacks.  It is in your interest to avoid them as much as possible, and to be able to recover as quickly as possible.  Even then, you can only recover to a point less better than where you started. Hence, reducing the occurrences of risks become a key factor in winning.

Is managing a project like conducting an orchestra?

Managing a project is so frequently compared to conducting an orchestra that the comparison has almost become a cliché. 

I understand the comparison. There is a slight similarity between conducting an orchestra and managing a project. The similarity lies in the fact that both the conductor and the project manager do not make the actual product. They simply orchestrate the work of those who produce.: a conductor controls the performance of many different specialists, combining the individual performances into one single harmonic product.

There are a couple of key differences though.

The first difference is that an orchestra has had time to rehearse and practice over and over exactly what they are supposed to do. Indeed, they must refine their work until it is flawless, before the actual live execution.  A project team hasn't got that luxury.  It has only one pass at executing the project.  

An orchestra will never be asked to work faster, redo a task, or cut the scope of a musical piece.  There is no such thing as crashing the music by playing faster.  Project teams have deadlines to meet and often need to redo work and work faster than normal.  An orchestra performance is an operation. It is perhaps the smoothest of operations.  There is no change of plans.  The audience's (stakeholders) mood will not change what the orchestra will play or how they play it.

But then again, why use a conductor as the focus of an analogy? Every orchestra presentation has an actual project manager orchestrating it, scheduling the rehearsals, picking the team, picking the conductor, selecting alternate members, etc. 

I think a more appropriate example is that of a coach in a basketball game.  The coach does not deliver the points, he manages the team so that they deliver the points. 

What shall I write about?

What is this blog for?  Why did I put up this blog?

First, I want a place to write down some of my thoughts, and play with them.   Writing helps you clarify your thoughts.

Second, this provide a place for me to communicate some of my ideas.  You may find them useful, or you may find them dangerous and mistaken (in which case, please let me know).

Third, this is an outlet to write in a less formal way and to sharpen my writing skills (and boy do they need sharpening).

Fourth, this is a place for me to jot down ideas that get my attention.

What subjects will I cover?

I do not want to limit my subjects, but it will surely include those areas of my professional interest: systems engineering, project and programme management, risk management, lean and agile solutions, organisational behaviour, computing, etc.

Who is my target audience? 

Me.  I am writing mainly for myself, but you are welcome to listen in.