The PMBOK’s Project Management Documents

Many documents are created in the profession of project management.  Some of these are critical to the successful completion of the project, and others are merely intended for organizing the work flow.  But the Project Management Body of Knowledge (PMBOK) outlines many documents that have an integral place within the structure of project management, and the following list is taken from the PMBOK.

Strategy Artifacts (4.6.1)

• Business Case.  A document that justifies the initiation of a project or investment.  It outlines the benefits, costs, risks, and strategic alignment, providing a rationale for why the project should be undertaken.  It helps decision makers assess whether the proposed action will deliver value to the organization.
• Project Brief.  A concise document that outlines the key aspects of a project, including objectives, scope, deliverables, timelines, budget, and stakeholder information.  The project briefserves as a foundational agreement between the project team and stakeholders, ensuring everyone understands the project’s goals and expectations.
• Project Charter.  The Project Charter authorizes the project, defining its objectives, scope, and key stakeholders.  The Charter is effectively outside of the project and outlines the project manager’s authority, resources, and initial requirements.
• Project vision statement.  Succinctly defines the overarching goal or purpose of the project and communicates the intended outcome in an inspiring way, aligning team and stakeholders around a common vision.

Log and Register Artifacts (4.6.2)

• Assumption Log.  A document where all project assumptions are recorded, tracked, and managed.  It includes details on each assumption’s validity, potential impact if incorrect, and validation methods.  It also helps manage risk by ensuring assumptions are tested and their effects on project outcomes are monitored.
• Backlog.  A prioritized list of tasks, features, enhancements, or issues that need to be addressed in a project or product development.  The project backlog serves as a dynamic to-do list that is continually updated based on project goals.
• Change log.  A record that documents all project changes as they flow through the cycle of proposed, approved, or rejected.  It includes details like the nature of the change, its impact, approval status, and implementation date.  The change log ensures transparency and helps manage the project scope.
• Issue log.  Tracks and manages problems or obstacles encountered during a project. It records details like the issue description, impact, owner, status, and resolution actions. This log aids in ensuring issues are addressed systematically, keeping the project on track and stakeholders informed.
• Lessons learned register.  Captures insights, successes, and challenges from a project.  It includes what went well, what didn’t, and recommendations for future projects. The lessons learned register aids the parent organization in improving processes, decision-making, and project management practices by learning from past experiences.
• Risk-adjusted backlog.  A prioritized list of project tasks or features where each item’s priority is adjusted based on associated risks.  This approach considers not only business value and urgency but also the potential risks, ensuring that risk mitigation strategies are integrated into project planning and execution.
• Stakeholder register.  A lists of all individuals or groups with an interest or influence in the project.  It includes details like their roles, expectations, influence levels, and communication preferences.  The Stakeholder Register helps manage stakeholder engagement and provides a foundation for stakeholder analysis and engagement planning.

Plan Artifacts (4.6.3)

