It's a reasonable thing to ask: when someone joins your project three months in, or when you need to reconstruct who approved what in month seven, where is the conversation?
For most architecture firms, the honest answer is: scattered across the personal inboxes of everyone who was on the relevant email threads. Which means it's inaccessible to anyone who wasn't on those threads, practically irretrievable unless you know exactly what to search for, and permanently lost when anyone who was on those threads leaves the project or the firm.
That's not a communication system. That's a filing system built from happenstance.
What Email Does to Project Communication
Email works fine as a communication channel, what it doesn't do is organize project communication in a way that's useful for project management.
When a decision about the structural frame connection gets made in a thread between the PM and the structural engineer, that decision isn't accessible to the project architect who joins the thread two weeks later. It's not searchable by the principal who needs to understand why the detail is designed the way it is. When the PM leaves, it's gone.
The volume compounds the problem. An architecture PM managing three active projects might have two hundred project-related emails per day. Within that volume, the decision threads, the approval confirmations, the coordination agreements — none of it is organized by project or topic. It's organized by time of arrival.
Finding anything more than a few days old requires knowing which keywords were used, who sent it, and approximately when. This is not a reasonable search experience for information that directly affects what gets built.
How Olumba's Messaging Works
Olumba's team messaging is organized around the project, not around individuals.
Conversations happen in the project. Files attached to messages are linked to the project's document system — not floating as orphaned attachments in someone's inbox. The conversation history lives in the project record, accessible to anyone with appropriate project access now and six months from now.
A few specifics worth knowing:
Unified messaging across org members and external collaborators. The structural engineer on your consultant team can be in the same project conversation as your internal project architect. The conversation is scoped to the project — nobody sees conversations they're not part of, but the right people see everything relevant to them.
Contact autocomplete. When you're starting a message, the system surfaces the right people based on who's on the project. You're not maintaining a separate contact list or looking up email addresses.
File attachments live in the conversation. When someone attaches a drawing to a message, it's there in the thread with the context of why it was shared. Not in a separate download folder. Not as a separate email attachment requiring a separate search. In the conversation, where the discussion happened.
What This Looks Like in Practice
A coordination question about a ceiling height at the mechanical room comes in from the MEP engineer. In the project messaging thread, they attach the relevant section. The project architect responds with a revised detail, also attached inline. A note is made about the decision. What was resolved and why. The pm sees it in their project view without being cc'd on a separate email chain.
Three months later, the contractor has a question about the same detail. The project architect opens the project, finds the conversation, and has the full context of the decision — the original question, the revised detail, the resolution. In one place. No email archaeology required.
When a new project engineer joins mid-project, they have access to the full project messaging history. They can read the coordination conversations, understand decisions made before they joined, and contribute from an informed baseline without requiring a two-hour onboarding call.
The Institutional Knowledge Argument
The most underappreciated cost of email-based project communication is institutional knowledge loss.
Every project runs on a continuous stream of small decisions, clarifications, and coordination agreements. These form the institutional knowledge of the project: the "why" behind every design choice, the record of every approval, the context that makes the drawings make sense.
When that knowledge lives in personal inboxes, it's distributed across the firm's people rather than across the firm's projects. When those people leave or get promoted, or change roles. The knowledge moves with them or disappears.
Olumba treats project communication as part of the project record. Not because it's bureaucratically important, but because the project's conversations are how the project's decisions get made. They should be findable, organized, and persistent.
If your firm's project conversations are currently living in email threads that disperse a little further every time someone leaves: consider checking out what they look like organized in the project instead. Try Olumba.