In 1785, when Scottish poet Robert Burns wrote, "The best laid schemes of mice and men; go often askew, and leave us nothing but grief and pain, for promised joy!" he had no concept of data centers gone awry. But, he knew all too well the nature that is human. Even those who plan, sometimes fail. We draw flow diagrams, keep immaculate notes, save every email, entertain all ideas, promote brainstorming sessions and have the latest project management tools. Yet, still we sometimes fail in the execution of those plans. Why does that happen? It happens because we often ignore or forget the first law of planning: Everything works on paper.
On paper, no idea hatched idea ever fails. The craziest schemes find credibility on a two-dimensional surface, only to fail miserably when translated into a three-dimensional world. The plan comes to fruition only to find that you're four feet short of a power outlet, you're 100 feet past the practical limits of a telephone point-of-presence (POP) or more simply you forgot to gather accurate pricing on a key product component.
The first question to ask, once the plan is in place, is "OK, now that we have a plan; what's wrong with it?" Honest feedback to this question will save you, as Robert Burns put it, grief and pain. It will also save you money and time. How often have you had a project go wrong and then someone popped up and said, "I knew this would never work because [Insert snarky comment that's six months too late here] but no one wanted to listen." Ask for negative comments. Ask to have the plan's weak points exposed. Imagine what would have happened if someone at White Star Line had asked that question once the drawing for the RMS Titanic was on the table.
Unfortunately, ego prevents us from asking the tough questions about our own beloved plans. No one wants honest feedback. Alternatively, no one wants to give it for fear of retribution.
The second question that should arise is "How can we make this better?" Again, encourage honest feedback and allow everyone to speak their minds openly and freely without fear of retaliation.
For example, if you're planning a server consolidation move and your plan is to move to blade servers and virtualization, there are some things you must know to make that plan work. Blades have special power requirements, take up an odd amount of space and have their own management applications. Blade solutions look great on paper and in three-dimensions, if you're prepared for the differences and idiosyncrasies that come with them.
Prototype a Solution
Whether you're building unsinkable ships or consolidating servers, you need a prototype stage. A prototype highlights design flaws in three dimensions that you cannot see in two. The prototype step operates to find flaws in the plan and hasten its revision prior to spending time and money on a full-blown solution. This is the classic "back to the drawing board" stage where one makes the difficult decision to either scrap or proceed with the plan.
A successful prototype does not automatically mean the plan is also successful. It's an evaluation stage to highlight problems and roadblocks prior to large-scale implementation.
Revisit the Plan
It works on paper. The prototype worked. The question now is, "will it scale?" When someone at your conference table blurts out the nightmare three-letter acronym for the data center equivalent of fingernails raking down a blackboard: VDI (Virtual Desktop Infrastructure), the answer is 'yes' but at great expense. Revisit your plan and decide whether it's worth the price to make it work. So far, you haven't invested a large amount of time or money into the project. And, you've learned from the experience. You might have learned enough to take a different path that leads to the same destination.
Don't marry yourself to a plan. Stay flexible and ready to explore alternative solutions.
Not all ideas are good ones, but they all work well on paper and in theory. When seeking your promised joy, save yourself the grief and pain of those plans gone askew by asking questions, prototyping the solution and revisiting your plan to see if it works on a large scale.
Ken Hess is a freelance writer who writes on a variety of open source topics including Linux, databases, and virtualization. He is also the coauthor of Practical Virtualization Solutions, which is scheduled for publication in October 2009. You may reach him through his web site at http://www.kenhess.com.