International Project Management Day




Requirements Management Plan


Quick Summary
Requirements are the backbone of the project, and how effectively they are managed can make or break a project. A requirements management plan captures the tools the team will use to record and track requirements, reinforces the importance of traceability, and articulates the project's risk management and change control strategies.


This template requires a Premium Subscription
Please log in. Don't have a log-in? Sign up now. Already a Member? Log in to upgrade immediately and get the file! A Premium subscription is only $14.95/month or $149/year and gets you over 200 templates, guidelines, and checklists.
15-day free trial period for new Premium subscribers! Learn more
Log in to download this file

Username:  
Password:  

What this is

A Requirements Management Plan documents the essentials of the requirements management process, including What is going to be done (scope, deliverables), How it's going to be done (resources, tools, people, naming conventions, traceability, timeline), and What's standing in the way (risk, change control). It specifies the information to be used to gather requirements, measure the work performed, report progress, and control changes for the project.


Why it's useful

Requirements are the backbone of the project, and how effectively they are managed can make or break a project. This is especially true for technology projects, but it's important regardless of the nature of the effort. The Requirements Management Plan is used to clarify roles and responsibilities, articulate timelines, define the boundaries of the scope of the work, and establish and maintain accountability over business analyst deliverables and their schedule. The plan captures the tools to be used, reinforces the importance of traceability, and articulates the risk management and change control strategies.

The Requirements Management Plan is drafted during the early phases of a project, Concept and Initiation. While the high-level scope, team, and timeline are defined, the business analyst (or the project manager acting in that role) supports these activities and incorporates the results into the draft plan. This iterative process continues throughout the planning process, as the team collaborates to define the work effort. By the end of the planning phase, the Requirements Management Plan should be defined, reviewed, and approved as a baseline. That's not to say it won't change–it likely will–but this is when the team can say with confidence, "Here's how we plan to manage the requirements for this project." Setting expectations up front and clarifying roles, responsibilities, priorities, and sequence early in the project will go a long way to ensuring that requirements elicitation, documentation, and validation go well.

Any of the sections of this document can be fleshed out in greater detail than others, depending on the nature of the project. The exact details and even the format of this document are not important. What's important is that you've thought through your approach to requirements, documented your planning efforts, and know how to proceed.


How to use it

  1. Tailor the plan outline. The sections in this template walk you through all the things you'll want to plan for in the requirements effort. But every project is a little different, so take the time to consider your project and add or remove sections as necessary. Review your outline with a peer or the project manager as well; their input and approval will help get you going in the right direction.
  2. Begin with what you know. Once you're comfortable with the plan outline, start by filling in the sections you feel comfortable with. Much of the initial information is probably available in existing project documents or notes from meetings and other team discussions.
  3. Fill in the rest, with team member help. Seek out members of the core project team and business stakeholders to help you fill in the rest of the plan. If you're working with a team of business analysts, get input from them about what they expect to see. Use this input to revise the plan until you feel it's likely to have both practical value and support from your stakeholders and team members.
  4. Distribute the draft plan to the project team, stakeholders, and your peers to solicit feedback and buy-in. Once the team has provided feedback and approval, publish the approved version as a baseline. Things change, so don't imagine that this version will always be current, but clear expectations up front will go a long way towards making the requirements process effective.
  5. Once the template is baselined, don't just put this on a shelf and forget it! Use it to help manage the requirements domain, and update it with changes as needed.


    This template requires a Premium Subscription
    Please log in. Don't have a log-in? Sign up now. Already a Member? Log in to upgrade immediately and get the file! A Premium subscription is only $14.95/month or $149/year and gets you over 200 templates, guidelines, and checklists.
    15-day free trial period for new Premium subscribers! Learn more
    Log in to download this file

    Username:  
    Password:  




    Related Templates
    Requirements Change Management Guideline
    This guideline condenses 20 years of lessons learned to provide a complete overview of change management components, processes, and controls.

    Requirements Measurement Plan
    This template is designed to help you think through how you will ensure that the documented requirements meet the expectations of your stakeholders, both in content and in quality.

    Requirements Workshop Planning Guide
    Detailed tips and a step-by-step guide to planning a requirements workshop designed to elicit and understand a specific set of requirements. Includes extensive suggestions on planning and conducting the workshop and post-meeting follow-up, along with a sample agenda and general meeting facilitation tips.

    Software Requirements Capture Guideline
    Detailed guidelines from an experienced software development executive intent on capturing all necessary requirements, documenting them thoroughly, and ensuring they are well understood.

    BURNING QUESTIONHow can I stay on track if they won't let us do requirements work? 
    When the conversation with Management is "we don't need to do requirements," we have to start by looking at how Management seems to be thinking of requirements.




    ©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
    About us   Site Map   View current sponsorship opportunities (PDF)
    Contact us for more information or e-mail info@projectconnections.com
    Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
888-722-5235
Learn more about ProjectConnections, our contributors, and our membership levels and product options.