Home
About the Guild
Articles
Books
–New Books
–Guild Books
–Guild Library
Consulting
Contact us
Resources
–Requirements
–Software Engineering
–Project Management
–Other
–Cocktails
Requirements Template
Seminars
–Mastering Requirements
–Risk Management
–Requirements Modeling
–Mastering the Requirements Process part II
Services
–Litigation Support
–Project Clinics
–Physical Exam
Volere

 

If you build software, chances are that you and your organization are using some technique developed by The Atlantic Systems Guild.


July, 2009

the Atlantic Systems Guild

Perspective: Summer 2009

 

Fear of Failure

Everybody is afraid of something. Heights is a common fear, some people fear spiders or snakes or dogs or confined spaces or the dark. None of these is exactly rational, but fear is part of the psychological makeup of almost all humans—it is one of our prime motivators. One of the most common fears (30% of Americans apparently) is the fear of speaking in front of a public audience. More people say they fear this more than they do death. This gives rise to the notion a third of the population would prefer to be in the coffin than give the eulogy.

The fear I am concerned with here is the fear of failure. Specifically, I am looking at an employee's fear of failing in the eyes of the manager or in the opinion of his/her peers. You can also think of it as a fear of public ridicule. This is not always a self-grown fear; nevertheless, it is a fear that is possibly the single largest inhibitor of innovation. It is worth looking at more closely.

xx
James Robertson

Consider this: an employee who is afraid of failure does not make suggestions for improvements or innovations. To do so risks disapproval. The employee knows that the manager's role is almost always to protect the status quo—if something is working, then why allow a disruptive innovation? As soon as the manager, or anyone else for that matter, says something along the lines "No, that's not going to work" or "we don't do that here", then the employee has failed in his/her own terms. So why reveal one's ideas by proposing innovations? They could well be the best innovations the organisation has ever heard, but they are not going to be heard—the fear of failure means keeping ones mouth closed.

Thankfully, fear is not always present. As I visit various organisations talking to them about innovation, I am struck by the dichotomy between the fearless and the fearful. Fearless organisation permit—indeed encourage—their employees to have ideas and start the process of evaluating and refining the idea. I hear things like, "That's a great idea. I have no notion of whether it will fit with our product line, or whether we have a market for it, but let's look further into it." The person having the idea receives nods of appreciation from the peers present, and significantly, all of them feel safe to suggest innovations.

I watched with satisfaction the participants at one of my local government clients. I was running a workshop on innovation, and the teams were responding with some remarkable innovations that would change the services they provide. There was no fear (keep in mind that this is a local government organisation). Instead, the team members made changes to their services without any of the anxious "will we be allowed to do this?" kind of remarks so often heard in these circumstances. I loved the smiles of delight when they realised they were making changes that improved their service—this after all is the point of local government—and in some cases made provision cheaper. I am happy to report that the innovations have a life beyond the workshop. Most of them are now part of the organisation's regular list of services.

It might seem strange that to be innovative, it is necessary to have no fear of failure, when failure is a significant factor in innovation. Most innovations fail. James Dyson needed 15 years and over 5,000 prototypes before he brought his bagless vacuum cleaner to market. The great Thomas Edison—perhaps one of the most innovative people ever to live—is quoted as saying "I have never failed. But I have found 10,000 things that do not work." Michael Dell accepts failure as part of his business. But instead of blame, the Dell peers get together after some failure and determine what—not who—went wrong and what they can learn from the failure.

Not every innovation works right out of the bag. Some do, and some take time before they are ready for prime time. Some sound good at first hearing but reveal themselves later to be impractical. So this kind of failure is part of what we do, or what we should be doing. Accept it. I am by no means advocating that we should reward failure by handing out obscenely large bonuses as seems to be happening to CEOs and Chairmen in the banking and finance industries. I am advocating that we accept failure and treat it as an unavoidable aspect of being innovative.

    "You have to be wiling to repeatedly fail—and to be misunderstood." — Jeff Bezos

None of this is meant to say that all we have to do is rid ourselves of fear-inducing managers, or anti-innovative organisations, and all will be sweetness and light. Some people carry the fear of failure regardless of the organisation they belong to. This is neither good nor bad, but simply that people who are afraid of failing will never be innovators.


James Robertson
London
April, 2009



Past Perspectives

xxThe Winter 2008/09 perspective entitled IT Financing was written by Tom DeMarco


xxThe Sumer 2008 perspective entitled Groundhog Day Part II was written by Tom DeMarco


xxThe Winter-Spring 2008 perspective entitled Groundhog Day was written by Tom DeMarco


The Winter 2007 perspective entitled Teams Don't Move was written by Steve McMenamin


The Fall 2006 perspective entitled Three Hours to Three Years was written by Peter Hruschka.


The Spring 2006 perspective entitled The Web Undone by Tom DeMarco.


The Winter 2006 perspective entitled Have We Finished Yet? was written by Suzanne Robertson.


The Fall 2005 perspective entitled Adult Behavior on Projects was written by Tim Lister.


The Summer 2005 perspective entitled No Great Leaps Forward? was written by Steve McMenamin.


The Spring 2005 perspective entitled Mastering Software Architectures was written by Peter Hruschka.


The Winter 2004 perspective entitled Early Involvement of Testers was written by James Robertson.


Amazon.com Links from this site to Amazon.com or Amazon.co.uk are done using Amazon's associates program. That Amazon.co.ukmeans, that if you use one of the links and end up buying the book, we get a cut. We are not getting rich on this, but thought that you should know that it is happening.


