<acronym id="asima"><div id="asima"></div></acronym>
<acronym id="asima"><small id="asima"></small></acronym>
<rt id="asima"><optgroup id="asima"></optgroup></rt>
<rt id="asima"><small id="asima"></small></rt>
<acronym id="asima"></acronym>
<acronym id="asima"><small id="asima"></small></acronym>
<tr id="asima"><optgroup id="asima"></optgroup></tr><acronym id="asima"><center id="asima"></center></acronym>
<sup id="asima"></sup>
<acronym id="asima"><optgroup id="asima"></optgroup></acronym>

Project Management Templates > Requirements and Change Management

Requirements and Change Management

Good, fast, cheap: pick two. This traditional project management quip is laced with truth. At some point, your team will have to make tradeoffs between conflicting requirements, or figure out whether (or how) to say no to last-minute scope creep. These templates, guidelines, and worksheet s will help you define and manage your project requirements, and handle change requests without disrupting your project. Our page on Requirements and Change Management Know-How also includes articles, case studies, mini-courses, and more. Plus, check out our list of templates and guidelines for design reviews.

Change Management
  • Guideline for a Simple Change Control Process
    A simple set of guidelines a team can use to indicate which project documents should be put under project/program level change control and when it should happen. This process was created by an IT organization, but is applicable to any group.
  • Configuration Management Plan
    Few things will derail a project faster or more expensively than teams operating from two conflicting design versions or outdated documentation. A Configuration Management Plan attempts to avoid lost time and expensive rework by documenting procedures the project team will use to control critical components of their project's "products"—hardware, software, documentation, written products, etc.
  • Requirements Management Plan
    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.
  • Requirements Measurement Plan
    It takes clear, unambiguous requirements to guide the team to the right result. Creating a plan to measure the requirements, in addition to the project work, insures you aren't handing off muddy requirements that will cause confusion and rework later in the project.
  • Change Control Form
    A form for requesting and documenting changes to the project (e.g. adding new features) or to elements within the project (such as changing a major spec of a piece of a system, product, or other deliverable). Includes fields for impact of the proposed change on the project timeline, budget etc., and on the components of the project deliverables.
  • Recommendation Template
    Craft an organized, well documented recommendation to proceed with a given business solution or alternative. It includes all of the key components needed to make an informed decision about whether or not to endorse or approve the recommendation.
  • Requirements Change Management Guideline
    If you're not doing impact evaluation and communication, you're not doing change management. This guideline condenses 20 years of lessons learned to provide a complete overview of change management components, processes, and controls.
  • Software Test Transfer Forms
    Practical forms to accompany a software build when Development sends it Testing, to serve as a record of what is being transferred, testing instructions, and ultimately a record of what was tested and the results.
  • Project Cancellation Guidelines
    A comprehensive guideline for determining whether a project should be cancelled and, once such a decision is made, for smoothly ramping down and closing out a cancelled project, taking into account possibly wide-ranging implications for your company and customers.
  • Change Management Planning Worksheet
    Any successful project will change something, by definition. For project managers, that means that change management skills are as important as project management skills. This worksheet helps you plan a strategy for successfully managing your users through the change process.

Requests for Proposals (RFP)
  • IT Project Request for Proposal
    A detailed, boilerplate template for an IT Request for Proposal (RFP) submitted by an Australian IT project manager. Color-coding separates pre-approved legalese from project-specific clauses, and File Properties are used as text fields to automatically include some high level project information and contacts.
  • New System Request for Proposal (RFP) Outline
    A comprehensive RFP template for new systems proposal requests, along with guidelines for RFP success and detailed annotations. Customize this template to fit your software system or co-development project and shave weeks off your RFP selection time.
  • RFP for Training Program Development
    Streamline the provider selection process using this template for a Training Program Request for Proposal (RFP). A comprehensive RFP will help you gain clarity and alignment on the real goals of your training program, and will make sifting through offerings and choosing an appropriate vendor easier on your selection committee.

