Sorry seems to be the hardest word

I've been getting a lot of stick about my car. Jeremy Clarkson berates me every week calling me a "Pious Driver". But it suddenly got a lot worse. Now it's open season for Toyota drivers: first with the accelerator pedal problems, then with the brake problems on newer models of the Prius than mine, and now the steering on the Corolla.

I joined an internet forum to find out how to connect my bluetooth phone to the car and I get a cascade of comments: "that's the least of your problems" was the kindest. The poster slogan "The car in front is a Toyota" has graffiti "lucky it's not behind you".

So it was good to see Toyota president Akio Toyoda making a sincere bow of apology. I accept his apology.

It is the sign of a good leader to take responsibility for errors and failures of their team.  Then to fully take on board the lessons learned.

“FIRST, get the cow out of the ditch. Second, find out how the cow got into the ditch. Third, make sure you do whatever it takes so the cow doesn’t go into the ditch again.” This is the advice - quoted by the Schumpter business column in the Economist - that Anne Mulcahy, the former boss of Xerox, says became her mantra as she fought successfully to revive the fortunes of the copying and printing firm.

And I am talking about sincere apology too. None of this "SORRY. This bus is not in service." or spinning to play the issue down. You have to admit the cow is in the ditch.

To "do whatever it takes so the cow doesn't go into the ditch again" Toyota now offer a five year warranty, and their slogan in the UK is Your Toyota is My Toyota accompanied by pictures of a committed local workforce.

Some say that Akio Toyoda did not bow low enough. I say that we could do with a lot more sincere bowing for apology. Bow .. Sir Fred Goodwin. Bow ..Victor Blank. Bow ..Rick Fuld.

I have a cunning plan..

Building your project plan is the most critical step in any project. Your plan is the basic way of measuring the progress of the project - and if you can't measure it you can't manage it. If your project is to be successful it must start with a solid plan. Much of comedy of BlackAdders sidekick and servant Baldrick lies in the unachievability of his "cunning plans" and are there lessons to be learned from the succinct communication of his plans?
But how can we access the quality of the project plan before execution - or before it goes pear-shaped? Here are my "top three"

• Completeness. Has everything been included? The best way to validate is through product based planning. You take the deliverable product and simply break it down into its component parts and assemblies (where there is some effort to put the parts together). So when planning a conference one area will be preparation of conference documentation - made up of component handouts for each session with the extra item of assembling the handouts into the conference binder. There should be activities corresponding to each component part and assembly.
• Accuracy. As well as requiring a reliable basis for estimating the effort required for each task the accuracy of the interdependance of tasks and resources is critical. So a simple plan (below) to code and test a simple client-server not only requires the accurate estimation of each task - overrun of any task will cause a delay to the whole project -  but also the accurate scheduling of resources. The resource to perform task 2 needs to be available immediately task 1 completes to meet the schedule. Overruning task 1 will waste the time for the resources committed for task 2 - which may also be the same resources for coding in task 3? If the complexity of the data needed is underestimated that will extend not just the database setup but the middle tier, the user interface and testing. 

• Socialising the plan. Most importantly the plan needs to be checked and committed to by everyone involved in the project. Too often the gantt chart will be produced by the PM - probably in Microsoft Project - and emailed out. However how are responses expected? Is there any narrative? Is there a list of assumptions used? Does everyone has the skills to use MS Project or even the software? So the ownership of the plan - and more importantly the committment to the plan and its accuracy- remains with the PM. Any mistakes remain the PMs problem. "I don't understand how the PM estimated this task so if I take longer then it's the PMs fault."
  To get commitment and belief in the project plan it needs to be "socialised" and fully communicated to get ownership by everyone involved. This communication needs innovative approaches - See Geof Lorys great "Lego My Schedule" and John Estrellas "How to create visual project timelines". But more importantly don't just depend on gantt charts; use narratives, brainstorming, risk workshops, feedback surveys or any way you can to get a true two way dialogue going to build trust and group committment. 

