Tag Archives: communications

If at first you don’t succeed – try, try again. But think about changes first.

On June 24th 2014, it is the 700th anniversary of the Battle of Bannockburn, at which the Scots defeated the English, and their ruling King, Edward the second.

The legend of Robert the Bruce ahead of the battle, hiding out in a cave on the run after six defeats,  is renowned the world over. The Scot saw a spider building a web. Time and time again the spider would fall and then climb slowly back up to try again. After many attempts, the spider managed to begin to weave a web on the cave wall and achieved its aim. Robert the Bruce, so the story goes,  was inspired by the spider not to give up and went on to defeat the English at Bannockburn. The motto of the story is usually:

“If at first you don’t succeed – try, try again.”

Whilst perseverance is an admirable trait, stubborness may not be. Trying the exact same thing which failed previously, in precisely the same way, may be said to be either determined or foolish. Trying again, but incorporating learnings from the past failure with flexibility to incorporate learning-by-doing, seems an altogether smarter choice.  Modifications for improvement and changes in action and their execution based on lessons learned have a higher chance of success*.

“Bannockburn is arguably the most famous battle to be fought and won by the Scots in Scotland, but it is widely acknowledged to be more than that— it continues to conjure up ideas of freedom, independence, patriotism, heroism, perseverance, and triumph against overwhelming odds.” [Bannockburn Heritage Centre]

In projects, overwhelming odds against achieving success can be built-in from the beginning, through lack of foresight to plan how to measure it. If you don’t know how you will measure success, it is hard to know when it has been achieved and at what cost. To measure success, you first need to know tightly what are your defined project scope and purposes. This helps set the goals of what you want to achieve technically, its  human understanding and crucially, expectations of how and when success will be measured.

Steve Jobs is sometimes quoted:

“You can’t just ask customers what they want and then try to give that to them. By the time you get it built, they’ll want something new.”

Trying again isn’t always about trying the same model, rolling out the original communications plan louder, or slower, or just again, but about embracing changes and adding in flexibility for future change.  Change is not a single event, but a process, and any attempted project launch needs to be prepared to learn from the past but also to plan for the future, as that process occurs. The scope of the project however, must stay tightly controlled, or risks losing control of budget and achieving the project aims.

By being visionary about what will be needed in future and aiming to be ahead of the design specifications there is room left for learning-by-doing in the ‘how’ you want to achieve the project, but it can’t allow deviance to become an entirely different ‘what’ of project scope.

To try and meet a future goal, basing it only on present specifications and expectations, means it will be outdated and fail when you reach the future implementation date. By launch date, the design and functionality are already outdated and not fit for purpose.

To compensate for that, measurable bite-sized chunks of projects, can be a way of frequent checking in to see if you are still on track with the overall aims of what you want to achieve, whilst retaining the flexibility to adapt to the human aspects of progress, and how you will achieve it.

Measures of success therefore need to be taken frequently to stay on track, ensuring alignment with your defined project scope and purposes. ‘Checking in’ to see if you are still on the correct course. This helps set the goals of what you want to achieve technically, in human terms and on a timeline, which crucially sets expectations of how and when success will be seen to have been achieved.

Some of the success at Bannockburn was recorded at the time in poetry. More recently, the themes have been preserved in music.

If the Flower Of Scotland tribute to Robert the Bruce, the Scots’ ‘almost National Anthem’ at least in terms of sporting events, is not your thing, you might prefer Aaliyah’s rendition of the theme, Try Again. Though her wardrobe choices are slightly more surprising than the Corries.

The theme is the same. To think again, before trying again, is wise.

“Those days are past now
And in the past they must remain
But we can still rise now
And be the nation again
That stood against him
Proud Edward’s Army
And sent him homeward,
Tae think again.”

Flower of Scotland, the Corries, 1967

*****

For more recent celebrations see: http://www.visitscotland.com/

