Models, methods and artifacts

Principles tell you how to think, domains tell you what to pay attention to, and focus areas and processes tell you when work happens. But to actually do the work, project teams use specific tools: models that explain how things behave, methods that produce results, and artifacts that record information. The PMBOK Guide 7th edition grouped these into a dedicated section on models, methods and artifacts; the 8th edition describes tools and techniques alongside its processes, and PMI publishes further guidance online. This lesson gives a guided tour of the most useful items, so that when a later course or an exam question mentions one, you know what family it belongs to and what it is for.

Three kinds of tools

A model is a thinking strategy to explain a process, framework or phenomenon: for example, a model of how teams develop or how people move through change. A method is the means for achieving an outcome, output, result or deliverable: for example, a way of estimating, analysing data or running a meeting. An artifact is a template, document, output or project deliverable: for example, a risk register, a schedule or a status report. The distinction is useful because each serves a different purpose. Models help you understand and predict; methods help you do; artifacts help you record and communicate.

Commonly used models

Change models deserve special mention because the 2026 exam includes a Business Environment task on supporting organizational change. ADKAR, developed by Prosci, describes individual change as five outcomes: awareness of the need, desire to participate, knowledge of how to change, ability to implement and reinforcement to sustain it. Kotter's eight steps describe organizational change, from creating urgency to anchoring new approaches in the culture. Bridges distinguishes change, the external event, from transition, the internal psychological process of endings, a neutral zone and new beginnings.

Complexity models help with the choice of approach discussed in lesson 6. The Cynefin framework distinguishes clear situations (cause and effect obvious; apply best practice), complicated ones (analysis or expertise needed; apply good practice), complex ones (cause and effect visible only in hindsight; experiment, sense and respond), chaotic ones (act first to stabilize) and confusion. The Stacey matrix plots agreement about requirements against certainty about technology: high agreement and certainty suggest simple, predictable work; low agreement and certainty suggest complex or chaotic work suited to adaptive approaches.

Commonly used methods

Methods fall into broad groups. Data gathering and analysis methods include interviews, surveys, benchmarking, root cause analysis, alternatives analysis, cost-benefit analysis, earned value analysis, trend analysis and decision tree analysis. Estimating methods include analogous, parametric, bottom-up, three-point and relative estimating such as story points and planning poker. Meetings and events include kickoff meetings, planning meetings, daily stand-ups, reviews, retrospectives, steering committee meetings and lessons-learned sessions. Other methods include prioritization schemes such as MoSCoW (must have, should have, could have, won't have this time), impact mapping and timeboxing.

Commonly used artifacts

Artifacts differ between approaches. Predictive projects typically maintain detailed baselines and a formal change log. Adaptive projects rely on the product backlog, iteration backlogs, burndown or burnup charts and information radiators, visible displays of progress that anyone can read. Hybrid projects combine them, for example a milestone schedule for governance and a backlog for team work.

Selecting and tailoring tools

No project uses every model, method and artifact. Over-documentation wastes effort and can hide the important information under noise; under-documentation leaves teams and stakeholders without the information they need. Selection should consider the development approach, project size and risk, stakeholder needs, regulatory requirements and organizational standards. A useful test for any artifact is: who will use it, for what decision, and how often? If nobody can answer, the artifact is a candidate for removal or simplification.

Canadian public-sector projects may be required to produce specific artifacts, such as business cases, Project Complexity and Risk Assessment results, gating documents, privacy impact assessments under federal or provincial privacy law, and, for federal services, official languages and accessibility assessments.

Artificial intelligence as a tool

The PMBOK Guide 8th edition adds guidance on using artificial intelligence in project work, including use cases, responsible use and ethics. AI tools can draft documents, summarize meetings, analyse schedules and risks, and answer questions about project data. They also raise questions of accuracy, confidentiality, bias and accountability. A sound approach treats AI output as a draft or input that a responsible person reviews, follows organizational policy on data and tools, and is transparent with stakeholders about how AI is used. The accountable leader principle applies: using a tool does not shift responsibility away from the people who rely on it.

Information radiators and transparency

An information radiator is a highly visible display of project information, such as a task board, burnup chart or risk wall, placed where the team and stakeholders can see it at a glance. Physical boards were common in co-located teams; distributed teams use shared online boards and dashboards. The idea is transparency: anyone can see the state of the work without asking for a report, which reduces status meetings and surfaces problems early. Transparency also supports trust, because stakeholders see the same information the team sees.

Measures that matter

Many artifacts exist to measure something. Good measures are linked to decisions, few in number and hard to game. Measures can be leading, predicting future performance (such as the number of open high risks or the trend in defect discovery), or lagging, reporting what has already happened (such as cost variance or features delivered). A balanced set includes both. Vanity metrics, which look impressive but drive no decision, waste attention. Later courses cover earned value, flow metrics and other measures in detail.

Choose a small, balanced set of measures at the start, agree who will use each one and for what decision, and review the set periodically. Dropping a measure that no longer informs decisions is as important as adding a new one.

When you meet a new tool in later courses, place it in this framework: is it a model that explains, a method that produces, or an artifact that records? Then ask what decision or understanding it supports. That habit makes long lists of tools far easier to remember and apply.

Tools also differ in cost. A burndown chart generated automatically from the team's board costs almost nothing to maintain; a weekly narrative report written by hand may cost hours. When two artifacts serve the same need, prefer the cheaper one, and automate where possible. The time saved goes back into delivering value, which is the point of every tool in this lesson.

The same thinking applies to meetings, which are methods: each should have a purpose, the right attendees and a clear output.