I Don’t Have Time to Manage Requirements; My Project is Late Already! Part IV

Requirements Summary

In this series we have provided an overview of requirements management, a description of the requirements management plan and its components, and some tips on how to negotiate for realistic time frames that include just enough time for the appropriate amount of requirements management.

Before we conclude, we need to make some important distinctions among terms that are sometimes used interchangeably. These distinctions are important, since they are not only invaluable for requirements planning, but also help clarify roles and responsibilities.

A Few Key Terms

The following are some terms which, when clarified, will aid in requirements management:

Project Management and Requirements Management.

Project management focuses on delivering the end product within constraints, such as time and cost. Project management includes the entire effort to produce the end result, of which requirements management is a part.

Requirements management focuses on defining the features, functions, capabilities, and characteristics of the end product, ensuring that they are defined completely and correctly.

Business Analysis and Requirements

Business analysis is the work of producing requirements. Business analysis can be performed in one project phase or many.

Requirements are the end result of completed business analysis work. Again, they describe the features, functions, characteristics, and capabilities of the end result of the project.

Projects, Products and Solutions.

Project. Endeavor or undertaking that produces a unique end product, service or result.

Product. We are using the term as it is defined in the PMBOK® to mean the end result of the project.

Solution. There can be both business and technical solutions. The business solution is defined by the sponsor and business subject matter experts. The technical solution, if there is a technical component to the project, is defined by the technical subject matter experts. After requirements have been defined, they are turned into a solution to the business problem that needs solving.

Life Cycles, Methodologies, Approaches

Life cycles describe the phases that take the project from its inception to its end. While it can be used to describe products (for example, the life cycle of a new pharmaceutical drug), concepts (life cycles of safety), or of living things (fleas and flowers), we are going to think of a life cycle of the project. Project life cycles are important, because they need to be managed.

Methodologies define how to get from the beginning to the end, usually through prescribed processes and templates. Frequently, phases and phase names are provided, as well as tasks to be completed within each project phase. The methodology may or may not prescribe multiple phases for completing business analysis.

Approaches are like “hybrids,” not quite life cycles and not quite methodologies. Examples are agile and Waterfall. Proponents of certain approaches often refer to “methods,” such as agile methods or SCRUM.

Summary of Requirements Management

Below are activities that need to be performed, either formally or informally, with a great amount of rigor or with practically none. They are closely aligned with the BABOK, version 2.0 but, since that document has not been published, we have avoided specific references to the Knowledge Areas. These are processes that need to be performed, regardless of the methodology or approach used.

Planning Business Analysis

These are the set of activities included as part of planning the business analysis phase, or phases, of a project. Whether planning for a new process, new or enhanced software, a new bridge or a feasibility study, deliverables and tasks must be identified, planning processes must be identified or created, roles and responsibilities must be agreed on, metrics established, and a plan for communications, formal or informal, must be created. Although not all project life cycles include a formal phase(s) for business analysis, the activities that comprise business analysis need to be taken into account.

As described in the series Overview, one of the key deliverables is the Requirements Management Plan, which is a set of documents that can be expected to change over time. The subsidiary plans that comprise the Requirements Management Plan are executed and updated at different points during business analysis.

Elicitation

This set of activities includes gathering stakeholder requirements and ensuring that their needs have been understood. Effective elicitation requires the ability to ask the right questions, listen to and synthesize responses, and record customer requirements. These skills are required for effective project management as well. Finally, elicitation tasks include determining elicitation techniques that are appropriate for the project.

Enterprise Analysis

In a nutshell, this process includes tasks to recommend, which projects to undertake by completing feasibility studies and cost benefit analyses. Once projects are undertaken, recommend the product scope.

Analysis

This set of activities includes the progressive elaboration of requirements from highest level to subsequently lower levels of detail, as more becomes known. Its purpose is to ensure that the business needs are truly understood and that requirements are defined completely and correctly. The requirements need to be elaborated in enough detail so that business clients are satisfied that their needs will be met, and the development team can create the end product or service.

Solution Assessment and Validation

This knowledge area describes how well the solution, or end product, solves the stated business problem and meets the approved requirements. This knowledge area includes activities related to making sure the end product matches the stated requirements, and is closely related to Quality Management.

Requirements Management and Communication

This set of activities involves the packaging of requirements to provide the level of documentation agreed upon in the Requirements Communication Plan (Business Analysis Planning and monitoring), taking into account the various audience preferences for format, level of detail, and frequency of communication. It also covers the handling of conflicts and issues. Finally, this knowledge area describes managing changes to the product and version. Because changes have to be managed across business analysis, it relates not only to Communications Management, but also to Integration Management.

Below is a matrix summarizing the interrelationship between the knowledge areas for Requirements Management, as shown in the BABOK, and project management, as framed in the PMBOK.

                 Integrating Requirements Management and Project Management

Final Words

In summation, requirements management, whether done formally or informally is a vital aspect of project management. Without the requirements management plan, the overall project management plan is incomplete. Taking the time to plan and manage requirements will lead to a better end product and increases the chances of having satisfied stakeholders.

In addition, if we revert to when requirements were not managed, we can expect to see the cost of projects and defect repair, as well as scope creep continue to increase. However, if we spend too much time on requirements management, we are at risk of creating a burdensome process that will delay the project. It is important, then, to apply an appropriate amount of requirements management rigor to our projects to ensure that we have:

• Thought about the approach we will take 
• Identified the business analysis deliverables
• Developed a requirements schedule
• Planned for requirements communications
• Clarified important roles and responsibilities
• Communicated our plan to our sponsor, ensuring an understanding of the requirements management plan and its importance

This care will help all stakeholders in planning their time and encourages their active participation on the project.

References
Ambler, S. (last updated March 3, 2007), Agile Modeling, retrieved on January 7, 2008, from http://www.agilemodeling.com/essays/changeManagement.htm and http://www.agilemodeling.com/essays/examiningBRUF.htm

Davis, A. Just enough Requirements Management Part 1, retrieved on January 7, 2008, from http://conferences.codegear.com/article/32301.

IEEE Standard 610,

1990,International Institute of Business Analysis (2006). A Guide to the Business Analysis Body of Knowledge, version 1.6.

Project Management Institute. (2004) A guide to the project management body of knowledge (PMBOK®) (2000 ed.). Newtown Square, PA: Project Management Institute.

Software Engineering Institute (SEI’s) Square Project updated 5/12/05.

are Principals, Watermark Learning, Inc. Watermark Learning helps improve project success with outstanding project management and business analysis training and mentoring. We foster results through our unique blend of industry best practices, a practical approach, and an engaging delivery. We convey retainable real-world skills, to motivate and enhance staff performance, adding up to enduring results. With our academic partner, Auburn University, Watermark Learning provides Masters Certificate Programs to help organizations be more productive, and assist individuals in their professional growth. Watermark is a PMI Global Registered Education Provider, and an IIBA Endorsed Education Provider. Our CBAP Certification Preparation class has helped several people already pass the CBAP exam. For more information, contact us at 800-646-9362, or visit us at http://www.watermarklearning.com/.