Knowledge management in an architecture office

Every office has solved it before. The junction of the loggia with the insulated façade, the stair core in an existing building, the authority’s condition that went through on the third attempt. The solution sits somewhere on the office server, in a 2019 project folder, in a detail drawing with a file name only its author understands. And that person may have left.

So you ask the senior colleague, or you solve the detail again. Both cost time, and the second is risky: the new solution has not yet been through the authority.

Why better filing alone does not help

The first reflex is order. A new folder structure, a naming convention, a wiki. That is not wrong, but it nearly always fails on the same three things:

• Filing follows the project; the question does not. Folders are sorted by project and work stage. People search by topic: “How did we handle fire safety in timber construction?” That is in five projects and in no folder.
• Nobody maintains the wiki under deadline pressure. Knowledge gets written down when there is time, and in the submission phase there never is.
• The migration is planned twice and never finished. Moving fifteen years of folders into a new structure is a project no office has a client for.

What helps instead: search where the knowledge already is

The other way is to leave the documents where they are and make them searchable by what is in them, not by file name. A question like “Where did we insulate a loggia across two storeys?” then finds the façade section from the Ottakring housing scheme, even if it is called FS_03_rev2.pdf.

For that to work in an office it takes three things:

1. Drawings must be readable, not just text. A detail is a drawing. A tool that reads only the text of a PDF will not find the section.
2. The answer names its source. Not “this is how it is done” but “this is how you did it in 2019 on project X, sheet 12”. Then you can check whether the solution still fits today.
3. The archive stays yours. Your office’s documents must be visible to no other office, and no model may be trained on them.

Knowledge made while working

Most of an office’s knowledge is never written down, because it comes up in conversation: what did the authority say at the last meeting? Which option did we drop, and why? That is why Piloti has a project memory. What a project has settled goes into later answers as a fact or an open point, and on request an answer becomes a file note in the project that goes for approval. So the knowledge gets on file while the work happens, not afterwards.

How Piloti handles it

Piloti searches your office’s archive together with building law and the project’s documents, and every answer names where it comes from. You upload folders as they sit on the office server, subfolders included, and the detail view shows where a file lived on your server. When a drawing matters, Piloti looks at the page as an image and marks which drawing it read.

How the platform, office, project and conversation levels fit together is in How Piloti works. Why we build Piloti this way is on Why Piloti.

A suggestion to start with

Pick a topic your office is asked about again and again, say fire safety on the façade or parking spaces, and three finished projects where it was solved. That is enough to see whether a tool finds your knowledge again. If you like, we will do it with you.