Printer Friendly Version

Do any of the following prevent you from asking more questions? You are:

• Afraid you might appear incompetent or uninformed
• Assume you already know all there is to know about the system you're developing
• Uncomfortable with the skill of questioning.

If you can answer "yes" to any of the items above, you may be putting your intranet system development project at risk.

A few months ago, I attended a Requirements Definition and Introduction to Process Modeling class given by Dan Myers of Myers & Associates, Inc. In the class he discussed a tool he calls "The Fate Chart." This chart helps you, your team, and your internal clients understand the difficulties faced when going through the process of defining requirements. It looks like this:

Let me explain each of the four quadrants individually.

When you don't know that you don't know, the result is left up to fate. This is the ignorance is bliss (or disaster) mode of operation. Since you don't know that you don't know, you don't ask questions nor do you document it in the requirements.

When you don't know that you know, it is because the fact, information, or habit is already ingrained in you as the result of your experience. In this case the risk is less than leaving it up to fate (because you ultimately know) but not ideal unless it can be articulated into a statement of fact within a requirement so your development team can know as well.

If you know what you know, then it is considered fact and becomes a requirement. This can be a gray area because of the two distinct ways in which something arrives at becoming a requirement.

When you know that you don't know, you need to ask questions. This is where the challenge I referred to earlier becomes evident. As information technology professionals and corporate managers, we tend to not want to ask questions. There is job security in appearing highly knowledgeable and indispensable. The fear is that if we allow ourselves to be vulnerable and ask a lot of questions it will reflect negatively upon our performance or others' perception of us. As a result, when we find ourselves in this quadrant of "you know that you don't know," one of two things happens:

1) You set aside your ego and ask skillful open-ended questions until such time as you have sufficiently distilled the facts and can mold them into a requirement,

2) You make assumptions which by default "become" fact and are included in the requirements.

While your concerns, fears, and tight deadlines might make scenario No. 1 look like the one with the most negative impact, in reality, scenario No. 2 creates the most significant potential risk and cost to your project. Why?

• You could potentially build and deliver the "wrong" system.
• Mistakes discovered later in the system life cycle cost exponentially more to fix than those uncovered in the requirements phase. In fact, defects found in released software are 80 times more expensive to fix than defects found in the specification phase. ¹

The topic of the art of the question could fill at least a book if not more. However, here are some quick tips you can use in your requirements process to help elicit the clearest and most accurate facts you can.

• Ask open-ended questions that cannot be answered simply with a yes or no.

• Loop simple questions to delve deeper. For example you might ask "What happens next?" Keep asking that question after each subsequent answer to get a full picture of the detailed flow of a process.

• Approach your inquiry with genuine curiosity. If you come from a place of curiosity and use appropriate tone and language, your internal customers are more likely to relax and open up rather than feel threatened or act defensive.

• Ask the same question to people who are involved at different points within the process to corroborate their stories and ensure your requirements reflect reality.

Perception is reality and everyone has a different perception of the current system or situation and how it should be. That is why the art of the question and clearly defining and clarifying requirements so everyone can clearly understand them is so crucial to your intranet's success.

¹ Source: "Getting Business Requirements Right: Fixing the Highest-Leverage Stages in the System Development Life Cycle" White Paper by Digital Mosaic
(http://whitepapers.itsj.com/detail/RES/1079466347_199.html&src=FEATURE_GLOBAL)