• Change control plan.  Outlines the processes and procedures for managing changes to the project scope, schedule, or resources. It defines how change requests are submitted, reviewed, approved, or rejected, ensuring that all changes are systematically handled to maintain project integrity and stakeholder alignment.
• Communications management plan.  The plan that details how, when, and with whom information will be shared throughout the project lifecycle, it specifies communication methods, frequency, key messages, and stakeholder communication needs.
• Cost management plan.  How project costs will be estimated, budgeted, managed, and controlled.  It also includes processes for cost estimation, funding limits, cost performance measurement, and how variances will be addressed.
• Iteration plan.  Outlines the tasks, goals, and deliverables for a specific iteration or sprint in agile project management.  It details what will be worked on and sets clear expectations for the timeframe.  This plan ensures focused effort and measurable progress within short development cycles.
• Procurement management plan.  This plans specifies the strategies and procedures for acquiring goods and services needed for a project.  It covers vendor selection, contract types, procurement timelines, and how purchases will be managed and evaluated.
• Project management plan.  The master, overarching document that outlines how a project will be executed, monitored, and closed.  The Project Management Plan integrates all other subsidiary plans like scope, schedule, cost, quality, communications, risk, and more, providing a roadmap for project delivery and a guide for managing project performance and changes.
• Quality management plan.  Defines the processes for ensuring project deliverables meet quality requirements.  It establishes the quality standards and provides a framework for quality assurance and control. This plan ensures that the project’s outputs align with stakeholder expectations, regulatory standards, and/or project objectives.
• Release plan.  In agile software development, a release plan outlines the strategic roadmap of when and how features or products will be released to the market or stakeholders.  It synchronizes development work with business objectives, detailing release schedules, content, and milestones to ensure timely and effective delivery of value.
• Requirements management plan.  Outlines the processes for capturing, analyzing, documenting, and managing project requirements throughout the project lifecycle.  It includes how changes to requirements will be handled and how tools will be used for tracking. This plan ensures requirements are clearly defined and managed effectively.
• Resource management plan.  Details how project resources will be acquired, allocated, and managed.  Resources include labor, equipment, and materials, and any other item necessary to complete the project.  It covers roles and responsibilities, resource calendars, training needs, and strategies for dealing with resource conflicts or shortages, ensuring optimal use and availability throughout the project lifecycle.
• Risk management plan.  Outlines how risks will be managed throughout a project.  The main steps are risk identification, analysis, prioritization, and response planning.  This plan helps mitigate negative impacts and capitalize on opportunities, ensuring smoother project execution.
• Scope management plan.  Defines how the project scope will be defined, documented, verified, and controlled.  It includes processes for scope statement development, requirements collection, scope change control, and ensuring the project stays aligned with its objectives, preventing scope creep and maintaining focus on deliverables.
• Schedule management plan.  Outlines the processes and techniques for creating, managing, and controlling the project schedule. It includes how the schedule will be developed, updated, and communicated, along with methodologies for handling schedule variances. This plan ensures timely project completion through effective time management strategies.
• Stakeholder engagement plan.  Details strategies for effectively managing relationships with project stakeholders. It outlines how to identify, analyze, and engage stakeholders, specifying communication methods, frequency, and key messages. This plan ensures stakeholders are involved, their expectations are managed, and their support is maintained throughout the project.
• Test plan.  A document that outlines the scope, approach, resources, and schedule of intended test activities for a project. It describes what will be tested, how testing will be conducted, test deliverables, and criteria for test pass/fail. This plan ensures systematic and thorough verification of product quality.

Hierarchy Chart Artifacts (4.6.4)

• Organizational breakdown structure.  A hierarchical model that shows how project roles and responsibilities are organized within an organization.  It links project tasks to organizational units or individuals, aiding in resource allocation, accountability, and communication.
• Product breakdown structure.  A hierarchical representation of the physical or tangible components of a product, breaking down the product into its constituent parts, sub-assemblies, and deliverables.  It also facilitates planning of product development to ensure all aspects are covered.
• Resource breakdown structure.  An organization of project resources into a hierarchical format, categorizing them by type, such as labor, equipment, materials, or cost centers. It helps in resource planning, allocation, and tracking, ensuring that resources are managed efficiently across all project activities and phases.
• Risk breakdown structure.  A hierarchical framework that categorizes potential risks associated with a project, organizing them by sources, types, or areas of impact, and aiding in systematic risk identification.  The Risk Breakdown Structure ensures comprehensive coverage of all possible risk areas within a project.
• Work breakdown structure.  A hierarchical decomposition of the total scope of work to be carried out by the project team.  It breaks down the project into manageable sections, deliverables, or work packages, facilitating planning, scheduling, resource allocation, and cost estimation.

Baseline Artifacts (4.6.5)

