How data becomes information, knowledge, and organizational memory
Projects generate large amounts of data.
Costs are posted. Schedules are updated. Progress is measured. Changes are logged. Risks are recorded. Decisions are documented. Forecasts are revised. Correspondence accumulates throughout execution.
By the end of a major project, the record can be extensive. The core question is how much of the understanding behind that record survives.
A cost increase, forecast revision or commercial position only becomes meaningful when its causes, assumptions, evidence and decisions remain connected.
Over time these relationships tend to weaken or disappear, leaving the organization with thousands of records and still struggling to reconstruct what the team understood at a particular moment, why a decision was made, how those decisions shaped the eventual outcome, and, most importantly, what this means for the project that is being kicked off a month from now.
This is the memory problem in project delivery.
From Data to Memory
There is a useful hierarchy underneath this problem:
Data → Information → Knowledge → Memory
Very often people assume that these terms are synonymous, but each layer depends on the one before it, while adding something different.
Data
Data is the raw material of project control.
It originates continuously through execution:
- cost and commitments
- progress and productivity
- schedule dates
- resource usage
- change and risk events
Much of this data already has a natural home.
Cost sits in ERP systems, schedules in planning software, change orders in registers and documents across repositories. Progress may be tracked through specialist systems or spreadsheets.
This is familiar territory for Project Controls. Good control starts by making project data structured, consistent and connected closely enough to execution that management can trust the underlying record.
Data quality matters because every higher layer depends on it.
A weak baseline, inconsistent cost codes, fragmented progress measures or poor change records create problems immediately. The organization is trying to interpret reality through an unstable foundation.
Strong project controls improve that foundation, because you can’t manage what you don’t measure.
It still leaves another question. What does the data mean?
The distinction is familiar in performance measurement. As discussed in What EVM Shows, and What It Misses, a technically sound performance measure still needs interpretation around the conditions producing it.
Information Emerges Through Context
Data becomes information when it is placed in context.
A cost variance of $500,000 is data. Understanding that the variance came from three additional weeks of paying for your people and other resources following delayed access turns it into information.
A forecast moving from $42 million to $47 million becomes meaningful when the organization can explain:
- which assumptions changed
- what evidence supported the change
- when the change became visible
- which risks were included
- which recovery assumptions remained open
- who accepted the revised position
Information is therefore created through relationships when data is connected to context, cause, assumptions, interpretation and consequence.
Much of that work happens inside project teams.
A planner understands why a sequence changed. Operations understands what happened in the field. The commercial manager understands the entitlement position. Finance understands the cost movement. Project leadership connects those views into a management position.
That interpretation may eventually appear in a report, forecast commentary, meeting note or dashboard.
Some of it never does.
Knowledge Accumulates Through Experience
Knowledge develops when information can be used to improve judgment.
A team may learn that a particular productivity assumption becomes unreliable under certain working conditions.
A commercial manager may recognize that a specific type of change becomes difficult to recover when evidence is assembled too late.
A project manager may learn which early signals deserve escalation and which tend to resolve without intervention.
This knowledge has considerable value because it improves future decisions. Its location is much less structured. Some of it makes its way into procedures, templates, estimating norms, risk registers and lessons-learned reports.
A large amount remains embedded in people.
Experienced project professionals carry a mental library built across years of execution. They recognize patterns because they have seen similar conditions before. They remember why a particular commercial approach failed, which assumptions proved optimistic, and where a previous project lost time or margin.
Organizations depend heavily on this accumulated judgment and that dependence becomes painfully visible when those people leave a project, move into another role, retire or simply forget the detail over time.
I have recently seen people within the same organization who were promoted, but because of the knowledge of the original role they end up wearing two, sometimes three hats at the same time. In another case they are slated for a one-year handover period to train their successor, stalling other important progress within the organization.
The documentation and data are still there, but the interpretation is almost impossible to hand over in a traditional setting.
Memory Preserves the Relationships
Organizational memory sits above data, information and knowledge.
Its purpose is to preserve the relationships that allow past project experience to remain intelligible, and first and foremost an advantage to the company.
That includes connections between:
event → evidence → context → assumption → decision → forecast consequence → outcome
That sequence is what allows the organization to understand the decision later.
Consider a forecast revision for instance. The organization may have the spreadsheet showing the previous forecast and the spreadsheet showing the revised numbers.
A functioning project memory would preserve much more:
- What changed in execution?
- What evidence was available at that point?
- Which assumptions were challenged?
- Which assumptions remained?
- What alternative outcomes were considered?
- What decision followed?
- Who participated in that decision?
- What commercial recovery was expected?
- What eventually happened?
Without this, later teams begin reconstructing history from correspondence, spreadsheet versions, meeting minutes and human recollection. They have to determine what was known at the time and separate it from information that became apparent later.
Even with access to the underlying systems that reconstruction can be difficult.
That is a memory problem.
Where Does Project Memory Live?
Data usually has an identifiable system, information often has an identifiable report and knowledge often has an identifiable person.
We all have that one person in an organization whose name is dropped when people don’t know what to do or where to look.
Organizational memory is difficult to locate.
Organizational memory is fragmented across systems, folders, inboxes, reports and people, each preserving part of the record. The relationships between those sources are difficult to manage, not in the least because not everyone has the same permission sets for these sources.
The organization possesses all those pieces. In claims, disputes, project recovery and forensic reviews that reconstruction can become a significant exercise. The cost is larger than the time spent searching.
The organization is repeatedly paying to rediscover understanding that already existed at one point or another.
The Handshake Between Project Controls and Memory
This is where the memory problem stays close to the traditional LPMS territory.
Project controls provides much of the data architecture. Cost structure, schedule logic, progress measurement, variance attribution, forecasting and change control create the formal record of execution.
Those records matter enormously because they create the foundation from which information and knowledge can develop.
The next step is preserving the context around that record.
Forecasts become more useful historically when the assumptions supporting them can be reconstructed. A schedule baseline becomes more informative when changes in sequence can be traced back to the conditions and decisions that produced them.
This begins to move beyond individual control functions toward Project Intelligence.
The focus expands from maintaining accurate project records to maintaining an intelligible project history.
Lessons Learned Arrive Too Late When Memory Has Already Decayed
Most organizations attempt to capture project knowledge formally at some point with close-out reviews, lessons-learned workshops and post-project reports.
Their quality depends heavily on what can still be reconstructed.
“Supplier mobilization was underestimated” may be correct, but without the original assumptions and uncertainty behind the estimate, the organization also loses the ability to judge whether the lesson should change execution planning, estimating logic or future risk premium calibration.
Lessons become reusable when the path to the lesson survives. Simply filling out a form that is saved in a random folder does not create a sustainable organizational memory.
The Management Consequence
The memory problem affects live execution. Management spends time rebuilding the basis for decisions, continuity becomes dependent on specific people, teams repeat analysis performed elsewhere, and later commercial or contractual interpretation becomes slower and more expensive.
The organization still has data.
Its ability to turn that data into accumulated intelligence is weaker.
This becomes increasingly important as organizations introduce advanced analytics and AI in project environments. Any system can only work with the data and context available to it. Intelligence built on fragmented organizational memory inherits the same fragmentation.
A Different Way to Think About Project Records
A mature project environment needs to preserve more than outputs.
It needs to preserve relationships:
- Data provides the factual record.
- Information gives that record context.
- Knowledge turns context into reusable understanding.
- Memory allows that understanding to survive changes in people, projects and time.
Project controls already provides a large part of the foundation. The next question is what happens to everything the project learns once the reporting cycle ends.
That is where the memory problem begins.