6. Elicit High-Level Business Requirements

Note: In this framework, the term initiative refers to programs and projects. The term work execution unit refers collectively to programs, projects, phases, releases, and work packages, all of which are considered temporary organizations.

Defining and Differentiating Requirements

The Core Definition

The foundational definition of a requirement applies universally, regardless of the scale or level of the initiative. According to the International Institute of Business Analysis, a requirement is “a documented representation of a condition or capability.” This definition serves as the starting point for distinguishing between the different types of requirements that emerge at various stages of an initiative

Business vs. Functional Requirements

A critical distinction exists between business and functional requirements. This distinction is based on their purpose and the stage at which they are defined. This principle is applicable across all levels, from a program to a specific work package.

• Business Requirements: These describe the new capabilities the organization will possess after an initiative is completed. They represent the high-level outcomes. The process of eliciting these requirements occurs during the initialization stage of a program, project, phase, or other work increment.
• Functional Requirements: These specify precisely how a technical solution will satisfy the business needs. They are defined later, during the planning stage of a project or work package. This detailed work is undertaken when a team of subject matter experts is available to detail the solution’s specific behaviors and features.

The Nature of High-Level Business Requirements

Focus on New Capabilities

At the initialization stage of any initiative, the focus must be exclusively on its high-level business requirements. The objective is to articulate the new capabilities the business seeks to acquire. These capabilities are the direct outcomes that will be enabled once the goal deliverable for that specific program, project, phase, release, or work package is handed over to operations.

The extent and granularity of a “new capability” is relative to its position in the work hierarchy:

• A program delivers a set of broad, strategic capabilities.
• A project delivers a more specific capability that contributes to the program’s goals.
• A phase or release delivers an incremental portion of a project’s capabilities.
• A work package delivers a discrete, granular component of a capability.

Example: Improving Transaction Transparency

Consider an initiative with the goal of “improving the transparency of the status of all transactions” via a new online solution. The business requirements, defined as new capabilities, could include the following:

• Allowing customers to place, follow up, and change orders online without intervention from the customer service department.
• Allowing the company to invoice customers without human intervention from the accounting department.
• Allowing customers and the company to have a summary and the status of all orders and invoices, including all past transactions.
• Allowing customers and the company to have access to all past communications.
• Allowing the customer service department to immediately identify a calling customer and have all related information at hand during phone calls.

Distinction from Benefits

It is essential to differentiate between business requirements (outcomes) and the benefits that result from them. This distinction is crucial for maintaining proper governance and justification at each level of an initiative.

• Outcomes: These are the new capabilities themselves. For example, the ability for customers to track orders online is a direct outcome of a project.
• Benefits: These are the positive results expected to materialize over time from using the new capabilities. For example, a higher customer retention rate is a potential benefit.

The relationship between outcomes and benefits is often hierarchical. The justification for a program is frequently tied to achieving strategic business benefits, such as higher customer retention. The example notes that customer dissatisfaction had multiple root causes, including lack of transparency, invoice errors, and long phone wait times.

Therefore, the realization of the overall benefit required a program that combined outcomes from multiple projects. The justification for a single project, such as the transparency initiative, is to deliver its specified outcome. The project’s success is measured by the delivery of that capability, which in turn contributes to the program’s intended benefit. An outcome from a single project may not be sufficient on its own to realize a major business benefit.

Practical Guidance for Elicitation

Conduct of Elicitation Meetings

When gathering high-level business requirements during the initialization of a program, project, or any sub-component, the primary goal is to achieve agreement on the new capabilities the business seeks to have once that initiative’s deliverable is in place.

Avoiding Technical and Solution-Oriented Language

The process must conscientiously avoid describing how the new capabilities will be implemented from a technical perspective. Any statements that are solution-oriented do not belong in the high-level requirements defined during the initialization stage. This applies at all levels and includes any discussion or documentation containing information about:

• Files
• Feeds
• Tables
• Flags
• Indicators
• Architecture

Such details are to be defined during later planning stages within the appropriate project or work package.

Conclusion: Role and Placement

High-level business requirements are not technical requirements. They are a clear articulation of the new capabilities the business aims to acquire through the successful completion of an initiative. This definition work is a fundamental part of creating the initializing reference for a program, project, phase, release, or work package. It sets the strategic direction and establishes the justification for the endeavor before any detailed solution planning begins.