• Budget.  A financial plan that outlines projected revenues and expenditures for a specific period. It serves as a tool for financial control, helping organizations or individuals to allocate resources, track spending, and ensure financial objectives are met while highlighting any variances for corrective action.
• Milestone schedule.  A timeline that highlights key points or events in a project’s lifecycle.  It identifies significant achievements or deadlines like project start, completion of major phases, or delivery of critical deliverables.  This schedule aids in tracking progress and ensuring project timelines are met.
• Performance measurement baseline.  A document that integrates scope, schedule, and cost baselines to establish a reference point for measuring project performance. It allows project managers to compare actual performance against planned, helping to identify variances, manage changes, and ensure the project stays on track towards its objectives.
• Project schedule.  A detailed plan that outlines when tasks, milestones, and deliverables will occur in a project. It sequences activities, allocates resources, and sets deadlines, providing a roadmap for project execution, monitoring progress, and managing time effectively to meet project objectives within the given timeframe.
• Scope baseline.  An approved version of a project’s scope statement, WBS, and its associated WBS dictionary.  It defines exactly what is included in the project and serves as a reference to control scope changes, ensuring that all project work aligns with the agreed-upon deliverables and objectives.

Visual Data and Information Artifacts (4.6.6)

• Affinity diagram.  A tool used for organizing large amounts of data or ideas into groups based on their natural relationships.  The Affinity diagram helps in brainstorming sessions by clustering similar thoughts or issues, making it easier to identify patterns or themes in chaotic data sets.
• Burn chart.  Often used in agile project management, a burn chart visually tracks the completion of work over time against the planned effort. It shows the amount of work “burned down” or “burned up”, helping teams monitor progress, predict completion dates, and adjust plans to ensure timely delivery of project goals.
• Cause-and-effect diagram.  Also known as a fishbone or Ishikawa diagram, this is a tool used for identifying potential root causes of a problem.  It organizes root causes into categories, visually mapping out how various factors might lead to an effect, aiding in problem-solving and process improvement.
• Cycle time chart.  Tracks the time taken from the start to the completion of a process or task.  Often used in lean manufacturing or agile development, it helps visualize how long activities take, thereby identifying inefficiencies, bottlenecks, and opportunities for process improvement.
• Cumulative flow diagram.  A visual tool used in Agile and Lean to show the status of work items in various stages of a workflow over time.  It helps track the amount of work in each stage, highlighting bottlenecks, work-in-progress limits, and overall project flow and stability.
• Dashboard.  A visual display of the most important information needed to achieve one or more objectives, consolidated and arranged on a single screen.  It provides at-a-glance views of key performance indicators, metrics, and data trends.
• Flow chart.  A diagrammatic representation that illustrates the sequence of operations, decisions, or steps in a process.  Using standardized symbols, it visually maps out workflows or algorithms, making complex processes easier to understand by showing how each step leads to the next.
• Gantt chart.  A type of bar chart that illustrates a project schedule.  Each task is represented by a bar; its length shows the duration, and its position indicates the start and end dates.  Gantt charts are a one of the project manager’s most used tools and are vital in planning, coordinating, and tracking project tasks and their dependencies.
• Histogram.  A graphical representation of the distribution of numerical data, histograms  use bars to show how often different values occur within a dataset, grouped into continuous ranges or bins, assisting with identifying patterns in the data spread and central tendency.
• Information radiator.  A large, highly visible display that provides up-to-date information about a project or process to anyone in its vicinity.  Designed for instant, passive communication, Information Radiator refers to any information dissemination system that keeps teams informed about progress, status, or issues without needing active interaction.
• Lead time chart.  A visual representation of the time from the initiation of a process to its completion.  Often used in manufacturing or service industries, it helps in analyzing how long it takes to deliver a product or service from order to fulfillment.
• Prioritization matrix.  A decision-making tool used to rank tasks, projects, or features based on criteria like importance, urgency, cost, or impact.  It can help to determine where to focus efforts by scoring items against predefined criteria.
• Project schedule network diagram.  A diagram that visually represents the sequence of tasks in a project, showing dependencies and the logical flow of work.  A “forward pass” and “backward pass” are used to determine which project tasks are on the critical path and must therefore be actively managed by the project manager.
• Requirements traceability matrix.  A document that connects requirements to their origin and tracks them through to project deliverables.  It ensures each requirement is accounted for, tested, and met, providing a clear link between what was asked for, what was designed, and what was delivered.
• Responsibility assignment matrix.  Also known as a RACI chart, the Responsibility Assignment Matrix defines roles and responsibilities within a project by using a matrix to clarify who is Responsible, Accountable, Consulted, or Informed for each task.
• Scatter diagram.  Graphically depicts the relationship between two numerical variables.  Each point on the plot represents an observation, with its position determined by the values of those variables.  It’s used to identify patterns, correlations, or trends, helping in data analysis and decision-making processes.
• S-curve.  A graphical representation used to monitor cumulative project progress over time.  It typically starts slowly, accelerates, and then tapers off, forming an ‘S’ shape.
• Stakeholder engagement assessment matrix.  Evaluates how engaged stakeholders are with a project, categorizing them based on current and desired levels of involvement (for example unaware, resistant, neutral, supportive, or leading).
• Story map.  A visual tool used in agile development to organize user stories into a narrative flow, reflecting the user journey or product features over time.  It aids in prioritizing development tasks, ensuring a focus on delivering value by mapping out the sequence and dependencies of stories.
• Throughput chart.  Displays the amount of work completed over time in a process or system.  It’s particularly useful in lean and agile environments to assess efficiency, capacity, and productivity, helping teams to understand workflow rates and identify opportunities for improving process speed or output.
• Use case.  Describes how a user will interact with a system to achieve a specific goal.  It outlines the steps from the user’s perspective, detailing the interaction flow, preconditions, triggers, and expected outcomes.  Use cases are critical for understanding system requirements and designing user-centric solutions.
• Value stream map.  A visual tool that illustrates the flow of materials and information as a product makes its way through the value stream.  Originally fom the manufacturing industry, it identifies waste, delays, and inefficiencies in processes, from raw material to customer.
• Velocity chart.  Generally used in agile project management, a velocity chart measures the amount of work a team completes during a sprint, typically in story points or hours. It helps forecast future performance by tracking historical data, aiding in planning, capacity management.

