Preparing for Business Requirements Gathering

---

To begin, the project team should consider the nature of data to be collected, categorized, and managed. To this end, the author offers a simple, knowledge-components model that characterizes the categories of knowledge to be drawn upon at the outset of requirements gathering:

• Marketplace/customer knowledge — information about business barriers and opportunities, customer profiles, prospect profiles, market demographics, and so forth

• Content knowledge — information about your enterprise's actual products and services, performance history, staff competencies, intellectual and physical assets, and so forth

• Process knowledge — information about how your enterprise manages itself in terms of its key processes (e.g., solution selling, manufacturing, distribution), as mentioned previously

Much of this information will come from sources internal to the business process under study, but some must also come from upstream providers to that process and the downstream customers of that process. For example, as an IT team begins work on the design of a new manufacturing system, it may focus its attention on interviewing key participants in the manufacturing process. At the same time, the team must include input from the logistic people (upstream) who provide the raw materials for manufacturing and the warehousing and distribution people (downstream) who handle the finished product.

The actual sources of information will themselves vary from one business function to the next and will be greatly influenced by the culture of the business unit in question. For example, any business operation that is audited on a regular basis or must comply with a great deal of regulation, such as finance and accounting or human resources, is likely to have formal policies and procedures already in place. These documents would be an excellent starting point for project discovery work. As your business analysts begin their data-collecting activities, consider these factors in searching for documentary evidence about business processes:

• Information may originate from sources external or internal to the business unit under scrutiny by the project team

• Information may be explicit (recorded in some medium) or tacit (walking around in the heads of content or process experts)

• Information may concern the enterprise's marketplace and customers, for example:

  • Business barriers and opportunities

  • Customer profiles

  • Customer and market demographics

• Information may concern the content of the business, for example:

  • Product descriptions

  • Service descriptions

• Information may concern actual business processes, for example:

  • Solution-selling workflows

  • Manufacturing workflows

  • Distribution workflows

Be forewarned, however. You must validate that department personnel actually follow the workflows and procedures as outlined in these documents before accepting them as an accurate portrayal of real business practices.

In contrast, other operating units run entirely on oral history. The only way to determine how things are done is to interview the key stakeholders at all levels within that business unit. Other sources of information to consider (if they are available), include departmental histories, operating manuals, prior IT organization research, meeting minutes and systems documentation concerning the IT systems already in place, customer and employee survey information, and the written and verbal musings of operating personnel. Do not rely entirely on the views of management. Managers will more often than not tell you how things should work rather than how they actually do work. Scrutinize whatever information the project team receives. Take nothing at face value, and ensure that you get a balanced viewpoint. All in all, be critical of what you read, hear, and learn.

Unfortunately, there may be a disconnect between what your sponsor and working clients believe must happen as a consequence of your IT project and what in truth is required. You need the support of management to proceed, so do not be antagonistic. Listen respectfully, but reserve judgment. Remember that your purpose is to collect objective business process requirements and to use these data points to move both the business and the IT sides of the house toward consensus about the scope and nature of the IT project at hand. By employing a simple lens and asking open questions, the team's business analysts should obtain the spectrum of information required for further action. To this end, your process of data collection and analysis must be deliberate, methodical, and as free of prejudice as possible.

Once the project team has identified its targets for analysis, it should obtain the backing of the sponsor and working clients to proceed. The true test of that support will be evidenced by the quality and quantity of time that line-of-business participants spend with you and your team. Sometimes, it makes sense to formally charter the data-gathering effort, defining these elements:

• Roles and responsibilities of business and technical personnel

• Scope of information to be collected and reviewed

• Desired data collection and analysis outcomes

• Timelines for the completion of tasks (a mini-project plan)

• Process metrics

For its initial set of activities, the project team would then conduct a quick, high-level mapping of the business process to derive a general knowledge of requirements. To that end, the team must explore both the business and technical sides of each business process by examining the following components:

• Current state of business process knowledge components:

  • Project charters

  • Contracts

  • Standing business requirements

  • Project plans

  • Resource plans

  • Budgets

  • ROI analysis

  • Process models and maps

• Current state of technical process knowledge components:

  • Operations scenarios

  • Operations documentation

  • Test plans and scripts

  • Performance metrics

  • Technical documentation

  • Change orders

As a next step, the team would complete an information system asset inventory and gap analysis, identifying the gaps in the current IT offering and any additional attributes desired of the enhanced or replacement system. Armed with this information, the team can proceed to identify those aspects of the process and its business functionality that require more in-depth research and understanding. As a final phase in the business requirements gathering effort, the team will construct a formal set of business requirements to be reviewed in detail by appropriate members of the business team and ultimately signed by the sponsor and the working clients. ^[2]

In concluding this work, the project team will have the business requirements that it needs to move from analysis to design. But getting to customer signoff can be tricky and is almost always laborious. Although your sponsor may want the project done, he or she cannot understand why all this time must be spent in discovery. Unfortunately, you will find that some of your customers do not want to be held accountable and are therefore annoyed by the rigor of the requirements process. Similarly, you and your team do not want to be accused of analysis paralysis by either business or IT management. Yet to blunder ahead without adequate attention to business requirements can only end badly when you turn to IT solution development and delivery. To balance these conflicting demands, use a thorough methodology that quickly lays out the entire business case in sufficient detail. You may then return and drill on those components that require more in-depth scrutiny. The process mapping technique demonstrated in this chapter will readily gather most, if not all, the information required to generate a satisfactory framework and blueprints for a formal IT solution design.

^[2]During the course of data gathering, the project team will identify key business process participants, who, due to their experience, knowledge, tenure, and veracity, have won the respect of the team. The project director must find ways to ensure that these folks are engaged in the process of project requirements development and review. When management is respectful of these employees and their opinions, bringing them into the formal process makes sense. But when management is clearly uncomfortable with their involvement, the project team should find ways to involve them informally. It would be a mistake to discount the views of these employees merely because they are out of favor with management.

---