Quick Answer
A project management artifact is a template, document, output or deliverable that a project produces, such as a charter, risk register or burndown chart. PMBOK 7 grouped these artifacts into eight categories: strategy artifacts, logs and registers, plans, baselines, visual data and information, reports, agreements and contracts, and other artifacts. This replaced the PMBOK 6 habit of listing inputs, tools and outputs (ITTOs) for every process. The big change: the guide no longer tells you when to use each artifact. It tells you what each one is, and you decide which ones your project needs.
✦
From my experience: On my UAE construction projects we never used every artifact in the book. The ones we opened every week were the schedule, the risk register, the issue log, the change log and the RFI and drawing submittal registers that tracked consultant approvals. The lessons learned register mattered at every handover. When I teach this to my PMP students, I tell them the exam does not ask you to list artifacts. It asks which one fits the situation in front of you.
This page is a practical list of project artifacts: what each one is, which ones you really need on a live project, and which ones matter for the exam. If you work in Scrum and want the three Scrum artifacts (product backlog, sprint backlog and increment) explained properly, read my Scrum guide instead. This page covers the full range across predictive, agile and hybrid projects.
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
PMBOK 7 changed how project outputs are described. PMBOK 6 put everything into processes with inputs, tools and techniques, and outputs (ITTOs). That was very structured but hard to memorise. PMBOK 7 moved to a principle-based model where artifacts are listed on their own, not tied to a process.
This fits hybrid and agile work better, but you need a different kind of understanding. You do not need to memorise which output comes from which process. You do need to know what each artifact is, what it contains and when it is useful.
This page gives you a practical list of project artifacts grouped by category, a short definition of each, which ones you really need on a real project, and what the PMP exam tests.
Exam context: Artifact questions can appear in all three exam domains: People, Process and Business Environment. Knowing what each artifact is for matters more than memorising categories. For the wider exam picture, 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. That is a wide definition on purpose. It covers a one-page charter and a risk register with hundreds of lines, a formal contract and a simple lessons learned log.
The main difference from PMBOK 6 is that artifacts are not tied to specific processes. In PMBOK 6, the risk register was an output of Identify Risks, an input to Perform Qualitative Risk Analysis, and so on. In PMBOK 7, the risk register is just an artifact in the Logs and Registers category. When you create it and how you use it is your tailoring decision.
Important for PMP candidates: The 2026 PMP exam is built on the 2026 Exam Content Outline, with PMBOK 8 as the current guide and about 60% of questions on agile or hybrid approaches. The artifact list on this page comes from PMBOK 7, and the ITTOs come from PMBOK 6. Both are still useful for learning, because exam questions still ask you to choose the right artifact or document for a situation. Do not throw away your PMBOK 6 knowledge.
02 · The Eight Categories
All Eight PMBOK 7 Artifact Categories: Complete Reference
Here are the eight categories, with a short definition of every named artifact.
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 equivalentBusiness 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 7Project 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 7Project 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: unchangedProject 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 7Roadmap
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 7Category 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 7Backlog
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 7Change 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 equivalentIssue 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: unchangedLessons 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 7Risk 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: unchangedStakeholder 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: unchangedRisk 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 7Category 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: unchangedScope 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 planRequirements Management Plan
Describes how requirements will be elicited, analysed, documented, traced and managed throughout the project. Defines the requirements traceability matrix approach.
Subsidiary planSchedule 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 planCost 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 planQuality 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 planResource 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 PlanCommunications 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 planRisk 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 planProcurement 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 planStakeholder 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 7Change 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 planCategory 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: unchangedSchedule 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: unchangedCost 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: unchangedPerformance 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 baselineThe golden rule of baselines: you only change a baseline through formal change control. Quietly moving the schedule baseline to hide slippage ("rubber baselining") makes every EVM number meaningless. If a change is approved, update the baseline formally and record it. If not, the variance is real and you report it. See the EVM Guide for how baselines are used to measure cost and schedule performance.
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 7Burndown / 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 7Cause-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: formalisedControl 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 toolCumulative 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 7Cycle 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 7Dashboards
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 7Flow 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 toolGantt 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 toolHistogram
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 toolInformation 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 7Scatter 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 toolStory 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 7Throughput 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 7Category 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 7Risk 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 artifactStatus 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: unchangedVariance 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 artifactForecasting 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 artifactCategory 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 artifactCost 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 artifactTime 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 artifactIndefinite 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 7Other 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 7Category 8: Other Artifacts
Important project documents that do not fit neatly into the other seven categories
8 other artifacts
Activity List
A full 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 artifactRequirements 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 artifactWork 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 artifactTeam 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 7Responsibility 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 artifactResource 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 artifactBid 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 artifactSource 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 artifact03 · PMBOK 6 vs PMBOK 7
PMBOK 6 vs PMBOK 7: Key Artifact Differences
PMBOK 7 changed how artifacts are described and organised. These are the differences that matter most for the exam and for real projects.
| 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 | Simpler |
04 · Tailoring
Tailoring: Which Artifacts Does Your Project Actually Need?
Tailoring is a core idea in PMBOK 7: pick the methods and artifacts that suit your project, instead of using everything on every project. No 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 and change log. These eight give you basic control on any project, whatever its size or method.
Real project vs exam: which artifacts matter where
Here is the honest split I give my PMP students who also run projects.
- You will use these every week on a real project: schedule, risk register, issue log, change log, status report and a simple stakeholder list. On construction jobs, add the RFI log and the drawing and material submittal registers.
- You will use these at key moments: project charter at the start, baselines when the plan is approved, lessons learned at each phase end and handover, and the contract when something goes wrong.
- Mostly for the exam (or for large, formal projects): separate subsidiary plans for every area, the RACI for every work package, cumulative flow diagrams and cycle time charts if you do not run Kanban.
Mistakes I see: students mix up the risk register and issue log, call the WBS the scope baseline (it is only one part), and pick a Gantt chart for an agile team when a burndown or information radiator fits better.
Preparing for the PMP Exam?
Artifact questions can come up in all three PMP exam domains. Our free study guide and practice questions help you practise choosing the right one.
05 · PMP Exam
Project Management Artifacts on the PMP Exam: What to Know
The PMP exam does not ask you to recite artifacts. It asks you to pick the right artifact for a situation. Here is what to expect.
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
In my experience coaching PMP students, the artifacts that come up most in practice questions are the 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 well: what they contain, when they are created, who owns them and how they link.
Study approach: Do not try to memorise every artifact by category. Learn the purpose of each main artifact and the situation that calls for it. The exam gives you a scenario and asks for the right action or artifact, which needs understanding, not memory. See the PMP Study Guide for a study plan that links artifacts to the exam domains.
06 · FAQ
PMBOK 7 Artifacts: 7 Questions Answered
A project management artifact is any template, document, output or deliverable created and used during a project. PMBOK 7 grouped them into eight categories: strategy artifacts, logs and registers, plans, baselines, visual data and information, reports, agreements and contracts, and other artifacts. PMBOK 6 tied each artifact to processes as inputs or outputs. PMBOK 7 lists them on their own, so you choose which ones fit your project 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.
PMBOK 6 listed artifacts as inputs, tools, techniques and outputs (ITTOs) inside 49 processes. Each artifact had a process that produced it and others that used it. PMBOK 7 dropped the process structure and listed artifacts in eight categories, leaving it to you to decide when and how to use each one. It also added artifacts from agile practice, such as the backlog, burndown charts, information radiators, story maps and cumulative flow diagrams.
The risk register is the detailed working document. It lists every risk with its description, probability, impact, owner, response and status, and the team updates it throughout the project. The risk report is a summary for people who need the big picture: top risks, trends, overall risk level and whether responses are working. The register is for the team. The report is for sponsors and steering groups.
The issue log tracks problems that have already happened and need action. The change log tracks change requests to the baselines (scope, schedule, cost or quality) and whether they were approved, rejected or deferred. A risk that happens becomes an issue. An issue that needs a baseline change creates a change request. The risk register, issue log and change log are separate, but together they show the health of the project.
No. Tailoring means you use only the artifacts that add value. A small internal project may only need a project brief, risk register, issue log, simple schedule and status report. A large, regulated project may need almost all of them. Base the choice on size and complexity, delivery approach (predictive, agile or hybrid), company standards, governance rules, risk level and what stakeholders expect. A sensible minimum for most projects is a 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.