Item Tracking

Goal

BABOK states the goal of the technique: capture the problems and the stakeholder concerns that bear on the solution and assign responsibility for them. A concern voiced in a workshop and not written down comes back later, at requirements sign-off, at user acceptance testing or in production, and it comes back more expensive. Recording without assigning produces a list nobody moves forward; assigning without recording produces a commitment nobody can trace six weeks later.

The technique is the generic container for everything a stakeholder raises. BABOK names seven item types: the action to be taken, the assumption made in the absence of information and still to be confirmed, the constraint imposed from outside, the dependency on a third party, the defect observed, the enhancement requested and the issue that blocks. That generality is deliberate: it gives one place where every concern lands, whatever its nature, and the triage then decides which process the item enters.

The deliverable is an item register that is filled in, shared and kept current: a table whose every row carries a concern, the person who raised it, an assessed impact, a priority, an owner, a resolver, an agreed strategy, a status and a resolution due date. BABOK adds that the register may be shared with the stakeholders: they see the state and the progress of the items, and they rank what remains open by importance.

The register settles one question: who answers for an open concern and by when. The analyst shows it to the stakeholder who comes asking what was done with what they said. BABOK states this strength first: stakeholder concerns about requirements are captured, tracked and resolved to their satisfaction. The technique produces a table. Its effect is a stakeholder who stops repeating a concern at every session because they see it written down, with a due date and a name against it.

Usage

When to use it

• Elicitation workshop or interview: record every concern on the spot, in the words of the person raising it.
• Requirements awaiting sign-off: a named blocking point, with an owner and a due date, makes the sign-off possible.
• Many stakeholders with diverging interests: make visible what is still open and who has to decide.
• Assumption made for lack of information: record it as an item to confirm, with the date by which it must be.
• Dependency on a third party outside the team's remit: track it with a due date and an agreed escalation route.
• Distributed team or asynchronous work: the shared register replaces the memory of the room, which no chat thread holds.
• Long engagement with turnover of people: the register is the memory that outlives the departure of whoever knew.
• Trust with the business has degraded: a shared register restores visibility faster than a status report.
• Audited or regulated context: the trace of who raised what, who decided and when becomes a requirement.

When not to use it

• Concern about a future and uncertain event: treat it as a risk (§10.38).
• Work that waits because capacity is short: put it in the backlog (§10.2), which orders by value.

Description

What an item record carries

BABOK lists fifteen attributes and introduces them with a formula: each recorded item may carry any or all of them. A fifteen-column register is a compliance exercise for most initiatives, and six columns kept current are worth more than fifteen abandoned after a month. The choice of columns is made once, when the register's rules are set, against what the initiative will maintain.

The identification attributes say what the item is and where it came from. The identifier distinguishes one item from all others and is the reference in minutes. The summary describes the item in one sentence, close enough to the words of the person who raised it that they recognise it. The category groups items with similar properties. The type is one of those BABOK names, and it drives the process the item enters. The date identified and the identified by field tie the item to a moment and to a person. The age of the item is computed from that date.

The qualification attributes say what the item costs while it stays open. The impact states the possible consequences if the item is not resolved by its due date, and BABOK gives it four axes: time, cost, scope, quality. An impact is expressed on one of those axes, with a magnitude. The priority is the importance of the item to the affected stakeholders. Setting it therefore belongs to them: the analyst who keeps the register transcribes it, and the resolver, for whom the item is a chore, works in the order it sets. The resolution due date is the date by which the item must be resolved or closed.

The accountability and resolution attributes say who does what. The owner is the stakeholder charged with carrying the item to closure; the resolver is the one charged with resolving it. BABOK makes these two distinct attributes, and this is the first distinction practice flattens. The owner chases, arbitrates, escalates; the resolver executes. Conflating them produces items owned by the person with the least authority to move them. The agreed strategy states what has been decided, in the vocabulary BABOK gives as examples: accept, pursue, ignore, mitigate, avoid. BABOK leaves the list open. A register sorts and counts better on a closed vocabulary, and these five values are enough to close it. Ignoring is a legitimate decision, taken and recorded, and it differs from an item that silently stops moving. The status places the item in its lifecycle. The resolution log records how the resolution is progressing and the approval of its completion. The escalation matrix, finally, defines the level that applies if the item is not resolved by the due date: it is a field of the record.

The lifecycle of an item

