What’s in a Project Manager?

Last week, I was organising my thoughts around a lesson for a client, and the lesson was aimed at Project Managers, so it had a little bit on what does it mean to manage a BIM project and a little bit of practical insight on how to browse an information model to autonomously extract the information you might need. It was just an introduction, but it was fun enough.

At some point during the preparation, I caught myself working around a concept that I then amended it, included it and deleted it again, and eventually kept, and it was something along the lines of: “your job is not to model.” It sounds almost offensive when you say it out loud to a room full of experienced professionals. But the more I work in this industry, particularly after BIM, the more I become convinced it is amongst the most useful thing I can tell a group of project managers.

So this week let’s try to unpack that sentence properly. It’s addressed to two different people:

• the Project Manager who is still elbow-deep in the design, often a senior designer who became a PM and isn’t quite sure what that means for their identity;
• and the BIM Manager who has to make this work in practice without making people miserable or starting a small civil war in the office.

1. The AutoCAD Hangover

There’s a generation of project managers in architecture and design firms — and I say this with full respect, because I’ve worked with many of them and they are often extremely talented — who learned to manage projects on the field, in the AutoCAD era. And in the AutoCAD era, jumping in to lend a hand and fix a drawing was fine. It was normal. It was even expected. The PM would sit down, open the file, clean up a detail, redraw a section, fix the hatching, copy the floor plan on the side to draft up an alternative solutution, save the file, and life went on.

Thing is, back in those days the barrier to entry was extremely low. Though AutoCAD can be complex if used right, it is and remains a drafting tool and it’s fundamentally about placing lines, arcs, and text on a canvas. The cognitive model is direct and spatial, close to hand-drafting. You could pick it up reasonably quickly, and — crucially — you could dip in and out of it without destabilising anything major. Two people could work on the same set of drawings, in separate files, with relatively predictable results. Version control was manual, chaotic, and occasionally terrifying, but the damage any one person could do by editing a file was usually limited to some stuff popping up on the side of an X-ref.

BIM doesn’t allow for this, and information modelling is a fundamentally different kind of work.

When you model in Revit, ALLPLAN or in any other serious BIM authoring tool, you are not placing lines: you’re required to place objects that carry parametric intelligence, that belong to classes with defined behaviours, that sit inside a shared model with a coordination structure, that feed into schedules and quantity take-offs and clash detection routines, and that interact with every other element in the model in ways that are not always immediately visible. When you place a wall, that wall knows it’s a wall. When you insert a door, that door knows it belongs to that wall. When you tag a room, that tag is pulling live data from an object and not from text you typed. All that jazz.

This carries a fundamental truth: we didn’t invent the BIM specialist because there were loads of youngsters without a job; that specialist role had to be introduced (and upskilled from a regular designer) because the skills required to model correctly in BIM are significantly higher than the skills required to draft in AutoCAD. Not just technically higher: conceptually higher. A competent BIM specialist needs to understand how families work, make strategic parametric decisions, comply on how worksets or linked models are structured, how level constraints and offsets propagate through the building, what the naming and classification conventions are, and how their decisions downstream affect coordination. It takes time to build this competency. It’s not something you can fake by being fast with a mouse. You don’t inherit it from any skill you previously learned as a designer.

So, here’s the problem: if a Project Manager — however experienced, however talented — dips into the model to “quickly fix” something, the consequences are not contained. They might break a family parameter without noticing. They might override a constraint that was deliberately set by someone else. They might edit something in the wrong workset and not check it back in. They might simply not know what they don’t know, which is the most dangerous state of all.

In the AutoCAD era, the PM fixing a drawing was a shortcut, albeit an expensive one. In the BIM era, the PM fixing the model is a liability. And it doesn’t make sense to train them extensively into modelling because, well, they have a separate job and they’re supposed to do something else.

So, what is it that they’re supposed to be doing?

2. What Managing a BIM Project Actually Looks Like

If the PM’s job is not to model, what is it? To manage the project, of course, but what does that mean?

This is where a lot of people get confused, because the transition from “I design things” to “I make sure things get designed” is genuinely difficult, and it’s made more difficult by the fact that BIM adds a layer of process complexity that didn’t exist before.