Drive a stake through this cliché

Kill off "Stakeholders". Not my esteemed business partners, suppliers, customers, technology, providers, shareholders, backers, funders, board members: I love you. Really.

It is just the word. "Stakeholders". Worse still the phrase: "Stakeholder Management". It is very convenient shorthand - and I have been guilty using it in CVs and general project communications. So what's wrong?

It's lazy. The shorthand conveniently lumps everyone involved in a project or enterprise into a single bucket. But they are all different. And they need to be treated differently. What is their stake? They are all in it for their own benefit, and they have to be approached and communicated based on their interest.

It's patronizing. You don't "manage" stakeholders. They cannot be herded like sheep or bossed around. You can influence their expectations and get them to deliver their commitments, but you don't manage stakeholders.

It's dangerous. Having "Stakeholder Management" as a simple heading encourages the mentality that this is a single task, which can be done once, or in a single communication, or in a regular meeting. Its continuous. It is different for each counterparty involved. It is multi-media. Its two-way.

Communicating change requires a different approach for each individual.

Communicating to people in an office about an upcoming move can't be done in a single communication. Some will want to find out about the carpet colour or their chair, and will complain like hell about the new office if not involved. Others will want a detailed document about the move, being told each step in the move. Others will just want to be shown the boxes to pack, and the labels to stick on their belongings. Some will only be interested what pubs and cafes there are near the new office, or the route between the two. You have to communicate for every style and every possible concern.

I first came across "stakeholders" in employee communications from a bank I worked for. They communicated the need for change for the benefit of stakeholders: shareholders, management, employees, customers. The expensively produced video showed a bank branch manager who was now happily delivering milk. It just left everyone asking "Why?" and seeing a cynical underlying message. It failed because it tried to communicate change for the greater good, when you have to sell the benefits of the change to the individual.

I recently came across the one time you must use stakeholder; a small private bank to the horse racing community. They look after the prize money until it is paid out to the winner. They are the true stake holder.

So let's kill off "stakeholder management" - unless you are really managing a real stakeholder.

Passing the point of no return

Pilots will know that when you are taking off there is a speed called V1. The plane has reached such a speed that there is not enough runway ahead of you to stop. So you are committed to take-off. Unfortunately V1 is usually less than V2 - the speed at which the plane can safely get off the ground. Any change after passing V1 – like a critical engine failure - can be catastrophic.

Many projects will feel like they have a similar point of no return. You have spent so much of time, effort, money and emotional investment that you have to go on. Going back to your old process may no longer an option: it is out of support or it won’t support new statutory requirements.
So what can you do if your project starts to fail after it has built up such a momentum?

Firstly Avoidance: your project management should have identified the risks before they happen, and mitigated them – a four engine plane is inherently safer that a single engine plane.

Secondly Act Decisively: A crew faced with an engine failure on take-off has to act quickly. They will have rehearsed the routines in simulators. Faced with a real situation they act in a split second. Can your project objectives and business case be quickly reconfigured so you still have a viable configuration? Throw out the catering trolleys to reduce weight for take off! But you can only act decisively if you have identified the risk.

If You Can, Stop. It is better to run off the end of the runway than to try to take-off without enough speed.

Finally Learn Lessons. All Air Incidents must be reported. There should be no fear of victimisation. Spin, cover-up or denial will only cause future catastrophes. If the crew followed procedures then they have nothing to fear. "Sully" Sullenberger, the US Airlines pilot who put down his crippled plane on New York’s Hudson River became a national hero. A project failure should lead to a process improvement.
A bank that bought PCs to re-equip its branch network found they were underpowered for the teller application when it was delivered. They could have sold them immediately to recover some cost but that would have realised an accounting loss. So the PCs sat in a warehouse for three years until they could be quietly scrapped. Was that the right outcome for me as a shareholder?