A story: I was once a team member on a project to move an office from one location to another. Even though there wasn’t enough equipment and people to fill all of the available office space in the new location, the project manager insisted on taking advantage of management’s good will and the available resources to build out the unused space.
Several months after the move, employees began complaining about high noise levels. It was determined that the cubicles were too noisy because the ceiling was highly reflective, the cubicle walls were short, and the cubicles were too close together. All of the cubicles office wide—including all of the unused build out—had to be replaced with taller walls and moved farther apart. Fixing the unused build out added about 35% additional cost to the change.
This was a classic case of “overbuilding,” the tendency to buck rolling wave planning and build things now which aren’t needed until much later. You see this all the time in IT Infrastructure projects. A small business learns that a bigger competitor has a high-availability SAN. Because that little business might someday have hundreds or thousands of customers and because they want to “keep up” and look “big,” they spend big money on their own SAN.
Next thing you know, a tiny IT staff has to manage a super-complex system in which they are using 10% of the functionality. Three years later, when better, simpler, faster technology rolls out, they’re stuck with the existing system.
How do you avoid the overbuild mess? By taking the building-block-approach to infrastructure design. A topic for another post…