Requirements Definition
  • SWOT Analysis
    A template and tips for conducting a SWOT Analysis—a review of Strengths, Weaknesses, Opportunities, and Threats affecting the subject of the analysis. SWOT analysis is often used to evaluate strategic choices (project objectives, priorities, etc.) and can also be used to review potential impacts on things like a process, solution, or business entity.
  • Business Data Dictionary Template
    A business data dictionary organizes and defines all the data elements relevant to a particular software system, and includes additional information that helps establish a common understanding of the nature of the data element.
  • Technique Brief - Context Diagrams
    Context diagrams are a time-tested method for using simple symbols to illustrate a system's boundaries, benefits, interactions, and data flows. Simple sketches can aid discussions of project features and scope, and detailed graphical interface specifications can improve communication and understanding with non-technical stakeholders.
  • Guideline: Conducting a Gap Analysis
    Whether it's launching a new project or discovering how well the current solution is meeting expectations, you need to know how to get there from here. A gap analysis will help you figure out where there is, where here is, and how best to bridge any gaps between them.
  • Agile Technique Brief: Requirements Cards
    Agile methodologies like Scrum and Extreme Programming (XP) often build on "user stories" as a way of capturing and tracking feature requirements. This brief explains how to use the technique—referred to here as requirements cards in order to widen the horizon to customers and stakeholders.
  • Requirements Interview Checklist
    A requirements interview is a focused interview with a key stakeholder or subject matter expert designed to elicit a specific set of requirements. This checklist is organized into sets of questions you should consider for each interview; important preparation that will increase your credibility and help you make the most of your time with these key resources.
  • 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.
  • Business Rules Management Guideline
    Business rules are an important part of the requirements package, but they're challenging to write, manage, and maintain without a rules repository. This guideline is designed to help you develop your own approach, by providing some basic guidance on business rules and tips for rules organization, management, and change control.
  • Marketing Requirements Document
    Document created by Marketing or Business group or other representatives of "customers" and "users" to express the perceived customer wants and needs for product, system, or service.
  • Product Requirements Specification
    An annotated outline for a Product Requirements Specification. Such a document is created early in a project to define what a product will be designed to do, in response to requests from customers and Marketing.
  • Software Requirements Specification
    Format for a Software Requirements Specification (SRS) document for a particular module or subsystem of software.
  • Interface Protocol Document
    An annotated outline created as a product or system's architecture is being defined, to specify how the different "building blocks" of the system will interface with other.
  • 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. Be sure you're actually building the right thing -- and be sure everyone else is sure, too.
  • Software Release Life Cycle - Phase 1: Preliminary Requirements Gathering
    A 1-2 page description of each recommended deliverable for the preliminary requirements gathering phase of a software release.
  • Requirements Traceability Guideline
    Tracing your requirements to tests, to code, or to other requirements, can be a complex and time-consuming effort. If you're contracted to a government project you may not have a choice. But is it worth it in the private sector? This guideline discusses traceability processes, requirements, and how to weigh the costs and benefits.
  • Requirements Walkthrough Checklist
    A requirements walkthrough is a focused meeting where requirements documents are reviewed in order to finalize or baseline the requirements before they are handed off to the development team. This checklist will ensure you have considered and accounted for the key components of a successful requirements walkthrough meeting.
  • Checklist for Manufacturing Release Readiness
    To be sure your product is really ready to be fully released into manufacturing, consider the items in this checklist from a company's product development process guideline. It asks key readiness questions in areas covering everything from product functionality to reliability, component sourcing to manufacturing yield.
  • New Project Proposal
    Templates providing a consistent format for the capture and evaluation of new product and project ideas.
  • Project Vision Example: Defining a Software Release Life Cycle
    A Project Vision document example from a medium-sized product development company that created a Software Release Life Cycle (SRLC) process to manage million lines-of-code software releases.
  • Product Definition - Critical Success Factors
    A checklist of critical success factors for defining a product, and a worksheet for assessing the current state of your project's information.
  • Project Definition - Statement of Work
    One approach to documenting high-level project objectives and key parameters in a concise document. This document should be only about 2 pages long.

Return to Top

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail info@www.alantis.com.cn
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:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.

<acronym id="asima"><div id="asima"></div></acronym>
<acronym id="asima"><small id="asima"></small></acronym>
<rt id="asima"><optgroup id="asima"></optgroup></rt>
<rt id="asima"><small id="asima"></small></rt>
<acronym id="asima"></acronym>
<acronym id="asima"><small id="asima"></small></acronym>
<tr id="asima"><optgroup id="asima"></optgroup></tr><acronym id="asima"><center id="asima"></center></acronym>
<sup id="asima"></sup>
<acronym id="asima"><optgroup id="asima"></optgroup></acronym>