Managing a BIM project means, at its core, managing of information is processed, produced, coordinated and shared. It means understanding what information needs to exist, when it needs to exist, in what form, and for whom. This is the logic behind the BIM Execution Plan, and it’s the logic that should drive the PM’s daily work. Not “how does this wall connect to that slab” but “do we have a shared understanding of what level of definition we need in this model phase, and are we on track to produce it?”

Concretely, this means that there’s a synergy to be created between the project manager and their BIM Coordinator, ’cause together their work needs to look a bit like this:

3. The Inconvenient truth: who’s your PM?

Here is a thing that is true in almost every architecture and design firm I have worked with: the Project Managers are, overwhelmingly, senior designers. They didn’t go to PM school, they didn’t read a textbook on information management unless they were really passionate about it: they became PMs because they were excellent at design, they accumulated years of experience, and at some point the firm needed someone to run projects and they were the obvious choice. They got the role as a reward for expertise, not as the result of a deliberate career pivot.

This is not a criticism: it’s a structural reality of how the industry works, and it produces PMs who bring deep design intuition to the role, which is genuinely valuable, the ability to read a drawing and immediately understand what’s wrong with it, the authority to make a design call without consulting three other people first. That’s not nothing. That’s actually quite a lot.

But it creates a tension, because the identity of a senior designer is built around the act of solving design problems directly, with your own hands (or your own mouse) and can’t do without the satisfaction of seeing your decisions materialise in a drawing, a model, a rendered image. That’s the feedback loop that built the career. And now, as a PM, they’re being asked to step away from it — to manage the process rather than execute it — and nobody has quite explained them what that means in practice or what the alternative feedback loop looks like.

So you keep wanting to step into the model, not because they’re being irresponsible or they’re control freaks, but because it feels like the natural thing to do, they’re genuinely good at design, and maybe because there’s a voice in the back of their head that says: “if I don’t do this, it won’t be done properly”.

That voice is understandable. That voice is also, in the BIM context, increasingly wrong. And the longer they listen to it, the more it costs them, and their team.

4. The Other Side of the Coin: not Losing the Designer in the Manager

So what do you do with a senior designer who has become a Project Manager and still has a head full of good design instincts? You don’t waste them. You redirect them.

The mistake firms make — and BIM Managers especially, when they’re trying to enforce proper process — is framing this as a binary: either you’re in the model or you’re out of the model, either you’re a designer or you’re a manager. That’s not a useful framing, and it tends to produce either non-compliance (the Project Manager who ignores the rule and models anyway, or sketches in CAD and drops the drawing to the team) or atrophy (the Project Manager who stops contributing design thinking altogether because nobody gave them a legitimate outlet for it).

The better framing is: how do we keep the design brain engaged without routing it through the model?

Here are some ideas to do exactly that.

Design review. There’s a big difference between sitting down and fixing a facade yourself, and sitting down with the designer, looking at the facade together, and articulating precisely what’s wrong with it and why. The second activity requires every bit as much design expertise as the first and arguably more, because you have to be able to explain your intuition rather than just act on it. It also produces a better outcome, because the designer learns something in the process. The PM’s design eye becomes a teaching instrument rather than a shorthand. It’s a bit like pair programming. We’ve seen it a couple of times.

Brief clarification and design intent documentation. Before a design decision reaches the model, someone has to translate the client’s requirements and the architect’s intent into something a modeller can actually act on. This is skilled work. It requires understanding what the client means when they say “more open feel” or “better natural light”, and translating that into spatial and technical language. It requires spotting the contradictions in a brief before they become contradictions in a model. A senior designer with good client communication skills is exceptionally well placed to do this, and it’s work that most firms do badly or not at all.

Chairing design coordination meetings. When you have a room full of technical specialists — structural, MEP, facade, interior — someone needs to guide the conversation with enough design intelligence to understand the implications of what’s being said. A Project Manager who’s also a great designer can do this in a way that a pure process manager cannot: they can hear a proposed structural solution and immediately understand whether it creates a problem for the spatial concept. That’s genuinely valuable, and it’s a legitimate use of design expertise in a management role.

