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.

The Working Advisor

The title of this blog is inspired by Leonard Sayle’s book, "The Working Leader: The Triumph of High Performance Over Conventional Management Principles"

A leader gets his hands dirty and interact with the day to day environment, adjusts his ideas to accommodate reality.

I am a consultant.  To many people, the word consultant brings to mind a professional who comes in to an organisation, looks at problems, writes up a document recommending solutions, and then leaves, without having any responsibility for implementing those recommendations.  Oh, and the sends a huge invoice for his services.

I believe a consultant is one who, although they may do the above, stays and helps execute the ideas they recommend. 

Execution and implementation reveals faults.  There is no harsher or more fair judge than reality.  Ideas that look good on paper may collapse when tried.