When I was young I built model airplanes. The instructions were usually simple, clear, and easy to follow. I was eventually able to build some cool looking planes, which I hung from the ceiling in my bedroom. But despite how clear the instructions were, it was easy to overlook the part that said “Allow the glue to dry completely.” Building model airplanes is mostly careful sanding and gluing of little parts and then letting them dry. So there is a lot of waiting involved in building each model. Growing up with so many instant conveniences like fast-food, the microwave oven, instant popcorn, and 30 second oatmeal made this waiting especially difficult. This frenetic pace has become part of our culture and even more intense today, with on-demand media and next-day shipping.

I’m not sure how many airplanes I destroyed or half-mangled before I finally learned better. It was not an easy lesson to learn. It took more than learning; it took a cultivation of discipline and an appreciation for the value of the reward.  There is a striking difference in quality between a rush job and sturdy, symmetrical and sharply painted model airplane. It took some “un-learning” too. I had to un-learn the mistaken notion that everything can be made instant. I also un-learned how to multitask. By focusing on one thing at a time, I actually saved time by making less mistakes. It sort of seemed like it took longer but since I made so few mistakes, actually by the time I finished the model, I saved time by not having to redo steps and waste time fixing mistakes.

This concept applies to changes in IT systems. When you roll out changes, it’s best to find the right deployment pace.  Roll changes out one at a time, and then give each change time to settle in and “gel” before you add new changes. If problems crop up, you want to be able to troubleshoot a known system, and you want to be able to restore to a previously known good configuration. Rushing deployments is the same as trying to put a model airplane together without letting the glue dry. Some things take only time, and rushing them will break them. Quality is partially a function of time spent. And taking short-cuts to cut costs doesn’t always cut costs in the long run. Sometimes trying to do it cheap results ends up costing more money since the constant maintenance eats up any deployment savings.

Rex Consulting is committed to building solutions built to last. Of course we realize that nothing lasts forever, and change is the rule, especially in this industry. But balance must be struck between quality and time. Aiming for 100% quality will result in over-budget and late projects. Aiming for 90-95 % quality should be the target. Quality is somewhat difficult to distinguish from extravagance, since this distinction is subjective and difficult to boil down to just a numerical analysis. Part of the the problem with some IT deployments today is the unbalanced focus on the measure of short-term financial results instead of on quality results.

Taking time doesn’t guarantee quality. With an inexperienced team that lacks the ability to recognize quality, you can end up late, over-budget and still low quality. It’s important therefore to approach the problem holistically, involving both financial as well as technical experts in decision-making.

© Copyright 2020 Rex Consulting, Inc. – All rights reserved