Collaboration and coordination

Halfway through the term, the class is split into teams of four for the coordination exercise. Each team takes the four-story mixed-use building on Lake Street and divides it: one student models the architecture, one the structure, one the mechanical ducts and one the plumbing and electrical. On the first morning, Callum and Ingrid both model the stair; nobody models the ceilings; and the structural model is ten feet east of everything else because Wren set up her own origin. Professor Ferreira lets it happen. 'Now you know why the first meeting on every real project is about coordinates, responsibilities and file exchange,' she says. 'Software lets four people work at once. Only agreement makes their work fit.'

Why collaboration is the hard part

A building is designed by many people in many organizations: the architect, the structural, mechanical, electrical and civil engineers, the landscape architect, specialist consultants for façades, acoustics, code and cost, and increasingly the contractor and trades. Each produces information for their part, often in different software. The value of BIM depends on bringing that information together in a controlled way so that it can be coordinated, checked and trusted. The technical side of this, file formats and software, is comparatively easy. The difficult side is agreeing who does what, when, to what standard and with what responsibility.

ISO 19650 and information management

The international standard for managing information over the life of a built asset using BIM is the ISO 19650 series. Parts 1 and 2, covering concepts and the delivery phase of projects, were published in 2018, based on earlier British standards; later parts deal with the operational phase, security, information exchange and health and safety. The standard is used across Europe, Australia and parts of Asia and is increasingly referenced in the United States, often alongside national guides.

ISO 19650 describes roles and documents. The appointing party is the client or owner. The lead appointed party is usually the main consultant or contractor who coordinates a team, and appointed parties are the members of that team. The client states what information it needs in exchange information requirements, the EIR. The delivery team responds with a BIM execution plan, the BEP, describing how it will meet those requirements, and with an information delivery plan listing every model, drawing and document it will produce, who will produce it and when. Projects also maintain a responsibility matrix that assigns each element or piece of information to one author.

# A model element responsibility check: every element must have exactly one author.
plan = {"grids and levels": ["A"], "structural slabs": ["S"], "architectural floor finishes": ["A"],
        "columns": ["S", "A"], "exterior walls": ["A"], "ducts": ["M"], "plumbing": ["P"],
        "light fittings": ["E"], "ceilings": [], "stairs": ["A"]}
names = {"A": "architect", "S": "structural", "M": "mechanical", "P": "plumbing", "E": "electrical"}
for item, who in plan.items():
    if len(who) == 1:
        print(f"{item:30s} {names[who[0]]}")
    elif not who:
        print(f"{item:30s} NOBODY  -> assign an author")
    else:
        print(f"{item:30s} {' and '.join(names[w] for w in who)}  -> two authors, agree one")

grids and levels               architect
structural slabs               structural
architectural floor finishes   architect
columns                        structural and architect  -> two authors, agree one
exterior walls                 architect
ducts                          mechanical
plumbing                       plumbing
light fittings                 electrical
ceilings                       NOBODY  -> assign an author
stairs                         architect

The check finds two problems that the class exercise also found: the columns have two authors, so one of them must be the single owner and the other must only reference them, and the ceilings have none. Real projects use the same kind of matrix, usually as a spreadsheet tied to the level of development for each element at each stage.

The common data environment

A common data environment, or CDE, is the agreed source of information for a project: a platform and a set of processes through which information is stored, shared, reviewed and approved. It may be a cloud platform such as Autodesk Construction Cloud, Trimble Connect, Bentley's ProjectWise or Graphisoft's BIMcloud, or a carefully organized file server with a document control process. Whatever the technology, ISO 19650 describes information as moving through four states.

• Work in progress is information being developed by one task team, visible only to that team.
• Shared is information released to the rest of the project team for coordination, after a check within the task team. Others can reference it but not change it.
• Published is information authorized for use, such as construction or tender, after review and acceptance.
• Archived is the record of superseded and final information, kept for audit and for the life of the asset.

Each container, meaning each file or model, carries metadata: a name following the naming rule from lesson 1, a revision code and a status code that says what it may be used for. The script below models the states as a small state machine that refuses moves the process does not allow, such as publishing a model straight from work in progress.

# A common data environment as a small state machine (after ISO 19650).
allowed = {("work in progress", "shared"): "check, review and approve within the task team",
           ("shared", "work in progress"): "rejected or revised by the author",
           ("shared", "published"): "authorized by the lead appointed party and accepted by the client",
           ("published", "archived"): "superseded or project complete",
           ("shared", "archived"): "superseded before publication"}
log = []
def move(container, state, new, by):
    reason = allowed.get((state, new))
    if reason is None:
        log.append(f"{container}: {state} -> {new} by {by}  REFUSED")
        return state
    log.append(f"{container}: {state} -> {new} by {by}  ({reason})")
    return new
