I must have some secret employees at the Financial Times writing for me or something. Atul Gawande wrote ‘Airline Pilot’ protocols in finance today and it caught my eye.
Some choice quotes:
He also found he made mistakes in handling complexity. A good decision requires consideration of so many different aspects of a company in so many ways that, even without the cocaine brain [confirmation bias], he was missing obvious patterns. His mental checklist wasn’t good enough. “I am not Warren,” he said. “I don’t have a 300 IQ.”
So he devised a written checklist.
Sometimes you don’t even know you’re making the mistakes over and over unless you get reminded of them by using the checklist. It’s there to keep you safe from your own mind. The easiest person to trick is yourself.
Even in his own firm, he’s found it a hard sell. “I got pushback from everyone. It took my guys months to finally see the value,” he said. To this day, his partners still don’t all go along with his approach and don’t use the checklist in their decisions when he’s not involved. “I find it amazing other investors have not even bothered to try,” he said. “Some have asked. None have done it.”
As I said before, people think checklists are beneath them. I’ve had a hard time convincing people to use them in any aspect of project work. Clients don’t like it because they think that’s why they hired you in the first place; you’re the expert. Consultants don’t like it because they think it will somehow make them look incompetent.
I’ve tried many different ways of motivating people to use the list, but in the end nobody seems to want to listen even when I show them measurable results. Ego.
Atul has a book out as well. I’ve already ordered it. Will you?
Posted: January 19th, 2010
Categories:
Uncategorized
Tags:
Comments:
No Comments.
One of the main duties I performed as a consultant was kicking off a project for a new client. The process went by many different names. Iteration zero, project kickoff, inception, and QuickStart. Sometimes a combination of them.
The thing I learned right away was that there was always plenty to think about and set up. All projects are different of course, but all projects are also the same in many ways. So, I began to do what I always do in a new situation and make a checklist.
I learned this skill a long time ago and it has served me well in many different ways. To my clients, I seem to have a super memory and intellect. Combining the checklist with GTD helps greatly. To my colleagues, I can share the list and get feedback and improvements for my own projects and help theirs. Now on with how to create your checklist.
First, I almost never start from scratch. I look to those who have done it before and have learned lessons the hard way. Nobody is smart enough to think of everything, and besides, why duplicate work? Look to retrospectives, post mortems, project wrap ups, lessons learned, bug reports, lawsuits (yep…), API versions, forums, email lists, etc. Anything where people are seeing 20/20 after something went well or, more importantly, something went wrong. Put it all on the list without filtering. If you don’t have stuff written down somewhere, try interviewing people and listen to their war stories. You’ll learn some good lessons. Write. Them. Down.
Second, once you have your list, try organizing it by rough topics: architecture, project management, QA, analysis, client relations, contracts, etc. This is a good time to take the list to your coworkers and ask them to fill in areas that you’ve missed. The important thing to remember is to keep things on the list unless they are incorrect. This list is for all projects, not just “your” project.
After you’ve created your checklist, put it somewhere it can be seen and used as well as collaborated on. A wiki is great for this because you can have multiple editors and you’ll get to see all of the versions. Tell people where it is and have them use it. Asking for feedback on how it works is a great way to get them to use it. They’ll improve things and add new items as they come up.
At this point, you’re probably expecting an example or even full version of my checklist. Sorry. That would rob you of the experience of creating it yourself which is well worth your time in just the collaboration alone.
Initially, people will complain that your checklist is too long. Ignore them. Explain that the checklist is there to keep them safe and spending a 30 seconds or a minute on each item on the checklist will save them loads of time and mistakes later.
One last thing. The checklist is a great tool to make sure you haven’t forgotten anything, but it isn’t a substitute for critical thinking. The checklist will help you to not look dumb, but you still have to be smart. Good luck.
Posted: January 17th, 2010
Categories:
Design,
Work
Tags:
Comments:
No Comments.
Remember learning to ride a bike or drive a car? It was hard at first, with all of those things to remember and do at once. Put your foot here, your hands there, look straight, now look in your mirrors, gas, brake, turn signals, WATCH OUT FOR THAT TREE!
Driving that car or riding that bike seemed like a very complex activity. You didn’t know the simple steps to take and they weren’t natural for you yet.
What we didn’t realize then was that those things were sophisticated, not complex. They only seemed complex because we were trying to learn and remember and do things all at once.
Breaking something down into smaller, easier to understand parts allowed us to master those things. We had training wheels for a bike, someone to hold us and push us when we needed it. Learning how much pressure to put on the brakes of a car while going straight in a parking lot.
We could then put those things together into a sophisticated process that became more than the sum of its parts. It just looks complex to those who don’t know.
The next time you are learning something complex, remember it is probably just sophisticated and you need to break it down into smaller parts and master those things before trying to do the rest. Agile adoption is a good candidate for that breakdown.
So if you are learning something new like Agile, find out where you can break it down and learn small things at first. If you are being taught or coached by someone else, make sure they teach you this way. It is much easier. If they disagree, ask them why.
Posted: January 14th, 2010
Categories:
Life,
Work
Tags:
Comments:
No Comments.