Lesson 10.1Lesson 10.1 · Doing BIM Well
The BIM Roles: Manager, Coordinator, Modeller
BIM is done by people in defined roles — here is who does what, and why the titles matter less than the responsibilities
BIM doesn't happen because software is installed. It happens because specific people take specific responsibilities.
Back in Module 1 we said BIM stands on three legs — model, process, people — and that most failures come from buying one leg and skipping the other two. This module is about the third leg made concrete: the roles that actually carry the work.
Here is the trap to avoid from the first sentence: a role is a responsibility, not a job title. On a large project 'BIM Manager' is a full-time post; on a small one, the same responsibilities sit on the architect's shoulders alongside everything else. The titles vary by country, by firm, by the standard being followed. What does *not* vary is the set of responsibilities that must be held by *someone*, clearly, or the information falls through the gaps. So learn the responsibilities first, and treat the titles as labels the industry happens to hang on them.
Don't hire a title. Hire the responsibility — and make sure, on every project, big or small, that every duty has a name next to it.
The three parties: who asks, who leads, who produces
ISO 19650 (Module 5) describes the collaboration as a chain of appointments, and gives the parties deliberately plain names. The appointing party is the client — the one who commissions the work and, crucially, states what information they need and why (the EIR). The lead appointed party is whoever the client appoints to coordinate delivery — often the main contractor or lead consultant — responsible for pulling the whole team's information together to a managed process and handing it back. Beneath them, each appointed party runs one or more task teams — a discipline (architecture, structure, MEP) producing its own model and information.
Notice the shape: it mirrors how construction has always been organised — a client, a lead, and specialist teams — but ISO 19650 makes the *information* responsibilities explicit at each level. The client doesn't just want a building; they must state what information they'll need to operate it. The lead doesn't just coordinate trades; they coordinate the flow of information. Each task team doesn't just build their part; they produce their information to the agreed standard and deliver it into the shared environment. The roles are old; naming the information duty at each is what BIM adds.
The practical roles: manager, coordinator, modeller
Inside that structure sit the hands-on roles most people mean when they say 'BIM roles'. The BIM (or information) manager governs the method: they own the BEP, set and enforce the standards and naming, run the Common Data Environment, and make sure information is produced, checked and exchanged to the plan. They are the referee, not a modeller — their product is a trustworthy process. The BIM coordinator works at the model face: they federate the discipline models, run clash detection, chair coordination meetings, and drive the resolution of issues (the BCF loop from Module 4). One level down, the modellers — architects, engineers, technicians — actually author the model: they place the objects, attach the data, and produce the views. And a role easy to forget: every discipline lead remains responsible for the *correctness* of their own model's content — BIM doesn't move design responsibility to a 'BIM person'.
The distinction that trips people up is manager versus coordinator. Roughly: the manager governs the information process (standards, CDE, BEP, delivery); the coordinator governs the geometry and its clashes (federation, clash detection, issue resolution). On a big project they're different people, sometimes whole teams; on a small one, one person, or the design lead, wears both. The responsibilities don't disappear when the titles merge — they just pile onto fewer shoulders.
The BIM manager keeps the information honest. The coordinator keeps the geometry from colliding. The modeller makes the thing. Someone must hold each duty — even if it's all the same tired person.
Titles vary; the responsibilities don't — and skills matter more than software
Two honest cautions. First, the titles are not standardised — 'BIM Manager', 'Information Manager', 'BIM Lead', 'Digital Delivery Manager', 'VDC Coordinator' overlap and blur, and a job advert's title tells you less than its listed responsibilities. Don't argue about labels; ask what the person is actually accountable for. Second, and more important for India and every developing market (Module 9): these roles are about skill and method, not button-pushing. A good BIM coordinator's value is in understanding how disciplines interact and how to resolve conflict, not in operating clash-detection software; a good BIM manager's value is in governing information, not in knowing menu commands. This is exactly why the skills gap is such a stubborn barrier — you can buy the software in an afternoon, but growing people who understand the *method* takes years.
Which returns us to the whole course's spine. BIM done well is not a tool operated by a technician; it is a discipline practised by skilled people in clear roles. Get the roles clear — even if one person holds several — and the information flows. Leave them vague, assume 'the BIM person will handle it', and the responsibilities fall between the cracks. The org chart is not paperwork; on a BIM project it is the plumbing through which the information runs.
Assign each duty to a role — then reveal
Whose duty is it? Assign each responsibility to a role — then reveal.
Pick a role, then tap the duties it owns
On a large project these roles are different people or whole teams. On a small one, the manager, coordinator and modeller duties fold onto one or two people — but every duty must still be held by someone, or the information falls through the gaps. A role is a responsibility, not a title.
Three altitudes on the same idea
Read the band that fits you — or all three.
Learn the roles as responsibilities, not titles. ISO 19650's three parties: the appointing party (client — states what information they need), the lead appointed party (coordinates the whole team's delivery), and the task teams (each discipline, producing its own information to the standard). Inside that: the BIM/information manager (governs the process — BEP, standards, CDE, delivery), the BIM coordinator (federates models, runs clash detection, drives issue resolution), and the modellers (author the model — place objects, attach data). Key idea: a role is a duty someone must hold, not a job title — on a small project one person wears several hats, but the responsibilities can't disappear. And these are skill-and-method roles, not software-operator jobs.
Know which hat you're wearing, and make sure every duty has an owner. The distinction that matters day-to-day: the BIM manager governs the *information process* (standards, naming, CDE, BEP, checked delivery); the BIM coordinator governs the *geometry and its clashes* (federation, clash detection, BCF issue loop, coordination meetings); the modellers author content; and every discipline lead stays responsible for their own model's correctness — BIM doesn't offload design responsibility onto 'a BIM person'. On a small job these merge onto one or two people; the trap is assuming a merged role means a dropped duty. Before a project starts, check that someone — named — owns each responsibility. And remember the value is in the method (understanding how disciplines interact, how to govern information), not in operating the software.
Design the role structure to the project, and invest in the scarce thing — skilled people. Match the roles to scale: a large project justifies a dedicated information manager and a coordination team; a small one folds those duties onto the design lead — but in both, make the responsibilities explicit (ideally in the BEP, lesson 10.2) so nothing falls between the appointing party, the lead, and the task teams. Resist two failure modes: treating 'BIM' as a technician's job bolted on at the end (it's a method that shapes the whole delivery), and letting titles substitute for accountability (a 'BIM Manager' title with no authority over standards or the CDE is theatre). The binding constraint, especially in India and developing markets, is people who understand the method — not software licences; growing and retaining that skill is the real adoption investment, because the roles are only as good as the competence filling them.
“The 'BIM Manager' or 'BIM person' is responsible for the BIM — everyone else just does their normal work.”
Do it yourself
Map the roles onto a real project — first a big one, then a small one — and watch the titles collapse while the duties stay.
- 1Take a large project: a hospital with an architect, structural engineer, MEP consultant, a main contractor and a client who will operate it. Assign each ISO 19650 party: who is the appointing party, the lead appointed party, and the task teams?
- 2Now place the practical roles: who is the BIM/information manager (governs standards, CDE, delivery)? Who is the BIM coordinator (federates, runs clashes)? Who are the modellers? On a project this size, note how these are likely different people or whole teams.
- 3Take a small project: a single architect designing a house with one structural consultant. Assign the *same* responsibilities again. Notice how the manager and coordinator duties both land on the architect — the titles vanish, but the duties (set the standard, check the model, coordinate the two disciplines) remain.
- 4Finally, for the small project, name one responsibility that is easiest to silently drop when one tired person holds every role — and how you'd make sure it still gets done. (Often: independent checking of the model's quality, because self-checking is weak. This is where a lightweight BEP earns its keep.)
The one line to carry out
If the roles say who is responsible, the document that says how they'll actually work together — standards, formats, milestones, who delivers what and when — is the BIM Execution Plan. Next: writing one that a team will actually use.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →