Traceability proportionate to decisions

Design the strategy around questions

A traceability strategy should explain which questions can be answered, for whom and when. Starting with “link everything to everything” can create maintenance work without demonstrating usefulness. In a fictional project modernizing an instruction service, Business wants to know which need justifies each selected requirement; QA needs to identify the intended acceptance check; APS needs to locate the associated operating procedure and whoever reviews a relationship when either endpoint changes.

These are four separate queries, Q1 through Q4. Define what makes an answer sufficient: identifiers, scope, applicable revision, recipient and conditions of use. The existence of a planned test does not mean it was executed successfully.

A relationship to a procedure does not establish production readiness either. The strategy prepares information for later decisions and should retain those distinctions. The analyst agrees these needs with responsible stakeholders before choosing fields or tools.

The central question is whether the design will provide a relevant, usable answer, rather than how many rows a dashboard can display.

Compare maintained information with explicit assumptions

The workshop uses four information packages, each treated as indivisible. R1 answers Q1 and Q2 and needs two maintenance hours per month; R2 answers Q2 and Q3 and needs two; R3 answers Q3 and Q4 and needs three; R4 answers only Q4 and needs one.

These values are fictional. Each package provides a complete answer to its listed queries throughout the exercise scope, provided relationships are valid and accessible. There are no setup costs, overlap savings or other amounts in this comparison.

Different packages’ costs are added once per package; selecting R1 and R2 does not permit subtracting effort because both answer Q2. The baseline permits authorized recipients to access the information and assumes sufficient maintenance capacity.

With a five-hour monthly limit and all four queries mandatory, two complete plans exist: R1 with R3, and R1 with R2 and R4. Both cost five. The calculation compares information strategies under these assumptions; it does not automatically select a tool or assign authority to approve the strategy.

If another comparison includes initial setup, separate it from monthly maintenance and check capacity before launch. Future savings do not supply hours within an already constrained window. Those additional costs enter only when the variant’s contract defines them.

Measure coverage without counting one answer twice

R1 and R2 contain four query associations in total: two in each package. However, the union of answered queries contains only Q1, Q2 and Q3 because Q2 appears twice. Q4 remains unanswered.

If every query counts equally for this indicator, coverage is three of four, or 75%, rather than 100%. The indicator describes only query coverage in this exercise. It does not say the service meets 75% of requirements or has 75% quality; any relationship between those quantities would need separate definition.

One mandatory query does not disappear because another has more links. If an organization assigns different importance to queries, document the rule and keep conditions that cannot be compensated visible. An aggregate can support communication while still showing that APS cannot identify who will maintain a relationship.

In the workshop, adding R4 to R1 and R2 covers Q4 and reaches five hours. Complete coverage remains conditional on assumed validity, scope and access; it does not turn the four answers into production authorization. Define the population too: three requirements examined in a pilot do not establish coverage of twenty.

If each requirement needs two answers, six confirmed pairs out of forty leave thirty-four awaiting confirmation. Without an agreed inference rule, turn those gaps into neither confirmed answers nor invalid relationships.

Check access for the person needing the answer

A query is not operationally covered merely because an administrator can run a search. Define each relevant query–recipient pair: Q1 for Business, Q2 for QA, and Q3 and Q4 for APS. In the access variant, R3 contains technically correct answers, but APS is not authorized to consult them.

Other packages remain usable by the specified recipients. R1 with R3 therefore no longer satisfies the strategy for those people, even though nominal coverage still contains four queries. R1, R2 and R4 continues to meet all four needs within five hours.

Do not resolve the restriction by copying data to an unauthorized destination. A separately stated variant permits an explicitly approved controlled view of R3 that restores required access and adds one monthly maintenance hour. R1 with R3 and that view then costs six, exceeding the five-hour limit.

A plan may be technically possible without fitting approved resources. Record the specific failed condition so access, design or budget can be reconsidered without assuming any of those conditions has already changed.

Allocate maintenance work to actual owners

