Showing posts with label patient safety. Show all posts
Showing posts with label patient safety. Show all posts

Wednesday, November 12, 2008

What about GM?

Toyota has a track record of taking over totally dysfunctional GM plants and making them functional by just changing management, with same unions, same facilities, same labor, same equipment. See history of NUMMI in Fremont, CA, going from GM's worst plant to the best in one year.

references:

Becoming Lean , Jeffrey Liker, page 62-63
http://books.google.com...

Stop Rising Healthcare Costs Using Toyota Lean Production Methods

By Robert Chalice (page 53)


http://books.google.com...

There may be no reason to lose the jobs, plants, or contracts.

Actually, what changed was not just management, but the whole underlying philosophy on which the plant was managed, which is the crucial change.

Chalice cites these factors as the new "five core values: teamwork, equity, involvement, mutual trust and respect, and safety."

In short, workers were treated as first class partners in the plant, not as some kind of "asset" to be "managed" and "controlled." They were listened to. They were respected.

Yes, that does make all the difference, in automobiles, as Liker points out, or in hospitals, as Chalice points out, supported by the Keystone study of John's Hopkins Dr. Peter Pronovost in Michigan, showing that when nurses were actually listened to by doctors, patients were significantly better off and had better outcomes.

Gasp. I took Dr. Pronovost's class in Patient Safety last year, and, yes, it really is that "simple." Culture drives safety and productivity. Culture drives the bottom line, not technology.

If you want things to work, you have to learn about human beings, and culture, and work within the constraints that puts on you. Humans are not machines and work way better than machines if allowed to (McGreggor's Theory Y), or way worse than machines if forced to (Theory X).

It's the job of the stockholders and stakeholders to realize that, and put management in place that will support the work force instead of trying to exploit it.

Period.


Monday, May 14, 2007

My Comair 5191 crash analysis now available

Because "systems thinking" is a difficult concept to describe, I wrote and just posted a paper analyzing a commercial aircraft disaster - the crash of Comair 5191 - in Lexington Kentucky, August, 2006. This is a full-length (30 page) analysis with pictures and diagrams and source materials, aside from the cockpit voice recorder transcripts, which are linked below. The final NTSB findings on the case are not yet out, to my knowledge.

It's a little rough around the edges, but it starts with the basic astounded question of how two, fully trained pilots, not under pressure, could taxi to and attempt to take off from the wrong runway, resulting in the death of all on-board except the one who was flying the plane, who was pulled from the flaming wreckage by a first responder. The runway was a few hundred yards too short for the plane to have made it off the ground safely.

So, it goes from "How on earth could this have happened!?" to "Oh... There but for the grace of God go I." Only the new commercial pilots on the pilot chat blogs couldn't imagine how such a thing could ever happen to them. It brought to mind the old saying "There are bold pilots, and there are old pilots." In this case, however, the rest of the world conspired to set the stage.

As with "errors" in hospitals, it typically takes a whole team of people to align their actions in the wrong way (the "swiss cheese model"), for someone to buy the gun, someone to load the gun, someone to cock the hammer, someone to hand it to the poor last guy in the chain, and that guy to pull the trigger. For legal purposes, blame is assessed one way, a way this paper does not assess. For purposes of safety engineering, and seeing where interventions might help to avoid ever having this happen again, we need to look at a whole different set of factors that set the stage for this "accident".

Please contact me if you'd like to use this paper (or a newer, better version) for instructional material. Thanks!

( Note: I am a private pilot, but I'm not a member of the NTSB or any official agency, and this analysis is a personal analysis for instructional purposes in safety engineering, not intended for legal purposes. I have no relationship that I know of to anyone involved in this case. These are all real, living people and my reconstruction may be entirely wrong. The point is to honor those who died by learning everything we can from their deaths so this won't happen again.)

Prior Posts:
Comair 5191 - Confirmation Bias and Framing (1/20/07)
Cockpit voice recorder transcripts
Washington DC Crash of Air Florida was 25 years ago - remembered
(with links to BMJ, High-reliability engineering, TEM, etc.)

Sunday, May 13, 2007

Powerpoint on why too much quality doesn't work



It seems to me that there can be such a thing as too many procedures, to the point where, as John Gall would say, the component that will fail is sthe one that you put in to make the system "fail-safe". That is, the thing that will kill you is the thing that you put in place to save you.

This may have been true of Comair Flight 5191, that crashed while attempting a mistaken takeoff from the wrong runway in Lexington, Kentucky last August.

Some pilots have wryly compared the pre-takeoff check list on a 727 to a "Michner novel", in terms of its length. In the case of Comair 5191, judging from the transcripts of the cockpit voice reocorder, the right-hand seat co-pilot apparently spent the entire taxi-time with head down, going though the checklist, while the left-hand seat pilot taxied the plane to the wrong runway, opened the throttles and told the copilot "you've got it."

We have some mixed signals on how to deal with this. In a perfect case, even a very "lightweight" solution is more than adequate. The picture illustrates a single sheet of typing paper rolled up and taped into that shape, holding up 3 books.

However, when it comes to checklists, or standard operating procedures (SOP's), sometimes there are simply too many. Cultures in the red-quadrant of the "competing values" diagram think that the problem is always too few procedures, and want to add more. They think the graph of reliability versus standardization goes up forever. In practice, the graph seems to be more hill-shaped, going up to a point, then somewhat down as more and more procedures start getting in the way, and finally result in catastrophic failure as the system crashes under the weight of it's own safety system. One can think, perhaps, of the "right number of laws" to have optimal regulation of an industry, and which of those two curves applies in whatever is your own case.

I put up a powerpoint slide presentation (no audio) considering this issue.
you can get it here, titled "spectacular.ppt".