Project Artifacts and How to Use Them

In this article we’ll look at the types of artifacts in project management, typical documents for each type.

There’s also a checklist of project artifacts by phase at the end, which you can use as an aide-memoire for creating your own documentation.

What is an artifact in project management?

An artifact is something you create. In project management, artifacts relate to documents, templates, outputs or a specific deliverable.

The PMBOK® Guide defines an artifact like this:

A document or other item created during a portfolio, program, or project to help manage it and provide information to the project team, stakeholders, and management.

However, when you read through the book it also talks about products being artifacts, so it’s not just things created to manage the project that count. This is a big change from the previous edition, which specifically called out that artifacts relate to the work of managing the project, not the thing you are creating as the output of the project.

That’s now changed, and in the glossary of the Eighth Edition, the definition of Product refers to it as an artifact.

Mostly, the term refers to the project documentation you produce that defines and supports the work you are doing.

Artifacts in the PMBOK Guide – Eighth Edition

Artifacts were categorized in the PMBOK® Guide – Seventh edition into 9 different types but the Eighth Edition has removed that distinction. It talks about artifacts more generally, scattered throughout, and does not try to categorize them.

But what if you don’t use PMI methods?

Documents are documents. Whether you subscribe to the PMI way of thinking or use another approach based on your background, skills, experience, certification or the expectations of management, I’m pretty sure that you’ll have to create project documents.

Although this list draws on PMI materials, it’s still going to be useful to you even if you use a different approach. And yes, agile project management artifacts get a mention.

What if you manage a program or PMO?

Good news! Program management artifacts are broadly the same as the ones you use on a project.

When I’ve managed a program, the artifacts I’ve created have fitted into the categories below: risk logs, plans, a vision for the program and benefits baseline and so on.

PMO artifacts will also fit into the categories below. For example, you’ll still need a strategy, you’ll have a register of all open and pipeline projects, you’ll have a plan and baselines, plus reports.

The actual documents created will be different because they’ll reflect the level of work you are doing and the overview you need from a PMO or program perspective, but the list of artifacts below will give you a good starting point for working out what you need.

Different types of artifacts

As I mentioned, in the old edition of the PMBOK Guide, there were 9 types of artifacts, and every project management document or thing you created fell into one of these categories (not least because the last one is a giant bucket for everything else, as you’ll see).

The current project management guidance is not specific about categorizing artifacts, but I still think it’s helpful to have the list in mind.

Here’s the list:

1. Strategy
2. Logs and registers
3. Plans
4. Hierarchy charts
5. Baselines
6. Visual data and information
7. Reports
8. Agreements and contracts
9. Other – a bucket category for anything else.

Let’s look at each of those in more detail. You’ll see that for each category, some of the really obvious stuff is not called out because it’s generic or obviously required for management purposes.

Industry-specific artifacts are not mentioned either, so if you work in a highly regulated field then some of the standard documents you’d expect to produce might be missing.

Also, if the artifact is the result of some other project management method or tactic, it won’t be mentioned here. For example, an estimate is the obvious output of the estimating process, so estimates aren’t mentioned again as a separate project artifact.

OK, let’s get to it: here’s the list of project management artifacts.

1. Strategy artifacts

This refers to documentation that relates to strategy and project initiation. For example:

• Business case
• Project vision statement
• Project charter
• Roadmap.

These documents are developed at the start of project and don’t normally change. Having said that, I’ve worked on projects where they have changed, because a lot depends on how the project evolves, and you know something is always going to be different.

Still, in principle, this category relates to the high level strategy stuff on the project and isn’t something you’d need to update often once it’s done.

Note: you’ll use these artifacts for project management across all the three performance domains.

2. Logs and registers

This category relates to the various project management logs and registers we have as part of the daily management of the process. You can grab the set I use here.

Some examples of the project delivery artifacts that fall into this category that I use to manage my own projects at work include:

• Assumption log
• Actions log
• Decision log
• Risk register
• Issue log
• Change log
• Backlog (see, agile project artifacts are relevant too)
• Stakeholder register

These documents represent a set of continuously evolving documents. They will be updated throughout the project.

Is it a log or a register?

Who cares? As long as you know what you are talking about, you can use either, or both interchangeably.

3. Plans

The third category of project artifact relates to the different types of plans produced. That includes:

• Comms management plan
• Release plan
• Requirements management plan
• Scope management plan
• Iteration plan
• Test plan
• Quality plan
• Logistics plan.

They are developed to help you work out how to run the project and can either be all in one document or separate documents.

Typically, they are written out documents i.e. a bunch of words, but you could have visual plans if it makes sense to use diagrams to show the flow of work. I can see that being particularly relevant for things like a release plan.

4. Hierarchy charts

Next up, we have hierarchy charts. These describe the relationships between various parts of the project.

