PERSPECTIVE 001
Your PM problem is probably not a PM PROBLEM.
When capable project managers develop their own ways of working, inconsistency may reveal less about the individuals than about the firm around them.
By Aaron D. Jenks, AIA, NCARB, LEED AP Founder, Schemata AEC L.L.C.
AUGUST 18, 2026 | 10-MINUTE READ
I have spent most of my career inside architecture, engineering and construction firms, and project management has probably generated more internal discussion than almost any other part of practice. Firms invest a great deal of time trying to improve it. They train project managers, revise procedures, introduce new software, change reporting formats, create templates and occasionally reorganize entire groups around the belief that project delivery needs to become more consistent.
Having participated in many of those efforts myself, what stayed with me was how often the same frustrations returned after everyone believed the problem had been addressed. A different project would run over budget, another team would become frustrated or another project manager would struggle with an issue remarkably similar to something discussed a year or two earlier.
For a long time, the obvious question was how to make the project managers better. I still think that is a legitimate question, but I have become much more interested in what the inconsistency is telling us about the firm around them.
One pattern in particular has become difficult for me to ignore. Without a clear, practical and usable way to structure and manage their work, project managers naturally fill in the gaps themselves. They have no real choice. Projects have to start, teams need direction, clients expect answers, and someone has to determine how the fee, schedule, staffing, communication and decision-making will actually work.
Experience usually fills the void. Someone who spent ten years at another company may bring pieces of that firm’s process with them. A long-tenured employee may continue using a method that worked well when the current firm was half its size. Another PM builds a spreadsheet that has evolved over several years and makes perfect sense to them, while someone else relies heavily on the project-management software or keeps much of the project structure in email, meeting notes and personal habits developed over the course of a career.
Many of those approaches may work very well for the individual PM. The problem becomes visible when several capable people inside the same firm are effectively running several different versions of project delivery.
001
The project team sees the inconsistency first.
Leadership often notices inconsistent project management when a fee is in trouble, a client becomes frustrated or a deadline is missed. The project team usually experiences it much earlier.
An architect working on three projects may encounter three different expectations depending on who is managing each one. One PM begins with a detailed kickoff and clearly defines responsibilities, while another assumes an experienced team already understands what needs to happen. Financial performance may be reviewed weekly on one project and monthly on another. Decisions may be documented in a central location, email, Teams, handwritten notes or whatever has worked for that PM in the past.
Good professionals become remarkably adept at navigating those differences. They learn how each PM operates, where information is kept, how decisions are made and when they have enough authority to move forward without asking permission. Eventually, people begin asking questions such as, “How does this PM like to run their projects?” or “Where does she want us to put this?” or “Does he want to review this before it goes to the client?”
Those questions sound harmless. I have come to see them as useful information because they reveal that part of the team’s energy is being spent learning how to work inside the firm rather than simply doing the work.
The cost rarely appears as a clean line item in a financial report. It accumulates in small pieces when someone prepares information twice, waits for direction that another person assumed was obvious, works from an outdated decision or spends an hour locating information because each project stores it differently. Any one of those events is manageable; hundreds of them across multiple projects begin to matter.
Some of that friction eventually appears in the project fee, schedule or quality. Quite a bit of it appears in the way people feel about working inside the organization. Talented people become frustrated when straightforward work feels harder than it needs to be, while younger staff struggle to develop good habits when the definition of a well-run project changes depending on who happens to be managing it.
The project still gets completed, which can create the impression that the system worked. From the team’s perspective, however, they may have spent an extraordinary amount of time compensating for the fact that there really was not one system.
This does not mean the PM is never the problem.
There are project managers who need more development, and there are people who simply are not well suited to the role. Architecture and engineering firms have a long history of promoting technically talented people into management because it appears to be the next logical step in their career, even though being an excellent architect or engineer does not automatically make someone a strong project manager.
Experience or coaching may be enough for some. Others may need a role that better fits their strengths. Firms hurt themselves when they avoid those conversations because confronting an individual performance issue is uncomfortable.
Examining the organization does not excuse individual accountability. A firm should expect its project managers to perform well while also being willing to consider whether it has created a reasonable environment for them to do so. If one PM struggles inside an otherwise clear and consistent system, leadership may have a people problem. If five competent PMs are all operating differently because the firm has never made the expected way of working clear enough to use, that is a different problem.
Changing one person will not correct it. The next PM will inherit the same ambiguity and eventually fill the gaps in whatever way makes sense to them.
“If five competent PMs are all operating differently because the firm has never made the expected way of working clear enough to use, that is the real problem.”
Procedures have to be useful enough to replace old habits
I believe firms need project-delivery standards, but I have also seen what happens when the solution becomes a complicated manual that nobody wants to use. A procedure creates consistency only when it is easier and more useful than the alternative.
Professional-service firms can produce processes that are technically complete and practically unusable. Every possible condition gets documented, every exception gets addressed, and the result becomes something people reference during training and quietly abandon when the real project starts. A PM who already knows one workable method has little incentive to replace it with something cumbersome, unclear or disconnected from the work.
The better question is whether the firm has been clear about the relatively small number of things that should not need to be reinvented on every project.
How does a project begin? How is the fee translated into a work plan? Who establishes roles and responsibilities? Where do critical decisions live? How frequently should financial performance be reviewed? How are scope changes recognized and addressed? What authority does the PM have, and when does a decision move to a principal?
These are basic operating questions, which is exactly why they deserve attention.
The visible problem may be pointing somewhere else
Project delivery does not operate separately from the rest of an AEC firm. What happens on a project is influenced by decisions made long before the project team begins working.
A fee that was too aggressive or not aggressive enough during business development eventually becomes a delivery problem. Staffing practices that leave PMs competing for the same people eventually become a delivery problem. The same is true of unclear authority, principals making client commitments outside the project-management structure and financial information that arrives too late to influence the work.
By the time leadership sees the issue in a project report, the underlying condition may have already moved through several parts of the organization.
Not every blown fee is evidence of a deeper organizational failure. Sometimes a project simply went badly, the team underestimated the effort, the client changed direction or a PM failed to do something they should have done. The useful part is learning to distinguish an isolated event from a recurring pattern.
Once something begins repeating across different people and projects, it deserves a stronger light. That requires seeing the firm accurately enough to understand what is actually happening, rather than assuming that the place where the problem became visible is where it began.
A procedure only creates consistency when it is easier and more useful than the alternative.
Alignment matters more than novelty
I do not think architecture and engineering firms need another person telling them that everything they have been doing is wrong, nor do I believe there is one new process that suddenly transforms a firm. Most firms already have many of the pieces they need: talented people, established processes, technology, financial information, leadership experience and years of institutional knowledge.
The weakness is often not the complete absence of a system. It is that the pieces developed at different times, for different reasons and under different leaders, and they no longer work together as well as everyone assumes they do.
A project-management procedure can be perfectly reasonable on its own but still fail if the PM does not have the authority the procedure assumes. Financial reporting can be accurate but ineffective if it arrives after the team has a realistic chance to change the outcome. A staffing process may work from an enterprise perspective while creating constant instability at the project level. Leadership can say it wants consistent delivery while rewarding individual principals for behavior that works against it.
Addressing those conditions does not require a revolutionary new idea. It requires someone to look across the firm, identify where the pieces are no longer working together and decide what should be strengthened, simplified, clarified or brought back into alignment.
What I would ask now
For years, I heard firms ask some version of the same question: How do we get our project managers to manage projects more consistently? I asked it myself plenty of times, and I still think it is a fair question.
Today, however, I would begin by asking whether the firm has made it reasonably easy for good project managers to be consistent in the areas that matter.
I would want to know whether the basic project structure is clear, whether financial information supports timely decisions, whether staffing practices reinforce the way projects are expected to operate, whether the PM’s authority matches the accountability placed on the role and whether the firm’s stated procedures resemble what actually happens once the project begins.
If those pieces are aligned and an individual still cannot perform, leadership has a much clearer basis for addressing the person. If they are not aligned, training or replacing the PM may simply move the visible problem without strengthening the organization underneath it.
The goal is not to make every PM identical. Good project managers will always bring different personalities, strengths, judgment and leadership styles to their work, and those differences can be a tremendous asset. The fundamentals of the firm simply need to be strong enough that every project team does not have to rediscover them.
The more I have thought about this, the less interested I have become in finding a new answer to project management and the more interested I have become in understanding what the recurring problem is trying to tell us.
Very often, the organization already contains most of the answer. Leadership needs a clearer view of where the weaknesses are, which conditions are creating unnecessary friction and which existing processes need to be brought back into alignment.
That is the kind of work I believe is worth doing.
Schemata helps AEC leaders examine recurring organizational problems, understand the conditions behind them and determine what should be strengthened, simplified, clarified or brought back into alignment.
Aaron Jenks, AIA, NCARB
Schemata AEC L.L.C.