Is "Good" Enough? - How Should You Apply The 80/20 Rule?
There's 20K in your budget for software and you had intended on using it for a real time data collection system for data center management, but the best solution would cost more than 20K just in professional services. Maybe it's not the money at all, but the concern over potential disruption to your DC production environment. You've got 30K for a monitoring tool, but you really want the comprehensive capabilities of an enterprise solution that starts at 150K. I guess you should just not spend the money or use it for more of the same old thing, because you can't buy the "perfect" or 100% solution.
Sitting on your hands saying "I don't have time" or avoiding decisions, because of the search for perfection isn't the answer! Don't waste your opportunity to get something instead of nothing.
When is "Good" enough? That's a tougher question than I thought it was, even though I consider myself an 80/20 rule evangelist. I use the 80/20 rule on a daily basis for every decision from whether to file a document, to determining whether 2% milk is acceptable when 1% isn't available. However, as a data center owner I've historically looked for absolutes and have always attempted to get the "perfect" environment. Unfortunately there rarely are any absolutes and perfection is a momentary condition at best, unless we're talking about Halle Berry (my wife would say Harrison Ford). Good enough isn't enough in many areas of data center construction and management. I would never assume my electrical designs were "OK". I would examine the plans for hours and have peers provide additional review. This process also applies to calculations around airflow, or the commissioning process and much more. What we need to recognize is that regardless of how "perfect" a specific solution is, it could always be better, but when do you sacrifice more time in an effort to get more perfect? A critical factor in determining where and when to use the 80/20 rule is the risk associated with getting it wrong. If you're calculating the power capacity of a cabinet, the 80/20 rule probably isn't a good idea. On the other hand if you have a need for improved visibility into your DC metrics, then any visibility is better than none. I picked DC metrics on purpose, because most of us hesitate in this area of operations because we assume a solution will either cost too much or be too disruptive to implement. This concern over covering everything in your metrics and or efficiency management is a roadblock for many because of the DC environment impact associated with putting metering and monitoring in a legacy space. However, any light in a dark spot is still better than no light at all, which is why I believe this area to be a perfect example of a place to use the 80/20 rule.
The impact of the search for perfection in IT projects
There are countless stories of IT projects gone wild because of scope creep. Generally speaking scope creep is a search for "new" perfection. New perfection is generated from hind sight and additional time to review technical options. However, scope creep as we all recognize comes with risks to cost, delivery schedule and even overall project success. Does risk to success mean we should never allow scope creep, absolutely not. However, new requirements should be weighed and an ROI review completed before the change (scope creep) is officially adopted. So how does scope creep and a search for perfection apply to "good enough"? It applies in several ways, including improving project execution and avoiding project paralysis. In the context of the article, I'm mostly covering "project paralysis" or "decision paralysis". Where and how does project paralysis come in to play? Project paralysis can be manifested in the simplest ways, like the struggle to select a food item on a menu that has dozens of items to choose from. It can also be demonstrated in IT solutions that are never successfully implemented because we're attempting to implement the perfect or best option.
The failure to choose and implement an 80% solution, because you couldn't find what you believe will be the "perfect" solution is not success. In other words no decision is still a decision, and it's often the worst option. Considering the struggles each of us face to find resources (human, hardware, or dollars), we can't afford to stay locked in a downward spiral or flat line because we don't have time to find the perfect option. A great example of how we all use the 80/20 rule is the "low hanging fruit" approach; "how can we get the most bang with the lowest investment of time and money?"
Assuming we all generally agree with the 80/20 rule, why then are we constantly struggling with fire fighting or ignoring efficiency improvements because we don't have the time to spend on selecting and implementing the "perfect" tool or process. We need to carefully consider our priorities for the year and determine the best way to spend what little we have in budget and human resources, but this should be a process for generating opportunity, not for doing the same old thing. When you look at a solution keep in mind your ability to execute quickly and the flexibility of your commitments. I know this strategy of looking at point fixes flies in the face of what many of us grew up with. All of us have worried about implementing things that will increase environment complexity and make future integration activities more costly. You should continue to worry about commitments that become a burden or technologies that add complexity, but the good news is that Cloud/SaaS offerings can help alleviate many of the risks.
Quick Tips on using the 80/20 rule in IT solution acquisition:
- Consider what your long term ownership of the solution will be
- Are there other systems that the new solution needs to integrate with
- Can you get out from under the new solution quickly when needed
- Will it bring immediate monetary or process improvement
- Is it a bridge solution that will support a piece part acquisition strategy
- Is it a near term gap filler
- Does it create an opportunity that might otherwise be missed for years while you wait for the perfect time/solution
The next time you see a solution that has the potential to positively impact your ability to support enterprise initiatives, don't just pass it up because it's not the tool or process you really want. Take a moment to consider your rules of ownership. Also, be sure to apply things like Cloud & SaaS to your ownership model as this creates a new perspective on the difficulty or ease of acquisition. After all, many of us want a Ferrari, but we still end up with a Ford or Toyota because we can't wait to have a car indefinetly.