<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:g-custom="http://base.google.com/cns/1.0" xmlns:media="http://search.yahoo.com/mrss/" version="2.0">
  <channel>
    <title>specifire</title>
    <link>https://www.specifire.co.nz</link>
    <description />
    <atom:link href="https://www.specifire.co.nz/feed/rss2" type="application/rss+xml" rel="self" />
    <item>
      <title>Fire design is a collaboration problem first</title>
      <link>http://www.specifire.co.nz/fire-design-is-a-collaboration-problem-first</link>
      <description>Fire engineers don't work in isolation. When coordination is improvised rather than structured, the cost shows up as rework and delays. PN22 aims to solve that.</description>
      <content:encoded>&lt;div data-rss-type="text"&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;span&gt;&#xD;
        
           Fire design looks, on paper, like a discrete engineering task. In practice it's one thread in a fabric that includes architects, structural engineers, builders, consent authorities, and building owners — each with their own documentation, their own timelines, and their own definition of what "done" means.
          &#xD;
      &lt;/span&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
&lt;/div&gt;&#xD;
&lt;div data-rss-type="text"&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      
          This is the condition fire engineers work in on every complex project. Not occasionally. Always. The ambiguities aren't a sign something has gone wrong — they're structural features of multidisciplinary design. Who owns the decision when a fire resistance rating depends on a wall system the architect hasn't specified yet? What happens when the builder can't source the product the fire report assumes? Whose job is it to notice when a late architectural change has downstream fire implications? These questions don't have clean answers in advance. They get negotiated, or they don't, and the cost of not negotiating shows up later.
         &#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      
          The risk, in a system this interdependent, is that each discipline retreats to what it can control. The fire engineer produces a technically correct report. The architect produces compliant drawings. The structural engineer signs off on their scope. Everyone has done their job. And yet the project still has coordination gaps, because the jobs were defined in isolation rather than in relation to each other. This is what siloing actually looks like — not ignorance or bad faith, but a rational response to complexity that makes the overall system more fragile.
         &#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;span&gt;&#xD;
        
           Good collaboration in this context isn't about personality or goodwill (though both help). It's about three things that can be practised and improved:
          &#xD;
      &lt;/span&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;ol&gt;&#xD;
    &lt;li&gt;&#xD;
      &lt;span&gt;&#xD;
        
           Communication that is designed for its audience rather than its author
          &#xD;
      &lt;/span&gt;&#xD;
    &lt;/li&gt;&#xD;
    &lt;li&gt;&#xD;
      &lt;span&gt;&#xD;
        
           Shared goals that are legible across disciplines, not just within them
          &#xD;
      &lt;/span&gt;&#xD;
    &lt;/li&gt;&#xD;
    &lt;li&gt;&#xD;
      &lt;span&gt;&#xD;
        
           Systemic thinking — the habit of asking not just "have I done my part" but "does the whole thing work."
          &#xD;
      &lt;/span&gt;&#xD;
    &lt;/li&gt;&#xD;
  &lt;/ol&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      
          When those things are absent, the costs are real but easy to misattribute. The architect calls with questions that are answered in the fire report — that's not an architect problem, it's a communication design problem. The fire engineer annotates drawings to duplicate information that already exists in the report as a workaround for an audience gap that was never properly addressed. The late-stage design change that cascades through three disciplines is not bad luck, it's the consequence of a brief that was never properly established. None of these show up as "coordination failure" on anyone's timesheet. They show up as rework, callbacks, and extended review cycles.
         &#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      
          This is what documents like Practice Note 22 are actually trying to solve. Not a paperwork problem, but a coordination infrastructure problem. PN22 doesn't prescribe who owns which function — it offers guidance on how to negotiate the moving parts: when the fire design brief needs to be established, how performance requirements get communicated across disciplines, what the fire report needs to do for a builder versus a consent authority. The assumption underneath it is that the ambiguities will arise regardless. The question is whether the project has shared practices for handling them, or whether each discipline is improvising independently.
         &#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      
          The firms that handle this well have usually developed their own version of those shared practices — specific workflows with specific collaborators, habits built into how briefs get written and how reports get structured. The limitation is that those solutions tend to live in individual relationships rather than firm-wide systems. They don't transfer when people change, and they don't scale.
         &#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      
          Structured guidance like PN22, used in good faith rather than as a compliance checkbox, does something more durable. It builds a common language across the sector — not a prescription for who does what, but a shared model of how the work fits together. That shared model is what allows collaboration to be robust rather than fragile: less dependent on the right people happening to know each other, more dependent on practices that hold regardless of who's in the room.
         &#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      &lt;br/&gt;&#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
  &lt;p&gt;&#xD;
    &lt;span&gt;&#xD;
      
          The overhead isn't the coordination. It's everything that happens without it.
         &#xD;
    &lt;/span&gt;&#xD;
  &lt;/p&gt;&#xD;
&lt;/div&gt;</content:encoded>
      <pubDate>Sun, 17 May 2026 00:43:00 GMT</pubDate>
      <guid>http://www.specifire.co.nz/fire-design-is-a-collaboration-problem-first</guid>
      <g-custom:tags type="string" />
      <media:content medium="image" url="https://irp.cdn-website.com/4c84e1fa/dms3rep/multi/base1.svg">
        <media:description>thumbnail</media:description>
      </media:content>
      <media:content medium="image" url="https://irp.cdn-website.com/4c84e1fa/dms3rep/multi/base1.svg">
        <media:description>main image</media:description>
      </media:content>
    </item>
  </channel>
</rss>