BABOK gives the statuses as examples: open, assigned, resolved, cancelled. The wording is illustrative and the organisation defines its own; BABOK instead states one firm rule in its item-management element: every item is tracked through to its resolution or its closure. A seven-state model follows from that. To BABOK's four statuses it adds in progress, between assignment and resolution, because work under way is a situation in which the item remains. It separates closed from resolved, because closure is an act of approval distinct from producing a solution. It separates, lastly, rejected from cancelled, where BABOK knows only cancelled: rejection is a readable state, distinct from the cancellation of an item that expires, is withdrawn or is merged into another. Four of these seven states are steps in the handling; three end the life of the item: rejected, cancelled and closed.

A raised concern passes an admissibility review first, and BABOK places that review at the moment the concern is voiced. The register keeps the rejected item: it is recorded as rejected and it is not deleted, because the person who raised it must be able to see what became of it. An admissible item becomes open, then assigned as soon as it has an owner and a resolver, in progress when work starts, resolved when a resolution is proposed and closed when the person who raised the concern or the affected stakeholder approves that completion. The cancelled state is terminal and remains reachable from open, assigned and in progress.

Escalation as a guarded transition

Escalation fires when the resolution due date passes and the item is not resolved. It routes the item to the next level of the escalation matrix and brings it back in progress, with a new decider, a new due date, a new resolver or a decision to cancel. The escalated item therefore keeps moving.

The standard vocabulary for this construction is that of UML state machines (OMG, UML 2.5.1, clause 14): a state is a situation during which an invariant condition holds, a transition moves the execution from one state to another, a trigger initiates it, a guard is a boolean condition that must hold for the transition to be taken and an effect is what runs on the way through. Escalation reads like this: trigger, the due date passing; guard, [due date passed AND status not resolved]; effect, the change of decision level. Modelling escalation as a status, by adding an "escalated" state where the item would sit, is the intuitive mistake: an escalated item is still being worked, and the register then loses the distinction between what an item is and what has just happened to it.

The analyst agrees the escalation matrix with the sponsor before the register opens. For each level the matrix names a measurable trigger, the body that decides and the mandate that body holds. The channel is part of the rule: a critical item is raised in person or by phone, an item at the routine level goes through the periodic review. A trigger counted in working days presupposes a calendar: in Switzerland that calendar is cantonal, and the Monday after the Federal Day of Thanksgiving is not a working day in the canton of Vaud.

HERMES, the Swiss Confederation's project management method, puts this transition in a single task. Deal with problems and benefit from lessons learned (5.4.3.29) holds that the person responsible who cannot solve a problem, or cannot solve it in time, escalates it immediately to those responsible in the project organisation. The escalation process is set project by project in the project management plan. The knowledge drawn from the resolution feeds the outcome Lessons learned (4.4.1.32), collected throughout the project. Where BABOK separates item tracking from lessons learned (§10.27), HERMES makes them the two halves of one task.

Running the technique from capture to closure

1. Set the rules before opening the register
   Which item types are in use, who may raise one, which statuses exist, at what cadence the review happens, what the escalation matrix is and where the register lives. This step gets skipped, and most registers die after a month. It is documented in the business analysis approach or in the governance plan.
2. Capture on the spot
   Record the concern in the workshop, the interview or the review: identifier, summary, date identified, identified by.
3. Assess admissibility
   Reject what is out of scope, merge what is already recorded and record the rejection.
4. Classify
   Category and type. A defect goes to the delivery team's fix flow, an assumption goes to a confirmation activity, a dependency goes to whoever holds the other end.
5. Assess the impact and set the priority
   The impact on BABOK's four axes, time, cost, scope, quality, with a magnitude. The priority with the affected stakeholders, using the ranking scheme the initiative already applies: prioritisation (§10.33) kicks in at this step. Set the resolution due date.
6. Name an owner and a resolver
   Two named people and an owner whose standing lets them chase the resolver.
7. Agree the strategy
   Accept, pursue, ignore, mitigate, avoid. The strategy is decided with the affected stakeholder, then recorded.
8. Track and review at a fixed cadence
   The resolution log records progress as it happens. The review walks the register item by item, with the stakeholders, at an agreed interval, and the register stays shared between two reviews. BABOK warns that one item may generate another and that resolution efforts must then not be duplicated: the review is where that coordination happens.