The contents of this site are copyright © 1995-2009 Atlantic Systems Guild Inc. and Atlantic Systems Guild Limited. Material may be reproduced provided this copyright notice is attached and the source is acknowledged. Please pay us the courtesy of notifying the author if you wish to use material from this site.



Happenings


2009
James Robertson teaches Mastering the Requirements Process in Brussels, August 11-13. Please contact I.T.Works.
Brussels, September 7,8. James Robertson teaches Becoming an Innovator . Please contact I.T.Works.
Tromso, September 7,8. Suzanne Robertson is in for Mastering the Requirements Process part 2 . Contact Den Norske Dataforeningen for details.
September 9-11, Suzanne Robertson is in Tromso for Mastering the Requirements Process sponsored by Den Norske Dataforeningen
September 14-16, Tim Lister teaches Mastering the Requirements Process in Washington, DC for Software Quality Engineering.
James Robertson presents Mastering the Requirements Process in London, September 15-17. Contact IRM UK Strategic IT Training
Suzanne Robertson teaches Mastering the Requirements Process part 2 in Brussels, September 15, 16. Please contact I.T.Works for details.
September 17,18 Tim Lister teaches Requirements Modeling. in Washington DC. Contact Software Quality Engineering for details.
London, September 28. James, Suzanne Robertson and Neil Maiden present a tutorial entitled "Innovation, Creativity and their Role in Business Requirements". Please see Business Analysis 2009 conference for details and registration.
James Robertson teaches Mastering the Requirements Process in Brussels, October 6-8. Please contact I.T.Works for details.
October 12-14, Tim Lister is in San Diego to teach Mastering the Requirements Process for Software Quality Engineering.
Leiden, October 13-15. Suzanne Robertson teaches Mastering the Requirements Process . Please contact Array Publications for details.
October 15,16 Tim Lister is in San Diego for Requirements Modeling. Contact Software Quality Engineering for details.
Reykjavik, October 19,20. James Robertson teaches Becoming an Innovator at the University of Iceland. Please contact Ragna Haraldsdóttir.
Suzanne Robertson teaches Mastering the Requirements Process part 2 in Rome, October 26 - 28. Contact Technology Transfer.
Suzanne Robertson presents Mastering the Requirements Process in Melbourne November 4-6 for Software Education
James Robertson presents Mastering the Requirements Process in Canberra November 4-6 for Software Education
Wellington, November 9-11. Suzanne and James Robertson present Mastering the Requirements Process . For details please contact Software Education
Suzanne Robertson teaches Mastering the Requirements Process part 2 November 12, 13 in Wellington. Contact Software Education for details of this advanced class.
Wellington, November 12,13. James Robertson presents Innovation & Requirements . For details please contact Software Education
Auckland, November 16-18. Suzanne Robertson teaches Mastering the Requirements Process . For details please contact Software Education
Wellington, November 19,20. James Robertson presents Innovation & Requirements . For details please contact Software Education
November 30 - December 2, Suzanne and James Robertson are in Sydney for Mastering the Requirements Process sponsored by Software Education
Melbourne, December 3,4. Suzanne Robertson teaches Mastering the Requirements Process part 2. Contact Software Education for details of this advanced class.
James Robertson and Martin Davie present Innovation & Requirements December 3,4 in Sydney. For details please contact Software Education
Suzanne Robertson teaches Mastering the Requirements Process part 2 December 7,8 in Sydney. Contact Software Education for details of this advanced class.
Christchurch, December 9-11. James Robertson teaches Mastering the Requirements Process . For details please contact Software Education

In Depth

Adrenaline Junkies and Template Zombies has won the 2009 Jolt Awards best general book.
The Guild's new book Adrenaline Junkies and Template Zombies - Understanding Patterns of Project Behavior is now available. Orders at Dorset House Publishing and Amazon.com


NEWS: IEEE Software magazine has selected "Provoking Creativity: Imagine What Your Requirements Could Be Like" by Neil Maiden, Alexis Gizikis and Suzanne Robertson as one of the Top Picks for influential articles over the 25 years of IEEE Software. Download pdf.


See video commentary about the Adrenaline Junkies book project.


NEWS: Adrenaline Junkies and Template Zombies has been adopted by the Copenhagen Business School for Prof. Rob Austin's course, "The IT Manager as a Business Leader."


The new Guild book has been published in German Adrenalin-Junkies und Formular-Zombies - Typisches Verhalten in Projekten. The book demonstrates the effect of behavior on project success. Please visit Hanser or Amazon.de for more details.


Platicando con Tom DeMarco: interview (in Spanish) with Mexico's Software Guru Magazine. "Creo que todos hemos comprendido que el aspecto sociologico de los proyectos es igual o mas importante que el tecnologico ..."


Suzanne Robertson has written an Executive Report "Requirements for Managing Requirements" for the Cutter Consortium's Agile Product and Project Management advisory service. Download a free copy
The Microsoft Store on Microsoft's Redmond campus will for the first time start carrying books from publishers other than Microsoft Press. Mastering the Requirements Process is one they have chosen to stock in this initial test phase.
The Volere Requirements Specification Template has been translated to Spanish. Thanks to Paul Babic of Smartmatic for the translation. A Microsoft Word version is available from the Volere site.
Suzanne and James Robertson announce the publication of the second edition of their best selling Mastering the Requirements Process
In response to many requests we have started a Volere Requirements discussion group.

home | about | articles | books | consulting | events | litigation support | resources | physical exam | clinics | template | seminars |services |

Contact the Guild top of page