Report Artifacts (4.6.7)

• Quality report.  Assesses the quality of project deliverables against set standards or requirements.  It includes metrics, test results, compliance checks, and improvement recommendations, providing insights into performance quality, areas for enhancement.
• Risk report.  Documents risks, their assessments, and mitigation strategies within a project.  The Risk Report includes details like risk probability, impact, current status, and planned responses.  This report aids in proactive risk management, keeping stakeholders informed about potential issues and the actions taken to manage or mitigate them.
• Status report.  Summarizes the current state of a project, and provides stakeholder with a clear, concise overview of where the project stands against its plan, particularly in the areas of milestones achieved, upcoming tasks, issues, and risks.

Agreements and Contracts (4.6.8)

• Fixed-price.  An agreement where the total cost is set in advance and does not change, regardless of the actual costs incurred.  It places the risk on the seller to deliver the project within the agreed price, providing the buyer with cost certainty.
• Cost-reimbursable.  Allows the buyer to pay the seller for all legitimate, incurred costs plus a fee representing profit.  Cost-reimbursable contracts shift more risk to the buyer since the final cost isn’t fixed, but provides flexibility if project scope or requirements evolve during execution.
• Time and materials.  Payment is based on the actual time worked and materials used.  Often used when the scope is not well-defined, a time-and-materials contract includes a fixed hourly rate for labor and actual material costs, which offers flexibility while increasing the risk of cost overruns if not managed well.
• Indefinite time indefinite quantity (ITIQ).  An indefinite time indefinite quantity (IDIQ) contract provides for an indefinite quantity of services or supplies over a fixed period.  It allows for flexibility in ordering, where the exact quantities and delivery schedules are not predetermined, hence it is suitable for ongoing or unpredictable needs within a set timeframe.
• Other agreements.  Most projects have a myriad of agreements, tenders and contracts that are utilized by the project team and project manager.

