Abstract
Through our experience working with project teams, in many industries, on hundreds of projects, we recognize that although project managers may understand the theory for developing project requirements, they do not have viable tools, techniques, or processes for enabling project stakeholders to clearly define their needs and the expected outcomes for the project. On many projects, the requirements definition effort can take months or, in extreme cases, years to complete before any tangible benefits are realized by the project effort. In this case, it is not uncommon for the environment in which the project was originally established to have changed.
All too often, project teams dive into the solutions they want to implement before ever gaining alignment on and before fully understanding the underlying needs for which they should be solving. Many times project team members believe that they can save the team time by starting with a solution, rather than starting at the beginning of the project and defining the needs. These “silver bullet” solutions rarely work. In fact, they often result in project teams’ implementing what appears, on the surface, to be a great solution, but what in reality is a solution that fails to address the true needs of the organization.
Project requirement definition requires a progressive elaboration approach. This approach starts with high-level definition of the Project Scope, which sets the boundaries for areas within the organization that are anticipated to change. Next, the team expands on the scope statement by collaboratively uncovering the need statements to be solved for (business requirements). Finally, the team can drill down to a technical approach, finding appropriate solutions that satisfy the project needs. This concept may seem simple, but unfortunately 71% of projects either fail outright, or are “challenged”---projects deliver fewer features and functions than the customer expects, are completed over budget, or are completed behind schedule (Standish Group, 2004).
The top four factors associated with project failure are:
- Poor end user/customer involvement (stakeholders)
- Poor executive management support
- Improper planning
- Unclear statement of requirements
This paper focuses on poor end user/customer involvement and unclear statement of requirements. It will present tools and techniques that can be used collaboratively to build comprehensive and clear project requirement statements that differentiate between what is needed and how the need will be met.
Project Requirement Definition Facilitated Meetings
Project teams struggle with developing clear requirement statements when they lack the tools and techniques to ensure that there is appropriate stakeholder involvement throughout the requirements definition activity. In far too many project environments, project managers do not possess skills enabling them to engage all necessary project stakeholders effectively in collaborative meetings, in order to describe their needs for the project. As a result, on these projects, the project manager, or a small subset of project team members, write the requirements for the stakeholders. These requirements are then routed throughout the organization in an attempt to gain alignment and buy-in. Often, the requirements are not uniformly understood and do not represent the full breadth of the project needs. This can lead to costly rework later during the project life cycle, or after the project implementation, when these missing or misunderstood needs are identified.
JAD (Joint Application Design) facilitated meetings effectively improve the requirements definition activity by incorporating collaborative meeting and group management techniques led by a neutral facilitator (i.e., someone without a stake in the project outcome). These facilitated meetings engage all of the appropriate stakeholders as participants who collaboratively meet, make decisions, and interactively build their project requirements.
For the success of any JAD meeting to be increased, the meeting must be fully planned before it is started. Planning enables the project management team and the facilitator to set expectations and agree on the deliverables, the activities to be created, and the techniques that will be used to produce project requirement deliverables, during the meeting. The facilitator conducts the meeting, using collaborative techniques to collect information, validate this information, and adjust it continually to ensure that it is clear and complete and addresses the needs of the project. The results of facilitated JAD meetings are consensus among participants, ownership, and buy-in on all decisions and deliverables produced during the meeting.
Foundation for Successful Requirement Development
Project Stakeholders
Project stakeholders must understand and be aligned on the boundaries of the project effort before the first requirement statement is ever written. This is accomplished when the project stakeholders work together to define the scope of their project. Project teams choosing to bypass the creation of a Project Scope statement are often operating under false assumptions, such as:
- “We talked about the scope when we kicked off the project, so people already understand the scope.”
- “We have a small project team, so everyone is already aligned on what we are doing and why.”
- ‘We have to implement a solution quickly, so we don't have time to document scope.”
Project stakeholders include anyone with a vested interest in or anyone who is impacted by the project. Key representatives from each of the project stakeholder areas, internal and external to the organization, should be engaged in the project scoping requirements definition activities. For the purposes of this discussion, project stakeholders are grouped into two different categories: (1) business/end users and (2) technical/solution providers.
Project Scope Statement
Without a clear Project Scope definition, the project stakeholders lack critical information needed to determine if any requirements are missing, if the solution proposed can be implemented, if the requirements effort has expanded beyond the expected areas of change (i.e., scope creep), or whether requirements discovered as the project progresses should be included or excluded from the project effort. The requirements definition activities can result in a random collection of business need and solution statements that may fall into an unconstrained project effort. Think of this as a funnel where only some of the business needs and some of the solutions work their way down through the funnel to the implemented product or project solution. Business needs and solutions are not necessarily linked together (Exhibit 1). Critical needs and solutions may remain outside the project effort, only to be discovered after the project implementation or too late in the project life cycle to be included without major rework and impacts to the project schedule and budget.
Exhibit 1---Project Requirements Developed Without a Defined Scope Statement
The starting point for differentiating the “what's” of a project from the “how's” of a project is the creation of the Project Scope Statement. The Project Scope Statement defines the project boundaries by describing what impacts the project will have on the organization, what parts of the current processes will be impacted, what interfaces are included in the project effort, what limitations will constrain the project effort, on what factors will the project success be measured, and what assumptions exist under which the project team is operating. Understanding all of these high-level “what's” provides the foundation for the project team to make decisions regarding which requirements to include in the project and which solutions best support the direction of the organization. The most accurate Project Scope Statement, offering the highest value to the project team, is one developed by all the project stakeholders, not by just the project manager.
The Project Scope Statement generally includes five specific deliverables. Once these deliverables are defined, they will guide the project team as they drill down into lower levels of requirement definition activities (Exhibit 2). The Project Scope Statement includes:
- Objectives (business and project)
- Context diagram---differentiating business processes and external entities
- Project constraints
- Critical success factors
- Project assumptions
Exhibit 2---Project Requirements Developed with a Defined Project Scope Statement
When asked to facilitate requirements definition activities for customers who will not invest the time to create the entire Project Scope Statement, we require the project team to define, at a minimum, the objectives, context diagram, and project assumptions. Business and project objectives enable the team to understand the changes that the organization is attempting to achieve (increase, reduce, or improve results of the organization) and the specific project efforts that will be funded to help the organization achieve these results. The context diagram will identify the organization's business processes that are expected to be changed by the project and the interfaces, or hand-offs, that need to be provided to external entities as part of the project solution. The project assumptions will identify decisions outside the control of the project team that are believed to be valid, but which may be invalid. These decisions directly influence project requirements, including what is in or out of scope for the project.
Requirements Definition: Documenting the “What's” for a Project
Types of Requirements
At the highest level, every project has two types of requirements: business requirements (what's) and technical requirements (how's). Business requirements define what the organization wants or needs to be able to do once the project is completed. They describe the changes in capabilities that will result from the project. Technical requirements, on the other hand, define solutions for how each project need will be satisfied. These solutions are directly linked to one or more business requirements. Many times, teams that implement a project that is missing expected functionality started by defining solutions first because they assumed that the needs were obvious and that everyone was already aligned on the needs. However, having everyone naturally aligned on the needs at the beginning of a project is rarely the case. Solutions implemented without a direct tie to a specific business need expose the project team to gold plating and possible project failure. When faced with this situation when working with our clients, we tell project teams that if everyone is already aligned on the business needs, it will not take much time to write them down formally. Ultimately, during the course of the activity to define the business needs, project teams realize that they were not aligned at all.
As project stakeholders define the business needs for their project, it is necessary to look beyond the obvious functional requirements covering the core business capabilities associated with the business processes on the context diagram. Stakeholders should also consider interface requirements, which are capabilities driven by the external entities represented on the context diagram. Additionally, nonfunctional, or supporting requirements, can be uncovered by ensuring that the meetings include participation beyond the core business stakeholders. Nonfunctional requirements vary by type of project and industry, but typically include:
- Audit requirements
- Security requirements
- Information movement requirements
- Reporting requirements
- Information integrity (validation/edit) requirements
Business Requirement Facilitated Meetings
Initially, the project manager should arrange to hold several 2- to 3-day collaborative meetings focused on defining the business requirements. The first business requirement meeting focuses on the higher level or “parent” requirements. Parent-level requirements include conceptual needs across all of the business processes, interfaces, and support requirement categories. The subsequent business requirement meetings drill down these “parent” requirements into detailed business requirements or “child” requirements.
To ensure that the business requirement statements focus on project needs and not on solutions, the meeting facilitator prompts the project stakeholders to begin each statement with the words “Ability to” or “Ability for” (Exhibit 3). Some project teams start their business requirements with the phrase “The system shall provide the ability to.” We prefer not to start business requirements using the words “system or system shall,” as these words tend to steer the activity into discussions on solutions and technical capability, rather than on business needs and functional capabilities.
Exhibit 3---Parent- and Child-Level Business Requirements
Initially, business requirements are brainstormed without regard to which business process they fall under. After the brainstorm, the requirements are clarified and categorized under one of the business processes. If the stakeholders find they are unable to categorize the business requirement under just one business process, this means that they have a gap that needs to be resolved. Causes of this gap include the following:
- The business requirement is not specific enough and may need to be broken into multiple statements, with each statement describing a need specific to the functionality associated with a business process.
- The business requirement is out of scope for the project, which is why it does not have a business process it fits under.
- The business requirement is valid, but the team discovers that there is a missing business process that should have been included as part of the Project Scope. After securing approval to add the business process, additional brainstorming is needed to identify other missing requirements that belong to the new business process.
During the business requirement meetings, the mix of business and technical project stakeholders consists of 90% business stakeholders and 10% technical stakeholders. We work with many customers who try to completely separate these two groups of stakeholders during the requirements effort. They often believe that business requirements need to be defined without the influence of technical solutions/limitations, or that the technical stakeholders simply do not need to be involved in the project until after the needs are clearly defined and “thrown over the wall” to the technical team to solve for.
Although it is true that the business requirement definition activities should not be constrained, too early, with perceived technical limitations, value is added to the definition effort by including a representative group of technical stakeholders in the facilitated meetings. These stakeholders provide insight as to whether a business requirement is clear enough for the technical team to use when considering solution options later in the project. They can also help identify when a requirement is too vague or appears to contain a solution.
The focus of the business requirement meetings is to ensure that stakeholders agree on business requirements that state the needed business capabilities, without describing how to find solutions for the need. Statements that include information about files, feeds, tables, flags, indicators, architecture, and so on are solution-oriented statements. Technical stakeholders should understand what the business wants to be able to do as a result of the project. When they hear that the business stakeholders describe solutions as needs, they should ask what the solution will enable the business to do, what is the need. This helps to lead the discussion back to the true business needs (i.e., the “what's”).
Requirements Definition: Documenting the “How's” for a Project
Once the project team is aligned on the business requirements, which clearly state the needs for the project, they are ready to expand the requirement statements to include solutions. By using the business requirement statements as the driver for documenting the project “how's” and tying each solution directly to the business need, the team ensures that the project includes only solutions that are in scope for the project. This minimizes the risk of using the project as a mechanism to justify a solution rather than to address a defined business need. By using this technique, solutions can be traced all the way back to the business processes that were expected to change and to the objectives that the organization expected to meet.
Developing the Technical Approach
Project teams should begin defining project solutions by starting with the documentation of a technical approach consisting of broad concepts relating to the architecture and foundation of the solution. The technical approach is usually formulated outside of the facilitated meeting and contains information used to understand the context that the technical requirements should fit within. The high-level technical approach could include categories, such as:
- Security
- Information management
- Software platform
- Storage
When project stakeholders attempt to define solutions without alignment on the technical approach, the technical requirement effort can stall due to confusion over multiple potentially viable ways to address the solution and solve for the needs of the project.
Technical Requirement--Facilitated Meetings
Project stakeholders should use collaborative facilitated meetings, scheduled over 2- to 3-day periods, to define the technical requirements. During the technical requirement--facilitated meetings, the mix of project stakeholders flips to 90% technical stakeholders and 10% business stakeholders. Again, it is highly recommended to include both types of stakeholders in these meetings. Although technical stakeholders may be resistant, the intent is not to encourage business stakeholders to dictate how the technical team should solve for the project solution. Business stakeholders provide value by confirming that the business need has not been missed or misconstrued in an attempt to drive to a solution. They also confirm, early on in the project, that if the proposed solution is developed it will in fact address the real business need and not create a negative impact on the business processes.
The solutions documented during the meetings are considered high-level design (HLD) in most methodologies. The statements describe how the technical team will address each project need listing out each change that they will make in the current environment. The documentation in these meetings is not intended to delve into low-level design (LLD), where the team will describe detailed characteristics and attributes associated with their solution (e.g., file/report/screen/lay-outs, field sizes, and attributes). Documentation of the technical requirements may also include technical assumptions. Technical assumptions provide alignment on any scope limitations of the solution.
The vocabulary for writing technical requirement changes from the vocabulary for business requirements. These statements should start with more specific verb phrases, such as:
- Build a table to
- Add logic for
- Modify the procedure to
- Update a screen/report/file to include
The change in verb phrases shifts the focus of the requirements from describing what capabilities or abilities are needed to how the capabilities will be met. Technical requirements are defined for every business requirement included in the project scope (Exhibit 4). With the individual business requirements serving as the driver for technical requirements, the project team ensures that every solution to be designed and implemented directly supports an agreed upon need for the project effort.
Exhibit 4--Technical Requirements Mapped to Business Requirement Statements
Sometimes, multiple viable technical approaches exist for the project solution. When this situation exists, it is best for the project stakeholders to assess each approach individually, comparing them side by side and identifying the pro's and con's, in an attempt to select one approach for defining the technical requirements. If one technical approach cannot be determined as the most viable approach, the meeting facilitator will need to ensure that the stakeholders are aligned on the multiple approaches being considered. The meeting discussion will need to document detail technical requirement statements for each technical approach being considered. As the details of each solution are clarified, it generally becomes easier for the project team to make a clear decision on one approach over another, or possibly to discover a new or blended approach to meet the project needs.
Summary: Ensuring Requirement Traceability Throughout the Project Life Cycle
By defining the boundaries of the project effort at the beginning of the project using the Project Scope Statement, the project stakeholders will have established the framework for making all future project decisions and tracing the evolution of the project requirement statements from high-level business needs (the “what's”) to lower-level solutions (the “how's”). Project managers need to ensure that they engage representatives from all affected stakeholder areas to minimize the risk of overlooking critical project needs. As business requirements are defined across the breadth of the business processes, consideration for functional requirements, interface requirements, and supporting nonfunctional capabilities need to be included.
To ensure that business requirements are both clear and in scope for the project, they must be mapped back to one business process defined during the project scoping activity. Creating a cross-reference column for the business process on each requirement statement allows the stakeholders quickly to see and review related business requirements together. Project stakeholders will have the ability to cross-refer business requirements to project assumptions and the business objectives, as well, by adding cross-references to each uniquely defined statement.
When project teams drill down to the project “how's” with technical requirements, they are literally expanding the business requirement statements by adding additional rows of detail under each business requirement. Using this technique continues to ensure that solutions tie back to business requirement needs, which in turn map to business process, and ultimately business objectives.
When project teams clearly differentiate between project “what's” and project “how's,” they increase the quality of the requirements defined for a project, reduce the incidence of missed requirements, and help prevent the implementation of unsubstantiated solutions that fall short of delivering expected functionality at the conclusion of a project.
