Seven Success Factors for Requirements Planning
If care isn’t given to planning the activities of defining product requirements, the entire project could go awry. It is one of the biggest reasons why 60% of project defects are due to requirements and almost half of the project budget is spent reworking requirements defects. There are many success factors that can relate to projects, products, and processes. Some apply to all three. For example, time taken to clarify roles and responsibilities helps ensure that all stakeholders know their accountabilities. Without a clear definition, it is almost certain that not only will tasks remain undone, but that those involved will be unhappy. Since stakeholders are involved in projects, in defining product requirements, in implementing new products, and in completing business processes, defining roles and responsibilities applies to all.
Here are some other examples of common success factors:
Regardless of whether we are working on projects, products, or processes, we work with other people. Collaborating, establishing partnerships, and using our networks in and outside of our organization help us face challenges and problems when they arise. We’ll find that others are more willing to help us through difficulties. When we implement a new project, product, or process, it is important to obtain agreement from those affected. Without this buy-in, the affected stakeholders may sabotage our efforts, intentionally or unintentionally.
- Clearly Articulated Benefits
All stakeholders involved need to have a clear understanding of what they are trying to accomplish and why. They need a clear sense of direction, and also an understanding of how their work contributes to the health and well-being of the organization.
- Managed Scope
Scope applies to projects, product requirements, and processes. The project and product scope are intertwined, since the scope of the product requirements affects the scope of the project. The project scope includes the entire effort to produce and implement the end product. Developing a prototype of a new bridge (product), for example, will usually take less effort (project) than creating and building the bridge itself. The scope of a process also needs to be managed. All processes begin and end, which are their boundaries or scope.
- Process Scope
This intertwines with the other two types in that the relative process scope size will affect how large a project is to work on it, and the product deliverables that are produced. As an example, if the project is to create software for a retail store point of sale application, it will be larger if it includes the process of Returns in addition to just the process of New Sales transactions.
- Clear Communications
Communication that sends the intended message in its entirety is meant to clarify, and if direct and unambiguous promotes success in work on projects, product requirements, and processes. Incomplete, unclear, or dishonest communications are some of the easiest ways to ensure conflict, as stakeholders struggle to make sense of what information they have received.
- Asking the Right Questions
Whether working on projects, product requirements, or processes, we will encounter things that need clarification. When we don’t understand such things as a requirement, a task, or a process step, we know to ask for clarification. However, sometimes we assume that the sender and receiver of the message have a common understanding when, in fact, they do not. We call this having different “mental models,” or mind pictures. On product definition, for example, a common reason requirements change is because we think we understand the business need, when really our mental picture is quite different from our clients.’ Because differing mental models can cause a great deal of rework on projects, products, and processes, it is important to ask clarifying questions.
- Adequate but not Burdensome Documentation.
No matter how good our memories are, we sometimes forget important things.
- Project. Agreements, deliverables, milestones, and risks plans are required on projects of all sizes.
- Product. A list of requirements and/or appropriate models, plus a method for ensuring that approved requirements have been implemented, are important for most business analysis work. Although the amount of formality varies from project to project, the need for the appropriate amount of documentation exists.
- Process. The documented process of who performs the work, what steps they will take, where the process begins and ends, initial inputs, and final outputs are included in the process documentation that is needed to ensure repeatability. Of course, too much documentation can be demoralizing and costly.
Common Success Factors for Projects, Products, and Processes – Seven “Cs”
In summary, projects can easily struggle and fail for many reasons. Not taking care of requirements and failing to plan are major contributors to failed projects. By following our seven “Cs” of planning, you can help your projects achieve greater success, run smoother, and result in happier customers. The success factors apply equally to other facets of work, such as with project and product planning, and will help beyond requirements planning.
The preceding is an excerpt from the book Practitioner’s Guide to Requirements Management, Part I: Requirements Planning, written by the authors of this article.
Don’t forget to leave your comments below
Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com) For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK). Their book, Practitioner’s Guide to Requirements Management, Part I: Requirements Planning is available through Amazon.com. For more information, contact them at 800-646-9362, or at www.WatermarkLearning.com.