Justify My Lab

We interviewed IT managers from small businesses to Fortune 500 companies and government organizations to find out how they align their lab proposals with business goals.

The Hard Sell

Establishing a test facility is essentially an entrepreneurial experience: You're going out on a limb, doing something that can yield high returns or be a complete bust, and taking the chance that someone out there is just waiting to eat your lunch.

Furthermore, experience shows that some industries may be a harder sell than others. The manufacturing industry, for instance, tends to avoid investing in IT infrastructure that doesn't yield a concrete payback, says Ken Stewart, IT manager at BKI, a food service manufacturing company. Stewart has hit a brick wall trying to get funding to build a test facility. "As far as IT expenditures are concerned, labs typically fall to the bottom of the list," he says.

You'll have no guarantee of continued support once the lab is running, either. Ray Gauthier, IT specialist at the federal Office of Management and Budget (OMB), has been able to procure lab equipment and build a test facility that mirrors his production network, but he constantly has to ward off "poachers" who want to use his lab gear.The Windup

Before you pitch a product-testing lab, do your homework. Find allies and know your audience. It helps if your credibility and reputation are spotless well before you start writing the proposal. Because testing labs don't contribute directly to the profit margin, you must be known as a good steward of corporate funds--someone who knows when a $4,000 router can do the same job as that $40,000 one. Otherwise, you can expect significant difficulty justifying the lab, no matter how good your business proposal is.

Assuming you have the credibility you need, you can begin to identify why your organization--not just your IT department--needs a testing lab. Such a facility requires a significant investment in capital and effort, and once started, it demands care and feeding. When identifying the need, look beyond the task at hand and prepare to explain why you'll need the lab on an ongoing basis.

You also must find people to listen to you. For certain kinds of labs, such as usability labs, it's hard to quantify their impact on the organization. Take the advice of one lab manager at a Fortune 100 consumer products company, who suggests linking your testing lab to product value at a senior director or vice president level as early as possible. A senior management sponsor will not only provide management support, but also can be a good source for getting the figures to build out the valuation of your testing setup. And, assuming you get to the proposal stage, your sponsor can provide a sanity check.

Beyond your sponsor, also consider the audience you're pitching to. Are you trying to sell a lab to an IT-friendly group, or is the management team leery of IT's spendthrift ways? You'll probably be fighting the perception that testing labs are an excuse for techies to play with their toys--not exactly a compelling business case.Remember, you're likely to be talking to people responsible for the company's everyday business operations. You could argue that testing has a direct link with those operations, but you're not likely to convince the CFO that an IT testing lab is part of the organization's nuts and bolts, such as cash flow, direct materials and direct labor.

As we talked to IT managers, we kept hearing the theme of avoiding "hassle" through the use of testing labs. But unless you translate "hassle" into dollar figures so that your audience can understand the connection, you can expect your plea to end up on nothing more than a wish list.To prepare for the pitch, consider more than just the current justifications for your lab. You'll probably have to defend your testing facility throughout its life and provide for ongoing funds to keep the lab functional. World events, such as Y2K and virus disasters, drove a one-time buildout of lab facilities at OMB, for example, but that facility remains useful today, testing virus updates and patches as well as software compatibility, says IT specialist Gauthier.

Be ready to justify the ongoing costs incurred by the steady deployment of security and other bug-fix patches over the lab's life span. Testing labs do quality assurance on service packs at Office Depot, for instance, and senior MIS project manager Rachel Pace is quite bullish on this use. "It's pretty easy to quantify savings," she says. You base those numbers on the type of work required when things don't go according to plan. If a patch is known to work fine across the industry, for example, but it conflicts with your homegrown application, you could face hundreds of hours of downtime and remediation across your user base. This is particularly true for large shops and ones whose operating system setups are diverse, as the window of time to patch critical flaws is small.

Besides emphasizing a lab's potential savings, look for ways to turn the lab into a bottom-line booster. If your organization is large enough to warrant them, for instance, chargebacks (charging other departments for services from your organization) are an extremely good way to keep your lab competitive--and therefore efficient. For example, one large Midwest manufacturer sells its lab's services to internal customers "as another way to improve its ROI justification," says a security manager at the company.

Clearly, this type of lab is the most entrepreneurial. It's a minibusiness within your enterprise, since it has both revenue (the chargebacks) and expenses. Fair warning: A lab that typically operates outside of the main IT department (it charges the IT department for its services) will require the most detailed proposal (see "The IT Agenda: Move Beyond the Free Lunch").Out of the Closet

No matter the size your organization, one thing worth pointing out to management is that IT folks always find ways to get resources for testing gear. As our Fortune 100 lab manager points out, "The lab is going to be there whether or not you formally fund it. People are going to snarf PCs, etc. Today, when you can get Internet services for $40 a month and Ethernet switches for a couple of hundred bucks, it's very easy to hide these types of expenditures." If there is a formal structure, IT is less likely to engage in covert lab operations. Such unofficial labs end up costing the company more money, as they are used less, tend to duplicate services and don't do as good a job of testing, since they're not adequately funded.

