Backlogs, Boards and Registers: Choosing the Right Artefact
Walk into most programme rooms and you will find more artefacts than anybody is maintaining: a board, two or three registers, a backlog in a tool, a plan on the wall, and a tracker somebody built in a spreadsheet because none of the others answered their question. The problem is rarely that a team has chosen the wrong one. It is that each was created to solve a real need, none was retired, and the same item now exists in four places at four different states of accuracy.
Section 4 of the PMBOK® Guide Eighth Edition covers the material projects produce and consume, and the practical way through it is to ask what question each artefact answers. Three shapes cover most of what a project needs.
Three questions, three artefacts
A backlog answers what should we do next. It is an ordered list of work not yet started, owned by one person who decides the order, and its value comes from being genuinely ordered, top to bottom, by somebody who has had to choose. A backlog with everything at the same priority is a list, and lists do not help anybody choose.
A board answers what is the state of the work right now. It shows items in progress, where they are stuck, and how much is open at once, and it is maintained continuously by the people doing the work. Its information is deliberately perishable: yesterday's board is of no interest, because the question it answers is about today.
A register answers what do we know, and what did we decide. Risks, assumptions, decisions, issues, lessons: each is a durable record with history, owner and dates, kept so that somebody in eight months can find out what was known and when. A register is consulted when a question arises, and it is the only one of the three that has to survive the project.
Two ways of mixing them
Asking a board to be a record. Boards are cleared, reset and rebuilt, which is exactly right for their purpose and fatal if they are also the only place a decision was captured. The classic loss is a decision taken at a stand-up, written on a card, delivered, and the card thrown away, so that six months later nobody can say why the approach changed in March. Anything that has to be answerable later needs a home that outlives the sprint.
Asking a register to drive work. Risk registers acquire columns called owner, action and due date, and then quietly become a second task list running in parallel with the real one. The actions go stale because nobody works from the register, the register loses credibility because its actions are stale, and the risk discipline goes with it. Actions arising from a risk belong in the backlog or on the board with everything else that competes for the team's time, with a reference back.
Eleven artefacts in one programme room
A bank's payments change programme had, when somebody counted, eleven maintained artefacts. A delivery board in the room, a backlog in the tool, a risk register, an issue log, a decision log, an assumption log, a dependency tracker, a RAID summary for the steering group, a milestone plan, a resource tracker, and a spreadsheet of open queries that one of the business analysts kept because nothing else told her which questions were unanswered.
None was unreasonable on its own. The effect was that the same dependency appeared on the board, in the dependency tracker and in the RAID summary, with three different dates, and the programme manager spent a day a week reconciling them. The decision log had not been touched in five weeks. Half the cards on the second board were from a workstream that had closed in the spring, and some of them had fallen off and were sitting on the ledge beneath it.
The consolidation took a morning and reduced eleven to four. The backlog stayed, in the tool, ordered. The board stayed, in the room, showing only work in progress. Risks, assumptions, decisions and issues went into one register with a type column, reviewed fortnightly, which removed three artefacts without losing anything. Dependencies moved into the backlog as items with owners, because that is what they were. The RAID summary was generated from the register for the steering pack rather than maintained separately, and the analyst's query spreadsheet became a column on the board, which is where it had always belonged.
What made it stick was a standing rule: every artefact has a named owner and a stated review interval, and anything without both gets removed at the next monthly check. Two more were removed in the following quarter under that rule, both of them things somebody had created for a single steering group and never closed.
Keeping the set small
Ask who reads it. An artefact with no regular reader is being maintained for an imagined audience, and it will drift within weeks. Where the only reader is the person maintaining it, that is worth knowing, because a private working document is fine and does not need to be a programme artefact.
Ask what decision it supports. Every record should be traceable to a decision somebody makes from it: what to work on, what to escalate, whether to release, what to tell an auditor. An artefact that supports no decision is a description of the project rather than a control on it.
Ask what happens if it is not updated for a month. If the answer is nothing, that is the honest test of its value. If the answer is that somebody will make a bad decision, it needs an owner and a cadence, and that is where the maintenance effort belongs.
For a PMP® candidate, what matters is that each artefact exists to answer one question, so a situation describing conflicting or stale project information is worth reading as an artefact problem rather than a discipline problem. A response that demands better updating has left the duplication in place. A structured PMP exam preparation course gives time to situations where the records are all present and none of them agree.
The exercise is worth an hour. List every artefact the project maintains, and against each write the owner, the review interval and the decision it supports. Anything with a gap in that line is either a candidate for removal or a piece of work nobody has been asked to do, and both are better known than assumed.
Interested in going further?
Most project information problems are structural: too many places holding the same thing, none of them owned. Omega's PMP® Exam Preparation works through tailoring the artefact set to what a project actually decides.
The artefacts a project produces and uses are described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
A170: Decision Log: The Forgotten Project Control
A169: Assumption Log vs Risk Register
A172: Lessons Learned Register: Use It Before the Project Ends
A174: Work Breakdown Structure: Still Useful in 2026?
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