9. Escalate what stalls
   The escalation matrix fires when the due date passes. The route is defined in advance, and it leads to a body that can decide.
10. Close on approval
    BABOK places the approval of completion inside the resolution log: closure is approved, normally by the person who raised the concern or by the affected stakeholder.

The register's metrics

The register produces metrics, and BABOK makes them an element of the technique: they say whether items are resolved by the right resources, whether the initiative is progressing and whether the tracking process is used. Four or five are enough. Each is read against a threshold, and a threshold crossed fires a named action: a metric that fires nothing is a number in a report. Every review sorts by age first, and age is computed from the date identified. A sheaf of weekly indicators costs more than the items it describes.

Placing the technique among its neighbours

Item tracking is the generic technique, and two BABOK techniques each specialise it for one kind of item. Risk analysis and management (§10.38) specialises it for items that are future and uncertain events. It keeps the register and adds a probability, a risk level that combines that probability with the impact and a treatment vocabulary of its own.

The two vocabularies share a core: accept, mitigate, avoid. They diverge where the kind of item forces it. Risk treatment adds transfer and increase, which only make sense for an event that has not yet happened: an exposure is transferred to an insurer, an exposure is increased to seize an opportunity. The agreed strategy of item tracking adds pursue and ignore, which only make sense for a concern already on the table. The handover between the two registers follows the same logic: a risk that materialises stops being a risk and becomes a problem to manage, which is to say an item. The UK government's Teal Book states the same switch: an identified risk either remains a residual risk, or it occurs and becomes an issue.

Backlog management (§10.2) specialises the technique for work that waits because capacity is short. BABOK defines it: a backlog appears when the volume of work to be done exceeds the capacity to do it. It therefore adds an ordering by value and a pull mechanism, where the top of the backlog is what will be done next. An item register prioritises to decide what will be resolved first, where a backlog, equipped with a capacity model and a pull mechanism, prioritises to decide what will be built next. An item that turns out to be a piece of product goes to the backlog.

Prioritisation (§10.33) supplies the ranking scheme that the register's priority field uses. Item tracking feeds, in return, the lessons learned (§10.27) at the close of the initiative, with the items that recurred and those that had to be escalated.

One tooling confusion still needs clearing: the delivery team's defect tracking. The defect is one of BABOK's seven item types, so a defect can be an item, but the team's tool is structured by version, test environment and test case, and developers read it. The business analyst's register is structured by the solution and by the requirements, and stakeholders read it; pushing the business analyst's items through the schema of a defect tool forces every concern into the shape of a bug.

The second confusion concerns the project issue log, kept by the project manager. The Association for Project Management glossary defines an issue by the breach of a delegated tolerance, which calls for the sponsor's support. That notion is narrower than BABOK's item, and it centres the project log on delivery, its schedule, its budget and its scope. The business analyst's register centres on stakeholder concerns about the requirements and the solution, and its success criterion is that the person who raised the concern sees it move. Where a project issue log already exists, open an item type or a view inside it and keep the business analyst's attributes there, starting with identification, owner, resolver and agreed strategy.

On projects run under HERMES, a neighbour comes from the method: the Change status list (outcome 4.4.1.3, Änderungsstatusliste), produced by the task Manage changes (5.4.3.2). The method gives the change-type item its own document, minimally required in the HERMES sense, in the traditional approach as in the agile one. In the traditional approach each row carries the change request number, the requester, the date of request, the person responsible for the decision, the status, the change date, the person responsible for the change, the effort, the cost and the consequences; in the agile approach the list documents at a minimum the identification of the request, its date, its status and the change date. The business analyst's item register therefore refers to that list for any change request.

HERMES likewise keeps decisions in two outcomes, one per hierarchy level: the List of management project decisions (4.4.1.20) and the List of steering project decisions (4.4.1.21). Each documents the outcomes of the decision-making tasks of its level for the whole duration of the project, with the decision, the milestone achieved or not, the underlying documents, the decision-makers and the date. The project sponsor decides at the steering level, the project manager at the management level (§5.1.2.2 and §5.1.2.3).

What makes the register fail

The register nobody owns

The items have an owner, the register has none. Nobody runs the review, nobody chases the ageing rows and nobody reads the file after six weeks. The register needs a keeper, distinct from the item owners.

The item with no owner or "the team" as owner

An item belonging to everyone belongs to nobody. BABOK's owner is a stakeholder, singular, and they have a name.