Other Artifacts (4.6.9)

• Activity list.  A comprehensive document that enumerates all the scheduled activities required to complete a project.  The Activity List represents the breakdown of the project into constituent tasks, and serves as a base document for many other parts of project management, including scheduling, resource allocation, and project tracking.
• Bid documents.  The collection of papers used in procurement to solicit proposals from potential suppliers or contractors.  They include specifications, terms, conditions, and instructions for bidding, ensuring all bidders have the same information to prepare their offers competitively, fairly, and transparently.
• Metrics.  Quantifiable measures used to track, assess, and report on various aspects of a project’s performance, including indicators like schedule variance, cost performance, quality levels, and team productivity.
• Project calendars.  Outlines the working days, shifts, holidays, and non-working times for the project team and resources.  Used for scheduling tasks, determining project duration, and managing resource availability.
• Requirements documentation.  A set of detailed descriptions that specify what the project needs to deliver, including functional and non-functional requirements, user stories, constraints, and assumptions.  This ensures all stakeholders have a common understanding of what must be achieved for the project to be successful.
• Project team charter.  A document that establishes the team’s purpose, objectives, roles, responsibilities, and operating guidelines.  It sets the foundation for team dynamics, communication protocols, and expectations, fostering collaboration and alignment towards achieving the project’s goals efficiently and effectively.
• User story.  A user story is a simple, informal description of a feature from an end-user’s perspective, capturing what they want and why. It follows the format “As a [user], I want [functionality] so that [benefit],” helping to focus development on delivering user value in agile projects.

The following list is organized by knowledge area.

Project Integration Management

• Project Charter (PMBOK 4.1.3.1).  This document initiates the project and authorizes the project manager.  It documents the business need for the project as well as assumptions and constraints the project must live under.  It generally includes high level scope and quality information.  It is issued by the project sponsor and represents the organizational authorization for the project.
• Project Management Plan (PMBOK 4.2.3.1).  This is the project managers road map and guiding document.  It is probably the single most important document for the project manager.  It outlines how the project will be managed, and includes the project schedule, budget, quality standards, project team requirements, project control, and anything else that is necessary to communicate how the project will be managed.  It should be approved by the project sponsor and changes made according to the official change control procedures specified within.
• Change Requests (PMBOK 4.3.3.3).  When a stakeholder wishes that the project manager make changes to the project, a change request form is filled out and filed within the project management plan.
• Work Performance Reports (PMBOK 4.4.3.2).  In order to communicate the project performance to the relevant stakeholders, the project manager or their delegate produces regular performance reports.  These include earned value reports, memos, justifications, recommendations and the like.
• Change Log (PMBOK 4.5.3.2).  The project management plan contains a record of all changes made, to ensure that the project is tracked and lessons learned are gleaned from the changes.

Project Scope Management

• Scope Management Plan (PMBOK 5.1.3.1).  A component of the project management plan, this document outlines how the project scope will be managed, how scope changes will be addressed, and how the project scope will be monitored and controlled to ensure scope changes do not happen unless they are required.
• Scope Statement (PMBOK 5.3.3.1).  This is the official statement which outlines the scope of the project.  It should outline the primary project deliverables as well as expressly include or exclude items that are not obvious to the scope.
• Work Breakdown Structure (PMBOK 5.4.3.1).  The WBS is the breakdown of the project into components for the purpose of identifying the scope.  The PMBOK’s Work Breakdown Structure and the Activity List (see below under Project Time Management) are separate items, but in practice they are often one and the same.
• Requirements Management Plan (PMBOK 5.1.3.2).  This is generally a subset of the scope management plan which outlines the requirements of the product.  It is important where there are many, complex project requirements, such as software development that contains many user interface design metrics, bug tracking and so forth.
• Requirements Traceability Matrix (PMBOK 5.2.3.2).  This is the central part of the requirements management plan.  It tracks each requirement to ensure all of the small details are addressed and the requirements are satisfied.

