To err is human.

Michelle Murraine, of The Zen of Non-Profit Technology, is hosting the non-profit blog carnival this week and wrote to remind me of the topic. It's a good one: We all make mistakes in our work with clients. What mistakes have you learned the most from? How do you deal with making mistakes? We develop application software for non-profit clients. In our work, there are three basic kinds of mistakes we can make. And being human, of course we've made all four. We can make a technical errors: a bug in a program, or a server that is incorrectly configured. Or we can give a client bad technology advice -- for example researching and recommending a third party product that proves to be inadequate to the task. Errors of these two types this are bound to happen now and then in technology consulting. When everyone involved knows from the very beginning of the engagement that errors can and will occur -- and that errors will be fixed -- these technical errors really present no problem to the long-range consulting relationship. A written procedure that discusses how such problems are to be reported and how errors will be corrected can go a long way toward building customer trust that the vendor or consultant is poised to fix anything that goes wrong in a complex project. And at times when error discovery might be particularly worrying to the client - during a training, or right at launch - describing problem detection and correction as an integral part of the process will lower client anxiety if a problem is found. Finally, totally honesty on the part of the vendor or consultant is essential. By doing so you are not only helping to fix the immediate problem, but setting a tone that will improve the entire relationship. Remember, the next mistake might be made by the client. And you certainly want to create a context where they feel free to admit their mistake to you. But far more serious than technical errors are mistakes that arise out of flawed ways of working. Paradoxically, this third type of mistake -- procedural errors - can often come from unrealistic or ill-thought-out efforts at pleasing the client. Sometimes you may over-promise in order to land a hot new project. Or you may find yourself bending the truth about budgets and schedules to alleviate a long-time client's anxiety. "Its going to be hard to have the website ready to launch by the 15th, but we will try". Or you may be giving in to what we like to call the Hot Dog syndrome, where you are blatantly showing off how quickly and easily you can do something the client has asked for. It's just human nature to find yourself a flirting with a client or co-worker now and then - , but don't issue a SQL Delete at such a moment! I speak from experience. You can't always tell that you are giving in to these bad instincts when you are in their grip. It just seems that you are trying to do what the client has asked for. So we've learned that it's important to have procedures and practices in place that force your brain into gear. Small consultancies are typically very light on such procedures -- they slow you down and involve more people at every step - but they can save you and your clients a lot of pain. For example, we have a rule that two people must approve any estimate for software development. Or that before your run a script to do some manipulation to a client's production database, you need to try it on the TEST installation. Or that someone other than the programmer needs to test any customizations before we release them. These structures help guarantee that clients really get the fruit of our experience.