Computerworld — If you want to hear your employees whine, just ask them to create a business case for their next project proposal. All together now: "That's too much work." "This project is so simple it doesn't need one." "It's a no-brainer, really. You should just go ahead and approve it."

Ignore the whining. Yes, business cases require time and effort, but projects generally eat up significant corporate resources. Comparing comprehensive business cases is still the best way to make trade-offs about which projects to fund.

Of course, you're not going to be able to convince everyone of the reasonableness of the business case requirement. Some, faced with the prospect of twisting a nonstandard project into the standard corporate business case template, will assault you with arguments for skipping the business case that might seem unassailable. Among the more compelling arguments you might hear are the following:

"This project is required to meet regulatory mandates ." Cases like this can be light in the benefit descriptions. But the case still has to be made. Not being hit with fines, penalties and liability is a benefit. And the business case must clearly describe how the project addresses regulatory requirements. Too often, projects are put into the regulatory funding bucket on slim pretexts. For example, in the early days of Sarbanes-Oxley , many companies found they were being told that previously deferred financial projects were required for compliance reasons. Many weren't.

" We need this project to reduce a critical risk ." Projects such as disaster recovery planning, business interruption planning, and security services are difficult to justify with a standard business case, since they neither increase revenues nor reduce costs. These projects address low-probability situations with potentially huge consequences. In such cases, under benefits, you need to quantify the cost of the anticipated failure (e.g., how much revenue will be lost per hour if the reservation system is down?)

"This project furthers our corporate mission." This argument is typically used in not-for-profit organizations and government agencies, where revenue concerns are secondary. Even then, it is viable only if the organization has created and prioritized a few clearly articulated strategic imperatives that support its mission. Projects can then be evaluated based on the degree to which they support one or more of these imperatives.

"This might sound crazy, but ..." This argument attempts to circumvent the business case review process, often when a project includes largely unverifiable assumptions. These projects typically represent a new business paradigm and may appear too risky to undertake. A few of these projects, often proposed by true visionaries, do deserve to be funded, and a business case is a first step toward helping you recognize whether a visionary project has real potential. A classic example is the iPod, which has dramatically changed the way music is sold. It's worth noting that although few organizations can afford to fund this type of project during a recession, Joseph Schumpeter, the well-respected economist, asserted that recessions are actually an excellent time to invest in these groundbreaking efforts.

Remember, business cases enforce rigorous project planning, which is a crucial component of project success. While some resistance to developing business cases is understandable, the truth is that a compelling business case can be your project's best friend. You can use it to help clarify and quantify project requirements and contingency plans, which actually enhances the chances that the project will eventually be a success. And you have to love anything that can keep your project from going down the drain, along with your job.

Bart Perkins is managing partner at Louisville, Ky.-based Leverage Partners Inc., which helps organizations invest well in IT. Contact him at BartPerkins@LeveragePartners.com .