A five-hour total does not establish that every team has capacity for its own share. In a separate variant, R1 belongs to the analyst and consumes two hours; R2 belongs to QA and consumes two; R3 belongs to APS and consumes three; R4 belongs to the analyst and consumes one.

The analyst has three monthly hours, QA has two and APS has two. Task transfers between teams are not permitted in this variant. R1 with R3 respects the overall limit but needs one APS hour beyond available capacity.

R1, R2 and R4 allocates three hours to the analyst and two to QA, meeting every limit. This does not establish that APS is unnecessary to the project: it describes only who maintains the selected packages. The strategy should identify events creating work, update responsibility and absence cover.

If maintenance depends on somebody whose availability is unconfirmed, a field named owner does not resolve the gap. Make conditions and dependencies explicit so the information commitment is sustainable beyond the day of presentation.

Define when a relationship can no longer answer

Plan relationships’ lifecycle before relying on them. A package may contain correct identifiers yet fail to provide an answer applicable to the requested revision. One possible exercise policy requires a relationship to become “awaiting confirmation” for the new revision after either endpoint changes materially, until its owner checks applicability.

The historical link retains its previous revision reference and is not deleted merely because work is pending. This is a fictional rule to agree, rather than a universal PMI requirement. Specify the review trigger, deadline, notification recipient and presentation of an unavailable answer.

A report updated only at month end may not serve a weekly committee; adding more relationships does not fix that delay. Before assuming a query is covered, check when its answer is needed as well. Designing these mechanisms defines the traceability strategy; performing each update and monitoring status are subsequent activities.

Keeping those activities distinct prevents treating an agreed policy as evidence of compliance. A useful plan also explains who handles exceptions when the maintenance commitment cannot be met.

Resize the strategy when decisions change

Proportionality depends on current decisions and obligations, rather than always choosing the smallest record. If a fifth mandatory query appears and no package supports it, neither original plan becomes sufficient merely because it still fits five hours.

Make the gap visible and assess changes to packages, resources or scope with responsible stakeholders. Conversely, a query may stop serving an operational decision after a component is retired. Confirm that change before removing recurring maintenance; historical preservation and maintenance of a current view are different commitments.

In the exercise, a policy requiring records to remain available for one year may allow transfer to a controlled archive without maintaining an unnecessary operational dashboard. Do not delete evidence simply because it is no longer used daily.

An evolving strategy should record the reason for a change, who accepted it and which dependencies remain protected. Nor should the same design be assumed proportionate for every component: a reversible decision and a transition affecting recovery may need different questions, while still respecting mandatory requirements within each scope.

Another possible change is requiring answers even when one package is unavailable. Normal coverage does not prove that continuity: in the supplied matrix, Q1 depends only on R1. Even maintaining all four packages cannot answer Q1 when R1 fails.

Another support or an authorized commitment revision is needed; duplicating Q2 answers does not repair that dependency.

Present a checkable traceability proposal

Deliver a proposal connecting queries, recipients, maintained information, assumptions, costs, capacity, updating and limits. For the workshop baseline, show both five-hour plans and explain why neither automatically takes precedence on cost alone.

Present variants separately: the access restriction removes one plan; the APS capacity limit can also remove it for a different reason. Do not silently combine assumptions from different variants. The proposal should let someone reproduce its conclusion and identify what would change it.

Include an example answer, an example gap and the rule for making that gap visible. In an international meeting, you might explain: “This plan supports all four agreed queries within five monthly hours, provided the links remain applicable and the named recipients can use them.”

That statement retains validity conditions without promising test outcomes or operational authorization. Use the workshop to practise justifying a sustainable information design. The packages, costs, rights and policies are fictional and describe neither a bank’s internal processes nor official exam conditions.

Approval of the proposed strategy still belongs to the designated decision owner.

Common pitfalls

Count repeated links as new queries; equate coverage with approval; ignore recipients and team capacity; assume archiving and current maintenance are the same obligation.