Photo credit: Dilip Barman via photo.net ‘ thistle near Bonar Bridge north of Inverness, Scotland.

*My lessons learned from experience of change management in  global projects rolling out SAP, 2001-2006.

Appendix F. For successful technology, reality must take precedence over public relations.

Richard Feynman
Richard Feynman via brainpickings.org bit.ly/1q1qWLt

June 6th 1986. Six months after the disaster, the Report to the Presidential Commission was released about The Space Shuttle Challenger.

Just over twenty eight years ago, I, like fellow children and citizens around the world, had watched the recorded images from January 28th 1986. We were horrified to see one of the greatest technological wonders of the world break up shortly after launch and crash into the sea minutes later. The lives of Challenger’s seven crew were lost, amongst them the first ‘ordinary citizen’ and member of the teacher in space project, mother of two, Christa McAuliffe.

As part of the follow up audit and report, Richard Feynman’s personal statement was included as Appendix F. Personal observations on reliability of the Shuttle. You can read his full statement. Below are just his conclusions and valuable lessons learned.

“If a reasonable launch schedule is to be maintained, engineering often cannot be done fast enough to keep up with the expectations of originally conservative certification criteria designed to guarantee a very safe vehicle. In these situations, subtly, and often with apparently logical arguments, the criteria are altered so that flights may still be certified in time.

They therefore fly in a relatively unsafe condition, with a chance of failure of the order of a percent (it is difficult to be more accurate).

Official management, on the other hand, claims to believe the probability of failure is a thousand times less. One reason for this may be an attempt to assure the government of NASA perfection and success in order to ensure the supply of funds. The other may be that they sincerely believed it to be true, demonstrating an almost incredible lack of communication between themselves and their working engineers.

In any event this has had very unfortunate consequences, the most serious of which is to encourage ordinary citizens to fly in such a dangerous machine, as if it had attained the safety of an ordinary airliner.

The astronauts, like test pilots, should know their risks, and we honor them for their courage. Who can doubt that McAuliffe was equally a person of great courage, who was closer to an awareness of the true risk than NASA management would have us believe?

Let us make recommendations to ensure that NASA officials deal in a world of reality in understanding technological weaknesses and imperfections well enough to be actively trying to eliminate them. They must live in reality in comparing the costs and utility of the Shuttle to other methods of entering space. And they must be realistic in making contracts, in estimating costs, and the difficulty of the projects.

Only realistic flight schedules should be proposed, schedules that have a reasonable chance of being met.

If in this way the government would not support them, then so be it. NASA owes it to the citizens from whom it asks support to be frank, honest, and informative, so that these citizens can make the wisest decisions for the use of their limited resources. For a successful technology, reality must take precedence over public relations, for nature cannot be fooled.”

Richard Feynman, 1918 -1988

“The Challenger accident has frequently been used as a case study in the study of subjects such as engineering safety, the ethics of whistle-blowing, communications, group decision-making, and the dangers of groupthink. It is part of the required readings for engineers seeking a professional license in Canada and other countries.” [Wikipedia]

Feynman’s Appendix F: Personal Observations on Reliability of the Shuttle is well worth a read in full.

From a business management point of view, Lessons Learned are integral to all projects and there is no reason why they cannot apply across industries. But they are frequently forgotten or ignored, in a project’s desire to look only ahead and achieve future deliverables on time.

Lessons learned can make a hugely important contribution to positive change and shaping outcomes. Assessing what worked well and how it can be repeated, just as important as learning from what went wrong or what was missing.

Public relations efforts which ignore learning from the past, and which fail to acknowledge real issues and gloss over reality doom a project to failure through false expectation. Whether due to naivety, arrogance, or under leadership pressure, it can put a whole project in jeopardy and threaten its successful completion.  Both internal and external stakeholder management are put at unnecessary risk .

In the words of Richard Feynman, “For successful technology, reality must take precedence over public relations.”