Fragmented Operational State
Why individually good systems can still produce an incoherent project operation.
BoRo Studio · Part of BoRo's work on operational architecture for Solar + BESS project delivery.
What operational state is
Operational state is the answer to a plain question: where does this project stand right now? Which design revision is current, what has been bought against it, what is built, what has changed and not yet been absorbed, and what the project is expected to cost as a result.
State is fragmented when that answer cannot be read from one agreed place and has to be assembled by a person from several sources that do not match.
Why good tools do not prevent it
A typical delivery organization has a tool for project management, an ERP for finance and purchasing, something for document control, a scheduling tool and something for field execution. Each can be well chosen and well run.
Each is also correct only about its own part. The scheduling tool knows the plan. The ERP knows what was committed. Document control knows which revision was issued. None of them is wrong, and no rule says which one describes the project. Coherence was never any tool's job.
The weekly meeting as a database
When no system is the record for the whole, the organization builds one out of people. The weekly project review is where the versions are reconciled: someone reads the schedule, someone reads the cost report, the project manager supplies what neither contains.
That works as long as attention is available. It also means the true state of the project exists for about an hour a week, in a room, and starts to decay when the meeting ends.
System-of-record boundaries
The fix is rarely one more system and almost never a single system for everything. It is a set of boundaries: for each fact that matters, which system is the record, and which systems only read it.
Committed cost has one owner. The current design revision has one owner. The state of a change has one owner. Once that is written down, two systems disagreeing stops being a matter of opinion and becomes a defect with an obvious correction.
Where to look first
Find a number that two functions report differently and that both can defend. Committed cost as seen by procurement and by project controls is a common one. Trace why they differ. The cause is usually a timing difference in when each system learns about a change, which is the same coordination latency seen from the data side.
That trace tells you which boundary is missing. It is a better starting point than a tool comparison, because it starts from how the operation behaves.