Team roles

In the second week Ingrid's team has its first argument. Tomasz has spent the weekend on a grid for the tower that suits a mass timber floor, 6.0 m between column lines; Ingrid has spent it on a plan for the clinic that wants 9 m bays for its exam room clusters. Each has assumed the other would adapt. Adaeze says she cannot start the ventilation layout until one of them gives way, and Rafael asks who decides. Nobody knows. Solberg, passing the table, does not settle it. 'You need a rule for this,' he says, 'before you need it again. Write down who decides what, and what happens when you disagree.'

Roles in an integrated team

Every member of an integrated team brings a discipline, and with it a set of responsibilities that do not disappear because the team works together. The architect is responsible for the building's overall design and its coordination, for the plans, sections and elevations, for life safety and accessibility in the layout, and for the envelope's design. The structural engineer is responsible for the gravity and lateral systems and the foundations. The mechanical engineer is responsible for heating, cooling, ventilation and plumbing, and often for the energy model. The electrical engineer is responsible for power, lighting, communications and fire alarm. The civil engineer is responsible for the site: grading, stormwater, utilities, driveways and the work in the street. On a real project a fire protection engineer, a code consultant, a cost consultant, an envelope consultant and others would join them.

In practice each discipline also has a person of record: the licensed professional who seals the drawings and takes legal responsibility for them. Integration does not change this. A structural engineer who agrees in the big room to a grid that suits the clinic is still responsible for the structure that results. 'Collaboration is not a way of sharing liability for your own work,' Qureshi tells the engineering students. 'It is a way of making your own work better by knowing more about everyone else's.'

Integrated teams also need roles that do not belong to a discipline. Someone must keep the decision log and the schedule. Someone must manage the shared model: set up the coordinates and levels, define how files are named and exchanged, and run the clash checks. Someone must keep the budget and know at every stage whether the design is inside it. On a real project these roles are filled by a project manager, a BIM manager and a cost consultant; in the studio, the team must assign them to its members, and Ingrid's team decides that she will keep the log, Hamid the model coordination, and Tomasz the cost inputs for Okafor.

Responsible, accountable, consulted, informed

A common way to set out who does what is a responsibility matrix, often called a RACI chart after its four roles. For each deliverable, one person is accountable: they own the result and make the final call. One or more people are responsible: they do the work. Others are consulted before the decision and give advice. Others still are informed of the result. The most important rule is that each deliverable has exactly one accountable person. Two accountable people means two people who can each say no, and a deliverable with nobody accountable is a deliverable nobody will finish.

Ingrid's team draws its matrix in the second session and checks it with a short script. The script counts the accountable people for each deliverable, finds any deliverable that nobody is doing, and adds up a rough load for each member: three points for being accountable, two for being responsible, one for being consulted.

# Who is responsible (R), accountable (A), consulted (C) and informed (I) for each deliverable
team = ["Ingrid", "Tomasz", "Adaeze", "Rafael", "Hamid"]
raci = {
    "massing and plans":         "A R C C C",
    "structural scheme":         "C A C I C",
    "lateral system and cores":  "C A C I I",
    "mechanical scheme":         "C C A C I",
    "electrical service":        "I I C A I",
    "site, curb and stormwater": "C I I C A",
    "energy model":              "C I A R I",
    "envelope":                  "A C R I I",
    "cost plan inputs":          "A R R R R",
    "code analysis":             "A C C C C",
    "clash review":              "R R R R A",
    "final boards":              "A R R R R",
}
problems = []
load = {p: 0 for p in team}
for task, row in raci.items():
    codes = row.split()
    if codes.count("A") != 1:
        problems.append(f"{task}: {codes.count('A')} people accountable")
    if "R" not in codes and "A" not in codes:
        problems.append(f"{task}: nobody doing the work")
    for p, c in zip(team, codes):
        load[p] += {"A": 3, "R": 2, "C": 1, "I": 0}[c]
print("load points (A = 3, R = 2, C = 1):")
for p in team:
    print(f"  {p:<7} {load[p]:3d} " + "#" * load[p])
print("problems:", "; ".join(problems) if problems else "none")

load points (A = 3, R = 2, C = 1):
  Ingrid   22 ######################
  Tomasz   17 #################
  Adaeze   19 ###################
  Rafael   15 ###############
  Hamid    13 #############
problems: none

The check finds no errors, but the load shows a problem the letters hide. Ingrid has the heaviest load, because she is accountable for the massing, the envelope, the cost plan inputs, the code analysis and the final boards. Hamid has the lightest, because the site is small. The team rebalances: Hamid takes on the clash review as accountable, which suits his role as model coordinator, and Adaeze, who is already responsible for the envelope's energy performance, agrees to take the lead on the envelope's thermal design, with Ingrid consulted on its appearance. The matrix is a living document, and Solberg asks the teams to revise it at every major review.