Project Time Management

• Schedule Management Plan (PMBOK 6.1.3.1).  A component of the project management plan, this is the central planning document relating to project scheduling.  It contains things like the scheduling methodology and tools as well as level of accuracy, units of measure, and organizational procedures.
• Activity List (PMBOK 6.2.3.1).  This is the official breakdown of the project work into tasks (aka activities).  Unlike the WBS (under Project Scope Management, above) which is used to identify the scope, the activity list is the official breakdown of the project which is used throughout the project for monitoring and control.
• Activity Resources (PMBOK 6.4.3.1).  Each activity is assigned a resource list, which is used to estimate the budget and schedule for the task.  This document consists of a resource table for each task, which can be presented in detail or summarized.
• Resource Breakdown Structure (PMBOK 6.4.3.2).  The RBS is a breakdown of all of the project resources into categories.  This aids in procurement and efficient management of all of the project’s resources.  It is more ideal for large projects with many resources.
• Activity Duration Estimates (PMBOK 6.5.3.1).  In project scheduling, each activity is assigned a duration after the resources are determined.  The compilation of the duration estimates results in an Activity Duration document.
• Schedule Network Diagram (PMBOK 6.3.3.1).  The activity-on-node or activity-on-arrow diagram which visually dispays the relationships between the tasks within the project.
• Project Schedule (PMBOK 6.6.3.2).  Most often the master project schedule is displayed as a gantt chart, a horizontal bar chart with time on the x-axis.
• Schedule Data (PMBOK 6.6.3.3).  Metadata about each task is gathered during the project scheduling process and aggregated into this document.  This includes information such as technical data, potential changes, and information for the project manager.

Project Cost Management

• Cost Management Plan (PMBOK 7.1.3.1).  A component of the project management plan, this document describes how the project costs will be planned, structured, and controlled.  It includes items such as level of accuracy, control thresholds, and performance measurement.
• Activity Cost Estimates (PMBOK 7.2.3.1).  Each task is assigned a budget, and the aggregate of these estimates results in the project budget.  Activity Cost Estimates include labor, materials, equipment, fixed cost items like contractors, services, facilities, financing costs, etc.  They can be presented in detail or summarized.
• Basis of Estimates (PMBOK 7.2.3.2).  The supporting data behind the cost estimates can be compiled into this document.  It can contain things like, assumptions, constraints, range (eg. plus/minus 10%), confidence level, and so forth.
• Project Funding Requirements (PMBOK 7.3.3.2).  This document takes the Activity Cost Estimates and adds the additional factor of time.  Since the tasks are performed at various times and the expenditure doesn’t happen at a constant rate throughout the task, the Project Funding Requirements document specifies the what funds are needed at what milestones to complete the project.

Project Quality Management

• Quality Management Plan (PMBOK 8.1.3.1).  A component of the project management plan, this document describes how the organization’s quality policies will be implemented.  It defines the quality standards against which the products will be measured, how they will be measured, and what the pass/fail criteria are.
• Process Improvement Plan (PMBOK 8.1.3.2).  A component of the project management plan, this document describes the processes used in the production of the project’s deliverables, how they will be monitored, and under what conditions they might be changed.
• Quality Metrics (PMBOK 8.1.3.3).  Often included within the quality or process management plans, above, this document outlines the project or product attributes which will be monitored and controlled, and how the Control Quality process will control them.  It describes specific product attributes, how it will be measured, and what the acceptable tolerances are.
• Quality checklists (PMBOK 8.1.3.4).  A checklist is a tool used to conduct the inspections to confirm the acceptance or rejection of the products based on the quality metrics (above).  It can be a simple check or one or two items or a complex list of frequently performed tasks.
• Quality control measurements (PMBOK 8.3.3.1).  This document consists of measurements of the quality of deliverables produced by the project.

Project Human Resource Management

