Item Tracking · Business Analysis Notes

What it is#

An item is anything raised during the work that needs a decision or an action and could affect the solution: an issue, an action, an assumption, a constraint, a question, a risk, a defect, a request for a change. Item tracking is the organized way to capture these items, assess and classify them, assign them to one or more stakeholders, and follow them until they are resolved.

The BABOK Guide describes the technique in three parts:

Item record — what you write down about each item: what it is, who raised it, how important it is, who owns it.
Item management — how an item moves through its life: raised, assessed, assigned, worked on, resolved, closed, or escalated.
Metrics — numbers about the list itself, such as how many items are open, how old they are, and how fast they are closed.

Few techniques are used as widely. The Watermark study tables show item tracking supporting almost every task in all six knowledge areas, from planning the business analysis approach to assessing enterprise limitations.

When to use it#

Use it whenever there are more than a handful of open points and more than one person has to act on them, which describes almost every initiative. Typical moments:

during elicitation, to park questions nobody in the session can answer;
during planning, to record assumptions and constraints that still need confirming;
during requirements reviews, to log findings and the rework they trigger;
while assessing a solution, to track what is limiting its value.

When not to use it. The study tables name the main weakness: the time spent tracking can outweigh the benefit, and that time might be better spent on other project work. For a two-person, two-week task, a short list on a whiteboard is enough. If your team already runs an issue tracker or a backlog, use it instead of starting a parallel spreadsheet. If you keep a separate risk register, link to it rather than copying risks into the item log.

How to do it#

Agree on item types. Keep the list short, for example: question, issue, action, assumption, decision needed, defect. Every extra type slows people down.
Define the record. Choose the minimum fields: ID, title, type, description, raised by, date raised, owner, priority, status, due date, resolution. Add fields such as impact or category only if someone will actually use them.
Define the life cycle. For example: New → Assigned → In progress → Resolved → Closed, plus Escalated. Write down who may close an item; usually the person who raised it, or the owner with the raiser’s agreement.
Set an escalation rule. Decide in advance what happens when an item misses its due date or the owner cannot resolve it: who it goes to, and after how long.
Log items as they appear. Capture them during the meeting, not from memory afterwards. One item per record; split compound items.
Assign one accountable owner. Several people can contribute, but one named person drives the item to resolution.
Review the list on a rhythm. Weekly works for most teams. Look at overdue and high-priority items first, and ask “what is blocking this?” rather than “is it done?”.
Close with a resolution. Record what was decided and where it is now reflected: an updated requirement, a decision log, a changed plan. An item closed without a resolution note tends to come back.
Report a few metrics. Open versus closed over time, average age of open items, number overdue. Use them to find bottlenecks, not to blame people.

Example#

The Workshop is a fictional chain of 12 bike-repair workshops building online booking and repair-status notifications. In one week of elicitation the analyst logs these items:

ID	Type	Description	Raised by	Owner	Priority	Due	Status
`IT-014`	Question	Can customers book a repair without choosing a mechanic?	Front-desk staff	Owner	High	Mar 14	Assigned
`IT-015`	Assumption	The parts supplier can provide its catalog as an export file.	Analyst	Development team lead	Medium	Mar 21	In progress
`IT-016`	Issue	Managers disagree on the length of a standard service slot (45 or 60 minutes).	Workshop manager	Owner	High	Mar 12	Escalated

At the weekly review, IT-016 is two days overdue because the managers cannot agree among themselves. Under the escalation rule it goes to the owner, who decides: 60 minutes for a full service, 30 for quick fixes. The analyst updates the booking rule, records the decision in the resolution field, and closes the item with a link to the changed requirement.

IT-015 turns out to be false: the supplier has no export. The analyst closes the assumption as “invalid” and opens a risk in the risk register, because the parts-ordering feature now depends on an unknown integration.

Common mistakes#

Items scattered across email, chat, and meeting notes → keep one list and link to it from everywhere else.
Items owned by “the team” or “everyone” → name one owner per item.
No due dates → give every open item a target date, even a rough one.
Closing without a resolution → record the answer and where it now lives.
Tracking trivia → if fixing something takes less time than logging it, just fix it.
Using item age to blame people → use metrics to spot bottlenecks, such as one overloaded stakeholder.
A list that only grows → merge duplicates and close stale items with an explicit “will not resolve” status.

Template#

Template

| ID | Type | Title | Description | Raised by | Date raised | Owner | Priority | Status | Due date | Resolution | Link |
|----|------|-------|-------------|-----------|-------------|-------|----------|--------|----------|------------|------|
| IT-001 | Question / Issue / Action / Assumption / Defect | | | | | | High / Medium / Low | New / Assigned / In progress / Resolved / Closed / Escalated | | | |

Checklist#

Item types and record fields agreed with the team
Life cycle and closing rule written down
Escalation path and time limit defined
Every open item has one owner and a due date
The list is reviewed on a fixed rhythm
Every closed item has a resolution note and a link to what changed

Sources and further reading#

IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK® Guide), version 3. International Institute of Business Analysis, 2015. Technique 10.26 “Item Tracking”.
Watermark Learning. BABOK v3 Study Tables. 2016. (study aid for the BABOK Guide). Section 10.26.