How decisions are made

A matrix says who decides each deliverable, but many decisions cross deliverables. The grid argument is one: it belongs to both the clinic plan and the structural scheme. For these, the team needs a decision rule. Some integrated teams decide by consensus, in which everyone must be able to live with the result; some by consent, in which a decision stands unless someone has a reasoned objection; some by the accountable person after consultation. Many use a combination, with a rule for escalation when the team is stuck.

Solberg suggests a rule that comes from the integrated projects he has led. Decisions are made in the big room, by consent, against the agreed targets and the brief. Anyone who objects must say which target the decision harms, and offer an alternative. If the team cannot reach consent in one session, the question goes to a short study by the people most affected, who bring two or three options with their effects on the targets to the next session. If that still fails, the decision goes to the owners, who decide. 'The owners hate being asked,' he says, 'so the rule works mostly because nobody wants to use the last step.'

Ingrid's team adopts the rule and uses it immediately. The grid question goes to a study by Ingrid and Tomasz, with Adaeze consulted, and they bring three options to the next session: the tower grid carried down through the clinic, the clinic grid carried up through the tower, and two grids with a transfer between them. Lesson five follows what they found.

The contract behind the team

On a real integrated project the roles and the decision rules are written into the contract. In a traditional arrangement the owner signs one contract with the architect, who signs subcontracts with the engineers, and another contract with the builder. Each party's duties run to the party it signed with, and disputes between the designers and the builder go through the owner. Integrated project delivery replaces these separate contracts with one agreement signed by all the key parties.

In Canada, the standard form is CCDC 30, the Integrated Project Delivery Contract, first published by the Canadian Construction Documents Committee in 2018 and revised in 2025. It brings the owner, the consultant, the contractor and, where appropriate, key trade contractors and suppliers into one agreement from the start of the project. Key decisions are made jointly. The parties share a pool of profit and loss tied to the project's outcome, and they waive claims against one another for errors, so that problems are solved rather than assigned. The 2025 revision divides the contract into a validation phase, in which the team confirms that the project can meet the owner's goals within the budget, and an execution phase, requires lean tools and a shared big room, renames the risk pool a profit pool, and adds a milestone for takeover before the warranty period.

Solberg emphasizes the principle rather than the clauses. When the profit of every party depends on the outcome of the whole project, each party has a reason to help the others succeed. When the parties waive claims against one another, they have less reason to keep the defensive paper trail that slows traditional projects. Neither works without trust, and trust is built by the behaviour the contract asks for: open books, shared models, joint decisions. A contract cannot create a team, he says, but it can stop a team from being broken by its own paperwork.

The studio cannot sign a real contract, but each team writes a one-page team charter modelled on the principles: the shared goals, the targets, the decision rule, the roles, how the team will meet and exchange files, and how it will handle a member who falls behind. Rafael asks why they need the last item. Qureshi answers that every team she has ever been on needed it at least once.

Communication

The team agrees a few working rules for communication. Questions that need an answer within a day go in the team's message channel; questions that need a decision go on the agenda for the next big room; nothing that changes another person's work is decided in a private conversation and announced later. Model files are exchanged on a shared platform, with each discipline publishing its model on Wednesday evening for the Thursday session. The team agrees to use one set of levels and grid names, one coordinate system and one file-naming convention, following the information management approach the students learned in their BIM course, based on ISO 19650.

Qureshi warns about a failure she sees often in student teams. The engineering students are used to working on a fixed problem and producing a correct answer; the architecture students are used to keeping problems open as long as possible. In an integrated team, both habits cause trouble. Engineers who wait for a fixed design have nothing to say in the early weeks, and architects who keep everything open leave the engineers nothing to design. The cure is to agree, at each session, which questions are being closed this week and which are deliberately left open, and why.

Exercise 2: the team charter

• Write a responsibility matrix for at least ten deliverables, with exactly one accountable person for each, and check the load on each member.
• Agree a decision rule, including how to escalate a question the team cannot resolve.
• Write a one-page team charter: goals, targets, decision rule, roles, meetings, file exchange and how you will handle a member who falls behind.
• Assign the cross-cutting roles: decision log, model coordination and cost inputs.

Self-check

• Does every deliverable have exactly one accountable person?
• Does every member of the team know what they must bring to the next big room?
• Could a new member of the team understand your charter without asking you?

At the end of the session, Ingrid reads the charter aloud and each member signs it. Hamid suggests one more line, which the team adds: 'If you change something that affects someone else, tell them before you tell the big room.' Qureshi, reading it later, says it is the most useful line in the charter.