The item "open" for a year

The missing escalation matrix is the defect: a due date with no consequence attached to missing it is a wish. The age of the item exposes it.

The shadow register

A business analyst's item register kept in parallel with the delivery team's tracking tool or with the project log. Two registers make two truths, and stakeholders read the one the developers do not feed.

Tracking that stands in for deciding

The item reread, rediscussed and reprioritised at every review, never settled. This is the technique's failure mode, and its mechanism is that the register makes indecision look like progress: the resolution log fills up, the review feels productive, the row looks active. The status has not moved a notch. An ageing item with a rich resolution log is therefore the register's worst case. The detector is already there, in the metrics: age, crossed with a status unchanged over three reviews. That crossing calls for a decision, including the decision to ignore, recorded as the agreed strategy.

Recording too much

BABOK states the limitation: extensive data collection on items can outweigh the benefits, and stakeholders can get bogged down in the details and the statistics. The "any or all" formula on the fifteen attributes allows six to be kept.

No admissibility triage

Everything said becomes an item, the register swells and priority stops meaning anything since everything is in it.

Impact written in adjectives

"High", with no scale behind it. An impact is written on an axis, with a magnitude.

Silent closure

Closing an item the person who raised it still cares about or erasing a rejected item destroys the trust the register was opened to build. Closure is approved, rejection is recorded.

Escalation modelled as a status

An "escalated" state where the item would sit mixes up the item's situation with the event that has just happened to it. Escalation is a guarded transition: the escalated item stays in progress, and the level that decides about it changes.

AI considerations

Item tracking is a technique half of which is clerical. Artificial intelligence attacks that half: AI makes recording cheap, and cheap recording is what BABOK warns against. A register that has grown to four hundred items because capture became free is a register nobody reviews. The only question worth asking about an item is therefore: will anyone act.

Capture from the session: a language model applied to a workshop transcript proposes, for every concern voiced, a summary, the date, the author and a type. The post-workshop write-up is the technique's most expensive line item: a summarisation task, which these models do well. The business analyst corrects, and whoever raised the item confirms the wording at the next review. Classification into BABOK's seven types: a short, stable label set applied to a short text, where an error is cheap because the review corrects the label. Duplicate and link detection: semantic similarity finds, in a two-hundred-row register, the item already recorded in other words, and a person confirms the match before two items become one. Stall detection: flagging items whose status has not moved for a given number of days, whose due date has passed or whose resolution log repeats the previous entry in different words. This is the mechanical half of the escalation matrix. Drafting the impact statement on the four axes starts from the item and the initiative's plan; the owner approves the proposal before it enters the register.

Naming the owner is an act of accountability: a model can propose a name from the stakeholder map, it cannot make anyone accountable. An owner assigned by a tool is an owner who has accepted nothing. Setting the priority belongs to the affected stakeholders, and it is a negotiation between diverging interests: a model that ranks the register by inferred severity has substituted its judgement for theirs and produced the ranking nobody approved. Agreeing the strategy and closing the item are decisions with political reach, and closure is pronounced only once completion has been approved. An item closed automatically because a model judged it resolved is a silent closure, pronounced at the scale of the whole register.

Data sensitivity is the sticking point the item register brings with it. Item summaries name people, record who complained about whom and carry the initiative's conflicts in plain text. Pouring a register into a public model amounts to exporting the organisation's internal politics and personal data with it. In Switzerland the revised Federal Act on Data Protection (revFADP), in force since 1 September 2023, applies: an item register carrying names is a processing of personal data. The practical consequence: use a model the organisation controls, or strip the names before the prompt.

Examples

An occupational pension institution (LPP) based in Lausanne (postcode 1003), insuring the employees of some 120 affiliated employers, is replacing its employer portal. The register carries the items raised during the first two elicitation workshops, held on 6 and 9 July 2026 with affiliation management, operations, an employer user group and the finance department. It is shown as it reads on 30.09.2026: on that date the statuses, the due dates and the escalation check against one another.

The register holds twelve of BABOK's fifteen attributes. Category and resolution log live behind each row, in the tool, and escalation lives in its own matrix.

ITM-003 has been escalated to level 3. At the 30.09.2026 snapshot the item is in progress: the body that decides about it has changed, from the project manager to the steering committee. No "escalated" state appears in the status column.

Visualisations