If, after you've studied all the pros and cons, you don't think you'll need a lab more than once in a while, consider outsourcing. This option can work effectively as an alternative to a permanent facility if you can't justify the payback, simply don't have lab expertise in-house and you aren't large enough to warrant additional staff (see "Testing To Go," for more on outsourcing lab work).

Writing the Proposal

You've found your allies and understand your audience, and you've considered how to justify this expense. Now it's time to write the proposal. Your first step is to lay out all of your assumptions. Make sure you spell out the types of costs a lab can help avoid. Those assumptions should be conservative: Senior managers will swat you down like a bug if you estimate every recovery from a bad patch job will take an entire day per workstation. Although cautionary numbers will not be as impressive as "I'm gonna save the company a gajillion dollars!," they will emphasize that you're being fiscally responsible (see our sample, "Cost of Downtime,").When building scenarios for a spreadsheet that illustrates the cost of downtime, historical data is your best predictor of risk and statistical relevance. For instance, if only one out of 10 hot fixes has caused a problem in your environment, then there is a 10 percent chance of a problem with future hot-fix deployments. Thus, if you've kept good records--or if you can reconstruct events from e-mails or work orders--you should be able to accurately represent probabilities in your business plan. If you don't have these records, there are administrators out there who do. Sage, an international organization for professional system administrators (www.sage.org), and similar organizations should be able to hook you up with people who can provide such data.

What about showing justification for lab testing projects that don't really have a quantifiable risk? That is, what if you've never done anything similar before and therefore don't have historical data to translate into probability of failure? It wasn't so long ago, for example, that there was no data on VoIP (voice over IP) rollouts. In such cases, you must perform a sensitivity analysis--a procedure that helps you discover how costs change as risk changes. In your spreadsheets, simply perform "what if" analyses using different failure rates--for instance, how 10 percent, 25 percent and 50 percent failure rates in your lab will affect your costs. Each percentage has a certain dollar payback to your organization. If changing the failure rate from 25 percent to 10 percent saves $15,000 annually, that means each percentage point of risk eliminated is worth $1,000 per year. So even if you can't predict the exact level of risk the lab would eliminate, you will be able to quantify how much each percentage of risk reduction translates into dollars. Since it's reasonable to assume that testing lowers risk by at least some amount, you'll be able to show a range of payback.

Finally, "business geek" techniques such as discounted cash flow (DCF, also known as NPV, or Net Present Value) analysis, which accurately represent any investment opportunity's total valuation, work well if you're talking about a lab investment. In particular, NPV--the value of future money, today, when taking into account future inflows and outflows of cash--discounts those flows (because money in your pocket today is worth more than money tomorrow) and factors in the time value of money. Several IT managers described their use of DCF to us, and while they refused to share their actual spreadsheets, they described the sheets well enough that, like the recipe magazines, we've re-created them for you (see "NPV of a Sample Lab").

Besides being conservative, these analyses must be "lifetime value" propositions: They must take into account the fact that lab gear has a finite life; that the value depreciates over its useful life; and that it has some sort of salvage value at the end--close to zero in some cases, 10 percent to 30 percent of its original value in others. In our sample spreadsheet, we chose 27 months as the useful life of the lab, but yours may be longer or shorter, depending on the technology life cycle at your organization. For example, if you're swapping out servers and equipment every four years, four years makes sense for the useful life of a lab.

Net Loss?

You'll notice that our sample NPV analysis ends up costing the company money. Since the analysis is conservative, however, and doesn't resort to quantifying factors such as "lost worker productivity," it's an easy sell. (Would your company spend a net $7,000 on a mechanism to avoid major process snags?) While one of the managers we interviewed says that labs always have a negative ROI, this isn't always true. For example, if you scale our example spreadsheet to 1,200 users, the NPV is a positive $22,000. But negative NPV is something you should be prepared to defend, as long as it's within reason, particularly in a small-to-midsize organization.

"Cost avoidance doesn't count at our company," says one IT manager. "I completely agree that it should count, but I beat my head against that wall every day." But if cost avoidance didn't count, no company would ever invest in new manufacturing facilities or process improvement. After all, cost avoidance contributes directly to profitability. In your quest for lab facilities, keep that link to improved profitability in the forefront, and you'll eventually sell your proposal, if not at your current company, perhaps at the next, more forward-thinking one.Jonathan Feldman is director of professional services for Entre Solutions, an infrastructure consulting company in Savannah, Ga., and the author of Teach Yourself Network Troubleshooting (second edition). He has worked with and managed technology in industries from health care and financial services to government and law enforcement. Write to him at [email protected].

Post a comment or question on this story.