Continue in 2 seconds

Gathering More Than Requirements

  • March 01 2004, 1:00am EST
More in

All systems designers know that you must have sound requirements in order to design any system, including a data warehouse or data mart. Every project methodology includes a section on gathering requirements. Why, then, do so many organizations struggle with this? Many project teams do not have access to actual business decision-makers. Other teams dutifully meet with groups of users, but then struggle with what was collected.

The primary purpose of gathering business requirements is to understand what the business community needs from their analytical environment. You want to understand the basic purpose of the business group and the challenges facing them. You need to have a general understanding of what they do and also of what they would like to do if time, money and technology were not in the way. This provides an overall frame of reference to use as the basis for the rest of the project and helps all of the team members to have a common foundation in the business.

If you have been with an organization for a long time, you may already have a good working knowledge of the business and thus the urge to skip this part of the project. However, remember that you are also trying to bring the rest of the project team up to speed, and there are other significant benefits from gathering requirements.

A strong partnership between the business and systems communities is one of the most critical factors for success on a data warehouse project. The process of gathering requirements is the perfect opportunity to build that partnership. Often, one or two key people have worked to create the project charter and have justified the project. Typically, the rest of the project team and most of the target audience for the data mart have not been involved in this. The project team must expand the partnership across the user community. This includes a cross-section of people from different business functions and from different levels of management. Interview sessions are the perfect opportunity to get to know these individuals. This is also a good time to identify individuals who are interested or may have the expertise needed for subsequent parts of the project.

During the interview sessions, you can learn a great deal about the attitude of business users toward the project. You can also learn about previous exposure and experiences with data warehouses or data marts. It is helpful to know who will actively and enthusiastically support the project, who is relatively neutral and who may not support and will perhaps attempt to derail the project. We can tap into the enthusiasm of our supporters, encourage and educate those who are neutral, and assess the risks that negative individuals pose to the project and develop a strategy to address their concerns.

It is also good to assess project expectations while we are gathering business requirements. During the sessions, I simply ask outright, "What do you expect this project to do for you?" If the user community's expectations are wildly different from the project scope, it is critical to know that now and begin to address these differences.

As you meet with businesspeople, you may encounter cynicism about the possibility that this will actually work. When you meet resistance, don't launch into a sales pitch. Try to dig deeper. Are you dealing with widespread skepticism, or do you have one vocal, influential unbeliever? Ask why skeptics think this will not work. Learn about prior efforts, especially those that fell short of expectations or flopped completely.

Once you understand the concerns, take an honest assessment of the project. What is different now? Is there new management? Is the company facing more serious challenges that are forcing fundamental changes in the business? What makes you think that this project will succeed where others did not? Review your project charter and determine who helped build the business case to try again. In many cases, you will be able to articulate why this project does not have a similar problem or how you plan to mitigate the risk for this effort. Now you are ready to launch that sales pitch about how the data mart will help them make better decisions and improve the business.

People like to participate in decision making rather than be told what to do. Begin by soliciting ideas from the business community. Listen to businesspeople discuss their business needs, business challenges and concerns about the project. Then, continue to include them throughout the project. We need the business community to help us make decisions. Business users who are involved in the project utilize the mart more and defend project decisions by sharing the business rationale. If the users do not feel connected, they do not have a vested interest in making it work. They don't help resolve problems and typically have limited use of the end product. They act as bystanders. We would rather that they be active participants, and this participation starts when we ask them to share their business requirements.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access