Before the program architecture step, a cross-functional initiative exists as a collection of separate workstreams where each function knows its own scope but nobody has a view of the program as a system. The architecture step produces a set of artifacts that show the program’s structure, ownership, dependencies, and governance in a single integrated view for the first time.
What the Architecture Step Produces
The primary output is a functional integration map: a view of how the program’s workstreams relate to each other, which ones run in parallel, which ones are sequential, where the handoffs happen, and which teams share dependencies. The integration map sits between an org chart and a Gantt chart; it shows how the work connects across functions. When the R&D leadership team sees that their clinical program milestones have four dependencies on Manufacturing’s capacity allocation decisions, two of them on the critical path, the conversation about coordinating timelines becomes concrete.
The remaining outputs round out the structural picture:
- Workstream definitions with explicit boundaries. Each workstream gets a defined scope: what it owns and where its boundary meets another workstream’s. Most cross-functional programs have gaps (i.e., work that falls between two workstreams and nobody owns) and overlaps (i.e., work that two workstreams both believe they own). The architecture step surfaces both.
- A governance model. Who makes decisions about what, and when two workstreams disagree on a dependency, who resolves it? What decisions require the executive sponsor versus what can be made at the workstream level? These questions are invisible until the architecture makes them explicit, and they determine whether execution runs smoothly or becomes a series of escalations.
What the Architecture Makes Visible
The architecture step is the first point in the engagement where the program’s real complexity becomes visible. Some workstreams discover they’re on the critical path and carry more risk than they realized. Others discover that a dependency they’d been treating as someone else’s problem is a shared constraint that requires joint planning.
The governance model surfaces a different kind of tension. Making decision authority explicit means some leaders have less authority than they assumed and some have more. A disease area head who believed they could make unilateral decisions about their pipeline timeline discovers that their manufacturing capacity is a dependency for two other disease areas, and changes require cross-program coordination. That’s a constraint the architecture made visible, not one it created.
How the Architecture Gets Built
The architecture is co-created in a session where the key stakeholders are in the room. We bring a draft structure based on intake and stakeholder mapping interviews (i.e., the 30% scaffolding), and the room pressure-tests, adjusts, and finalizes it. In one engagement, stakeholder interviews surfaced three shared dependencies that nobody had mapped.
The co-creation matters because the architecture needs to reflect how the organization actually works. We can propose workstream boundaries, but only the people in the room know that the oncology and rare disease programs share a regulatory affairs team that can’t be split across two disease areas, or that the CFO needs to sign off on any scope change that affects the pipeline investment portfolio. The room brings the institutional knowledge that makes the architecture executable.
What Changes After the Architecture Is Visible
The most immediate change is the quality of planning conversations. Before the architecture, planning discussions are abstract: “we need to align on timeline.” After the architecture, they’re specific: “your workstream’s March milestone depends on our February deliverable, and our February deliverable has a resource constraint. How do we solve this?”
The architecture also changes how the program gets governed. With dependencies mapped and decision authority defined, the steering committee can spend its time on decisions that require executive authority instead of on status updates and escalation management.
The program architecture doesn’t guarantee smooth execution, but it guarantees the program’s structural risks are visible before execution starts, and that the organization has a framework for addressing them. The pre-mortem will later force the team to design around those risks, and each step’s connection to the next is what makes the methodology hold together.