The register, the escalation matrix and the metrics are objects made of rows and columns, read, sorted and filtered by stakeholders: twelve attributes for six items, four escalation levels, five metrics and their thresholds. They render as tables.

The item lifecycle is a spatial object: seven states, directed transitions, three terminal states, a guard set on an edge and a branch that leaves the "in progress" state and returns to it. It is a state machine. A "current status, next status" table would lose what the technique teaches and a spreadsheet does not give: the guard that fires escalation and the return of the item to in progress.

The lifecycle also serves day to day: set beside a real register, it turns that register into an audit instrument.

• An item left "open" without ever passing to "assigned" has no owner, and the register let it through.
• An item whose status is "escalated" betrays a badly posed state model, since escalation is a transition.
• An item that went from "resolved" to "closed" with no trace of approval in the resolution log was closed by the keeper of the register: that is silent closure.

Cost

Tooling

The minutes with an action table are the cheapest form: an identifier, a summary, an owner, a due date. They suit a short engagement with a handful of stakeholders, and they beat a proper register nobody maintains.

The spreadsheet works. Its usual failure is that copies multiply: five versions and an email thread, where one keeper and one shared copy would do. It does offer sorting by age in one formula, which most registers do not have. Collaborative pages and lists (a Confluence table, a SharePoint list, a Notion base) fix that flaw: shared, versioned, filterable by status and by owner, with nothing to install. It is the pragmatic choice when the delivery team has no tracking tool.

Ticket-tracking tools (Jira, Azure DevOps, GitLab, Redmine) give for free what the technique asks you to build by hand elsewhere: the state model, assignment, age computation and escalation driven by a service agreement. BABOK's seven item types translate directly into ticket types. This is the obvious choice where the delivery team already works, and it answers the shadow-register pitfall. Service-management and compliance platforms (ServiceNow and equivalents) earn their place when the escalation matrix has to be enforced by a service agreement rather than remembered by a person and when items cross organisational boundaries. They are heavy for a register at the scale of a single initiative.

Requirements-management tools with a linked item or issue object (Jama Connect, IBM DOORS Next, Polarion, Visure) offer what a spreadsheet does not give: traceability from the item to the requirement it threatens, so that a blocked requirement shows as blocked in the traceability matrix. That is worth its price in regulated work, where the auditor will ask for that trace. Whatever the tool, the rule does not change: one register, shared, whose status a stakeholder can read without having to ask.

Sources

• IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.26 Item Tracking: the anchor source, the goal, the seven item types, the fifteen record attributes, the statuses given as examples, the escalation matrix, item management, the metrics, the strengths and the limitations.
• UK Government Project Delivery Function, The Teal Book, chapter 21: Issue management: the switch from risk to issue (a risk that occurs becomes an issue), tolerances as an escalation trigger and the sequence identify, assess, respond, monitor and report then close, with a named owner for every issue.
• Association for Project Management, Glossary of project management terms: the definitions of issue, issue log and issue management by a professional body, founded on the breach of a delegated tolerance, narrower than BABOK's item.
• Object Management Group, Unified Modeling Language (UML) v2.5.1, clause 14 StateMachines and §13.3.4 for the trigger: the standard vocabulary of state machines, state, transition, trigger, guard and effect, on which the reading of escalation as a guarded transition and the notation of the lifecycle both rest.
• Swiss Confederation, Federal Chancellery, HERMES 2022, Project Management Reference Manual, task 5.4.3.29 Deal with problems and benefit from lessons learned, outcome 4.4.1.32 Lessons learned: the immediate escalation of a problem the person responsible cannot solve or cannot solve in time, the escalation process set in the project management plan and the continuous collection of lessons as the task's only outcome.
• Swiss Confederation, Federal Chancellery, HERMES 2022, Project Management Reference Manual, outcome 4.4.1.3 Change status list, task 5.4.3.2 Manage changes: the register that tracks change requests, minimally required in the traditional approach as in the agile one, with the content required for each of the two.
• Swiss Confederation, Federal Chancellery, HERMES 2022, Project Management Reference Manual, outcome 4.4.1.20 List of management project decisions, outcome 4.4.1.21 List of steering project decisions: the two decision registers, one per hierarchy level, with their content (decision, milestone achieved or not, underlying documents, decision-makers, date). The reference manual splits the levels in §5.1.2 Decision-making tasks: steering decisions are the project sponsor's, management decisions the project manager's.