Imagine a nice piece of lumber — strong and dry, ready to be of service in any construction project. It’s strong, and it will be strong every day. Good ol’ reliable lumber.
Now cut that lumber on an angle and add a bracing plate. It’s still strong, but it’s not as strong. Now replace the bracing plate with a hinge. It’s still strong, but not steady. Now add 10 more hinges to the piece of lumber, heat the wood a little to add a curve in the bottom tenth, and stain it red. Now use it as a support joist for a house.
Why the Word “Except” will Cost you Money
When developing a process, it is important to imagine each process as a vector — which means “All things coming in here will come out there. All variables and outcomes will be the same every time.” Building a project plan involves identifying and arranging your process vectors.
Each time the project team uses the word “except” in a process development discussion, go ahead and add $100,000 to your final project price. The word “except” cuts your process vector in half — like our lumber example above. Sure a few exceptions are possible, but the more exceptions in your process, the less reliable it becomes. And if your project team loses its ability to restrain its exceptions, the final project turns into garbage.
Why so inflexible, dude?
Don’t take it personally — this is system design, not “idea squashing.” Many project teams misconstrue system design as an exercise in creative thought, and they take it personally when their ideas are reined in for being outside of the scope of the project. It’s not a matter that your idea is or isn’t creative, interesting or funny, it’s that the system is probably not built to handle that the exceptions being bandied wildly about during your process meeting.
When designing a system (such as a software process, manufacturing process, business workflow, etc.) it is more useful to focus on the vectors that will be used by the greatest number of processes in the same way each time. Start there, and try to stay there.
Give your exceptions a procedural escape hatch in your system design so that customer service humans handle the exceptions. You’ll provide far better service overall by handling exceptions this way instead of trying to build them into your software or services procedures.
Let your processes be straight, strong, predictable and reliable. If some strange phenomenon might occur outside of that process, let a person handle it. That’s what they’re there for.
And, if I were your customer, I’d far rather talk to “Marge” for my exceptional situation than to try to wrestle with a software system that doesn’t know how to handle my inquiry. Marge is friendlier and baby, she GETS me.
Marci De Vries is president of MDV Interactive, a web consulting firm in Baltimore. Reach her at email@example.com.