Mentoring on design intent. Junior team members are often technically proficient in BIM but still developing design judgment. The senior Project Manager who can sit with them — not to model for them, but to help them understand why a particular design decision was made — is doing something that has long-term value for the firm. This is the transfer of design culture, not just technical skill, and it requires the kind of contextual knowledge that only comes from years of practice.

Quality gatekeeping at milestones. Before a model or drawing set is issued to a client or a contractor, someone needs to look at it with a designer’s eye and ask: is this good enough? Does it communicate clearly? Does it represent the design intent accurately? Is there anything that will make the client ask a question we should have answered already? This is a meaningful checkpoint, and it’s one that benefits from a Project Manager who still has strong design instincts.

None of these activities require opening Revit. All of them require the design intelligence that the PM spent years developing.

5. A Note to BIM Managers

If you’re a BIM Manager reading this, you probably recognise most of what I’ve described. You’ve seen the Project Manager who keeps touching the model, you’ve seen the damage it causes, and you’ve probably tried, at some point, to address it. Maybe diplomatically, maybe less so.

I want to offer you a reframe.

The conversation you need to have with your Project Managers is not primarily a conversation about BIM compliance, but about professional identity and role clarity. If you walk into that conversation with a list of rules and a tone that says you’re doing this wrong, you will get defensiveness. You will get the appearance of compliance and the reality of workarounds. You will not get change. If you walk in with a genuine acknowledgment that the PM’s design expertise is valuable, and a clear picture of where and how that expertise should be applied, you have a much better chance of getting someone on your side.

Practically, this means a few things.

First, make the role boundaries explicit and positive, not just prohibitive. It’s not enough to say “don’t model”. You need to be able to say “here is what your contribution to this project looks like, and here is why it’s important.” If you can’t articulate that clearly, the Project Manager will fill the gap with what they already know how to do.

Second, create legitimate touchpoints for design input. If the Project Manager has no structured opportunity to contribute design thinking into the modelling process, they will create unstructured ones, maybe by opening the model. Build design review sessions into the project rhythm if they aren’t already. Make them the named chair of design coordination. Give their expertise a formal home.

Third, invest in their BIM literacy without expecting BIM authoring. There’s a level of BIM understanding that a Project Manager genuinely needs: enough to read a model health dashboard, enough to understand what a Level of Information Need means in practice, enough to have an informed conversation with a client about what the model can and cannot tell them at a given stage. That’s not the same as modelling competence, and it can be developed through targeted, short interventions: a focused workshop, a practical session on navigating a model as a viewer, a walkthrough of the coordination process from the management side. This is, incidentally, exactly the kind of training I was preparing for that client last week, and the reason this whole line of thinking started.

Finally, be honest about the fact that this is a change management problem, not just a technical one. The resistance you’re encountering from Project Managers is the expression of a professional identity that hasn’t yet found its new form in a BIM environment. Your job — alongside process governance and model quality — is to help that identity evolve. That’s a more interesting job than policing worksets, and it’s ultimately more impactful.

6. What’s in a Project Manager, Then?

Shakespeare’s paraphrased question, applied to names, was about whether the label matters or whether the thing itself does. I’m inclined to think they both matter.

The Project Manager label, in architecture and design, carries a lot of historical baggage. It implies someone who has earned their stripes as a designer, someone who knows how things are made, someone you can trust with a client because they’ve spent years in the trenches. That’s not wrong. But the trenches have changed, and the way you demonstrate that trustworthiness and that expertise has to change with them.

A good Project Manager in a BIM environment is not someone who has stepped back from design, but someone who has stepped up into a broader responsibility for how information is created, managed, and used across a project. They’re still using everything they know about design. They’re just using it differently: to clarify, to review, to guide, to protect the quality of work that other people are executing.

That’s a harder role. It requires everything the designer knows, plus the ability to operate at the level of systems and process, to see the project whole, rather than any one of its parts.

The model doesn’t need another hand in it: it needs someone watching over the whole operation who knows what good looks like.

That’s what’s in a Project Manager.