• Human Resource Management Plan (PMBOK 9.1.3.1).  A component of the project management plan, this document describes how the project team will be defined, acquired, managed and eventually released.  It includes information such as organizational charts, roles and responsibilities, resource calendars, and management techniques.
• Project staff assignments (PMBOK 9.2.3.1).  The staffing documents for the project team, including staff directories, organizational charts, etc.
• Resource calendars (PMBOK 9.2.3.2).  These documents describe the availability of staff members.  They might include commitments to other projects, attendance at conferences, time zones, work hours, or any other item which restricts the availability of staff members to work on the project.
• Team performance assessments (PMBOK 9.3.3.1).  These documents include performance assessments for individual team members as well as performance assessments of the entire project team.  This can be measured via technical success factors or human resources factors such as staff turnover rate, team cohesiveness, etc.

Project Communications Management

• Communications management plan (PMBOK 10.1.3.1).  A component of the project management plan, this document describes the communication needs of the project, how they will be structured, monitored and controlled.  Standard communication needs such as progress reports, investor circulars, and the like, are documented as well as non-standard communication needs like the circumstances when project changes are required.
• Project communications (PMBOK 10.2.3.1).  Under the Manage Communications process, many of the actual project communications with stakeholders become part of the project documents.

Project Risk Management

• Risk management plan (PMBOK 11.1.3.1).  A component of the project management plan, this document describes how risk to the project’s success factors will be managed.  It includes things like risk analysis methodologies, budgeting, and definitions of risk probability and impact.
• Risk register (PMBOK 11.2.3.1).  As the central planning document for project risk analysis and control, the risk register contains a list of the most important risks to the project’s completion.  For each risk, it identifies the likelihood of occurrence, the impact to the project, the priority, and response plans where applicable.  It also details the initial response to the risk, i.e. Acceptance, Avoidance, Mitigation, or Transfer.

Project Procurement Management

• Procurement management plan (PMBOK 12.1.3.1).  As a component of the project management plan, this document describes what external expertise will be required, its justification and scope.
• Procurement statement of work (PMBOK 12.1.3.2).  The statement of work (SOW) describes the work to be performed under a contract. Different industries often have variations which have specific meanings, like Terms of Reference, etc.
• Procurement documents (PMBOK 12.1.3.3).  These are the documents that solicit bids, quotations, or proposals from interested vendors.  They often go by the names Invitation to Tender, Request for Proposal (RFP), Request for Qualifications (RFQ), and others.
• Source selection criteria (PMBOK 12.1.3.4).  This document identifies the criteria under which the bids, quotations or proposals will be evaluated.  It identifies how the successful proponent will be selected.
• Make-or-buy decisions (PMBOK 12.1.3.5).  Sometimes the decision to use internal resources versus procuring an external vendor involves many complex factors.  This can result in analysis of pros and cons, analysis documents and project reports.  These documents become part of Make-or-buy decisions, an output of the Plan Project Procurement process.
• Agreements (PMBOK 12.2.3.2).  Upon signing and execution of contracts and agreements, agreements with vendors become part of the project documents.

Project Stakeholder Management

• Stakeholder Analysis (PMBOK 13.1.2.1).  This document analyzes each project stakeholder in the categories of Power (to create project changes) and Interest in the project.
• Stakeholder management plan (PMBOK 13.2.3.1).  A component of the project management plan, this document describes how the stakeholders will be managed.  It includes things like the stakeholder engagement levels, communication requirements, and stakeholder analysis.
• Stakeholder register (PMBOK 13.1.3.1).  This document identifies each project stakeholder, including which part of the project scope is of the most interest to them, what their main requirements are, their expectations and potential influence.
• Issue log (PMBOK 13.3.3.1).  Project issues are logged for future reference.

Related posts:

Project Management Documents Project Procurement Management According to the PMBOK Project Resource Management According to the PMBOK Project Communications Management According to the PMBOK What is Project Integration Management? Project Stakeholder Management According to the PMBOK