On every manufacturing program I have worked on, the Design Manager title covers a wider range of actual responsibility than any job description captures. At the narrow end, a DM tracks submittals and manages the RFI log. At the broad end, she is the person who understands what Engineering has decided, what Procurement has committed, and what Construction can actually execute -- and who holds accountability for keeping those three in alignment as the program evolves.
The narrow version of the role produces good document management. The broad version produces a running program. The difference is not seniority -- it is whether the DM has been given, and has accepted, the mandate to operate across functional boundaries rather than within a single function's reporting structure.
When the DM role is configured narrowly, the integration gaps do not disappear. They fall to weekly coordination meetings, informal phone calls between discipline leads, and the program manager's judgment about which conflicts to escalate. The result is a program that runs on heroics rather than on a repeatable system. That works until the experienced individuals leave, or until program scale exceeds what heroics can manage.
The Design Manager does not control what Engineering designs. She does not control what vendors propose. She does not control what Procurement commits to or when equipment arrives. What she controls is the information flow between all of those parties -- and information flow, on a complex industrial program, is where schedule risk concentrates.
The specific levers the DM holds:
None of these levers require technical authority over design decisions. All of them require organizational authority to compel action from Engineering, Procurement, and Construction when information handoffs are not happening on the schedule the program requires.
The distinction between a DM Playbook and a DM Handbook is not semantic -- it reflects two different levels of design management documentation that a mature program organization needs.
The Handbook defines the environment. The Playbook defines the operator. A well-written Playbook without a Handbook produces individual competence inside an incoherent system. A Handbook without a Playbook produces documented governance that no one can operationalize.
The failure modes in design management are not random. They concentrate at specific structural points that are predictable across programs, regardless of the individuals involved.
Engineering deliverables have a stated issue date and a "for procurement" date that are often not the same, and often not well-coordinated. The "for procurement" designation means the design is sufficiently developed that Procurement can issue an RFQ or commit a PO -- not that the design is complete. When Engineering does not actively communicate what has changed since the "for procurement" issue, Procurement commits to specifications that may be superseded before the vendor submits drawings.
On a BESS program I worked on, 22% of vendor submittals received at least one revision request that traced to a specification change issued after the PO was placed. The average resolution time for those revisions was 19 days, against a submittal review target of 10. The design-procurement handoff timing was the single largest driver of submittal log backlog.
The most contentious design coordination issues arise at boundaries between disciplines: where the structural engineer's work ends and the mechanical engineer's begins, where the electrical single-line connects to the HVAC controls, where the civil grading plan meets the underground utilities design. Each engineer is responsible for her own scope. No engineer is explicitly responsible for the interface.
A Design Manager who does not explicitly own interface coordination will find that interfaces are managed informally, inconsistently, and late. The informal version of interface management is a field engineer noticing a conflict during a walkdown -- which is, on a fast-track program, the most expensive place to discover it.
On every program I have observed, the number of design changes documented as formal change orders understates the number of changes that actually occurred by a factor of at least two. The undocumented changes are not necessarily small. They are changes authorized informally, implemented by Engineering, and never propagated to Procurement or to the construction work package list.
The DM's change control function is not primarily about documentation discipline -- it is about ensuring that every change, once authorized, reaches all parties that need to act on it before they perform work against the superseded state.
If a Design Manager has only one instrument to manage a complex industrial program, it should be a well-maintained deliverable register -- a document that lists every Engineering output expected on the program, its scheduled issue date, its required state at issue (IFR, IFC, As-Built), the downstream activity it enables, and its current status.
The deliverable register is not a replacement for a Primavera P6 schedule. It is the Engineering-specific instrument that feeds the schedule. When the register is current and accurate, a program manager can determine in minutes which Engineering outputs are on the critical path, which are delayed, and which delays have downstream consequences. When the register does not exist, or exists in a state no one maintains, that analysis requires a series of conversations that each take days.
On programs using Aconex as the document management system, the deliverable register can be constructed from transmittal and document register records -- but only if those records are consistently maintained against a defined document numbering and categorization scheme from program start. Retrofitting document management discipline onto a program that has been running informally for six months is a weeks-long exercise.
The formal constructability review, where Construction personnel review Engineering drawings before IFC issue, is standard practice on well-run programs. It is also frequently inadequate as the sole mechanism for catching design-construction conflicts, because it is scheduled against a milestone that may be months away when the conflict first becomes detectable.
On fast-track programs where Engineering and Construction run concurrently, the question is not whether to do constructability reviews -- it is how to ensure that Construction has meaningful input into design decisions as they are being made, not only after Engineering considers the design complete. This requires the DM to create a standing forum where the field superintendent can raise questions about design direction before the design is locked.
The most effective version I have seen operates as a 30-minute standing weekly meeting between the lead structural engineer, the lead MEP coordinator, and the field superintendent -- with the DM present to log action items and track resolution. The agenda is the list of active RFIs, plus design issues the superintendent has flagged from the look-ahead plan. No formal presentation, no slides. A structured conversation that surfaces conflicts before they reach the field.
A Design Manager who does not read the Primavera P6 schedule with the same fluency as she reads Aconex is managing with incomplete information. The schedule tells her which Engineering activities are on the critical path, which milestones are at risk, and what the downstream consequences of a design delay will be on Procurement and Construction. Without that context, she is prioritizing workload by intuition rather than by impact.
This does not mean the DM needs to be a scheduler. It means she needs to understand what the schedule is telling her about the program's current risk posture, and translate that into prioritization decisions for her team. Which submittal reviews need to be compressed? Which design issues need escalation today rather than in the normal review cycle? Which vendor is about to miss a delivery milestone with no float against the critical path?
Document numbering schemes, file naming conventions, revision control protocols, and transmittal procedures are not bureaucratic overhead. They are the infrastructure that makes it possible to answer basic operational questions quickly: what is the current revision of drawing X, when was it issued, who reviewed it, and what changed from the prior revision?
On programs that lack consistent documentation standards, answering those questions requires manual investigation that can take hours. On programs with well-implemented standards, the answers are available in Aconex in seconds. The difference compounds over the life of the program as document volume grows.
The DM who installs documentation standards at program startup, and enforces them with enough consistency that they become habitual, is creating infrastructure that will save her hundreds of hours over the program's life. The DM who defers documentation discipline finds that retrofitting it is more expensive than doing it from the start.
The Design Manager who lasts on a complex industrial program is not the one who manages documents well. She is the one who manages the information that flows between Engineering, Procurement, and Construction -- and who can tell you, at any point, what the program actually knows and what it does not yet know.
One of the persistent structural problems in capital programs is that institutional knowledge -- the understanding of why specific decisions were made, what alternatives were considered, what constraints drove the design -- lives primarily in the heads of the people who were present. When those people move to the next program, the knowledge does not transfer. The next team starts the same investigations, makes some of the same mistakes, and re-learns lessons that were learned at cost on previous programs.
A Design Management Handbook, maintained as a living document across programs, is the mechanism for capturing that institutional knowledge in transferable form. Not just process documentation -- which captures what to do -- but the reasoning behind the process: why the deliverable register is structured the way it is, what happened on a prior program when it was not maintained, what the specific failure modes were and how they were addressed.
That kind of documentation is not written during a program. It is written after, by someone who was present and who has enough distance to assess what actually mattered. The DM who builds that habit is contributing to the organization's ability to run subsequent programs with less friction -- which is the compounding value of a genuine design management practice over a series of one-off projects.