As with many such ideas the idea of looking a “worst practices” came in a moment of epiphany.  I was sitting in a hotel hallway chair waiting for a colleague to emerge from a conference presentation.  I had just sat though a wonderful presentation detailing how an information technology team had directed itself and its company though a massively complex software development and implementation process.  At every turn they had faced problems and at each crossroads and conflict their management plan had guided them to success.  Clearly this team and their project were a shining example of the “best practices” in IT development.

As I sat there I was both in awe of their insight and dedication to following their framework through thick and thin – and feeling depression as I reflected on my previous efforts to manage such projects myself.  In contrast to their clarity of vision and incisive action my projects always seemed to find me in a muddle of data of questionable accuracy, unplanned problems of indeterminate cause or solution, and goals that shifted long before they were achieved.  What, I mused, was I doing wrong?  Was I the only person who failed to craft and lead such efforts?  Or, was it possible, that these enlightened presenters had only told me about had gone right in their efforts?  To be sure, they had mentioned problems, but their narrative showed how they had solved those with near prescient insight and skill.  And ultimately their description of the best practices that had led them to success were indeed insightful and useful.

But, I wondered, I’ve always found I learned more when something went wrong than we things went right.  While I was always happier when things were right, the heuristics that I rely on, the axioms that lead me into and through my next challenge, are those learned in the crucible of challenge.  Instead of looking at what went right in a project – wouldn’t it be more educational (okay – and more entertaining) to look at what went wrong?