Chapter 6: Collecting and Capturing Business Requirements for IT Projects

---

Introduction

At several points, this volume has alluded to business analysis as a role within the project management office (PMO). The business analyst is integral to project delivery and continuous process improvement — both among the customers served by the IT organization and within IT itself. In fact, changes within the enterprise and IT go hand-in-hand. Almost invariably, when new technologies are added to established or emerging business practices, those processes must change to reap the full benefit of IT enablement. Similarly, the IT organization must adapt itself to the additional products and services in its portfolio of deliverables. Within this grand scheme, the business analyst's role supports the design, development, and implementation of change in a number of ways:

• Documenting existing business processes and customer uses of IT

• Developing and documenting process flows in terms of a particular technology-enabled solutions (i.e., functional specifications)

• Developing project business and functional specifications and assisting in the drafting of technical specifications

• Working with the project manager to develop statements of work, project schedules, deliverable descriptions, issue tracking documents, and management reports

• Preparing test scripts and quality assurance scenarios for the testing and release management processes

• Facilitating and supporting business process reengineering within customer departments and perhaps within the IT organization itself

Key to this work is gathering knowledge about how the enterprise serves its customers. As an outcome of this process, business/IT project teams can establish the particulars for reengineering and IT-enablement undertakings. Look around your organization and you will see that many of your colleagues are regularly engaged in the collection and analysis of customer business requirements. For instance, service delivery personnel must gather customer requirements for their SLAs and performance measures. Project management teams get deeply involved in the documentation of business requirements as part of the analysis and design phases of any project. Thus, the process of business requirements gathering is important to most of us in IT. On the one hand, the quality of this work determines how well you understand your customer's need for and commitment to process change; on the other hand, the effort establishes the metrics for customer satisfaction in the delivery of the IT systems that will help to enable those process changes. By adhering to a set of thorough and accurate customer requirements, IT personnel will more properly align product and service delivery with their customers' needs and expectations.

There are many sound approaches to the process of business requirements gathering. Some of these are cited in the selected readings section in Appendix K. The author's own view of requirements gathering reflects his interests in business process reengineering and knowledge management. I blend these two disciplines in my approach to the task. To frame this discussion, let us consider the context for the work of business analysis.

Each enterprise's business processes dictate their own information needs and associated IT requirements. The typical enterprise has no more than six or so key business processes. Within these large operating realms, however, there may be any number of information management subsystems in play, each with its own demands for IT. At any given time and as part the allocation of IT resources and effort, the enterprise will focus on some subset of these processes, looking to enhance their capabilities or even to completely reengineer how they impact the business unit and its customers. A sample set of key business processes within an enterprise might include the following:

• Lead generation — the processes of market and competitive analysis, market awareness and branding, customer prospecting, and prospect profiling and identification

• Sales cycle management — the process of converting prospects into customers

• Delivery management — the manufacturing process, ^[1] including customer and engagement management

• Distribution management — the process of product or service delivery to the customer

• Financial management — the processes of accounting, accounts receivable administration, accounts payable administration, financial controls, and reporting

• Human resource management — the processes of payroll and benefits administration, staff recruiting and retention, and staff training and development

Note that these logical groupings of business processes capture most, if not all, process work within an enterprise. The nature of your particular business may require that you recast these representational groupings to better reflect your marketplace (e.g., a bank might refer to delivery management as service delivery, and a university might refer to the same grouping as program and classroom delivery), but the intent is the same. Within these headings, one may arrange all of the products and services that IT provides in support of enterprise business processes. As Chapter 2 and Chapter 3 have already discussed, external market forces and customer demand, as well as the internal drivers within the enterprise for process improvement, will encourage your business leaders to reevaluate their technology investments regularly. In some cases, they will recognize the need to enhance existing IT systems; in other instances, they will call for their wholesale replacement. When this occurs, line-of-business management will call upon the unique skills of the IT organization to help sort out the change process and to integrate or reintegrate technology with patterns of work.

As a starting point, business managers typically consult with their IT organization counterparts (or their IT CREs) to identify and select those IT projects of the greatest value to the enterprise. For example, if the enterprise has just expanded its sales force or faces problems with customer retention, the team might target the technology complex that supports sales cycle management for a face lift. Similarly, if the enterprise finds that it cannot compete in terms of the cost effectiveness of its manufacturing process, the team might choose logistics or distribution management for an IT-enabled makeover. Your organization should follow some rational process, like the one offered in Chapter 3, to identify, select, and prioritize projects for the IT team. Eventually, project teams will be charted and the analysis will begin to determine how best to deploy information technologies in support of your business partners' requirements. Even during the commitment process detailed in the previous chapter, the project will need to conduct enough research to properly scope the assignment and to recruit colleagues with the appropriate skills for the work at hand.

In choosing an approach to requirements gathering and analysis, your team must take into account the culture of enterprise, the quality of the IT organization's current relationship with the business units in question, and the nature of the business process and set of technologies under review. No two situations call for the same approach. In most instances, however, your business analysts should gather the same sorts of information to establish replacement processes, including process workflows, business rules, the roles and responsibilities of process participants, existing points of IT enablement, and so forth. This chapter offers a systematic yet simple and straightforward way to decompose and document business process components for subsequent analysis. The benefits of this approach reside in its adaptable application to very different sorts of business activities and its ability to engage customers in the discovery process. If, as a result of this rapid-fire approach to requirements gathering, the team uncovers issues that call for more detailed research, analysts may devote more focused time to these components of the business process. In the end, you will find that perhaps 70 to 80 percent of your questions are answered through the thorough use of the author's template, complemented by other methodologies as needed.

^[1]In a mature service economy, such as that of the United States, the enterprise's deliverables to the customer are usually a set of services rather than tangible goods. Therefore, the reader should not limit his or her frame of reference to a particular subset of our service economy. The author's model applies to all types of for-profit or not-for-profit enterprises.

---