Imagine this scene—you've just gotten back from lunch and you're checking your email. The first email you open is from the VP:

Effective immediately, starting with the release currently under development, our flagship product, SalesSupport, will be converted to use a proprietary database in place of the current SQL DB. Deploying SalesSupport with our ClientMaster(SM) database will enable us to realize cross-marketing opportunities and increase revenue substantially.

As you read the email, you start to feel queasy. You realize that changing to this database means that the third-party contact management component you are using won't work. You'll either have to get the vendor to build a one-off that will access the ClientMaster(SM) database or modify the component in-house.

Good luck waiting for the vendor to make the new version. And, if you change the component in-house, it won't be a one-time job: every time the vendor comes out with a new version of the component, you'll have to customize that code, too. How could the VP make this decision? How could he be so dumb? You know this will cost money and customers. You hit the reply key and start to list all the reasons this is a really bad idea.

If you've ever been in this spot, you know that sometimes telling the big boss he's about to be an idiot works and sometimes it just gets your butt kicked. Communicating effectively up the chain requires some finesse.

Suspend Judgment
Most likely, the managers in your company aren't stupid people. The decision may make sense from a perspective that you can't see right now. One day I came to work to read an edict that every project must provide evidence of compliance with a certain off-the-shelf methodology. Never mind that most of the department had no training in the methodology and didn't have access to documentation for it. Development managers were told they must comply or provide evidence explaining why their project should be exempted from the requirement. In terms of changing the way teams developed software or improved project performance, this was about the most nonsensical thing I had ever heard.

Then I learned that top managers in the company had made a strategic decision to enter a heavily regulated line of business. In order to receive approval to compete in this arena, the company had to pass an audit to establish that the development area adhered to a repeatable development process.

That bit of information explained the focus on compliance and producing documentation for exceptions. The goal of implementing a methodology wasn't to improve the quality of the software or the predictability of projects. As long as the methodology helped the company past the audit, it was a success.

If you can't imagine a scenario where the management decision would make sense, ask around. But, ask in a way that doesn't imply anyone is stupid. Questions such as "What's the intent behind the database decision? I'm puzzled about how the vendor upgrades will be handled," will work better than "Didn't they think about the upgrade path?"

You may be able to pass important information upstream. Hierarchy tends to act as a filter: Top management may not be in touch with all the detailed operational aspects of how employees actually move product out the door. If this is the case, you may have information that will help them make a better decision. Figuring out how to get information up the chain effectively requires savvy and planning.Assess the Lay of the Land
Hold off on the reply button a bit longer and don't barge into the VP's office just yet. Look around your organization to see how information flows up. Can the newest programmer sit down and talk to the VP of development? Does communication follow the org chart? What happens to people who bring up problems to their boss's boss? Do they get a fair hearing without retribution? Or are they sidelined forever?

If your organization communicates only along the chain of command, work the chain. If you hit a brick wall at the first level, you need to decide how important it is to you to push the issue further. Is it worth having your boss chew you out? Is it worth losing your job? I'm not saying those responses are right, but it is the reality in some organizations. Look around and decide how much it's worth to you.

Some organizations are different in different areas. I worked in one company where it was okay to skip levels in the development organization, but not in the test organization. The key managers in the test organization were ex-military. In the test organization, issues went step-by-step up the chain of command or they didn't go at all.

Speak the Same Language
State your position in a way that maps to management concerns, and in language they'll understand—which usually means money. Going technical on a manager who has never worked in the technology arena will cause his eyes to glaze over. First, identify one-time costs like development, testing, additional hardware or infrastructure, documentation, conversions, and rollout. Then list ongoing costs: continued maintenance and support, modification of new versions, licensing agreements, and so forth. Don't forget customer-related costs and consequences.

Do Your Homework
Don't just walk in and say, "Hey, this will cost a lot." A complete cost analysis isn't necessary; some level of factual information is. If you aren't fluent in budgets and capital expenditures, find someone who is knowledgeable to coach you. If your manager is supportive of your efforts, she can help you with fully burdened development costs, equipment costs, or license costs for the product you work on. I have found that the folks in accounting are often quite happy to explain how budgets work.

Sum up your findings in financial terms and lay out customer consequences. Take a little trouble preparing how you will communicate up the chain. It may take a little while, but if you do it right, you'll look like a leader and you may save the company a serious misstep. When the SalesSupport team showed the VP that it would cost $2 million to migrate existing customers to the ClientMaster(SM) database, he changed his mind.