I had recently bought the Kindle, the e-Reader from Amazon - the first book on it was Atul Gawande's "Checklist Manifesto" - this book was recommended by two people I know, one from work and by another friend of mine from college, who I had reconnected with recently. What interested me in the book was the reviews that talked about resolving complex problems. I've personal interest in the theory of complexity and have
my own perspective of it.
After reading the book, I believe there is a slight distinction - there are problems which are "complex" in nature in trying to find solutions and then there are problems that have known solutions but the complexity is in execution. The book is about the latter part of it.
Interesting part of it is Gawande' talks about Brenda Zimmerman and Sholom Glouberman (Univ of Toronto's) work on Complexity... Its another matter that it is very similar to Cynefin framework (that had interested me significantly and made me write
my perspective on solving problem in complex space). Gawande, in his book, introduces the concept as following:
systems can be understood as being simple, complicated, complex. Simple problems, such as following a recipe or protocol, may encompass some basic issues of technique and terminology, but once these are mastered, following the "recipe" carries with it a very high assurance of success. Complicated problems, like sending a rocket to the moon, are different. Their complicated nature is often related not only to the scale of a problem, but also to issues of coordination or specialised expertise. However, rockets are similar to each other and because of this following one success there can be a relatively high degree of certainty of outcome repetition. In contrast complex systems are based on relationships, and their properties of self-organisation, interconnectedness and evolution The metaphor used for complex systems is like raising a child. Formulae have limited application. Raising one child provides experience but no assurance of success with the next. Expertise can contribute but is neither necessary nor sufficient to assure success. A number of interventions can be expected to fail as a matter of course. Uncertainty of the outcome remains. You cannot separate the parts from the whole.
After classifying the problem-types as above, Gawande goes ahead and calls the challenges he describes in his book, as complex. Its erroneous since the most problems he describes are complicated - i.e., they are in the knowable space (as per Cynefin framework) and it just needs diligence in execution. The "complexity" in execution is a function of two things - the number of tasks that needs to be done without any errors, in the right sequence and short time duration within which those tasks needs to be executed...
If you let go the above issue, I'd still think his book is worth a read - he tells a good story. He has quite effectively woven a good front in building up the theme and then presented the solution. He could have been bit more concise, but I guess he was driven by a page-count-need ! Gawande's view is that in a complicated problem, due to its magnitude, the difficulty lies in getting the order, interfaces and hand-offs right amongst equals who bring in different competencies to the execution of the solution; A very visible and concise cook-book, not the one that tells what to do (which the experts usually know), but the one that is a gentle reminder/nudge. He calls this a
checklist. I, personally agree to his solution. When you are up against time and pushed to do a number of actions (in a sequence that is essential), I'd rather have a guide (or a checklist) that helps me to do those. Personally, I'd rather take any guidance that would help me get the syntax right, that would help me spend my competency on the semantics of doing my work well.
Another key point of note that he talks about in the book, but I believe he has not highlighted it enough is the adoption of checklist. He describes how tough it was to introduce a checklist in the medical profession, when compared to the profession of flying. The essence being is that checklist are seen as a affront by the expert (surgeons) who believe the checklist are an insult to their authority, knowledge of systems and competence. It would have been of greater use, if he had also addressed some of the work, that led up to a successful adoption of checklist. Was it change management ? Was it working through the chain of command ? Was it through data ? Was it something else ? The message of checklist came through clearly in the first few chapters; instead of repeating it across with several more examples, it would have been a better, rather complete, if he had discussed the adoption too...
In any case, even though it falls short in some areas, a good book to read. Read it if you've the time, $$s and you'd want to know more than what is written above ! :-)