• Work breakdown structure
• Product breakdown structure
• Organizational breakdown structure
• Risk breakdown structure
• Resource breakdown structure
• Cost breakdown structure.

You might not need all of these and you might have various versions of each of them.

Basically, they show high level info that is decomposed into detailed sections. The upper levels encompass all the information covered by the lower levels.

Typically, these are progressively elaborated as you go through the project, so you can come back to them and edit/update as required.

Also, I’d add to this category that one of the most useful charts I have for my projects is the team org chart to show who is doing what and how they fit together.

5. Baselines

We create baselines throughout the project. They represent approved versions of whatever plan they relate to. Here are some examples:

• Budget baseline
• Milestone schedule
• Scope baseline
• Performance measurement baseline.

Baselines will be created and updated as the project progresses and as major changes happen, so they need a time and date stamp.

6. Visual data and information

This is a catch-all category for anything that’s not a written document in the traditional sense. Here’s a non-exhaustive list of the types of visual data you might have on your projects:

• Cycle time chart
• Dashboard
• Flow chart
• Gantt chart
• Requirements traceability matrix
• Velocity chart
• S-curve
• And the simple whiteboard would fit in here too.

The point of having visual data sources is that they make it easier to understand the information. (Especially for people with short attention spans!)

You’ll typically create them after you complete some kind of data analysis to help you absorb the information – and the best case scenario is that you’ve got the tools to update them automatically instead of every dashboard being a beautiful, but manual creation.

7. Communication

This category was called ‘Reports’ in the Seventh Edition, but I’ve changed it because it really is a lot broader than that.

There are a few project communication artifacts mentioned in the Eighth Edition. For example, emails, broadcast messages, presentations, newsletters and social media.

Project management seems to involve a lot of reports, and even with improvements in artificial intelligence in project management, it’s still likely that the bulk of reports are going to need some kind of manual intervention.

Here are some of the typical reports produced on a project:

• Quality report
• Risk report
• Status report
• Formal records for particular stakeholders eg a highlight report for a sponsor or monthly reporting for the PMO.

8. Agreements and contracts

You might not have agreements and contracts on your project because it obviously depends on if you are buying anything. Having said that, you could have internal agreements with other departments: if we had staff on secondment I’d be expected to write formally to the manager releasing their staff member and create a specific agreement for that.

Here are some examples of artifacts that fall into this category:

• MOU (Memorandum of Understanding)
• Fixed price contract
• Cost reimbursable contract
• Time and materials contract
• Indefinite delivery indefinite quantity contract
• Any other type of legally-binding agreement.

9. Other

Here’s a bunch of artifacts that don’t easily fit into any other category:

• Project requirements and associated documentation
• Team charter (some of the team management models in project management may suggest creating something like this e.g. you could use it during the Tuckman ladder)
• User stories
• Bid documents.

And I’m sure there are others you may have come across in the past that are useful documents for your own projects.

The principles of managing projects are the same, regardless of what artifacts you think are most relevant to your approach. They are documented in the Standard for Project Management.

Project management artifacts by phase

As you’re probably realizing by now, as the docs are created and updated throughout the life cycle, the idea of project management artifacts by phase isn’t really very accurate. You create them when they are needed and refer to and update them as necessary. It’s not like you write them in one phase and forget about them.

However, I know that it’s still helpful sometimes to have a reference checklist, so here is my own version of what phase relates to which artifact, and because my background is in predictive projects, that’s what this relates to.

Project phase	Typical artifacts
Initiation	Business case Project vision statement Project charter Roadmap Team charter
Planning	Assumption log Risk register Issue register Change log Stakeholder register Comms management plan Release plan Scope management plan Test plan Quality plan Logistics plan Work breakdown structure Product breakdown structure Organizational breakdown structure Risk breakdown structure Budget baseline Milestone schedule baseline Scope baseline Performance measurement baseline Gantt chart Requirements and requirements traceability matrix
Execution	Dashboard Flow charts or process maps as needed MOU, contracts and agreements (but could be earlier in the life cycle depending on the type of vendor)
Monitoring and Control	Quality report Risk report Status report Ad hoc stakeholder reports
Closure	Project closure document Handover documents

Can I use AI to create project artifacts?

Yes!

LLMs, tools like Copilot and ChatGPT or other proprietary tools that you are have (authorized) access to as part of your work stack, are great at creating documents.

Use generative AI to create templates, a list of headings and the outline structure for a document. You can then fill it in with the details and company-specific information.

I would always be careful about what corporate and sensitive information you feed into an AI tool because you don’t know where your secrets will end up! Make sure you understand the terms and conditions of the tools you are using — but once you’ve crossed that hurdle, AI can massively speed up the time it takes to create project documents.

FAQ