s = "work in progress"
s = move("KPB-ELM-ZZ-ZZ-M3-A-0001", s, "published", "student")      # skips review
s = move("KPB-ELM-ZZ-ZZ-M3-A-0001", s, "shared", "Wren")
s = move("KPB-ELM-ZZ-ZZ-M3-A-0001", s, "published", "Prof. Ferreira")
s = move("KPB-ELM-ZZ-ZZ-M3-A-0001", s, "archived", "Prof. Ferreira")
print("\n".join(log))
print("final state:", s)

KPB-ELM-ZZ-ZZ-M3-A-0001: work in progress -> published by student  REFUSED
KPB-ELM-ZZ-ZZ-M3-A-0001: work in progress -> shared by Wren  (check, review and approve within the task team)
KPB-ELM-ZZ-ZZ-M3-A-0001: shared -> published by Prof. Ferreira  (authorized by the lead appointed party and accepted by the client)
KPB-ELM-ZZ-ZZ-M3-A-0001: published -> archived by Prof. Ferreira  (superseded or project complete)
final state: archived

Worksharing: many people, one model

Within a single discipline, several people often need to work on one model. BIM programs support this through worksharing. In the traditional arrangement, a central model is stored on a server and each user works on a local copy, synchronizing regularly to send their changes and receive others'. Elements are borrowed while being edited, so two people cannot change the same wall at once. The model is divided into worksets, such as exterior shell, interiors, core and site, which can be assigned to people and loaded or unloaded to keep models fast. Cloud worksharing does the same over the internet, and Archicad's Teamwork reserves elements in a similar way. The discipline needed is simple but strict: synchronize often, release what you have borrowed, work in your own areas, and never copy the central model to make a private version.

Linking and federating models

Between disciplines, models are not usually merged. Each discipline keeps its own model, and the others link it as a reference. The architect links the structural model to see the columns and beams; the mechanical engineer links the architectural model to route ducts through ceilings. For coordination, all the discipline models are combined, read-only, in a federated model in a coordination tool. Linking only works if every model shares the same coordinate system. Projects agree on a survey point tied to the site's real coordinates, a project base point near the building, true north and project north, and the levels, and every discipline acquires these from one shared source. This is the first item in any BIM execution plan, and getting it wrong, as the class discovered, shifts entire models feet away from each other.

Communicating issues: BCF and coordination meetings

Coordination produces issues: a duct that hits a beam, a door that swings into a column, a missing fire rating. These must be recorded, assigned, tracked and resolved. The BIM Collaboration Format, BCF, developed by Tekla and Solibri around 2010 and now a buildingSMART standard, records each issue with a title, description, status, assignee, a camera viewpoint and the identifiers of the elements involved, so that anyone opening the issue in their own software is taken to exactly the right place in the model. Issues travel as small BCF files or through cloud services, without sending whole models. Platforms such as BIMcollab, Revizto and the coordination modules of the major CDEs manage the same information.

Most projects hold regular coordination meetings, often weekly during design development and documentation, where the federated model is reviewed, new issues are raised and old ones are closed. A good meeting is short and focused: issues are prioritized, each has one owner and a due date, and decisions are recorded. The model makes problems visible; people still have to decide how to fix them.

Contracts and responsibility

Who owns a model, who may rely on it and who is liable if it is wrong are contractual questions. In the United States, the American Institute of Architects publishes a digital data exhibit, E203, and a project BIM protocol form, G202, and ConsensusDocs publishes a BIM addendum, which set out model uses, levels of development and the reliance that each party may place on others' models. Integrated project delivery, in which the owner, architect and contractor share risk and reward under one contract, makes the fullest use of shared models, but most projects still use traditional contracts with BIM requirements attached.

Exercise 10: a BIM execution plan

This exercise takes about four hours, followed by the team modeling work.

• As a team, write a short BIM execution plan for the mixed-use building: project information, team roles, BIM uses, software and versions, coordinates, naming, CDE states and exchange schedule.
• Prepare an element responsibility matrix with level of development at schematic design and construction documents.
• Set up a start-up model with levels, grids and shared coordinates, and have each discipline acquire coordinates from it.
• Run one exchange cycle: each member shares a model, the team federates them, and at least three issues are recorded in BCF.
• Deliverable: the BIM execution plan, the responsibility matrix, a screenshot of the aligned federated model and the issue list.

Self-critique checklist

• Does every element in the matrix have exactly one author?
• Do all four models align without manual moves?
• Do our file names and status codes follow the plan?
• Does every issue have an owner, a due date and a viewpoint?

A weekly rhythm

Most teams settle into a weekly rhythm. Early in the week each discipline works in its own area. Midweek, models are checked within each team, cleaned of temporary elements, and published to the shared area on an agreed day and time. The coordinator federates the new models, runs clash tests and checks, and prepares the issue list. At the coordination meeting, the team reviews the issues and decisions, assigns new work, and the cycle begins again. Milestones such as the end of design development or the issue for tender are marked by a formal review and the move of information to the published state. The rhythm is unglamorous, but projects that keep it rarely face surprises on site.