I have a theory. I think that technical people are being insulated from important business matters. Perhaps it's because management wants technical people to concentrate on technical concerns. Perhaps it's because management isn't convinced that technical people understand anything about business strategy. Whatever the reasons might be, I want to put my theory to the test.

Think about the project you're working on now. Mentally examine your part of it, then expand your mind to encompass the entire project. Think about all the groups working on it and what they do. Think about the timeline. And think about the anticipated end result. Got all that firmly in the forefront of your consciousness? Good, because it's quiz time. See if you can answer the following questions:

1. Why is this project important?
2. How does it contribute to the long term strategic direction of the company?
3. How will it improve the company's competitive position in the near term?
4. How much will it cost?
5. What financial benefits (reduced costs, increased revenues, etc.) will the project bring?
6. Who will benefit most from a successful outcome to this project?
7. What will happen if the project fails?
8. What capabilities will the users find most compelling and why?
9. If users don't use this software, what will they use instead?
10. How well would the majority of the technical contributors on the project answer these questions?

My final question is more personal: how did you feel when you were answering those questions?

If you felt confident that you understood both the marketplace in which your company operates and the business case for your project, you're probably in the minority. More often I find that technical people (who themselves are usually quick to chastise management for technical cluelessness) are unaware of the business reasons behind project decisions.

No wonder many software defects boil down to miscommunications. It's difficult to understand what you're building if you don't know why you're doing it.

Let me give you an example of the importance of "why."

Early in my career I was put in charge of document production at a small company. Eager to be precise, I provided precise measurements for the spacing of 3 holes along the left hand side of the 8.5" x 11" booklets. The day before the documents were due back, Barry, the manager at the document reproduction company, called me.

"Why do you need the holes in these documents?" he asked.

"Uh, so I can put them in 3-ring binders." I replied, wondering where this conversation was going.

"That's what I thought," he said. "In that case, whoever did these measurements is smokin' something." I blushed furiously; glad he couldn't see my expression over the phone. That would be me, I thought to myself. Barry continued, unaware of my embarrassment, "They won't fit in a 3-ring binder at all. Should I just punch these for a 3-hole binder and ignore the measurements?""Yes," I replied meekly. As I hung up the phone I realized that I'd made a silly mistake in trying to be so precise. My intent was to ensure that there could be no room for miscommunication. Instead, I'd almost caused a disaster. Fortunately, Barry had enough experience with documents that he guessed my intentions. Knowing intentions is the key to requirements. That's the difference between "recorded requirements" and "real requirements."

I often see requirements that read like my specifications for the three holes in the documents. They're precisely worded, but there's no hint about why the software should do what the requirements ask.

"The window shall be no more than 800x600 pixels in size."

Lovely. Why?

Some of you may have recognized those numbers, a common monitor resolution. A window larger than that size will overwhelm the screen on a low-resolution monitor. But how much harder would it be to say, "The warehouse personnel use machines that operate at 800 x 600 resolution. All windows must fit on the screen without scrolling, so don't make them larger than that size."

If you are beginning to wonder if you know enough about the business, seek out the information you need. Read everything you can get your hands on: your company's press release, financial data, competitor's web sites, customer discussion forums, and consumer reviews. Ask your manager about the company's strategic direction and how your current project contributes. Keep asking questions about the business until you really understand not only what you are being asked to do, but also why you are being asked to do it.

Then, if you find yourself in a situation like Barry, asked to do something that doesn't make sense, you'll have the knowledge to articulate your concerns. And in doing so, you might find that management is a little more open with technical people about their business concerns. Show them that you can learn about their world, and they'll give you the information you need. Go ahead, challenge them to give you "the business."