Information Management

Integration technique · See it on the map

Guide only — Names whatever information systems the org runs.

The tools and habits for storing and finding project documents already written down.

When to use it

Whenever a fact the project generates repeatedly needs one durable, findable home — a budget line, a risk, a change request, a weekly status reading — so asking 'what is the current answer' is a lookup, not an investigation.

When to avoid it

When the thing that needs to move is judgment rather than a fact: why a call was made, what to watch out for next time, what a vendor is actually like to negotiate with. Forcing that into a form field produces a record that is technically searchable and practically useless. That is the knowledge management technique's job, not this one's.

Steps

1. Decide the artifact's structured home: a modelled row with fields the system computes over (a BudgetLine, a Risk, a ChangeRequest) if the data is structured, a NarrativeArtifact body if it is prose.
2. Give it one owner and one place — matching driftless's one-row-per-(project, kind) convention for narrative artifacts — rather than letting duplicate drafts accumulate in parallel.
3. Decide who updates the record and how often, and hold that cadence (a weekly StatusSnapshot, not a status page nobody has touched in a month).
4. When a record is superseded, replace it explicitly rather than editing the old one in place, the way a new Baseline version supersedes the last — so a later search never turns up two conflicting 'current' answers.
5. Confirm the record is actually reachable by whatever is supposed to read it — a report, a dashboard, a wizard's completeness check — because an artifact nothing queries is a file, not managed information.

What it produces

• A system of record for a specific category of project information, with a clear owner and refresh cadence.
• The retrievable artifact itself, in a form whatever needs it downstream can actually consume.

Common pitfalls

• Recording the same fact through two paths — a hand-typed figure alongside a value the system already derives — so the two quietly drift apart and 'the system' now gives two different answers to one question.
• A repository so sprawling or so duplicated that finding the current version costs more than just asking the person who wrote it, which defeats the entire point of storing it.
• Confusing 'it is in the system' with 'someone will read it' — a record no process actually consumes is storage, not information management.

Worked example

A regional signage rollout keeps its planned spend as five BudgetLine rows, one per cost category, instead of a spreadsheet three people edit independently. When finance asks for planned spend by category, the answer is a single group-by query against BudgetLine, not a reconciliation between conflicting spreadsheet copies that were last saved on different days.

Source

• PMBOK-6 §4.4.2.3

Where it comes from: this technique is named by the PMBOK Guide, 6th edition.