In PMBOK 7, a project management artifact is any document, output or deliverable created during a project. PMBOK 7 organises artifacts into eight categories: strategy artifacts, logs and registers, plans, baselines, visual data and information, reports, agreements and contracts, and other artifacts. This replaces the PMBOK 6 approach of listing inputs, tools and outputs (ITTOs) within each knowledge area process. The key shift is that PMBOK 7 no longer prescribes when to use each artifact — it describes what each artifact is and leaves the timing to the practitioner's judgement based on the project context.
8
artifact categories in PMBOK 7
49+
named artifacts across all categories
PMBOK 7
replaces ITTOs with principle-based artifact catalog
PMP exam
artifacts tested across all three ECO domains
When PMBOK 7 was released, one of the biggest changes for PMP candidates and working project managers was the shift in how project outputs are described. PMBOK 6 organised everything into processes with inputs, tools and techniques, and outputs (ITTOs) — a highly structured but notoriously difficult-to-memorise framework. PMBOK 7 replaced this with a principle-based model where artifacts are catalogued independently of any prescribed process.
The result is more flexible and better suited to hybrid and Agile environments — but it requires a different kind of understanding. You no longer need to memorise which output belongs to which process. You do need to understand what each artifact is, what it contains and when it is most useful.
This guide covers all PMBOK 7 artifact categories with every named artifact defined, how the framework compares to PMBOK 6, and exactly what the PMP exam tests on this topic.
🔗
Exam context: Artifacts are tested throughout the PMP exam across all three ECO domains — People, Process and Business Environment. Understanding which artifact serves which purpose is more important than memorising categories. For the broader PMBOK 7 exam framework, see the PMP Study Guide and the PMP Certification Guide.
01 — Foundation
What Is a Project Management Artifact in PMBOK 7?
PMBOK 7 defines an artifact as a template, document, output or project deliverable. The term is deliberately broad — it covers everything from a one-page project charter to a complex risk register with hundreds of entries, and from a formal contract to a simple lessons learned log.
The important distinction from PMBOK 6 is that artifacts in PMBOK 7 are not tied to specific processes. In PMBOK 6, the risk register was an output of the Identify Risks process, an input to the Perform Qualitative Risk Analysis process, and so on — the ITTO chain. In PMBOK 7, the risk register is simply an artifact in the Logs and Registers category. When it is created and how it is used is a tailoring decision made by the project manager based on context.
⚠️
Important for PMP candidates: The current PMP exam (based on the ECO released in 2021) blends PMBOK 6 and PMBOK 7 content. You are expected to understand both the ITTO structure from PMBOK 6 and the artifact-based approach from PMBOK 7, plus Agile frameworks. Neither edition is exclusively tested — the exam tests your ability to apply the right approach in the right context. Do not abandon PMBOK 6 knowledge when studying PMBOK 7.
02 — The Eight Categories
All Eight PMBOK 7 Artifact Categories — Complete Reference
PMBOK 7 organises all project management artifacts into eight categories. Below is the complete reference — every category with every named artifact defined.
🎯
Category 1 — Strategy Artifacts
Created before or during project initiation to define purpose, direction and justification
4 strategy artifacts
Business Case
Documents the justification for the project — the problem or opportunity being addressed, expected benefits, costs, risks and strategic alignment. Used by sponsors and governance boards to approve project initiation.
PMBOK 6 equivalent
Business Need
A brief statement of the organisational need or problem the project addresses. Often a precursor to the business case — the "why" before the "how much."
New in PMBOK 7
Project Brief
A lightweight alternative to a full project charter — used on smaller, less complex projects. Contains the essential project definition: objectives, scope summary, timeline, budget estimate and key stakeholders.
New in PMBOK 7
Project Charter
Formally authorises the project and gives the project manager authority to apply resources. Contains project purpose, measurable objectives, high-level requirements, assumptions, constraints, sponsor and PM assignment.
Core artifact — unchanged
Project Vision Statement
Describes the desired end state of the project in inspirational terms. Common in Agile and product development contexts — helps the team maintain alignment with the end goal during iterative delivery.
New in PMBOK 7
Roadmap
A high-level timeline showing milestones, phases or release cycles for the project or product. Used to communicate the overall delivery path to stakeholders without the detail of a full project schedule.
New in PMBOK 7
📋
Category 2 — Logs and Registers
Living documents updated throughout the project to track evolving information
8 logs and registers
Assumption Log
Records all project assumptions and constraints identified during planning and execution. Assumptions are documented, reviewed and validated as the project progresses — an assumption that proves false becomes a risk or issue.
Formalised in PMBOK 7
Backlog
An ordered list of work items, features or user stories to be delivered. Central to Agile and Scrum delivery. The product backlog contains all potential work; the sprint backlog contains work committed for the current sprint.
Agile artifact — new in PMBOK 7
Change Log
Tracks all change requests submitted to the project — their description, status (submitted, approved, rejected, deferred), impact assessment and approval authority. Distinct from the issue log.
PMBOK 6 equivalent
Issue Log
Records all active issues (problems that have materialised, not risks that might) — description, priority, owner, target resolution date and status. Issues are not the same as risks; they are confirmed problems requiring action.
Core artifact — unchanged
Lessons Learned Register
Captures what went well, what went poorly and what should be done differently — maintained throughout the project, not just at closure. Feeds into the organisational process assets for future projects.
More emphasis in PMBOK 7
Risk Register
Documents all identified risks — description, probability, impact, risk score, owner, response strategy and status. One of the most important living documents in a project. Updated regularly throughout execution and monitoring.
Core artifact — unchanged
Stakeholder Register
Lists all project stakeholders with their role, contact details, power/interest level, current engagement level and desired engagement level. The primary input to communication requirements analysis and stakeholder engagement planning.
Core artifact — unchanged
Risk Report
A summary-level report of the overall project risk exposure — top risks, risk trends, residual risk level and response effectiveness. Distinct from the risk register (which is the detailed working document).
New as named artifact in PMBOK 7
📝
Category 3 — Plans
Documents describing how specific aspects of the project will be managed
12 plan artifacts
Project Management Plan
The master plan — integrates all subsidiary management plans and baselines. Describes how the project will be executed, monitored, controlled and closed. A formal, approved document that requires change control to update.
Core artifact — unchanged
Scope Management Plan
Describes how scope will be defined, validated and controlled. Includes how the WBS will be created, maintained and approved, and how scope change requests will be processed.
Subsidiary plan
Requirements Management Plan
Describes how requirements will be elicited, analysed, documented, traced and managed throughout the project. Defines the requirements traceability matrix approach.
Subsidiary plan
Schedule Management Plan
Defines the scheduling methodology, scheduling tool, level of accuracy for duration estimates, schedule update process and thresholds for schedule variance (SV) that trigger corrective action.
Subsidiary plan
Cost Management Plan
Describes how costs will be planned, structured, monitored and controlled. Includes cost estimating approach, budget aggregation method, EVM thresholds and funding requirements.
Subsidiary plan
Quality Management Plan
Defines quality standards applicable to the project, quality objectives, roles and responsibilities for quality, QA and QC activities, and quality metrics that will be used to assess deliverable quality.
Subsidiary plan
Resource Management Plan
Describes how physical and team resources will be acquired, developed, managed, controlled and released. Includes team roles and responsibilities, training needs and resource calendars.
Renamed from HR Management Plan
Communications Management Plan
Documents all planned project communications — who receives what information, how often, through which channel, who is responsible and how communication performance will be monitored. Built from the communication requirements analysis.
Subsidiary plan
Risk Management Plan
Defines how risk management will be conducted — risk categories, probability and impact scales, risk appetite, risk register format, risk review frequency and roles and responsibilities for risk management.
Subsidiary plan
Procurement Management Plan
Describes how procurement activities will be conducted — what will be procured, when, through which contract type, how vendors will be selected and how contracts will be managed and closed.
Subsidiary plan
Stakeholder Engagement Plan
Documents the strategies and actions required to engage each stakeholder group effectively. Maps current vs desired engagement levels and the communication/involvement approaches for each. Complements the communications plan.
More prominence in PMBOK 7
Change Management Plan
Defines how changes to the project baselines will be identified, assessed, approved or rejected and implemented. Describes the Change Control Board (CCB) composition, authority levels and change request process.
Subsidiary plan
📐
Category 4 — Baselines
Approved reference points against which project performance is measured
4 baseline artifacts
Scope Baseline
The approved version of the project scope — comprising the scope statement, WBS and WBS dictionary. Changes to scope require formal change control. The scope baseline is what you measure actual deliverables against.
Core artifact — unchanged
Schedule Baseline
The approved version of the project schedule — the planned start and finish dates for all tasks and milestones. Used to calculate Schedule Variance (SV) and Schedule Performance Index (SPI).
Core artifact — unchanged
Cost Baseline
The approved time-phased budget for the project — the Planned Value (PV) curve. Used to calculate Cost Variance (CV) and Cost Performance Index (CPI). Excludes management reserve (which is not baselined).
Core artifact — unchanged
Performance Measurement Baseline
The integrated scope, schedule and cost baseline — the PMB. This is the baseline used for Earned Value Management performance measurement. Approved changes update all three component baselines simultaneously.
EVM baseline
💡
The golden rule of baselines: A baseline can only be changed through the formal change control process. Adjusting the schedule baseline informally to hide slippage — sometimes called "rubber baselining" — destroys the integrity of all EVM measurements. If a change is approved, update the baseline formally and document it. If a change is not approved, the variance is real and must be reported. See the EVM Guide for how baselines are used in cost and schedule performance measurement.
📊
Category 5 — Visual Data and Information
Charts, diagrams and visual tools used to analyse and communicate project information
13 visual data artifacts
Affinity Diagram
Groups ideas, issues or requirements into natural clusters based on their relationships. Used in requirements gathering sessions and retrospectives to organise large amounts of input quickly.
Formalised in PMBOK 7
Burndown / Burnup Chart
Agile progress charts. Burndown shows remaining work declining over time. Burnup shows completed work increasing. Both visualise sprint or release progress against the planned trajectory.
Agile artifact — new in PMBOK 7
Cause-and-Effect Diagram
Also called a fishbone or Ishikawa diagram. Maps the potential causes of a problem or quality defect back to their root sources across categories (people, process, equipment, materials, environment, methods).
Quality tool — formalised
Control Chart
Tracks a quality metric over time against upper and lower control limits. Used to distinguish normal process variation (common cause) from unusual spikes (special cause) that require investigation.
Quality control tool
Cumulative Flow Diagram
Shows the flow of work items through workflow stages (e.g. To Do, In Progress, Done) over time. Used in Kanban and Agile to identify bottlenecks — a widening band in one stage indicates work is piling up there.
Agile artifact — new in PMBOK 7
Cycle Time Chart
Plots how long individual work items take to move from start to completion. Used in Agile and Kanban to identify outliers and improve flow predictability.
Agile artifact — new in PMBOK 7
Dashboards
Visual summaries of key project metrics — often showing schedule, cost, scope and risk status at a glance using RAG (Red/Amber/Green) status indicators. Used for executive-level reporting and steering committee presentations.
Formalised in PMBOK 7
Flow Chart
Visual representation of a process or workflow showing steps, decision points and the flow between them. Used for process analysis, root cause investigation and documenting procedures.
Process tool
Gantt Chart
Bar chart showing tasks plotted against a timeline with dependencies and resource assignments. The most widely used schedule visualisation in traditional project management. Shows planned vs actual progress.
Core scheduling tool
Histogram
Bar chart showing the frequency distribution of data — used in quality management to analyse defect distributions, resource utilisation patterns or risk probability distributions.
Quality analysis tool
Information Radiator
A highly visible, continuously updated display of project status information — physical (whiteboard, wall chart) or digital. Keeps the team and stakeholders informed without requiring meetings or formal reports.
Agile artifact — new in PMBOK 7
Scatter Diagram
Plots two variables against each other to investigate whether a relationship (correlation) exists. Used in quality management to test whether a suspected cause is correlated with a quality outcome.
Quality analysis tool
Story Map
A visual backlog organisation technique in Agile. User activities are arranged horizontally (the backbone) and stories are arranged vertically by priority. Helps plan minimum viable product (MVP) by identifying the minimum set of stories needed for each release.
Agile artifact — new in PMBOK 7
Throughput Chart
Tracks the number of work items completed per unit of time. Used in Agile and Kanban to measure delivery rate and forecast future delivery. Complements velocity in Scrum environments.
Agile artifact — new in PMBOK 7
📄
Category 6 — Reports
Formal communications summarising project status and performance for specific audiences
5 report artifacts
Quality Report
Summarises quality management issues, improvement recommendations, QC measurements and the status of quality activities. Identifies quality non-conformances and their resolution status.
Formalised in PMBOK 7
Risk Report
Provides an executive summary of the overall project risk exposure — top risks, risk trends, residual risks and effectiveness of risk responses. Distinct from the detailed risk register.
New as named artifact
Status Report
Regular periodic summary of project health — covering schedule performance (SPI), cost performance (CPI), scope status, top risks, issues, upcoming milestones and decisions needed. The primary communication tool for sponsors and steering committees.
Core artifact — unchanged
Variance Report
Compares actual performance against the baseline — schedule variance (SV), cost variance (CV) and scope changes. Quantifies how far the project has deviated from plan and identifies the drivers of variance.
EVM reporting artifact
Forecasting Report
Projects future performance based on current trends — Estimate at Completion (EAC), Estimate to Complete (ETC), Variance at Completion (VAC) and Schedule at Completion. Answers "where will we end up if current trends continue?"
New as named artifact
🤝
Category 7 — Agreements and Contracts
Formal agreements between the project and external parties
5 agreement artifact types
Fixed Price Contracts
FFP (Firm Fixed Price), FPIF (Fixed Price Incentive Fee) and FPEPA (Fixed Price with Economic Price Adjustment). Seller bears cost risk. Suitable when scope is well-defined and stable.
Procurement artifact
Cost Reimbursable Contracts
CPFF (Cost Plus Fixed Fee), CPIF (Cost Plus Incentive Fee), CPAF (Cost Plus Award Fee). Buyer bears cost risk. Suitable when scope is uncertain or evolving. Requires strong buyer oversight.
Procurement artifact
Time and Materials (T&M)
Hybrid contract — fixed unit rates for labour and materials, variable quantity. Risk is shared. Used for staff augmentation, consulting and work where the level of effort cannot be predicted upfront.
Procurement artifact
Indefinite Delivery Contracts
IDC, IDIQ (Indefinite Delivery, Indefinite Quantity). Framework agreements with pre-agreed rates, used when the volume of services or goods is not yet known. Common in government and large enterprise procurement.
Formalised in PMBOK 7
Other Agreements
MOUs (Memoranda of Understanding), SLAs (Service Level Agreements), letters of intent and teaming agreements. Used to formalise relationships that do not require a full contract but need documented mutual commitments.
New in PMBOK 7
🗂️
Category 8 — Other Artifacts
Important project documents that do not fit neatly into the other seven categories
8 other artifacts
Activity List
A comprehensive list of all scheduled activities required to complete project work packages. Each activity has a unique identifier, description, scope of work, predecessor and successor relationships.
Schedule artifact
Requirements Documentation
Records all stakeholder requirements — functional, non-functional, quality, regulatory, training and support. Forms the basis for scope definition and the scope baseline. Includes requirements traceability matrix.
Scope artifact
Work Breakdown Structure (WBS)
A hierarchical decomposition of the total project scope into work packages — the smallest unit of work that can be planned, estimated, monitored and controlled. The foundation of scope definition and cost estimation.
Core scope artifact
Team Charter
Documents the team's values, working agreements, ground rules, communication norms and decision-making approach. Particularly important in Agile teams and co-located or distributed teams starting a new project.
New in PMBOK 7
Responsibility Assignment Matrix (RACI)
Maps work packages or activities to team members using the RACI categories: Responsible (does the work), Accountable (owns the outcome), Consulted (provides input) and Informed (kept updated). Prevents accountability gaps.
Resource artifact
Resource Calendars
Documents when specific resources (people, equipment, facilities) are available for the project — accounting for holidays, other project commitments and part-time availability. Input to schedule development.
Resource artifact
Bid Documents
RFP (Request for Proposal), RFQ (Request for Quotation) and IFB (Invitation for Bid). Used in procurement to solicit responses from potential vendors. The procurement management plan defines which format is appropriate for each procurement.
Procurement artifact
Source Selection Criteria
Documents the criteria used to evaluate and select vendors — weighting technical capability, cost, experience, management approach and past performance. Ensures an objective, defensible vendor selection process.
Procurement artifact
03 — PMBOK 6 vs PMBOK 7
PMBOK 6 vs PMBOK 7 — Key Artifact Differences
The shift from PMBOK 6 to PMBOK 7 changed how artifacts are described and organised. Here are the most important differences for PMP exam candidates and practising project managers.
Aspect
PMBOK 6 Approach
PMBOK 7 Approach
Change
Organisation framework
Artifacts listed as ITTOs within 49 processes across 10 knowledge areas
Artifacts catalogued in 8 categories independent of processes
Evolved
Process prescription
Specifies when each artifact is created (which process produces it)
Does not prescribe when — tailoring to context is the PM's responsibility
Evolved
Agile artifacts
Minimal — PMBOK 6 focused on predictive delivery; Agile in separate Agile Practice Guide
Integrated — backlog, burndown, information radiator, story map, CFD all included
New
HR Management Plan
Human Resource Management Plan
Resource Management Plan (broader — covers physical resources too)
Renamed
Project Brief
Not a named artifact — project charter used for all sizes
New lightweight alternative to the project charter for smaller projects
New
Roadmap
Not a named artifact in PMBOK 6
Strategy artifact — high-level timeline for milestones and phases
New
Risk Report
Not a named artifact — risk reporting embedded in status reports
Named artifact in both Logs & Registers and Reports categories
New
Team Charter
Team ground rules mentioned but not a formal named artifact
Named artifact — particularly important for Agile and distributed teams
New
Lessons Learned Register
Primarily a project closure activity
Maintained throughout the project from initiation to closure
Evolved
Scope of artifacts
~100 outputs listed across processes, many overlapping
~50 clearly defined artifacts in 8 categories — less duplication, more clarity
Streamlined
04 — Tailoring
Tailoring — Which Artifacts Does Your Project Actually Need?
One of PMBOK 7's central principles is tailoring — the practice of selecting the methods and artifacts appropriate to the specific project context rather than applying every artifact to every project. Not every project needs every artifact listed above.
Tailoring decision — questions to ask for each artifact
Does this artifact add value on this project, given its size, complexity and risk level?
Is there an organisational standard that mandates this artifact regardless of project type?
Can a simpler artifact serve the same purpose? (e.g. project brief instead of full charter for a 6-week internal project)
Does the delivery approach affect which artifacts are appropriate? (Agile projects use backlogs and burndowns; predictive projects use Gantt charts and WBS)
What does governance require? Regulated industries, government contracts and large capital projects often mandate specific artifacts regardless of methodology.
📋
Minimum artifact set for a small project: Project charter (or brief), risk register, issue log, stakeholder register, project schedule (Gantt or backlog), status report, lessons learned register, change log. These seven give you the minimum viable governance for any project regardless of size or method.
Preparing for the PMP Exam?
Artifacts are tested across all three PMP exam domains. Our free study guide and practice questions cover the full PMBOK 7 framework including artifacts, principles and performance domains.
Project Management Artifacts on the PMP Exam — What to Know
Artifacts are not memorisation topics on the PMP exam — the exam tests your ability to identify the right artifact for a given situation. Here is what is actually tested.
What the Exam Tests
Which artifact is the right output for a given scenario — e.g. "the team needs to track outstanding problems that are affecting delivery" → issue log, not risk register
The difference between similar artifacts — risk register vs risk report, issue log vs change log, scope baseline vs WBS
When to use Agile artifacts vs predictive artifacts — backlog and burndown in Agile, Gantt and WBS in predictive, both in hybrid
The relationship between artifacts — the stakeholder register feeds communication requirements analysis which feeds the communications management plan
Tailoring decisions — when is a project brief appropriate instead of a full project charter? When is a T&M contract more appropriate than fixed price?
Most Frequently Tested Artifacts
Based on the PMP Examination Content Outline (ECO), the most commonly tested artifacts are: project charter, risk register, issue log, stakeholder register, lessons learned register, WBS, communications management plan, change log and the three baselines (scope, schedule, cost). Know these in depth — what they contain, when they are created, who owns them and how they relate to each other.
🎓
Study approach: Do not try to memorise all 49+ artifacts by category. Instead, learn the purpose of each major artifact and what situation calls for it. The exam will present scenarios and ask you to identify the appropriate action or artifact — which requires understanding, not memorisation. See the PMP Study Guide for the full 16-week study plan that integrates artifact knowledge with the ECO domains.
06 — FAQ
PMBOK 7 Artifacts — 7 Questions Answered
In PMBOK 7, a project management artifact is any template, document, output or project deliverable created and used during a project. PMBOK 7 organises artifacts into eight categories: strategy artifacts, logs and registers, plans, baselines, visual data and information, reports, agreements and contracts, and other artifacts. Unlike PMBOK 6, which tied artifacts to specific processes as inputs or outputs, PMBOK 7 catalogs artifacts independently — allowing practitioners to select which artifacts are appropriate for their specific project context through tailoring.
PMBOK 7 organises project management artifacts into eight categories: (1) Strategy artifacts — project charter, business case, roadmap and project brief; (2) Logs and registers — risk register, issue log, assumption log, change log, backlog, stakeholder register and lessons learned register; (3) Plans — the project management plan and all subsidiary plans; (4) Baselines — scope, schedule and cost baselines; (5) Visual data and information — Gantt charts, burndown charts, dashboards, control charts and other visual tools; (6) Reports — status reports, risk reports and variance reports; (7) Agreements and contracts — fixed price, T&M and cost reimbursable contracts; and (8) Other artifacts — WBS, RACI, activity list, requirements documentation and team charter.
The main difference is how artifacts are organised and described. PMBOK 6 listed artifacts as inputs, tools, techniques and outputs (ITTOs) within 49 specific processes. Every artifact had a defined process that produced it and other processes that consumed it. PMBOK 7 removes the process framework and catalogs artifacts independently in eight categories, leaving the decision of when and how to use each artifact to the practitioner. PMBOK 7 also adds many new artifacts from Agile practice — including backlog, burndown charts, information radiators, story maps and cumulative flow diagrams — that were not part of PMBOK 6.
The risk register is the detailed working document — it lists every identified risk with its description, probability, impact score, owner, response strategy and current status. It is a living document updated throughout the project. The risk report is a summary-level communication artifact — it presents the overall project risk exposure to stakeholders who need a high-level picture rather than the full register detail. It covers the top risks, risk trends, overall risk level and whether responses are working. The risk register is for the project team; the risk report is for sponsors, steering committees and governance bodies.
The issue log tracks problems that have already occurred and are affecting the project — confirmed problems requiring active management and resolution. Issues are real events, not hypothetical ones. The change log tracks change requests submitted to modify the project baselines (scope, schedule, cost or quality) — these may be approved, rejected or deferred through change control. A risk that materialises becomes an issue; an issue that requires a baseline change generates a change request. All three — risk register, issue log and change log — are separate artifacts that together form the core project health tracking system.
No — PMBOK 7 explicitly promotes tailoring, which means selecting only the artifacts that add value for your specific project. A small internal project might only need a project brief, risk register, issue log, basic schedule and status report. A large, complex, regulated project might need nearly all artifacts listed. The decision of which artifacts to use should be based on project size and complexity, delivery approach (predictive, Agile or hybrid), organisational standards and governance requirements, risk level, and stakeholder expectations. The minimum viable artifact set for any project is typically: project charter or brief, risk register, issue log, stakeholder register, schedule, status report and lessons learned register.
PMBOK 7 introduced several artifacts from Agile practice that were not part of PMBOK 6. These include: backlog (product backlog and sprint backlog), burndown and burnup charts (sprint and release progress tracking), cumulative flow diagram (workflow bottleneck visualisation), cycle time chart (flow efficiency measurement), information radiator (visible project status display), story map (visual backlog organisation for MVP planning), throughput chart (delivery rate measurement), and team charter (working agreements and values). These artifacts are particularly relevant in Scrum, Kanban and hybrid delivery environments.