New DMs are typically thrown into complex capital projects with minimal structural guidance beyond "coordinate the design team." Experienced DMs develop their own methods through trial and error over years of projects, but that knowledge rarely gets systematized, and it rarely gets transferred. The result is that every project reinvents design management from scratch, quality is inconsistent, and delivery depends on whether the particular DM assigned to a project happens to have the right experience for that project's specific failure modes.
That is not a people problem. The DMs working in the industry are generally skilled and dedicated. It is a systems problem: the role lacks the codified frameworks that other high-stakes professional functions take for granted. A structural engineer at an EOR firm has design standards, calculation templates, peer review procedures, and a defined methodology for every deliverable. A DM at the same firm has a job description and whatever processes they developed at their last job.
The argument here is that design management, like structural engineering, admits of systematic practice. There are specific things a DM should be doing across eight domains, in specific sequences, with specific tools and checkpoints. When those things are done well and consistently, projects deliver on scope, schedule, and budget at rates that have nothing to do with luck or heroics.
Requirements, constraints, and inputs is the foundation. Business objectives, spatial programs, utility tie-in constraints, regulatory prerequisites, owner-furnished equipment specifications - these must be documented systematically before design begins, not discovered mid-execution when they generate change orders. Getting this domain right makes every subsequent domain easier. Neglecting it generates scope disputes from month one.
Scope management is where DMs most commonly lose control. Total scope definition, package boundaries, explicit exclusions, interface definitions between packages and disciplines, and a rigorous change control process. Scope that drifts without documentation is scope that generates cost and schedule surprises that feel, to the owner, like DM incompetence - even when the technical work is excellent.
Schedule management means integrating design activities with permitting timelines, long-lead equipment delivery windows, and construction sequencing needs. A design schedule that exists in isolation from the construction schedule is not a design schedule, it is a list of dates. The DM's job is to make design a pull system for construction, not a push system that releases drawings when the engineers are ready.
Budget and cost requires the DM to understand the cost implications of design decisions in real time, not at project close. Value engineering is most effective when it happens during schematic design, not during bid phase when changing a structural system means reissuing a package that took six months to produce. The DM needs cost awareness, not just technical awareness.
Resource planning is consistently underinvested. DMs inherit a staffing plan written during the proposal phase based on a ROM-level scope and then spend the project trying to right-size it against reality. The discipline engineering leads who show up two weeks late because the staffing pipeline was not managed, the specialist consultant whose contract was not executed before the deliverable was due, the senior engineer who is 80% allocated to another project - these are resource planning failures, not scope or schedule failures, and they cascade into both.
Construction administration is the ultimate measure of design management quality. RFI response time, submittal review turnaround, bid package completeness, field issue resolution speed - these are the metrics that the GC and CM actually care about. A DM who produces technically excellent drawings that arrive late, generate excessive RFIs, and take three weeks to respond to field questions will be rated poorly regardless of design quality. The design team serves construction. That orientation has to be active, not nominal.
Design administration and controls is the domain of tracking: open actions from coordination meetings, pending decisions that are holding downstream deliverables, change log status, deliverable schedule against actual, risk register currency. The DMs who do this well run lists. The DMs who do not run lists spend their time rediscovering what they already knew but did not record, and things fall through cracks that then have to be reconstructed under schedule pressure.
Process improvement is the domain most frequently deprioritized because it has no immediate deliverable attached to it. Capturing lessons from each project phase before the team rotates, standardizing tools that worked so they can be reused, contributing to organizational knowledge so the next DM on the next project does not solve the same problem from scratch - this is how organizations get better. It requires deliberate allocation of time that is always competing with delivery pressure.
Design managers are the mortar between disciplines, contracts, and execution. When that mortar is strong, projects hold together under pressure. When it is not, the cracks show up in the field.
Good DMs keep things moving and respond to issues. Great DMs anticipate what the issues will be before they arise and have already put the structural conditions in place to handle them. That distinction is almost entirely about systems.
A great DM enters a project with a requirements capture process, not just a requirements document template. They run the first interface coordination meeting in week two, not week eight when the interface conflicts are already drawn into the packages. They have a standing agenda for weekly coordination meetings that forces systematic coverage of all open items rather than discussion of whatever is loudest that week. They track every decision in a log that includes the alternatives considered and the reasoning for the choice - because three months later, when the downstream impact of that decision is being disputed, the log is what resolves the dispute.
These practices are learnable. They are not personality traits that some DMs have and others do not. A DM who runs lists and builds coordination processes will outperform a more technically brilliant DM who works from memory and manages by presence - especially as project complexity scales past what any individual can hold in working memory.
BESS facilities, gigafactories, and advanced manufacturing plants are a different animal than the industrial projects that established most EPC firms' institutional knowledge. The design interfaces are more complex - integrating civil, structural, mechanical, electrical, process control, and specialty systems that did not exist in the same combination ten years ago. The schedule pressure is more intense - market windows are short and owner financing assumptions depend on specific COD dates. The regulatory environment is less settled - AHJ interpretations for novel facility types require active management, not passive compliance.
The DM who succeeds on a 150MW BESS project or a cell-to-pack assembly facility is doing something materially harder than the DM who succeeded on a conventional industrial building five years ago. The eight domains are the same. The execution demands within each domain are higher. That argues for more systematic practice, not less - and for organizational investment in building DM capability at scale, not just finding the right individual for each project and hoping they have the right background.