Introduction
As the profession of Project Management continues to integrate with and become a core success factor to new product development efforts, it is important that a formalized, predictable approach to Product Requirements Definition be used. Product Requirements Definition (PRD) methodology helps define the components of an operational product and the method in which these components must integrate to achieve desired results.
The objective of this document is to clearly present the benefits of a formalized PRD approach by outlining an activity progression for the effort, introducing sample template components and discussing the importance of management issues such as Change Management, Risk Management Strategies and Knowledge Management.
Components of Product Requirements Definition Process
The PRD effort is in many respects the most important phase of a product. It sets the foundation for all subsequent phases of the product’s life cycle. The presented approach minimizes the probability of investing additional development time to redevelop or later modify by delivering a clear, identifiable set of specifications for a product effort. An outline of the activity progression may look like:
1. Define, analyze and document the fundamental business need for the product to be developed. By using a Business Case template to guide the process of defining the business need, a framework for the business case will be built that considers the organizational and process issues that must be addressed during the effort.
2. Develop a Product Requirements Document written in natural language to describe the services that the product must deliver. The product will be described from a user’s perspective and will be built based upon inputs such as interviews from expected product users.
3. Prepare process flow charts adequate to complete the design and development of the desired product. This step focuses on the desired user interaction with the product and the services the product will provide. During joint product development sessions, representatives from product development, engineering, process owners and other interested parties work in intense meetings to further define product details. A series of user scenarios are used to guide this process.
4. Identify a business impact map including specific change management challenges and impact priorities that you anticipate will accelerate or impede the introduction of the proposed product.
5. Identify risk management strategies for ensuring success of the product initiative.
6. Document key milestones of the product implementation plan.
7. Obtain sign-off from all parties on Product Requirements Definition Documentation.
8. Identify a knowledge transfer facilitation team.
The Requirements and Specification Process
The requirements process establishes a description of the capabilities the custom product must provide, the environment in which it must perform, and the functional specification of the system. The end result of the structured steps of this process is a software specification adequate for entering into product development. A recommended requirements and specification process is shown in the flow diagram in Exhibit 1. This critical stage of a product’s life cycle is often deemphasized in a haste to deliver an operational product. In reality, however, this is in many respects the most important phase of a product as it sets the foundation for all subsequent phases of the product’s life cycle. Inadequate time and effort spent in the requirements and specification process inevitably results in such problems as delivery of a product that fails to achieve a business need, lengthened schedule to redevelop or modify the product, and increased ultimate development costs. Those development projects without an adequate description of the product’s requirements and associated specifications are at significant risk for failure.
Business Case Study and Requirements
The first step of the requirements and specification process is to define, analyze, and document the fundamental business need for the system to be developed. This business need may be broad and multifaceted, in which case a custom product may be only one part of the solution to the business need. However, the custom product definition must factor in its interaction with other parts of the fundamental business need. This business need will become the basis for all subsequent product requirements and functional specifications. Because a Business Case template is used, the process of defining the business need is repeatable and the risk of missing an important component is minimized. Listed below are some sample elements and supporting questions for inclusion on a Business Case Template.
Exhibit 1. The Scoping Process
Exhibit 2
Business Case Template
Element #1: What Should The Program Accomplish?
1. Describe the overall business purpose or challenge that the solution will help to address.
2. Will the proposed development effort affect your Business Model? If so, how?
3. What organizations will participate in your solution from a “business” standpoint, such as Channel Partners, Business Partners, etc.? Describe the relationship and business arrangement between your company and these partners.
4. What is your vision for business arrangements with end users?
5. Who do you envision as the different “user types” of your system? Who are the end users? Who are the system administrators? How do they fit within the Business Model, and what is the role of each in the solution?
6. What is the expected time frame for completion?
7. List your key milestones for implementation of this system.
8. What are some of the high-level requirements you envision in your solution?
Element #2: Who Will Make It Happen and Is the Organization Ready for Change?
Note: The following questions focus on the organization’s change environment, focusing on roles, responsibilities, and program impacts. Stakeholders are those individuals or groups that have a “stake” in the success or failure of the program. The stake could be responsibility or accountability for the program’s success, involvement with a redundant or related program, or involvement in the definition, rollout, or use of the program.
1. Who is the main decision-maker? (go/no-go, budget, accountability for success)
• Name (optional)
• Position/title
• Department/function
2. What is the decision maker’s role? (Check all that apply.)
• Set direction
• Monitor progress
• Communicate results to leadership
• Accountable for success of program
• Responsible for budget decisions and negotiations
• Responsible for securing sponsorship in organization
• Communicate direction to organization
• Implement program/product specifics
• Other (please specify)
3. Who will be responsible for the successful definition and implementation of the product?
4. What resource roles will be included in the project team?
5. Who needs to “sponsor” the project for it to be successful through the organization (e.g., interested parties in leadership, potential obstacles in leadership, other internal/external partners)? Check all that apply.
• CEO/President
• CIO/IT Group
• COO
• Executive Management team
• Specific Executives (specify function)
• Key personnel in the organization (e.g., vocal supporters/ “nay-sayers”)
• Key customers (internal or external)
• External Partners (e.g., consultants, strategic partnerships)
• Other (please specify, e.g., mergers, independent business units, internal consulting group, etc.)
6. Who are your advocates—who in your organization will be vocal supporters of the project with their peers? Who might speak against it that you can involve in the project (potential converts)? Who will be your power users? How many users will you have? What is the technical skill level of your user groups?
7. What strategies do you plan to use to gain buy-in and create “converts”? (Select all that apply.)
• Communication planning
• Workshops
• Create sponsor committee
• User groups
• Pilot testing
• Change program
• Other (please specify)
7. What “partners” both within and outside of the organization will be affected by this project (e.g., new processes, information links/sharing)? Consider vendors, instructors, human resources, IT, suppliers, customers, outsourced services, etc.
8. Please check the characteristics that apply to this program (see Exhibit 2):
Element #3: How Do You Do It Today—What Is Your Current Versus Planned Business Environment?
The following questions are about the organization’s current business environment versus the “desired future state.” This is where product impact and interdependencies are identified and examined in the business.
10. List the specific impacts that this program is expected to have on:
• Processes (work and support processes—consider changes and interdependencies)
• Policies (promotion, hiring, development, training, etc.)
• Other projects/programs (interdependencies, redundancies, timing issues, resources)
• Customers (Interfaces, customer values and behavior impacts)
• Suppliers (Interfaces, dependencies, changes, commitment levels)
• Business units within the Organization (Interfaces, dependencies, changes, commitment levels)
• Other
11. What constraints will you be operating under? (Financial, schedule, technological, resource)
Element #4: Do You Have the Technology Environment to Support the Program?
12. What is the technology platform vision?
13. What are your current workstation hardware standards?
14. What are your current workstation software standards?
15. What is your next workstation software upgrade and when do you plan to do it?
16. How would you describe your technology environment? Centralized, Decentralized, Both or Neither (explain).
17. What databases are you currently using to store organizational data?
18. What network platforms and operating systems do you use?
19. Describe your technology support process and resources.
Element #5: How Will You Know That the Program Has Been Successful?
These questions should help to identify the degree and related metrics for measuring the results/impact of this product in the organization.
20. To what level does the organization intend to measure the ROI of this investment?
21. What measurements and means of data capture will be used? Besides providing a framework for the business case, the template considers the client’s organizational and process issues that must be considered for a successful project. The stakeholder sections of the template will assist in understanding and addressing the needs of everyone impacted by the project. Finally, the business requirements will define those criteria that will be used to determine the project’s success. Please note—If a documented business requirement already exists for the product, this document can become the basis for development of the subsequent requirements and specifications described below. This document should be reviewed to assure that there exists a shared understanding of its contents and its proposed intent.
Product Requirements
The next progression of requirements development and documentation is the product requirements document. This document should be written in natural language and describe the services that the product must deliver. It should be focused only on external system behavior, describing the system from a user’s perspective. The description should be built upon inputs such as interviews with expected product users and experience with other existing systems.
A template for a PRD could be used which would outline elements such as:
• The user audience for the software product to be developed
• The services the product must deliver
• The operational and performance goals for the software product
The statements made in the PRD should be traceable to statements in the Business Case. Following is a sample outline to use in developing a PRD template.
Sample Product Requirements Definition (PRD) Template
Title Page
Table of Contents
1.0 Introduction
1.1 Purpose of Document
1.2 Scope
1.3 Definitions, Acronyms and Abbreviations
1.4 Feasibility of Alternatives Reviewed
2.0 General Description of Product
2.1 Product Description
2.2 Product Functions and Features
2.3 User Characteristics
2.4 General Constraints
2.5 Assumptions and Dependencies
3.0 External Interface Requirements
4.0 Operational Performance Requirements
Appendices (as needed)
Upon completion of the PRD, a review session with the sponsor is conducted and final acceptance of the PRD is acknowledged through mutual signatures of a PRD acceptance letter. This review process can be facilitated through the use of checklist templates and standardized acceptance letters.
User Interface and Navigation Model JAD
With the fundamental description and constraints of the system described in the PRD, the requirements and specification process must move toward the development of functional specifications adequate to design and develop the product. For web-based systems, an important interim step is to next focus on the user interface and navigation model expected of the system. This step requires a focus on the desired user interaction with the product and the services the product should provide. By using process flow charts to identify current state business processes, desired state business processes and the transformation map between the two, required navigation and User Interface elements will be surfaced.
The Joint Application Development (JAD) session is highly productive for this step of the overall Product Requirements Definition process. In JAD, representatives of the end-users, system owners, developers, and other concerned parties work in intense meetings to define system details. This step of the process, like the previous ones, must focus on the business problem that is being addressed by the system and not on technical details. A series of user scenarios are often extremely beneficial to lead the JAD team through this step of the process. The expected outcomes of this JAD process are a detailed user-interface design based on standard system capabilities, the database schema for nonstandard tables and fields, and a list of system functions and their associated business needs. It should also result in an online screen navigation model and graphic design standards. The JAD session provides another opportunity for the use of standard tools in the form of template guidelines for conducting a JAD session.
Functional Requirements Document
Based on previous steps of the process, this step will develop and document a more detailed description of the system adequate for designing the software. The Functional Requirements Document (FRD) along with the higher-level Product Requirements Document (PRD) serves as the contract specification for the subsequent development phase of the project. As opposed to the previous requirements documents, the FRD should be written for software designers rather than users, managers, and executives. For each of the functions identified in the User Interface/Navigation Model JAD session, detailed specifications for performance of the system must be developed. An outline template for the FRD can be used to provide standardization.
Finalize Solutions and Obtain Sign-Off from Sponsor
As a final step, gather all product specification documents, including the initial Business Case, high-level Product Requirements Document and the detailed Functional Requirements Document to assemble in a formalized work packet. Ensure that all required parties have agreed upon, signed off, and received the documents. At this point, the proposed product can enter the development phase with a sound foundation of communicated, clearly detailed objectives.
Important Management Issues for the Product Requirement Definition Process
Change Management Planning
New technologies and their transformed business processes may be challenged by some in the organization. When managing a PRD effort, it is critical to integrate change management techniques that focus on the landscape of the organization. This is accomplished by identification of a business impact map including specific change management challenges and impact priorities that may accelerate or impede the introduction of the new product and complimentary business practices. By using process flow charts during the User Interface and Navigational Model JAD Sessions (section 1.3), areas of impact have probably already been identified. By expanding these maps, additional impact points will be surfaced and can be prioritized to develop a Change Management action plan. Some activities to consider are: conducting new technology awareness sessions, developing an internal and external communication plan, determining competency gaps relating to the introduction of the new product and processes, evaluating solutions for post “go-live” support and end user knowledge capture and transfer.
Risk Management Strategies
A detailed plan for Product Requirement Definition must include integrated Risk Management strategies in the form of alternatives planning, identification of risk sharing opportunities, and risk prevention tactics. The focus of the risk management activities will initially be during the specification phase but will expand into product development and testing, implementation and post “golive” phases. By mapping potential risks against the Business Impact Map (developed during 1.3 User Interface and Navigational Model JAD and expanded during the Change Management Planning activities), risks can be prioritized to apply the appropriate resources at critical junctures of the product lifecycle. Some sources of risk for the product lifecycle may include: strategic issues, process integration, financial, schedule, change management issues, system performance and expectations, employee retention, resource skills and availability, market responsiveness, business operations and disruption, operational risks, legal concerns, and technology limitations or immaturity.
Knowledge Management
To help negate one of the risks of the PRD process—the availability and retention of resources with necessary competencies— it is prudent to recognize the need for a knowledge transfer plan and facilitation team. This plan and supporting team will help to: locate appropriate knowledge resources internal and external to the organization, compile and manage knowledge, apply organizational knowledge to business challenges surfaced as a result of the product initiative, identify potential knowledge capture mediums, facilitate “Lessons Learned” sessions and assist in integrating a knowledge management approach into the current and future PRD efforts by using templates and repeatable processes.
Conclusion
Product Requirements Definition (PRD) Management defines the components of a product and their required successful integration. This effort is the most important phase of a product as it sets the foundation for all subsequent phases of the product’s life cycle. By using the foundations of project management, this approach provides clear objectives, agreed upon expectations, consideration of the organizational impact, identification of a risk management strategy and facilitation of knowledge transfer between resources to promote and perpetuate the product’s life cycle.
