Deliver the architecture

Delivery in architecture has a particular shape. RFIs and variations carry legal weight. Drawings are issued in sets, with revisions that matter. Consultants are neither staff nor clients and need their own way in. Builders arrive late and stay to the end. And behind all of it runs a construction contract, in which the questions and changes that started as correspondence become acts with consequences.

A general work tool models all of that as tasks with attachments. Mudo models it as what it actually is.

Four questions, four systems

Delivery looks like one activity from outside the practice and is four from inside it, which is why these are four capabilities rather than one register with filters.

Drawing review answers what changed — one issued set against another, and the difference between them. Registers answer what is owed — the questions, issues, decisions and deliverables the practice has accepted responsibility for, each with the weight its own record type carries. Portals answer what may cross — the same records seen through a smaller opening by a client, a consultant or a builder. And contract administration answers what contractual consequence followed — which instruction was issued because of which question, who had the authority to determine it, and what it moved.

They are not layers of one another. An RFI can be answered without anything being instructed; an instruction can be issued without a variation following; a variation can be determined without the drawings changing. Keeping them distinct is what lets each one be read on its own terms, and what lets a chain be followed from a question on site to the contractual fact it eventually produced.