BackSpin
The problem of dealing with details arises when a project starts and people say, “Oh, we’ll work out the details later.” This statement must rank as one of the most dangerous assumptions that can be made in business.
It is like saying that you’re going to climb to the top of Mount Everest as you actually start the climb. By the time you’re high up enough to know you need oxygen, it is a little too late to get your hands on any.
In business, much the same problem applies. How many times have you started a project working from “the big picture” (top down) with the intention (really a belief more akin to religious faith than an actual plan) to map out those niggling details later?
One place we all know that the “top down leave the details for later” approach just doesn’t work is in software engineering. We’ve all heard the stories of software projects that bit the big one because of some stupid, little system issues that should have been nailed down before coding. Given that wealth of negative experience, you’d think that such snafus would be a thing of the past.
No such luck. The industry hears every month of another CRM or ERP project that has tanked because it was out of control. Occasionally random bad luck is involved, but not usually. The problem usually lies in the assumptions. “Ah,” someone says, “we’ll use X,” where X is a process or component or something that does something you want. And under normal conditions X is great. But as it turns out, under other conditions, X becomes the source of catastrophic failure.
Let me give you an example: A financial company was very concerned about the availability and security of its data and so located its back-up data centre in Phoenix (no earthquakes and no flooding – the latter had caused the company a problem with its first data centre). It leased the sixth floor in a new building, installed an air conditioned, lights-out computer room and, to suppress radio emission, “caged” the room. The company had a back-up generator, fire suppression system and multiple data lines. What could go wrong?
Well, the water tank on the roof burst. Several thousand gallons of water percolated through the building’s structure, and because the computer suite was caged, filled it up to a depth of a couple of feet. And, of course, this happened at night. Had a fire started, the smoke alarms would have raised a warning, but the company didn’t have flood alarms – who’d need those on the sixth floor?
Now the more generous of you might say, “Come on, Gibbs, that was a 1000-to-1 chance! Who could have foreseen it?” Sorry, but being hit by a meteor is a 1000-to-1 chance; being flooded on the sixth floor should have been considered.
The details are what get you every time and are generally what make IT’s job so damn hard. It’s the little details that define the true cost of IT operations. Some you deal with as they emerge because the world changes, but others should be planned for if you’re any good at your job.
When it comes to projects, that million-dollar budget is great for getting off the ground, but the details that emerge from lack of forward thinking will cost you half that again or more.
The devil, and hell, is definitely in the details. So the next time someone in your IT group says “Oh, we’ll work out the details later,” tell ’em about the flood on the sixth floor.
Send a tsunami of comments to backspin@gibbs.com.
