What a project manager really needs to know about requirements

Abstract

Successful project management is all about documenting project scope decisions. What is the problem in scope management? Project managers have not been exposed to best practices in documenting requirements. Project managers have not been trained in negotiating conflicting requirements. To make the project situation worse, many organizations don't have business analysts to assist the project manager in the specialized tools and training needed to elicit, analyze, specify, document and confirm stakeholder agreement with the requirements.

This paper provides a general outline that you can follow to incorporate industry standard requirements activities and correlate key practices, tasks and techniques in the International Institute of Business Analysts (IIBA) Body of Knowledge (BOK) with the Project Management Institute (PMI^®) A Guide to the Project Management Body of Knowledge (PMBOK^® Guide). To accomplish this, a project manager will look at these three areas: International Institute of Business Analysts (IIBA) key knowledge areas, tasks that are common to all projects and distinguishing between different elicitation and analysis techniques.

Discover key requirements knowledge areas

The Discovery Process

As a project manager you need to understand the total business analysis knowledge areas that are required for an end-to-end requirement process. This ensures coordination of business analysis scope development activities with project management cost and time measurements.

The requirements process has no single, established best practice standard. Yet you are expected to know how to effectively gather requirements from diverse stakeholders to capture needs and wants successfully in project charter and planning documents. The stakes get even higher since we know that monitoring, controlling, and execution activities, and successful customer project acceptance all depend on how well we discover, develop, and document scope requirements.

IIBA has summarized the key knowledge areas that are necessary to successfully complete project requirements activities throughout the project. (Exhibit 1). There are key tasks and techniques that can be grouped into common knowledge areas. These knowledge areas are important for the business analyst to understand and master. Successful project management is more likely to happen when a project begins well. Effective requirements discovery, analysis and documentation practices are key factors in project success.

The IIBA knowledge areas focus on requirements. Requirements are necessary attributes in a system. They are statements that identify a capability, characteristic, or quality factor of a system in order for it to have value and utility to a user. All the following knowledge areas are necessary to successfully document project requirements.

Exhibit 1 – IIBA Knowledge Areas

The key to project success: You need to have someone on the team that understands all the issues in each of these knowledge areas. If you don't have the expertise, you have several options: hire expertise, contract expertise, or outsource part or all of the project work to an outside party. If you can't do any of these options, then senior management has assigned you a death march project; a project that is in your organizations project portfolio but isn't appropriately staffed.

After understanding the key requirements knowledge areas that are necessary on each project, let's explore how business analysis and project management work together for project success.

Define key tasks that are common across industries

The Definition Process

As, a project manager, you need to review the standard business analysis tasks and evaluate how to tailor these activities to your project. This ensures that the planned scope activities will accurately capture stakeholder requirements within agreed too cost and time boundaries. This also will reduce project failure due to cost and schedule over-runs and increase the chance of customer adoption of the project.

Key tasks across industries

There are common project practices regardless of industry or project type. Professional associations have documented these project standards.

Project managers use the PMBOK^® Guide to integrate process groups. The process groups are initiating, planning, executing and monitoring & controlling and closing. These are guidelines needed to integrate project activities. PMI has a broad program focus. (Exhibit 2)

Business analysts use the IIBA knowledge areas to plan and manage requirements. The knowledge areas are requirements gathering, analysis, documentation & communication and requirements implementation. These are guidelines needed to integrate requirements activities. IIBA has a narrower scope focus than PMI. (Exhibit 2)

Technical resources select a development life cycle to guide product development activities. Industry standard business solution life cycles include requirements, design, construction, test and deliver phases that guide product execution activities. Developers have a product focus. (Exhibit 2)

Technical and project management roles have worked together successfully for decades. Now a business analyst enters the picture. Business analysts will assist the project manager in clarifying scope and working with the customers to validate customer satisfaction. Wait – isn't that part of the project manager role? Historically – yes. But business analysts can provide specialized skills sets and additional resource bandwidth to assist the project manager in accomplishing project goals. Alignment of the roles of the project manager and the business analyst occurs by documenting roles and responsibilities.

Exhibit 2 – IIBA and PMI Life Cycle Integration

Alignment of the PMBOK^® Guide process groups and the IIBA knowledge areas is accomplished with a requirements management plan. The analyst proposes which elicitation techniques and analysis models should be used. They submit the plan for project management sign-off. Sign-off provides authorization, funding and resources and team commitment and customer involvement.

The key to project success: Alignment of the PMBOK^® Guide process groups and the IIBA knowledge areas is accomplished with a requirements management plan (RMP). There is a lot of benefit from creating a RMP. An agreement means that the tough conflicts have been worked out and all agreed too requirements activities are now included in the project schedule.

So let's explore the elicitation and analysis activities that are in the requirements management plan.

Distinguish between different elicitation and analysis approaches

The Distinction between discovery techniques

As, a project manager, you need to agree to specific requirements activities that will be done on your project. The evaluation of their strengths and weakness for your project helps you choose elicitation and analysis activities that provide the best cost and time tradeoffs.

The time and schedule cost is high if including customer and business process user feedback in your project requirements. The pressure is always there from customers and senior management to deliver projects faster. Ralph Young in Effective Requirements (2001) states that studies show that up to 85 percent of the defects in developed software begin in the requirements. So successful project leaders include end user input in the requirements to reduce defects.

End user input is gained by business analysis elicitation and analysis techniques.

The Elicitation Approaches

Elicitation has several names. IIBA has identified elicitation tasks as requirements gathering; others call it requirements development or requirements discovery. Inputs to elicitation would be a charter. An output of elicitation would a business analysis model.

Elicitation is associated with the PMBOK^® Guide initiation and planning activities. Project execution has not begun. Design activities have not begun.

Talking to project stakeholders is mandatory. Talking to them with a purposeful elicitation plan is a learned skill. Literature surveys show that almost dozens of such techniques are available, but a few are recognized as the most effective. The key elicitation approaches are listed in Exhibit 3 with their definition, strengths and weaknesses.

Exhibit 3 – Elicitation Choices

The key to project success: choose elicitation techniques based upon the riskiness of your project. High risk requires more conversations with your stakeholders to ensure understanding of their needs. More conversations mean more models.

Analysis Approaches

Analysis is creating models. Models are created to complement textual based requirements. Executives don't read long textual documents. Customers may not read the complex and confusing shall statements common in requirements documents. Inputs to analysis would be elicitation results. An output of analysis would a further specification and documentation of the analysis model. Completion of business analysis models can also concurrently kick off technical work on architecture design and test case development.

IIBA groups the analysis approaches into four models; problem domain, usage, process and data. See exhibit 4 for their definition, strengths and weaknesses.

Exhibit 4 – Analysis Choices

The key to project success: Choose enough models to have both an externally customer facing view and internally development facing view. Models are invaluable in project communication. Problem domain models bridge the communication barrier between the business analyst and the end users. These models contain the scope and bring consent that the customer visually understands the project boundaries. The data models provide information needed by the technical team to start design, construction and test activities. A complete usage or data model stabilizes the project by giving clear direction to the technical team about project scope. This brings project stability by eliminating unnecessary requirements discovery later in the project that brings confusion and cost to a project team.

Conclusion

Successful project management is all about documenting project scope decisions. Best practices include choosing a combination of elicitation and analysis techniques that are tailored to your specific project. Project managers can use the IIBA approach to elicit, analyze, specify, document and confirm stakeholder concurrence with the requirements.

Benefits of improved requirements practices: