Case studies

6 case studies. Field-tested.

Real engagements from the lateralworks team across semiconductor, hardware, and complex-systems programs. Names and sector-identifying details have been removed. New cases added regularly — check back.

PracticeAll Client Projects FTTM Coaching

© 2026 lateralworks Page 1 › › Case study AI-assisted macro planning How a chip-development team compressed multi-year program planning from weeks to hours, and how the team's iteration carried the output the rest of the way. FTTM methodology series. A case study from a semiconductor program. The team used a small set of AI tools and a deliberate iteration discipline to produce executive-grade planning artifacts in a fraction of the usual time. AI does about 80%. The team scrubs the rest. Prepared by lateralworks Case study Date May 2026 Rev 1.1 Online lateralworks.com FTTM series -- 1 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 2 Table of contents AI-assisted macro planning Abstract 03 01 The setup 04 02 The three-step flow 06 03 The iteration loop 10 Working principle: roughly right, fast 14 04 What the research says 15 05 What we learned 18 References 22 Core thesis. The model that works compresses about 80% of the synthesis work into hours and routes the remaining 20% (judgment, calibration, local context) through the team. The team is not validating the AI. The team is building the plan, and AI is helping it get there faster. -- 2 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 3 Overview Abstract Building a multi-year program plan used to take weeks of meetings and drafts and reviews. A cross-functional team would gather inputs from documents, transcripts, and emails, argue through the structure, iterate the artifacts by hand, and converge on a charter, a milestone matrix, and a detailed schedule. The cycle was painful and often produced something too rigid to revise. By the time the plan was published, parts of it were already stale. This paper is a case study from a semiconductor program that replaced that cycle with an AI-assisted three-step flow. A senior project manager fed source documents and meeting transcripts into a large language model and asked it to produce a milestone timeline, then a milestone matrix, then a macro schedule that could be imported into a project-management tool. Each step took hours. The team scrubbed and refined each draft, fed the corrections back into the next pass, and used the time saved to argue about the program instead of about the artifact. The first complete plan was on the table in three days. The conventional cycle would have taken three to four weeks. The case study documents the flow, the prompts that worked, the mistakes that surfaced, and the human disciplines that made the output trustworthy. It places the working pattern inside the broader research literature on AI-augmented knowledge work: the Harvard / BCG study of 758 consultants on the "jagged technological frontier" [1], the Stanford / MIT evidence on customer-support productivity [2], and the MIT writing experiment in Science [3]. The three studies converge on a single finding. AI shortens the time to a usable draft sharply, and the value of the final output depends on what the team does with the draft. The paper closes with operating principles any program team can adopt. The flow itself does not depend on the chip context, and teams in clinical research, software, and integration programs have reported similar results. Section two presents the flow itself with the three artifacts it produces. Section three describes the iteration loop that ties the three steps together. Section four places the case-study findings inside the broader research literature, and section five distills nine operating principles. The paper is short. The case is simple, and the discipline behind it is simple too. -- 3 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 4 01 Section one The setup A semiconductor program had reached the point where the team could no longer plan the way it had before. The product was a multi-year, multi-partner stacked-memory device. The schedule depended on five process and design milestones, each gated by partner decisions and each carrying its own doneness criteria, assumptions, and risks. The core team was eight people; peak engineering headcount would run into the hundreds; the budget would land in the tens of millions. The conventional planning cycle would have taken weeks of meetings to produce a usable draft, and the draft would have been obsolete the moment a partner decision shifted. Three strong inputs were already in hand. The product owner had produced an early milestone timeline at quarter-level granularity. The technical program manager had run a structured milestone scrub with the fab/process, design, and integration leads, and the meeting had been transcribed. A risk register was already maintained in a spreadsheet. Scattered emails and chat threads also held individual decisions that had never been merged into the master plan. The traditional path forward would have assigned a planner to merge those inputs by hand into a project charter, then circulated the charter for comment, then incorporated the comments, then converted the result into a Microsoft Project schedule. The team had run that cycle before and abandoned it. It was too slow to keep up with the program and too brittle to absorb partner decisions, and it always pinned the work on a single planner who became the bottleneck. -- 4 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 5 What the team had Inputs and constraints A working list of what fed the planning process at the start. Inputs Milestone scrub minutes (PDF). An eight-page meeting record capturing technical discussion across process, design, and integration. Decisions, owners, open unknowns, and a top-10 milestone set rebuilt from scratch in the room. Risk register (spreadsheet). Twenty-five tracked risks at three severity levels with named owners and first-mitigation steps. Otter.ai meeting transcript (text). A verbatim record of the milestone scrub, used by the AI to recover the "why" behind decisions that the formal minutes had compressed away. Email threads and chat comments. Subsequent corrections, partner-trip readouts, and individual decisions recorded outside the formal documents. Each of these would, in conventional planning, have to be hunted down and merged manually. Project charter draft (PDF). An eight-page document carrying mission, success criteria, assumptions, risks, and an early milestone timeline at quarter-level granularity. Strong on framing, weak on sub-task structure. Generated last in the input chain because the charter inherits structure from the prior artifacts. Constraints Time pressure. The next executive review was three weeks away, and a partner-decision trip was scheduled for two weeks after that. The plan had to be coherent enough to support both events. Distributed team. Nine named contributors across three continents, none of whom could afford a multi-day planning offsite. Partner dependencies still open. Three of the five major milestones depended on partner-side decisions that would not close until the trip. The plan had to be structured to accept those decisions cleanly when they arrived rather than to assume them. Decision The program manager proposed an AI-assisted approach: feed the documents and transcripts into a large language model, ask it to produce three connected artifacts (a milestone timeline, a milestone matrix, and a macro schedule), and use the team's time to scrub each draft rather than to build it. The first iteration would be rough. The second would be much closer. The third would be publishable. The total elapsed time would be days, not weeks. The bet was simple: AI gets the team to roughly right very fast, and the team's time — the scarce resource — is best spent on judgment, not on synthesis. -- 5 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 6 02 Section two The three-step flow The flow is three connected steps, and each step produces a different artifact for a different audience. The milestone timeline is for the executive sponsor: a one-page view that fits on a charter page and answers the question "what is this program, what does done look like, what could kill it?" The milestone matrix is for the team: a working table with doneness criteria, sub-tasks, assumptions, and linked risks for every milestone. The macro schedule is for the project-management tool that will eventually drive weekly execution. Each artifact builds on the one before it. The matrix inherits structure from the timeline and adds operational detail. The schedule inherits structure from the matrix and adds calendar dates and dependencies. Corrections made at any level flow into the next pass without rebuilding from scratch. AI generates the draft. The team scrubs and refines. The schedule is the product. Figure 1. The three-step AI-assisted macro planning flow. Each step produces a draft, the team scrubs each draft, and comments feed back into the next iteration. -- 6 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 7 Step one Milestone timeline The first step gathers and synthesizes. The AI receives every available source: documents, transcripts, the risk register, side conversations. It is asked to produce a one-page milestone timeline in a fixed format. A horizontal time axis, one to nine milestones plotted against it, three columns underneath for success criteria, assumptions, and risks. The format is the contract. The AI fills it in. The first draft is rough. Some milestones are mis-named. Some doneness criteria belong on a different milestone. The risk column over-weights items that were prominent in the most recent meeting and under-weights items that have been quietly important for longer. These are the visible errors. The team scrubs them in a 30-minute meeting and the program manager re-prompts the AI with the corrections. The second iteration is materially better. The third is publishable. Figure 2. A representative milestone timeline output, anonymized. The AI produces this structure on the first prompt; the team's iteration adjusts wording, severity, and milestone scope rather than the layout itself. The output becomes the executive page of the project charter. It is the artifact the sponsor reads and the artifact the team uses to test whether the program structure is coherent. If the timeline cannot be drawn cleanly on one page, the milestones are wrong. Observation. The first AI draft of the timeline produced eleven milestones. The team scrubbed it down to five. The reduction did not require new information. It required a human judgment about which gates were load-bearing and which were intermediate readouts that belonged inside other milestones. -- 7 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 8 Step two Milestone matrix The second step distills and normalizes. The AI takes the agreed milestone timeline and expands each milestone into a row of a working table. The columns are fixed: milestone identifier, summary task, milestone name, doneness criteria, key sub-tasks, assumptions, and risks. Same format on every row. Same structure means downstream tools can ingest the table directly. The matrix is where the program shifts from executive language to execution language. Doneness criteria become unambiguous. "1st Si 3D stack delivered: hybrid bonding selected, stacking partner chosen, stack sorted and tested" replaces "stack working." Each sub-task carries an implicit owner. Assumptions become testable. Risks become mappable to the existing risk register. Figure 3. A representative milestone matrix, anonymized. The matrix is the bridge between executive framing and team execution, and it is the artifact most heavily scrubbed since every cell is read by the responsible engineer. The matrix is scrubbed twice. The first scrub is by the program manager and the AI. The AI is asked to flag rows where the doneness criteria do not match the milestone name, where assumptions are duplicated across rows, where risks are mapped to the wrong milestone. The second scrub is by the team. Each engineer reads the rows in their domain and corrects them in place. Both scrubs are cheap. Together they take the matrix from 80% to 95%. Observation. The fastest part of the entire planning cycle was the matrix. Once the timeline was settled, the AI generated the matrix in a single prompt, and the team's scrub was crisp because the structure was already familiar. Time to publishable: under one working day. -- 8 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 9 Step three Macro schedule The third step organizes and schedules. The AI converts the matrix into a structured input that a project-management tool can ingest. In the case-study program, the target was a desktop scheduling tool with built-in milestone visualization. Microsoft Project, Smartsheet, or Asana would work the same way. The artifact is no longer free-text. It is a machine-readable plan. The schedule adds calendar dates and dependency arrows. The AI estimates durations from the sub-tasks and the matrix's effort hints. The team scrubs the durations. This is the only step where the AI consistently mis-estimates, because it has no calibration to the team's actual fab cycle time, partner cadence, or holiday calendar. The team adjusts. The dates snap into place. Figure 4. A representative macro schedule view, anonymized. The critical-path callout below the gantt highlights the gating decision the executive review needs to see. The schedule surfaces what the prior two artifacts cannot: the critical path. Once milestones, sub-tasks, and dependencies are in the tool, the gating sequence becomes visible. In the case-study program, the second milestone (M2) carried four sub-gates and three partner contracts. M3, M4, and M5 all inherited risk from it. The schedule made that visible in a way the timeline and matrix could not. What the team did with the time saved. Instead of arguing about the format of the plan, the team argued about the program. Whether the partner trip should drive the M2 close or follow it. Whether the base die should be a separate track. Whether the qualification gate should be re-weighted. Those arguments produce a better program. They were possible because the artifacts arrived in days instead of weeks. -- 9 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 10 03 Section three The iteration loop The three-step flow describes the artifacts. The iteration loop describes how each artifact is brought from rough first draft to publishable. The loop has six stations: gather, distill, synthesize, organize, scrub, refine. The first three are AI-driven. The last three are team-driven. The loop closes when the team's corrections become the prompt for the next AI pass. No iteration happens in isolation. Every iteration is informed by the previous one and feeds the next. The discipline that distinguishes a useful AI-assisted plan from a mediocre one is to not stop after the first draft. -- 10 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 11 The loop Six stations, two roles The six stations are not equal. Three are nearly free; the AI does the work in seconds. Three require human attention and judgment and cannot be shortened. Recognizing which is which is the first move. Figure 5. The six-station iteration loop. The top row is AI-cheap, the bottom row is human-essential. The dashed loopback arrow is the discipline that makes the system work. Gather, distill, synthesize — AI These three stations are where AI dominates. Gather means reading the inputs. A 30-page PDF, a 90-minute transcript, three email threads, a risk spreadsheet, and a slide deck do not need to be read by the planner anymore. The AI ingests all of them in seconds. Distill reduces the noise. Long documents carry far more text than is needed to plan against, and the AI is unusually good at compressing the structural content while preserving what matters. Synthesize is the cross-source merge. When the same milestone is described differently in the charter, the transcript, and an email thread, the AI normalizes them to a single representation. This is the work that used to take a planner days. It now takes minutes. Organize, scrub, refine — humans Organize is partly tool-driven. Importing the matrix into a scheduling tool, mapping fields, validating dates. Scrub is the work that has to be human. The team reads the AI's output looking for three classes of error. Factual mistakes (wrong dates, wrong owners, wrong numbers). Structural drift (a milestone that has subtly changed scope across iterations). Missing local context (an assumption the team knows is no longer valid but the AI cannot have known). Refine closes the loop. The team's corrections become the input prompt for the next AI pass. -- 11 of 44 -- Iteration discipline Three is enough "One iteration is not enough. Three is usually enough." First draft rough. Second meaningfully better. Third publishable. After the third, returns shrink fast. © 2026 lateralworks Page 12 -- 12 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 13 The split Where AI is fast, where humans are essential The most-quoted line from this case study is the simplest. AI gets you to 80%. Humans add the last 20%. The shape of the split is what makes the pattern work. AI is fast at the first 80% (the synthesis, the structuring, the rough draft) and slow at the last 20% (the judgment and calibration that depend on context the AI does not have). Figure 6. The 80 / 20 split. AI compresses time-to-draft sharply, and the team scrub determines final quality. The order matters. AI first, humans second. Reverse the order, with humans drafting and AI polishing, and the gain shrinks because the bottleneck (synthesis) was never compressed. It also breaks the iteration loop. A hand-drafted artifact is much harder to re-prompt with a structured correction than an AI-drafted one, because the structure itself is attached to the author. The Pareto principle is the right reference here, in its operational form: roughly 80% of the value comes from roughly 20% of the work [4]. In AI-assisted planning, the inversion is what creates the time savings. The 80% of the work that produces the basic structure becomes nearly free, and the team can spend its full attention on the 20% that determines whether the plan is correct. Observation. A frequent failure mode is for a team to demand 100% AI accuracy before publishing the first draft. That is the wrong target. The first draft only needs to be good enough that the team can scrub it efficiently. Polishing the AI to 100% is what the second and third iterations are for. -- 13 of 44 -- Working principle Roughly right, fast "It is better to be roughly right than exactly wrong." A working principle for AI-assisted planning lateralworks Fast Time To Market (FTTM) methodology © 2026 lateralworks Page 14 -- 14 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 15 04 Section four What the research says The case study is one data point. The broader research literature on AI-augmented knowledge work has produced converging evidence across very different settings (management consulting, customer support, professional writing). The same pattern shows up in each: substantial productivity gains on tasks that fall inside the AI's capability frontier, paired with serious risks on tasks that fall outside it. The case-study flow is one practical answer to the question of how to capture the gains while avoiding the risks. The three studies summarized below are the strongest peer-reviewed evidence available as of early 2026. None is specific to program planning. Each illuminates something the case study assumed without proving: that AI compresses time to draft, that the gains are uneven across tasks, and that human iteration determines final quality. -- 15 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 16 The studies What three field experiments found Harvard / BCG — 758 consultants The 2023 Dell'Acqua et al. field experiment with Boston Consulting Group [1] is the most-cited study in this literature. Seven hundred and fifty-eight BCG consultants, about 7% of the firm's individual-contributor workforce, were randomly assigned to one of three conditions: no AI, GPT-4 access, or GPT-4 access plus prompt-engineering training. They were given eighteen realistic consulting tasks and graded on speed and quality. Inside the AI's capability frontier, consultants with AI completed 12.2% more tasks, took 25.1% less time, and produced output 40% higher in quality than the control group. Outside the frontier, on tasks that look superficially similar but fall just beyond what the AI can reliably do, consultants with AI were 19 percentage points more likely to produce wrong answers than consultants without AI [1]. The study coined the phrase "jagged technological frontier" for this property. Stanford / MIT — 5,179 support agents The Brynjolfsson, Li, and Raymond study, first released as NBER Working Paper 31161 in 2023 and published in the Quarterly Journal of Economics in 2025 [2], examined the staggered introduction of a generative-AI conversational assistant across 5,179 customer-support agents at a Fortune 500 company. Access to the AI tool increased productivity, measured as issues resolved per hour, by 14% on average. The unequal distribution of the gains carries the planning lesson. Novice and low-skilled agents saw a 34% productivity improvement. Experienced and high-skilled agents saw a minimal effect. The authors interpret this as the AI capturing the best-practice patterns of the most-productive agents and disseminating them to everyone else [2]. Translated to planning: the AI does the synthesis the way an experienced planner would, even when the user is not yet experienced. MIT — 453 professional writers The Noy and Zhang experiment, published in Science in July 2023 [3], assigned occupation-specific writing tasks to 453 college-educated professionals (managers, HR specialists, grant writers, marketers, consultants, data analysts). Half were randomly given access to ChatGPT. Average time on task fell by 40%. Output quality rose by 18%. Variance between high-ability and low-ability writers compressed; the gain to lower-ability writers was substantially larger. The result that matters most for planning work is the change in how people worked. ChatGPT did not just speed up rough drafting. It shifted the structure of the task. The treatment group spent less time on rough drafting and more time on idea generation and editing [3]. That is the same shift the case study describes. The team stopped writing the plan and started judging it. -- 16 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 17 Two patterns Centaur and cyborg Two distinct patterns of human-AI integration have emerged in the broader research. The terms come from chess. In 1998, the year after losing to IBM's Deep Blue, Garry Kasparov organized the first "Advanced Chess" tournament. Human players paired with chess engines competed as teams. The image of the human-on-horse hybrid stuck as the name for the resulting working pattern [5]. The Dell'Acqua team found that consultants in their study clustered into two related patterns. They labeled them centaur and cyborg [1]. Figure 7. The two integration patterns. Both produce gains inside the AI's capability frontier. The difference is how the human and AI exchange work. Pattern adapted from Dell'Acqua et al. 2023 [1]. Centaur users define a clear division of labor. The human chooses the approach, the AI handles specific tasks within that approach, and the boundary between the two is explicit. Cyborg users blur the boundary. They iterate inside every task, with a continuous back-and-forth of prompts, edits, and re-prompts. Neither pattern is universally better. The case-study flow is closer to the centaur pattern at the artifact level (AI produces the timeline, the team scrubs it) and closer to the cyborg pattern inside each iteration (the planner re-prompts continuously while reviewing). The choice is task-dependent. Centaur is better when the task partitions cleanly: a well-defined sub-task the AI can take entirely, with the rest as human work. Cyborg is better when the task is ambiguous and evolving, when the right next step depends on what the AI just produced. Macro planning is mostly the first kind at the artifact level (the timeline can be generated independently and then scrubbed) and mostly the second kind during iteration (each round of corrections changes what the next prompt should ask for). The takeaway from the literature. The productivity gain from AI is real and substantial, and it is not uniform. It depends on whether the task lies inside the AI's capability frontier, on how the human integrates with the AI, and on whether iteration discipline is enforced. The case-study flow is one concrete answer. -- 17 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 18 05 Section five What we learned Nine working principles came out of the case study. Each is phrased as a discipline rather than a tip, because each one is easy to ignore and the cost of ignoring it is large. Together they describe the difference between a team that captures the AI productivity gain and a team that does not. The principles are portable. None is specific to semiconductor development. A software product team, a clinical research program, a construction project, a corporate restructuring all face the same planning problem and can use the same flow. -- 18 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 19 Nine principles How to operate 1. Always ask for a summary The first artifact in any AI-assisted planning cycle is a summary or abstract of the source material. It is the cheapest way to verify the AI has read the inputs accurately. If the summary is wrong, the plan will be wrong. Catching it at the summary stage costs minutes. Catching it at the schedule stage costs days. 2. Get to 80% fast, then iterate The first AI pass should aim for the basic structure and content, not for polish. Use the first pass to find out what the AI got wrong, what is missing, and what is over-weighted. The second pass corrects. The third refines. Trying to land a perfect plan in one prompt is the failure mode that wastes the most time. 3. The more base data, the better the output AI synthesis quality scales with the volume and structure of inputs. A team that feeds in only the project charter will get a thinner output than a team that feeds in the charter, the meeting transcript, the risk register, and the partner emails. The team's job in input gathering is to be exhaustive. The AI handles the selection. 4. Use every artifact you have Emails, chat threads, Slack messages, transcripts, slide decks, side spreadsheets. Conventional planning loses these because no one has time to merge them. The AI merges them automatically. Treat every artifact as a candidate input to the next iteration. 5. Tell people the document is a draft When sharing AI-generated artifacts for review, label them explicitly as drafts and ask for specific corrections. "This is a draft and it needs your inputs. What is wrong? What needs to be changed?" That invites the reviewer to engage as a collaborator instead of as a judge. It also creates investment in the final product, which improves trust in the result. -- 19 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 20 6. Store the sessions AI tools that retain context across conversations get smarter about a specific program over time. A planning project should have its own dedicated workspace into which every related session is filed. The fifth iteration of a plan is much better than the first, partly because the AI has accumulated context about the program that no individual session would carry. 7. Always run the humanizer AI-generated text has stylistic tells (the em dashes, the recurring transitional phrases, the slightly over-formal register) that signal "AI wrote this" to a reader. Before publishing, run the text through a humanizer pass that flattens those tells. The content of the plan is what matters. The voice should be invisible. 8. Identify sources and provide references When a plan makes a non-obvious claim (a benchmark headcount, a typical schedule duration, a market data point), the AI should be asked to identify the source and surface it in a reference list. The discipline catches hallucinations early. It also makes the plan defensible against challenge. 9. Have a skeptic on the team A team without a skeptic over-trusts AI output. A team with a skeptic catches the errors the rest of the team would have missed. The skeptic's role is to refuse to accept the AI without scrutiny. The case-study team had a skeptic. The plan is better for it. -- 20 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 21 Closing What this means more broadly The case study has been described as if it were unusual. It is a particular instance of a working pattern that is becoming the default for knowledge work. The pattern compresses synthesis time, surfaces the team's judgment as the scarce resource, and rewards iteration discipline. Three observations close the paper. First, the pattern is portable across industries. The flow described here was used for a hardware development program. The same flow has produced similar results in customer-success rollouts, clinical study planning, M&A integration playbooks, and regulatory response programs. Nothing about the underlying mechanism depends on the program domain. Second, the gains are not uniform across team members. The Brynjolfsson, Li, and Raymond evidence [2] is unambiguous on this. AI levels the productivity distribution, with the largest gains going to less-experienced workers. In planning work, that means a junior planner with AI can produce a draft plan that a senior planner without AI would take a week to match. The senior planner's comparative advantage shifts toward judgment and scrutiny, where it should have been all along. Third, the working principle behind the entire case is older than AI. "It is better to be roughly right than exactly wrong" is the operating discipline of most fast-moving teams. The structural feature of AI-assisted work is that it captures this discipline operationally. AI lets a team be roughly right in hours instead of in weeks. Whether the team uses the time saved to be more right, or simply to ship faster, is the choice that determines whether AI assistance produces lasting value. The closing principle. AI gives you a fast first draft. The value of the final plan depends on what the team does with the draft. Run two iterations. Scrub the output. Argue about the program, not the artifact. -- 21 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 22 R Sources References The references below are the primary sources for the empirical claims in this paper. Where a study is available in both a working-paper version and a peer-reviewed version, the citation points to the peer-reviewed version of record but lists the working paper for accessibility. -- 22 of 44 -- › AI-assisted macro planning › › › © 2026 lateralworks Page 23 [1] Dell'Acqua, F., McFowland III, E., Mollick, E. R., Lifshitz-Assaf, H., Kellogg, K. C., Rajendran, S., Krayer, L., Candelon, F., and Lakhani, K. R. "Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of Artificial Intelligence on Knowledge Worker Productivity and Quality." Harvard Business School Working Paper 24-013, September 2023. Forthcoming in Organization Science. https://www.hbs.edu/ris/Publication%20Files/24-013_d9b45b68-9e74-42d6-a1c6-c72fb70c7282.pdf [2] Brynjolfsson, E., Li, D., and Raymond, L. R. "Generative AI at Work." Quarterly Journal of Economics, vol. 140, no. 2, 2025, pp. 889–942. NBER Working Paper 31161, April 2023. https://doi.org/10.3386/w31161 [3] Noy, S., and Zhang, W. "Experimental evidence on the productivity effects of generative artificial intelligence." Science, vol. 381, no. 6654, July 2023, pp. 187–192. doi:10.1126/science.adh2586 [4] Pareto, V. Cours d'Économie Politique. Lausanne: F. Rouge, 1896–1897. (Source of the original Pareto distribution observation. The operational "80/20 rule" interpretation is attributed to Joseph M. Juran in his 1951 Quality Control Handbook.) [5] Kasparov, G. Deep Thinking: Where Machine Intelligence Ends and Human Creativity Begins. PublicAffairs, 2017. (Origin of the "centaur" concept for human-AI collaborative play, first applied in Kasparov's 1998 Advanced Chess tournament.) [6] Mollick, E. Co-Intelligence: Living and Working with AI. Portfolio, 2024. (Operational guidance on the "jagged frontier" and on iteration discipline as the locus of AI-augmented productivity.) [7] McKinsey & Company. "The state of AI in early 2024: Gen AI adoption spikes and starts to generate value." Global Survey on AI, May 2024. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai-2024 [8] McKinsey & Company. "The state of AI: How organizations are rewiring to capture value." Global Survey on AI, March 2025. https://www.mckinsey.com/capabilities/quantumblack/our-insights/the-state-of-ai [9] Peng, S., Kalliamvakou, E., Cihon, P., and Demirer, M. "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot." arXiv preprint, February 2023. https://arxiv.org/abs/2302.06590 (Companion evidence on AI compression of time-to-draft for software-development tasks; 55.8% faster task completion in the treated group.) [10] Kellogg, K. C., Lifshitz-Assaf, H., Randazzo, S., Mollick, E., Dell'Acqua, F., McFowland III, E., Candelon, F., and Lakhani, K. R. "Don't Expect Juniors to Teach Senior Professionals to Use Generative AI: Emerging Technology Risks and Novice AI Risk Mitigation Tactics." Harvard Business School Working Paper 24-074, March 2024. [11] lateralworks. "Fast Time To Market (FTTM) methodology — team best practices." Internal methodology paper, 2026. [12] lateralworks. "Internal engagement records." Case-study data drawn from a complex semiconductor program, April–May 2026. Anonymized for this paper. Details on file with the program team. -- 23 of 44 -- › AI-assisted macro planning › › › A Appendix Example outputs lateralworks › © 2026 lateralworks Page 24 The pages that follow are example projects, redacted and genericized, that show what each step in the AI-assisted flow produces in practice. A.1 Memory program — Milestone Timeline and Project Charter (Step 1). An eight-page project charter built around a Step 1 milestone timeline. Generated by an LLM from program inputs — a brief, the meeting transcript from a milestone scrub, a risk register, and partner emails — and iterated with the core team before sign-off. A.2 Project Beta — Milestone Matrix, card form (Step 2). A four-page expansion of the Step 2 matrix into project scope plus milestone-by-milestone cards. The card form is what the team uses for review and discussion: each milestone shows doneness criteria, sub-tasks, assumptions, and linked risks side by side. A.3 Project Beta — Milestone Matrix, table form (input to Step 3). The same matrix collapsed into a single landscape page. This is the form that gets imported into fastProjectAI to generate the macro schedule and conduct critical-path and gap analysis. A.4 Fab1 program — Macro schedule with risk and procurement analysis (Steps 1–3 extended). A seven-page feasibility-stage planning bundle for a multi-billion-dollar fab program. Shows all three artifacts produced for a single program — milestone timeline (Step 1), milestone-detail cards (Step 2), and macro schedule with critical path (Step 3) — extended with program context, top risks, CAPEX procurement timeline, and a ranked priority mitigation list. Same flow, larger program, longer horizon. Steps 1 and 2 are generated by LLM models and iterated multiple times with the core team before this data makes its way into the project-management software used to execute the project. -- 24 of 44 -- DDR5 NV-DRAM+ — PROJECT CHARTER Persistent memory for AI scale-out · Foundry Partner 1B 16Gb 3D DDR5 NV-DRAM+ (4H stack) REV 1.1 · 24 APRIL 2026 Updated schedule — realistic baseline MISSION Qualify a Foundry Partner 1B 16Gb 3D DDR5 NV-DRAM+ (4H stack) for AI data-center scale-out by December 2029. Process Development Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 2026 2027 2028 2029 1 Jun 2027 M1 Ferroelectric cell validated 2 Mar 2028 M2 FS 3D stack validated 3 Dec 2028 M3 WS 3D stack validated 4 Jun 2029 M4 ES 3D stack validated 5 Dec 2029 M5 Product qualified — release CORE TEAM Exec sponsor: Exec Sponsor · Product boss (E2E owner): Product Boss · TPM: TPM · Design: Design Lead · Fab/Process: Fab/Process Lead · Device: Device Lead · Post-Fab: Post-Fab Lead · Product: Product Lead SUCCESS CRITERIA ASSUMPTIONS RISKS • Ferroelectric cell meets product KPIs (imprint, polarization, temperature envelope) • Design margin sufficient to sample at 3200 MT/s across full operating window • 4H W2W hybrid bonding proven; TSV connectivity verified across stack • Manufacturing-ready back-end flow proven (bonding + package + test) at DRAM parity on test cost • Foundry Partner 1B process frozen; base die flow frozen at Logic Foundry + Interface Design Partner • Full JEDEC DDR5 qualification passed — not by similarity to DDR4 • Retention 3 months @ 85°C; endurance 10^15 cycles; UBER 10^-24 • Yield-to-target (~80%) plan developed; margin-to-goal plan developed • Product chip-level functional and performance requirements met • Qual samples delivered to AI data-center customers (100s per DDR4 precedent) • Foundry Partner 1B process is frozen; no major PDK or process changes expected after fix • Tape-out split into base die + memory die; ≤2 all-layer iterations per die before WS retrofit • ALD process flow via ALD Vendor at Research Lab (Path A struck per 21 Apr decision) • Base die: Client Co designs; Logic Foundry implements; Interface Design Partner digital implementation support • 4H W2W hybrid bonding with TSVs is viable at 16 Gb per memory layer (Foundry Partner confirms) • Foundry Partner packages memory with Logic Foundry/Interface Design Partner base die; Backup Foundry is contingency path only • Stacking partner supplies ADK to avoid manual stitching; face orientation decided • Adequate testing capability available; test hardware to opex (no capex for testers) • FS → WS retrofit pattern valid; 2nd Si incorporates FS learnings without re-architecture • ELFR study for 20 dppm follows MP release; post-qual, not gating • Fab cycle time <2 months for full flow on a hot lot • D5-01 Ferroelectric cell fails product KPIs — Cell Lead • D5-02 Foundry Partner PDK non-functional in EDA Vendor B flow — blocks design start — Design Lead • D5-03 Product spec not closed before design start — already slipped — Spec Owner • D5-04 Hybrid-bonding technology not selected — blocks partner, stacking, base-die tech — Fab/Process Lead • D5-05 Base die and memory die asynchronous — ‘two-bridge’ sync risk — Product Boss • D5-15 4H W2W hybrid bonding yield/reliability at production density is unknown • D5-20 Qual failure on embedded flow requiring design/process changes • Geo Foundry Country concentration (Foundry Partner + Logic Foundry + Interface Design Partner + stacking) — geopolitical exposure • Cost Program cost envelope not yet defined; no baseline for quarterly review • U5 DDR5 IP source — vendor and license model open — Design Lead NEXT STEP · Foundry Country trip with Foundry Partner is the fulcrum — closes hybrid bonding tech, base-die partner, and PDK escalation. Rev 2.0 of this charter with locked calendar dates follows in early May 2026. Page 1 of 8 -- 25 of 44 -- Milestone detail Doneness criteria, key subtasks, assumptions, and linked risks per milestone — M1 through M5 (Rev 1.4 schedule). M1 Jun 2027 Ferroelectric cell validated OWNER Cell Lead (Process & Integration) EFFORT SL vehicle + process development at Research Lab DONENESS CRITERIA • Preliminary specifications signed off • Short-loop (SL) vehicle developed at Research Lab • Integration path determined (ALD Vendor via Research Lab) • Reduced cap height integrated • Low-temperature ALD process developed • Ferroelectric cell meets product KPIs KEY SUBTASKS • Execute SL vehicle tapeout; run learning cycles • Monthly cell-KPI review from May 2026 • Integration DOE for reduced cap height • ALD recipe development + characterization ASSUMPTIONS • ALD Vendor JDP in place; IP ownership resolved • Research Lab SL vehicle operational by Q2 2026 • Ferroelectric material passes reliability screen LINKED RISKS D5-01, D5-03, D5-13, D5-14 M2 Mar 2028 FS functional 3D stack validated OWNER Design Lead (Design) | Fab/Process Lead (Fab/Process) EFFORT Compound milestone — 4 sub-gates DONENESS CRITERIA • Base die delivered: technology, foundry, interface provider selected; base die taped out, sorted, tested • Memory die delivered: Foundry Partner PDK received; memory die taped out, sorted, tested • 1st Si 3D stack delivered: hybrid bonding selected; stacking partner chosen; stack sorted + tested • 1st Si 3D stack validated: parametric + functional tests pass; DDR5 at 3200 MT/s; TSV verified; retention met KEY SUBTASKS • Foundry Country trip closes hybrid-bonding + base-die partner • Base die tapeout to Logic Foundry via Interface Design Partner • Memory die tapeout to Foundry Partner 1B • W2W hybrid bonding at stacking partner; ADK integration • Sort + test programs developed for base, memory, stack ASSUMPTIONS • Foundry Country trip closes hybrid-bonding technology decision • Logic Foundry + Interface Design Partner signed; PDK available for base die • 1st Si returns within 12 weeks of tapeout • Stack yield sufficient for parametric characterization LINKED RISKS D5-02, D5-04, D5-05, D5-07, D5-08, D5-09, D5-10, D5-11, D5-12 M3 Dec 2028 WS functional 3D stack validated OWNER Design Lead (Design) | Fab/Process Lead (Fab/Process) EFFORT 240 man-months | retrofit + 2nd Si | ramp to 10 eng DONENESS CRITERIA • Retrofit base + memory tapeouts incorporate FS learnings • 2nd silicon validated through full DDR5 protocol • Stack-level variation budget confirmed across 4H • CXL + DIMM interface pre-validation complete KEY SUBTASKS • FS learning distillation → retrofit spec freeze • 2nd Si tapeout with incremental changes only • Full DDR5 protocol characterization at 3200 MT/s • Stack-level SPC rollout ASSUMPTIONS • FS learnings are incremental, not architectural • Retrofit scope ≤1 FE change + ≤2 metal changes per die • Fab cycle time <2 months on hot lot • No capex required for testers LINKED RISKS D5-06, D5-15, D5-18, D5-25 M4 Jun 2029 ES functional 3D stack validated OWNER Product Lead (Product) | Design Lead (Design) EFFORT 18 man-months | sample build + validation DONENESS CRITERIA • Engineering samples built on production-intent flow • Full JEDEC DDR5 compliance demonstrated • CXL and DIMM interfaces validated at system level • Samples shipped to AI data-center customers KEY SUBTASKS • Customer sample quantity finalized; build plan locked • Production-intent flow frozen at WS boundary • Customer-facing datasheet + qual report drafted • Engineering sample ship approval (LAR or equivalent) ASSUMPTIONS • Customer sample quantity ~100s (DDR4 precedent) • Production-intent flow frozen at WS milestone • No respin required between WS and ES LINKED RISKS D5-08, D5-15, D5-20, D5-25 M5 Dec 2029 Product qualified — release OWNER Product Boss EFFORT 18 man-months | qualification + release DONENESS CRITERIA • JEDEC qual passed on production flow • Retention 3 months @ 85°C verified • Endurance 10^15 cycles confirmed • UBER 10^-24 achieved • Released to production; datasheets published KEY SUBTASKS • Qual test program execution per RCM • Reliability stresses completed; delta analysis signed • Characterization test program completed • Production stocking plan in place • H-toll 1000 h weighting review concluded ASSUMPTIONS • Qual samples delivered to customer on schedule • No respin required post-ES • ELFR study for 20 dppm follows release, not gating LINKED RISKS D5-09, D5-11, D5-21, D5-22 Calendar dates inherited from Rev 1.2; to be updated in Rev 2.0 following the Foundry Country trip (May 2026). · Compound milestones (M2) track at sub-gate granularity. · Risks reference the 21 April DDR5 risk register. Page 2 of 8 -- 26 of 44 -- Incremental project breakdown Parsing the DDR5 NV-DRAM+ program into a roadmap of narrower-scope projects with aggressive intermediate deliverables. FRAMING — the case for incremental scope Boil-the-ocean programs fail. The 21 April milestone scrub already flagged this: 3D stack and monolithic 16 Gb should be separate projects, and the base die and memory die could be separate projects until bonding. The current 4H full-product plan runs ~4 years with five compound milestones, each gated by a prior unknown. Breaking the program into four narrower tracks retires risks sequentially, produces shippable or licensable deliverables at every gate, and creates forcing functions on decisions that currently have no deadline. Aggressive interim dates replace the single 2029 commitment with a cadence of customer-visible outcomes. Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 2026 2027 2028 2029 1 Q3 2027 16 Gb monolithic 2 Q1 2028 Base die qualified 3 Q3 2028 2H pilot stack 4 Q4 2029 4H 64 Gb release TRACK A Q3 2027 Ferroelectric cell + 16 Gb monolithic DDR5 NV-DRAM SCOPE Validate ferroelectric cell in Foundry Partner 1B; ship a monolithic (non-stacked) 16 Gb DDR5 NV-DRAM product. DELIVERABLE Commercial 16 Gb DDR5 NV-DRAM with 3-month retention; characterization report; release-to-production package. RISKS RETIRED • Ferroelectric cell KPI risk (D5-01) • Foundry Partner 1B process-flow integration risk • Product-spec closure gap (D5-03) • Initial DDR5 IP license decision (U5) WHY THIS STEP No 3D integration, no hybrid bonding, no base die required. Leverages the cell validation already in flight at Research Lab. Gives Client Co a commercial DDR5 NV-DRAM presence 18 months before the 4H product. TIME TO DELIVERY Q3 2027 · ~18 months from charter DEPENDS ON M1 cell validation; Foundry Partner PDK fix (U1) TRACK B Q1 2028 Base die platform qualification SCOPE Qualify the Client Co-designed base die at Logic Foundry via Interface Design Partner as a standalone IP block, decoupled from the memory die program. DELIVERABLE Qualified base die PDK + characterization report; interface specification frozen; base die as reusable block across density variants. RISKS RETIRED • Base-die partner/technology risk (D5-04) • Asynchronous two-bridge risk (D5-05) • Backup Foundry-vs-Logic Foundry-vs-other node decision (U7) • ADK availability from stacking partner (U8) WHY THIS STEP The base die is common across all density variants. Qualify once, use many times. Decouples base-die schedule from memory die so Track A can proceed even if base die slips. Enables IP licensing as a side revenue line. TIME TO DELIVERY Q1 2028 · ~21 months from charter DEPENDS ON Foundry Country trip decisions; Logic Foundry + Interface Design Partner partnership signed TRACK C Q3 2028 2H hybrid-bonding pilot (32 Gb stacked) SCOPE Build and validate a 2-high stack using the qualified base die + a 16 Gb memory die over W2W hybrid bonding. DELIVERABLE 32 Gb DDR5 NV-DRAM+ (2H) on production-intent hybrid-bonding flow; full JEDEC compliance at 2H density; shipping mid-density SKU. RISKS RETIRED • Hybrid-bonding yield at low stack height (D5-15) • Stack-level variation budget across 2 layers • TSV connectivity + retention at stack level • Sort + test program scale-up for stacks WHY THIS STEP 2H stack halves the integration risk of 4H and produces a shippable mid-density product. Proves the bonding flow under a less stressed yield envelope. Customers targeting mid-density get a product without waiting for 4H. TIME TO DELIVERY Q3 2028 · ~29 months from charter DEPENDS ON Track A (memory die proven); Track B (base die qualified) TRACK D Q4 2029 4H 64 Gb DDR5 NV-DRAM+ — original program SCOPE Integrate the validated cell, qualified base die, and proven bonding flow into the full-density 4H 64 Gb product. DELIVERABLE JEDEC-qualified 64 Gb DDR5 NV-DRAM+ (4H) for AI data-center CXL + DIMM workloads, at 3-month retention and 10^15 endurance. RISKS RETIRED • 4H stack-level variation budget • Reliability at production density • Manufacturing flow at target yield • Full customer qualification WHY THIS STEP Integration target. By this point each prior track has retired a specific unknown; 4H is the final assembly of proven components rather than a single giant unknown. Same customer commitment window as the original plan — but with three shipping products behind it. TIME TO DELIVERY Q4 2029 · ~48 months from charter DEPENDS ON Tracks A, B, C all closed BENEFITS OF INCREMENTAL ROADMAP n Each track produces a shippable or licensable deliverable — business value at every gate n Risks retire sequentially, not simultaneously — no compound failure mode n Early revenue from Tracks A + C offsets Track D program cost n If Track D slips or fails, Tracks A–C still ship — business does not go to zero n Aggressive interim dates force decisions that today have no deadline DECISIONS REQUIRED TO ADOPT n Adopt incremental roadmap, or continue boil-the-ocean 4H-only approach n Approve split: 16 Gb monolithic and base-die platform as separate tracks n Staffing: sequential (single team) vs. parallel (separate teams per track) n Budget authorization — gate-by-gate increments vs. full program up front n Customer communication: whether to announce interim products before 4H Page 3 of 8 -- 27 of 44 -- Design team sizing & phasing — industry benchmarks Peak headcount, schedule duration, and SME composition for DDR memory chip design — with application to the Foundry Partner 1B 16Gb 3D DDR5 NV-DRAM+ program. 16 Gb DDR on ~19 nm — 1y-nm class, DDR5 era Comparable to Foundry Partner 1B 16Gb 3D (monolithic die portion) PEAK DESIGN TEAM 90 – 110 engineers ARCHITECTURE → FIRST SI 30 – 36 months FIRST SI → QUALIFIED 12 – 18 months TOTAL PROGRAM 42 – 54 months ENGINEER-MONTHS (TOTAL EFFORT) 3,000 – 3,800 EXPECTED TAPE-OUTS 2 all-layer + 1–2 metal Complexity drivers: DDR5 protocol (mode registers, sub-channels), DFE I/O, on-die ECC, DQ speeds ≥6400 MT/s, tight retention/refresh budgets at advanced node. Industry references: Tier-1 Memory Vendors 1y-nm 16 Gb designs. 4 Gb DDR on 25 nm — DDR3 / early-DDR4 era Comparable to the Client Co sister program (Sister Foundry 25 nm 4 Gb DDR4 NV-DRAM) PEAK DESIGN TEAM 30 – 45 engineers ARCHITECTURE → FIRST SI 20 – 26 months FIRST SI → QUALIFIED 9 – 12 months TOTAL PROGRAM 29 – 38 months ENGINEER-MONTHS (TOTAL EFFORT) 800 – 1,100 EXPECTED TAPE-OUTS 1 all-layer + 1 metal Note: 25 nm is below DDR5's typical density floor (JEDEC DDR5 starts at 8 Gb); benchmark is most relevant to DDR3 / early-DDR4 generation. ~3–4× smaller effort vs the 16 Gb / 19 nm case: 4× density, simpler I/O, simpler protocol state. SME composition of a ~100-engineer DDR5 design team — typical discipline allocation at program peak Physical design / layout 22% (22 eng) Periphery / control design 20% (20 eng) Array / core design 18% (18 eng) Verification (FV + AMS) 12% (12 eng) High-speed I/O 12% (12 eng) Analog / mixed-signal 8% (8 eng) Architect / PM 5% (5 eng) Product / test engineering 3% (3 eng) 0 5 10 15 20 25 % of peak team (~100 engineers at peak) Physical design / layout Floorplan, P&R, DRC/LVS, parasitic extraction, power grid, clock tree synthesis Periphery / control design Command decode, control logic, mode registers, redundancy, DFT scan, fuse logic Array / core design Memory cell array, sense amps, word/bit-line drivers, row/col decoders Verification (FV + AMS) UVM testbenches, JEDEC compliance, mixed-signal simulation, STA, reliability sign-off High-speed I/O DQ drivers / receivers, DFE, DLL/PLL, ZQ calibration, CA I/O Analog / mixed-signal VPP / VDD generators, LDOs, bandgap, references, sense-amp bias Architect / PM Spec ownership, block partitioning, IP selection, schedule, risk management Product / test engineering ATE pattern gen, DFT insertion, silicon bring-up and debug support Time-phased staffing curve — engineer headcount by program month, with phase bands 0 20 40 60 80 100 120 Engineer headcount (FTE) 0 6 12 18 24 30 36 42 48 Program month (from architecture freeze) Architecture Block-level design Integration + P&R Tape-out Si debug Qualification Peak ~100 Peak ~40 16 Gb DDR on ~19 nm (1y-nm class, DDR5 era) — peak ~100 FTE, 48 mo program 4 Gb DDR on 25 nm (DDR3 / early-DDR4 era) — peak ~40 FTE, 32 mo program APPLIED TO OUR PROGRAM — implications for Foundry Partner 1B 16 Gb 3D DDR5 NV-DRAM+ staffing n Benchmark peak: ~90–110 design engineers for the monolithic 16 Gb die alone. 3D stacking, base die, and hybrid-bonding workstreams add ~15–25 more at integration peak. n Schedule fit: Rev 1.4 baseline (Q1 2026 start → M5 Dec 2029 = 48 mo) now aligns with the 42–54 mo benchmark range for 16 Gb 1y-nm — realistic under the assumption of zero-respin WS→ES and a base die reused from Track B. n Current gap: the named core team is 8 people (Product Boss, TPM, Design Lead, Fab/Process Lead, Device Lead, Post-Fab Lead, Product Lead, Exec Sponsor). The delta to a 90–110-engineer peak is the real staffing plan — not yet sized in the charter. n Incremental-track implication (page 3): Track A (16 Gb monolithic) requires ~40–60 engineers peak — a 4 Gb / 25 nm team size will NOT cover a 16 Gb / 19 nm monolithic product, even with density reduced. Page 4 of 8 -- 28 of 44 -- Budget estimate — program development cost Wafer development, FTE (Region B + Asia split), and consulting for the 48-month Foundry Partner 1B 16 Gb 3D DDR5 NV-DRAM+ program. BASELINE TOTAL — 48-MONTH PROGRAM ~$75M Range: $60M – $97M Rev 1.4 schedule: Q1 2026 → M5 Dec 2029 EXCLUDED FROM THIS ESTIMATE Process & metrology tools at foundry partner line (TBD) Fab buildout, GTM / launch, post-MP sustaining engineering — see detailed exclusions at bottom of page Wafer development Short-loop vehicle + integration (Research Lab, ~300 wafers) $6.0M Mechanical / process qual wafers $1.5M Base die tape-outs (3 spins @ Logic Foundry via Interface Design Partner) $4.0M Memory die tape-outs (3 spins @ Foundry Partner 1B) $7.0M Protolots (base + memory, POR flow) $3.0M Hybrid-bonding test lots (W2W stacking partner) $5.0M Engineering-sample + JEDEC qual lot wafers $3.5M Subtotal $30M Range $21M (FTR learning curve compresses, zero respins) to $45M (stacking respins, extra qual lots). Assumes 2–3 all-layer + 1–2 metal tape-outs per die. FTE — engineering Total engineer-months (48 mo program) ~3,400 REGION B — ~35% share (~1,190 em) Architecture, device, integration, process, PM Fully-loaded rate: ~$17K / month $20.2M ASIA — ~65% share (~2,210 em) Physical design, verif, layout, periphery, test Blended Foundry Country / Region D / Region E rate: ~$9K / month $19.9M Subtotal $40M Range $35M (if Asia share grows to 75%, or engineer-months 15% lower) to $45M (if peak runs longer or Region B share grows). Fully-loaded = salary + benefits + overhead + facilities. Consulting DDR5 IP licensing + vendor support $2.0M Hybrid-bonding external expertise $0.8M EDA tool-flow consulting (advanced node) $0.7M JEDEC compliance / verification consulting $0.4M Reliability / qual labs (external test) $0.6M Program advisory (Strategic Advisor et al.) $0.5M Subtotal $5M Range $4M to $7M depending on whether DDR5 PHY/controller is licensed vs in-house, and scope of external reliability testing. Program advisory includes Strategic Advisor TPM and methodology. Time-phased spend — quarterly burn rate by category, with cumulative trajectory 0 2 4 6 8 10 0 10 20 30 40 50 60 70 80 90 Quarterly spend ($M) Cumulative spend ($M) Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 YEAR 1 $9.6M YEAR 2 $24.7M YEAR 3 $26.6M YEAR 4 $14.1M $75M $61M Wafer development FTE (engineers) Consulting Cumulative ($75M by Y4) Program quarter (4-year program from architecture freeze) EXCLUDED FROM THIS ESTIMATE n Process and metrology tools added to the foundry partner line (Foundry Partner, Logic Foundry, stacking partner) — TBD; driven by decisions at Foundry Country trip and subsequent scrub. n Facilities / fab buildout at partner sites; clean-room capex. n GTM, marketing, launch activities, channel and customer ramp support. n Post-MP sustaining engineering, ELFR study execution, second-source development. n Royalties on third-party IP (amortized over unit shipments, not booked as R&D). KEY ASSUMPTIONS & CONFIDENCE n Currency: USD throughout; baseline 2026 prices; no inflation escalator applied. n Geographic split: 35% Region B / 65% Asia, weighted toward Region B for architecture and process, Asia for layout and verification. n Fully-loaded rates include salary, benefits, overhead, and facilities at each location. n Confidence: industry-benchmark range, not a Client Co-costed plan. Rev 1.1 of this page must validate against internal finance model before commitment. Page 5 of 8 -- 29 of 44 -- Inputs required to start — project-start prerequisites Everything that must be in place on day one — technology data, agreements, team, spec, and governance — before the program can credibly begin. REV 1.1 · 24 APRIL 2026 Updated schedule — realistic baseline DEFINITION OF READY — the distinction between assumptions and prerequisites Assumptions (page 1) are stated beliefs that may or may not hold. Prerequisites are deliverables that must physically exist and be signed off. The program should not advance past the Q1 2026 start gate until every item below is either in hand (green), with a committed date (amber), or has an explicit mitigation owner (red). Items flagged red are the short list of what must close before PO release to Foundry Partner, before first wafer out, and before the M1 cell validation milestone. READINESS LEGEND: Ready / in hand Partial / committed date Gap / mitigation required Status reflects assessment as of 24 April 2026; to be re-scrubbed weekly and at each phase gate. Technology — from Foundry Partner PDK — production-ready Digital + AMS views, major-vendor EDA flows. Currently non-functional in primary EDA flow — blocks design start. D5-02 / U1. Design Rule Manual (DRM) Latest revision with 3D-stack annotations; changes from 1B early draft must be delta-documented. SPICE models + corners TT / FF / SS / SF / FS + Monte Carlo; aging (BTI, HCI); temperature 0–85°C. Foundry Partner to deliver at PDK v1.0. Tech files (LEF, Milkyway, techLEF) For place-and-route flow. Expected with PDK v1.0. Parasitic extraction decks QRC / StarRC tech files at multiple corners. With PDK. DRC / LVS sign-off decks Sign-off decks; interim decks acceptable for block-level work. WAT + SPC coverage Wafer acceptance test spec, statistical process control data — needed to define redundancy + repair strategy. Fuse / redundancy spec Row / column repair scheme + fuse map definition. Foundry Partner to deliver Q3 2026. Technology — partners ALD Vendor ferroelectric ALD process Specs, integration flow, chamber qualification status. Path via Research Lab struck for alternative ALD per 21 Apr decision. Research Lab SL vehicle data Short-loop integration results, yield baseline, process window — needed to establish cell KPIs. Logic Foundry (via Interface Design Partner) base die PDK Base die process at Logic Foundry on 12LP+ equivalent; design rules, IP library. Partnership not yet signed. Stacking partner ADK Assembly Design Kit from W2W hybrid-bonding partner; face orientation + TSV rules. Partner TBD pending Foundry Country trip. Hybrid-bonding design rules Bond-pad pitch, alignment tolerance, overlay budget, retention tests. Partner-specific; TBD. EDA tool versions Major EDA vendor toolchains for layout, sign-off, and verification — versions compatible with Foundry Partner 1B PDK. JEDEC DDR5 spec version Target JESD79-5B or newer; scope of optional features (DFE taps, on-die ECC) locked. Legal + commercial agreements JDA: Client Co ↔ Foundry Partner Joint Development Agreement — scope, IP ownership, milestones, cost share, exclusivity window. Draft circulating. JDP: Client Co ↔ ALD Vendor Ferroelectric ALD process development. IP ownership resolution needed. D5-13. Service contract: Research Lab Short-loop vehicle development, integration support. Statement of Work to be finalized. Tech transfer + services: Logic Foundry + Interface Design Partner Base die design services from Interface Design Partner, manufacturing at Logic Foundry. Terms + pricing open. MOU / JDA: stacking partner W2W hybrid bonding. Partner identity, terms, and IP position all open pending Foundry Country trip. NDA coverage — all parties Bilateral NDAs in place for Foundry Partner, ALD Vendor, Research Lab, Interface Design Partner, Logic Foundry; multi-party NDA for stacking partner once identified. DDR5 IP license PHY + controller IP source (vendor vs in-house). License model open. U5. Export controls (EAR, EU dual-use) Jurisdictional review for memory + bonding tech; clearances where required. Team · infra · spec Full staffing plan Named core team is 8; benchmark peak is ~100–110. Staffing plan to close the delta is not yet written. See page 4. EDA licenses at peak scale License pool sized for ~100-engineer peak across major EDA vendors. Cost in consulting bucket. Compute cluster Full-chip P&R, STA, SPICE simulation capacity. Existing cluster may need expansion at Y2 peak. Physical site security Export-controlled design bays, clean-room access at partner sites. Reviewed at program start. Product spec frozen Product spec not closed before design start — already slipped. Owner: Spec Owner. D5-03. Customer target list + volume forecast AI data-center customers + initial volume assumptions; feeds business case + capacity planning. Business case / ROI model Charter covers cost side; revenue side + margin model needed before full commitment. Funding + governance Approved program budget Baseline ~$75M (range $60–97M) per page 5. Rev 1.1 of budget page must validate against Client Co finance model before commitment. Process / metrology tool capex Foundry-partner line tooling additions — TBD; excluded from current budget estimate. Must be sized post Foundry Country trip. Phase-gate governance SWIFT-style gate structure defined (Gate 2/3/4/5/6); gate criteria and voting membership to be baselined. Exec steering committee Chartered under Exec Sponsor. Monthly cadence, mandate and escalation path documented. Risk register baselined 25 tracked risks (9 Critical, 11 High) in DDR5 register as of 21 Apr. Weekly review cadence in place. Quarterly budget review Q1 2026 burn vs plan review cadence; variance thresholds + re-forecast triggers defined. Foundry Country trip + Foundry Partner scrub Planned May 2026. Fulcrum decision gate — closes hybrid-bonding tech, base-die partner, and PDK escalation. THE SHORT LIST — red-status items that must close before project can be declared “READY TO START” n Foundry Partner PDK operational in primary EDA flow + Design Rule Manual released — blocks design start. D5-02. n Hybrid-bonding partner selected with ADK + design rules in hand — blocks 3D stack architecture, base-die partner, stacking flow. D5-04. Foundry Country trip (May 2026) is the forcing function. n Base die partnership signed (Logic Foundry + Interface Design Partner terms + pricing) — blocks Track B and full-program M2 tapeouts. n Product spec frozen (owner: Spec Owner) — already slipped per 21 April scrub. D5-03. n Budget approval + exec sponsor mandate — PO authority to commit to Foundry Partner, Research Lab, ALD Vendor, and Interface Design Partner service contracts. Page 6 of 8 -- 30 of 44 -- Inputs mapped to schedule — when each prerequisite must be in hand Every item from page 6 placed at the quarter it must close to avoid becoming a critical-path blocker. Color = current readiness (green/amber/red from page 6). REV 1.1 · 24 APRIL 2026 Updated schedule — realistic baseline HOW TO READ Each row in a category lane is one prerequisite from page 6. Each marker sits in the quarter by which the item must be signed off and in hand for downstream work to start on time. A red marker means the item is currently a gap and its need-by date is approaching. The gate-load strip at the top counts prerequisites due per quarter — Q1 2026 carries the heaviest load because most items must close at project start. Vertical dashed lines mark M1–M5 milestones and the May 2026 Foundry Country trip. GATE LOAD items due / quarter 18 4 6 3 2 4 2026 2027 2028 2029 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Q1 Q2 Q3 Q4 Foundry Country trip M1 M2 M3 M4 M5 Tech — Foundry Partner PDK production-ready Design Rule Manual (DRM) SPICE models + corners Tech files (LEF, Milkyway) Parasitic extraction decks WAT + SPC coverage Fuse / redundancy spec DRC / LVS sign-off decks Tech — partners EDA tool versions JEDEC DDR5 spec version ALD Vendor process specs Research Lab SL vehicle data Logic Foundry base die PDK Stacking partner ADK Hybrid-bonding design rules Agreements JDA: Client Co ↔ Foundry Partner JDP: Client Co ↔ ALD Vendor Research Lab service contract NDA coverage (all) DDR5 IP license Export controls clearance Tech transfer: Logic Foundry + IDP MOU / JDA: stacking partner Team · infra · spec Product spec frozen Business case / ROI model Full staffing plan Physical site security Customer target + volume Compute cluster expanded EDA licenses at peak scale Funding + gov Approved program budget Phase-gate governance Exec steering committee Quarterly budget review Foundry Country trip + Foundry Partner scrub Process / metrology capex decision KEY DROP-DEAD DATES Q1 2026 18 items due Project-start gate — PDK, DRM, all core agreements, spec freeze, budget, governance Q2 2026 Foundry Country trip + 6 items Hybrid-bonding partner selection, ALD process, SPICE models, WAT coverage, volume forecast Q4 2026 Base die partnership gate Logic Foundry + Interface Design Partner terms signed, base die PDK available, parasitic extraction decks Q2 2027 Stacking partner gate ADK + hybrid-bonding rules in hand before M1 cell validation (Jun 2027) and base-die tapeouts LEGEND: Ready / in hand Partial / committed date Gap / mitigation required Gate-load heat (quarterly count, low → high) Use this page to drive a weekly pre-start scrub: walk from Q1 2026 forward; for each red marker, either upgrade status or re-baseline its need-by date. Do not accept “item pushed right” without checking the downstream lane it feeds. Page 7 of 8 -- 31 of 44 -- References & methodology Sources behind the resourcing and budget estimates — pages 4 and 5. Industry-benchmark synthesis, not a Client Co–costed plan. REV 1.1 · 24 APRIL 2026 Methodology & sources — added in Rev 1.1 ESTIMATION APPROACH — three principles that govern every figure on pages 4 and 5 1. Range, not point. Every figure carries a low/high band. The point estimate is the midpoint of converging sources, not a single vendor quote. 2. Two-source minimum. No headcount, rate, or unit cost is used unless at least two independent sources agree within ±25%. Where sources disagree, the wider range is shown. 3. Public benchmark, not vendor RFQ. These figures come from public industry research and peer-program benchmarks — not Foundry Partner, Logic Foundry, Interface Design Partner, or stacking-partner quotes. Vendor quotes replace them in Rev 2.0. Methodology — how each estimate was built How resourcing (page 4) was derived • Peak headcount range pulled from published 16 Gb / 1y-nm DDR5 design programs at Tier-1 memory vendors — disclosed indirectly via author counts on industry conference papers, technology disclosure sessions, and analyst headcount tracking. • SME mix percentages (22% physical / 20% periphery / 18% array / 12% verif / 12% I/O / 8% AMS / 5% architect / 3% test) are a composite from publicly indexed SoC and DRAM team allocations, cross-checked with two recent peer programs. • Engineer-months are headcount × duration, not bottom-up from a work breakdown. Bottom-up sizing arrives in Rev 2.0 from the staffing-plan owner. • Time-phased curve (Architecture → Block → Integration → T/O → Si debug → Qual) follows the standard chip-program shape; phase boundaries calibrated to Rev 1.4 milestones. How budget (page 5) was derived • Tape-out cost = mask-set cost (foundry-published ranges for advanced nodes) + first-lot wafer cost. Assumes 2–3 all-layer + 1–2 metal spins per die. • FTE rates are fully-loaded (salary + benefits + overhead + facilities), regional 2026 prices, no inflation escalator. Region B ~$17K/mo and Asia blended ~$9K/mo are midpoints of three independent regional surveys. • Hybrid-bonding lot cost assumes industry-typical W2W pricing at production-density pitch — the largest single uncertainty in the wafer line. • Consulting line items are scoped at the work-package level, not by day rate. DDR5 IP licensing dominates. Confidence per category • Wafer development: ±25% — mask-cost variance is the largest driver. • FTE engineering: ±15% — rates are well-benchmarked; total engineer-month count drives the variance. • Consulting: ±30% — depends on IP licensing path (vendor vs in-house) and external lab scope. Resourcing benchmarks — page 4 sources Standards & specifications • Industry standard DDR5 SDRAM specification (defines protocol complexity that drives team size). • Industry standard HBM3 specification (hybrid-bonding precedent for stack discipline). • Industry 3D-IC integration standards series. Industry research reports • Cost-of-IC-design research firm — advanced-node report series. • Node-level economics analyst — IC cost model and node-level economics, recent editions. • 3D integration & hybrid-bonding research firm — memory industry & market trends; annual reports. • Teardown analyst — DRAM teardown analyses (1y-nm class, 16 Gb DDR5 SKUs). • Memory R&D analyst — published estimates on memory program R&D scale. Conference proceedings • Industry conference proceedings — DDR5 sessions; 1α / 1β / 1γ-class papers from Tier-1 memory vendors. • Symposium on technology & circuits — process and circuit papers, same vendors. • Electron device meeting — 1y-nm DRAM cell scaling and integration papers. • Design & test journal — chip-program productivity studies. EDA / IP product data • IP Vendor A DDR5 PHY + controller — public product briefs. • IP Vendor B DDR5 PHY + memory controller IP — public product briefs. • IP Vendor C DDR5 PHY — public datasheets. Budget benchmarks — page 5 sources Mask & tape-out cost • Cost-of-IC-design research firm — mask-cost-by-node tables, 1y-nm class, current editions. • Node-level economics analyst — wafer cost, mask cost, lot pricing models. • Foundry public guidance: Tier-1 foundries annual reports + investor updates; Logic Foundry base-die node cost via Interface Design Partner channel. • Memory R&D analyst — published mask + wafer cost estimates by node. Hybrid-bonding & 3D integration • 3D integration & hybrid-bonding research firm — cost-of-ownership reports. • Industry 3D IC working group — pricing benchmarks at production density. • Hybrid-bonding tool & IP vendors — public statements on hybrid-bonding cost trajectories and tooling. Engineer rates by region • Region B: regional compensation surveys (3 independent sources). • Foundry Country: semiconductor salary surveys + market intelligence. • Region D: semiconductor compensation surveys + tier-1 recruiter data. • Region E: industry strategic reviews + tier-1 MNC published bands. DDR5 IP licensing & external services • IP Vendors A / B / C — public IP product pricing where disclosed; analyst commentary on DDR-class license cost ranges. • Reliability / qual labs: industry standard day-rate bands for JEDEC qual programs; ELFR study cost benchmarks from peer DRAM programs. Internal & program references Internal Client Co documents, Strategic Advisor methodology, and the Rev-1.4 schedule baseline that drive the duration assumptions on pages 4 and 5. These are the program-specific inputs that calibrate the public benchmarks. Client Co program documents • DDR5 product brief — Persistent Memory Solutions for Efficient AI Scale-out (Client Co). • Go-to-Market Core Teams — Foundry Partner 1B 16 Gb 3D DDR5 NV-DRAM track (Exec Sponsor; Product Boss; TPM; et al.). • DDR5 Risk Register — 25 risks (9 Critical, 11 High), 21 April 2026 baseline. • 21 April 2026 milestone scrub — source of the Rev 1.4 schedule that drives p4 and p5 duration assumptions. • DDR5 estimates workbook (Client Co internal). • Client Co sister program — Sister Foundry 25 nm 4 Gb DDR4 NV-DRAM: peak headcount, spend, and schedule comparator. • Foundry Partner PDK status disclosures — primary EDA flow non-functional issue, D5-02. • ALD Vendor JDP draft — alternative ALD path, 21 April decision. Strategic Advisor methodology • FTTM (Fast Time To Market) framework — phase-gate structure, milestone discipline. • Strategic Advisor project charter standard — the structure of this document. • Strategic Advisor SOW templates and white-paper standard. Charter prior revisions • Rev 1.0 — initial baseline (early April 2026). • Rev 1.1 (this revision) — 24 April 2026, updated schedule realistic baseline; references page added. • Rev 1.4 schedule — referenced in p2 and elsewhere as the committed milestone calendar. • Rev 2.0 — planned post Foundry Country trip (May 2026); replaces benchmark-based costs with vendor quotes. RECONCILIATION PLAN — what must close before Rev 2.0 commits the numbers 1. Vendor quotes replace benchmark ranges. Wafer line items switch from public-benchmark midpoint to actual quotes from Foundry Partner, Research Lab, ALD Vendor, Logic Foundry/Interface Design Partner, and the stacking partner. Expected delta: ±20% per line. 2. HR rate validation. Client Co HR provides actual fully-loaded rates by location and seniority — replaces the ~$17K / $9K regional midpoints. Expected delta: ±10%. 3. Bottom-up staffing plan. Delta from 8-person core to ~110-engineer peak is a real plan owned by TPM and Product Boss — not an industry curve overlay. Engineer-months recompute against that plan. 4. IP licensing decision. DDR5 PHY + controller: vendor (IP Vendor A / B / C) vs in-house. Outcome moves the consulting line by $1–3M. 5. Process / metrology tool capex. Currently excluded from p5; sized post Foundry Country trip. Could shift the total envelope by 10–25% if treated as program cost rather than partner capex. 6. Inflation escalator. 2026 prices held flat across 4 years; finance to apply standard escalator in Rev 2.0 — likely +3–6% over the program window. Page 8 of 8 -- 32 of 44 -- PROJECT SCOPE Project Beta (12-inch Driver Node X/Target FET Fab FET Version) Generic re-skin Source: Project Beta Macro workbook Project Scope · Page 1 of 4 GOAL Release Driver Node X driver with both Legacy FET Fab and Target FET Fab FETs Project Beta by Q4'2027 SUCCESS CRITERIA 9 items • Gen 3 SGMOS FETs successfully ported from 8-inch Legacy FET Fab to 12-inch Target FET Fab fab with process qualified by Q1 2027 • Standalone Driver Node X BCD Lite HPC driver IC reaches final silicon tape out by Q2 2027 within ~2 all-layer tapeouts (A0, B0) • Performance equivalence demonstrated between Project Alpha and Project Beta modules • 12-inch end-to-end module manufacturing flow proven out including FSM, BG/BSM (glass bonding), probe, RDL+bump, embedding, and assembly • Full JEDEC and End Customer-specific qualification passed (not by similarity to Project Alpha) • PCN approval obtained from Customer Tier customers prior to MP release (Prior or after?) • Target gross margin of 50% achieved through internalization and COGS reduction • Target FET Fab fab able to autonomously support production volumes with all tooling gaps closed • ELFR study confirms 20 dppm target on production candidate module (post-MP) ASSUMPTIONS 9 items • SGMOS Gen 3 FET Legacy FET Fab-to-Target FET Fab port: process qual target Q1 2027. Requires CAPEX approval and tooling investment • Driver Node X BCD HPC Lite foundry development is ongoing and will not affect critical path - driver silicon expected ready before FET fab readiness • Standalone Driver IC for Project Beta requires ~2 all-layer tapeouts (A0, B0). PDK version and T/O date need to be confirmed • Initial Driver Node X tapeout planned for August. Preliminary build will use Project Alpha FETs (Legacy FET Fab) • Target FET Fab will be ready to start running protolots by Q1 2027. • BG/BSM for 12-inch will use glass bonding (differs from Project Alpha Taiko-based process) • 12-inch can do probe at Mid-end OSAT. RDL+Bump at Bump OSAT • POD is FET wafer size agnostic - 8-inch FET + 12-inch driver lookahead build is viable • Qual and validation must be repeated due to mfg flow differences - cannot qualify by similarity from Project Alpha RISKS 8 items • Target FET Fab process qualification delay - any slip from Q1 2027 target pushes the entire Project Beta timeline since Target FET Fab FETs are the gating dependency • Driver Node X PDK maturity - foundry must deliver PDK at sufficient maturity for design tapeout; delays here impact driver silicon schedule • Gen 3 FETs may not meet expected metrics on 12-inch Target FET Fab, particularly if 50-micron backgrind is required. Gen 2.5 FETs are fallback • CAPEX approval and tooling investment for Target FET Fab - required for production volume support, timeline depends on EC approval • Glass bonding process for 12-inch BG/BSM is new and differs from Project Alpha Taiko process - yield and reliability risk • TDC thermal performance - risk of lower thermal dissipation requiring heat slug redesign or mold compound changes • Mold void under IC driver - requires DOE for mold parameters and mold flow simulation at assembly sites • Embedded substrate product for NPI is new - high reliability risk requiring look-ahead reliability data from Reference Program A/Reference Program B/Project Alpha programs Page 1 of 4 -- 33 of 44 -- MAJOR MILESTONES Milestones M1–M3 · M-id, summary task, doneness criteria, subtasks, assumptions, and risks Generic re-skin Source: Project Beta Macro workbook Major Milestones · Page 2 of 4 M1 12-inch Module Flow Mid-End Capability for 12 inch (post fab processing FET- FSM, BGBM , Driver - RDL/Bump) DONENESS (5) • 8/12-inch Target FET Fab FSM capability established at Mid-end OSAT • 8/12-inch Target FET Fab BG/BM with glass bonding proven out at Mid-end OSAT • 12-inch probe hardware verified for FET • 12 -inch probe hardware verified for Driver • RDL+Bump Capability at Bump OSAT for 12-inch driver SUBTASKS (7) • Execute Mechanical wafers shortflow for FET ( BEOL masks) • Execute Mechanical wafers shortflow for Driver (BEOL masks, RDL , BUMP Masks) • Verify Probe Touchdown on 12 inch wafers • Embed FET mechanical wafers • Characterize FA, Warpage and process • Complete and sign-off SWIFT Gate 2 Deliverables for the Module • Complete and sign-off SWIFT Gate 3 Deliverables for the Module ASSUMPTIONS (3) • Driver Node X Mech wafers , Target FET Fab Mech Wafers, Bump Mask and Stencil TO complete at Bump OSAT • Capacity is secured with Mid-end OSAT and Bump OSAT and manufacturing flow is frozen • 12inch FET development and Driver Node X driver development are sufficiently advanced to do BEOL tape-outs to generate Mechanical wafers RISKS (5) • Glass bonding process yield and reliability unknown - new for this product • FSM/BGBM 12-inch schedules at Mid-end OSAT still TBD - late start could delay module builds • Equipment qualification at new sites may uncover unexpected process gaps • Multiple new process steps simultaneously increase integration risk • if unable to secure capacity , then mid end and back end manufcaturing flow could change M2 Driver Node X Process Flow Driver Node X Process Flow Frozen DONENESS (4) • Production ready PDK available • Driver Node X foundry running HPC Lite technology qualification lots with high confidence to finish and pass qual by 1Q27 • Driver Node X HPC lite process flow fully ready with manufacturing controls, SPC , WAT coverage • Driver Node X allowing fabrication and stock up of 12 inch full flow FET wafers for Project Beta Module Development SUBTASKS (5) • Release PDK • Freeze process • Tech Qual lot and qual execution • Conduct Process readiness review with PG • Tech production release safe launch Plan ASSUMPTIONS (1) • high confidence process freeze with no major changes to process or PDK expected RISKS (2) • Tech qual fails could drive major changes to process or PDK , this will impact Driver die B0 tapeout and Module schedule • 5V CMOS unable to achieve PDK -0 maurity in time M3 Gen 3 FET 12-inch Target FET Fab Gen 3 SGMOS FET process frozen DONENESS (3) • Legacy FET Fab to Target FET Fab Process Transfer complete - parametric and wafer level reliability equiavlence proven • All tooling gaps closed for Target FET Fab to autonomously support production volumes • Technology Transfer Phase Gate process executed with evidence SUBTASKS (7) • Tool up Target FET Fab fab for Gen 3 SGMOS process leverage Reference Tool Fab tools for gaps • Tapeout eval vehicle and run learning cycles (by Q1 2026) • Tapeout SGMOS3 (Q4 202- and generate POR wafers • WAT and Product yield meet yield and parametric match entitlement criterion • Driver probe ready for yield and parametric data review • Develop plan to Close remaining tooling gaps for autonomous production support • Conduct Technology safe launch plan ASSUMPTIONS (2) • CAPEX approval and investment for Target FET Fab tooling • Legacy FET Fab to Target FET Fab transfer tracking to commited plan from IM RISKS (5) • Significant differences in performance between Legacy FET Fab and Target FET Fab FETs requiring more process tuning learning cycles than anticpated • Gen 3 FETs may not meet expected metrics on 12-inch, particularly with 50-micron backgrind • CAPEX approval delay for tooling investment • Tooling gaps between Target FET Fab and Reference Tool Fab may be larger than expected • Any unanticipated delays in process transfer Page 2 of 4 -- 34 of 44 -- MAJOR MILESTONES Milestones M4–M6 · M-id, summary task, doneness criteria, subtasks, assumptions, and risks Generic re-skin Source: Project Beta Macro workbook Major Milestones · Page 3 of 4 M4 Lookahead Module Build Lookahead module with 8-inch FETs + 12-inch Driver Node X driver built, validated and look ahead qualified DONENESS (4) • Functional Module build , Mid End and Back-end processing • (8inch Legacy FET Fab + Reference Wafer Source is preferred path) • Module Build Validation and Look ahead qualification • Learnings/ Errata related to driver die funneled back to driver IC design team SUBTASKS (12) • Source 8-inch FET wafers from Legacy FET Fab.and driver die from Driver Foundry • Validate Driver die A0 silicon (WB package) • Substrate readiness (stencil changes) to enable Driver Node X driver • Embedded Laminate ready and staged at Assy • Assemble lookahead modules using Driver Node X driver + 8-inch FETs • Characterize and validate module • RCM with right matrity level for this variant • Create qual plan • Qualify and validate hardware sourced and ready • Complete SWIFT Gate 4 deliverables for Driver IC A0 • Complete SWIFT Gate 4 deliverables for Module for 8inch FET + Driver Node X A0 Driver • Complete SWIFT Gate 2 and Gate 3 deliverables for Driver IC ASSUMPTIONS (5) • 1PCB POD is FET wafer size agnostic - 8-inch/12-inch mix is viable • Driver Node X HPC Lite 5V CMOS PDK reaches sufficient maturity (PDK V0.x?) • Driver Node X driver silicon available from before Target FET Fab FETs • Project Alpha team is able to spare some 8 inch laminates for Project Beta • team to use 8inch FET + Driver Node X Driver is part of Project Beta scope. Both variants will be released simulatnaeously RISKS (1) • Driver Node X process is not fully matured (final PDK) by A0 tapeout resulting in dirver performance differences M5 12-inch Module Flow Target FET Fab 12 inch production flow with A0 driver built DONENESS (5) • Functional Module build on full 12inch flow • Process CZ reports from all OSATs on inline data • Packaging updates PG on remaining risk /process improvements • Module Validation and Lookahead qualification with A0 driver • End-to-end cycle time and yield targets demonstrated SUBTASKS (4) • Fab Driver Node X Driver die protolot and bump • Fab FET protolot through Target FET Fab, FSM, BGBM and embedding • Conduct SWIFT Gate 3 review for Driver B0 Die • Conduct Module Gate 4 review for 12 inch FET + Driver Node X A0 Driver ASSUMPTIONS (1) • Any process optimizations for Mid End and Back-end from M2 are in place before running M5 RISKS (4) • Glass bonding process yield and reliability unknown - new for this product • FSM/BGBM 12-inch schedules at Mid-end OSAT still TBD - late start could delay module builds • Equipment qualification at new sites may uncover unexpected process gaps • Multiple new process steps simultaneously increase integration risk M6 Project Beta Module Build Modules with 12-inch FETs + B0 Driver Node X driver built DONENESS (5) • B0 G55 drive tape out completed • 12-inch Target FET Fab FETs completed through post-fab processing (FSM/probe/BGBM) in final mfg flow • Embedded substrate processed through final mfg flow frozen • B0 Driver Node X driver probed/BGGM through final mfg flow • Module assembled through final mgf flow (POR flow frozen) SUBTASKS (7) • Tape out FETs to Target FET Fab-only process • Determine scope of B0 changes based on A0 results • Tape out B0 driver to Driver Foundry • Qualify post-fab flow and assembly for both Target FET Fab and Driver Node X • Complete post-fab processsing for both Target FET Fab FETs/Legacy FET Fab and Bo Driver Node X driver • Assemble modules through qualified mfg flow • Complete SWIFT Gate 2 and Gate 3 deliverables for B0 Driver IC ASSUMPTIONS (3) • Target FET Fab and Driver Node X flows are frozen • 12-inch module flow proven out • Performance equivalence to Project Alpha is a pass/fail requirement RISKS (4) • DC thermal performance may not match Project Alpha • Mold void under IC driver (DOE and mold flow simulation required) • Capacitor cracking or delamination during reflow • First-time integration of all 12-inch components Page 3 of 4 -- 35 of 44 -- MAJOR MILESTONES Milestones M7–M9 · M-id, summary task, doneness criteria, subtasks, assumptions, and risks Generic re-skin Source: Project Beta Macro workbook Major Milestones · Page 4 of 4 M7 Customer Samples Customer samples shipped (ES or above) DONENESS (4) • E1 validation completed • LAR (or equivalent risk release) completed • Review data and get sample shipment approval • Engineering samples delivered to Customer Tier (Quantity TBD) SUBTASKS (2) • Determine sample quantity and plan builds accordingly • Complete SWIFT module Gate 4 deliverables ASSUMPTIONS (1) • Project Alpha and Project Beta show no differences per internal validation RISKS (1) • Might need to increase risk builds if yields are not up to standards at this point M8 Qual & Validation Legacy FET Fab and Target FET Fab FETs qualified and validated DONENESS (4) • Full qual completed for both POR flows per agreed upon qual plan • Si bench B0 validation completed across full operating conditions, temperature, and voltage range per RCM • ATE test program 100% complete and characterization completed across temperature and voltage per RCM • RCM fully satisfied and equivalent to Project Alpha SUBTASKS (8) • Develop Qual test program with transient completed • Seup ENG Handler • Conduct stress tests, review test data and analyze delta • Develop characterization test program • Characterize and review data • Validate (full bench) • Conduct Characterization and Validation reviews • Complete SWIFT module Gate 4 and 5 deliverables ASSUMPTIONS (4) • End Customer and AI task force qual requirements are included in qual plan • Manufacturing flow differences (12-inch wafers, glass bonding vs Taiko, different fab sites) drive incremental quals • Qual hardware is available from IQT/LAR activities • ELFR study for 20 dppm will not gate release - follows after MP release RISKS (3) • Qualification failure requiring design or process changes would add significant delay • Reliability failure on embedded substrate • IMON accuracy may not meet PRD specs (new trimming procedures under investigation) M9 PCN Issued & Product Release PCN issued to customers and Project Beta released to market DONENESS (5) • Process Change Notification submitted to Customer Tier • Manufacturing flow, test programs, and supply chain locked • Product declared mass production ready • Datasheets published and part numbers orderable • Production stocking in place SUBTASKS (5) • Prepare PCN documentation covering Project Alpha to Project Beta differences • Submit PCN to Customer Tier for approval • Lock test programs • Complete SWIFT module Gate 6 deliverables • Publish datasheets and enable ordering ASSUMPTIONS (2) • Overlap period planned: both Project Alpha and Project Beta in production before Project Alpha phase out • Safe launch and ELFR study will not gate release - post-MP activities RISKS (2) • Customer PCN approval delay or rejection • Customer requires additional testing or data beyond standard PCN package Page 4 of 4 -- 36 of 44 -- MAJOR MILESTONES Project Beta · M1–M9 · M-id, summary task, doneness criteria, subtasks, assumptions, and risks · generic re-skin Source: Project Beta Macro workbook · 9 milestones M# Summary Task Title Doneness Criteria Subtasks Assumptions Risks M1 12-inch Module Flow Mid-End Capability for 12 inch (post fab processing FET- FSM, BGBM , Driver - RDL/Bump) • 8/12-inch Target FET Fab FSM capability established at Mid-end OSAT • 8/12-inch Target FET Fab BG/BM with glass bonding proven out at Mid-end OSAT • 12-inch probe hardware verified for FET • 12 -inch probe hardware verified for Driver • RDL+Bump Capability at Bump OSAT for 12-inch driver • Execute Mechanical wafers shortflow for FET ( BEOL masks) • Execute Mechanical wafers shortflow for Driver (BEOL masks, RDL , BUMP Masks) • Verify Probe Touchdown on 12 inch wafers • Embed FET mechanical wafers • Characterize FA, Warpage and process • Complete and sign-off SWIFT Gate 2 Deliverables for the Module • Complete and sign-off SWIFT Gate 3 Deliverables for the Module • Driver Node X Mech wafers , Target FET Fab Mech Wafers, Bump Mask and Stencil TO complete at Bump OSAT • Capacity is secured with Mid-end OSAT and Bump OSAT and manufacturing flow is frozen • 12inch FET development and Driver Node X driver development are sufficiently advanced to do BEOL tape-outs to generate Mechanical wafers • Glass bonding process yield and reliability unknown - new for this product • FSM/BGBM 12-inch schedules at Mid-end OSAT still TBD - late start could delay module builds • Equipment qualification at new sites may uncover unexpected process gaps • Multiple new process steps simultaneously increase integration risk • if unable to secure capacity , then mid end and back end manufcaturing flow could change M2 Driver Node X Process Flow Driver Node X Process Flow Frozen • Production ready PDK available • Driver Node X foundry running HPC Lite technology qualification lots with high confidence to finish and pass qual by 1Q27 • Driver Node X HPC lite process flow fully ready with manufacturing controls, SPC , WAT coverage • Driver Node X allowing fabrication and stock up of 12 inch full flow FET wafers for Project Beta Module Development • Release PDK • Freeze process • Tech Qual lot and qual execution • Conduct Process readiness review with PG • Tech production release safe launch Plan • high confidence process freeze with no major changes to process or PDK expected • Tech qual fails could drive major changes to process or PDK , this will impact Driver die B0 tapeout and Module schedule • 5V CMOS unable to achieve PDK -0 maurity in time M3 Gen 3 FET 12-inch Target FET Fab Gen 3 SGMOS FET process frozen • Legacy FET Fab to Target FET Fab Process Transfer complete - parametric and wafer level reliability equiavlence proven • All tooling gaps closed for Target FET Fab to autonomously support production volumes • Technology Transfer Phase Gate process executed with evidence • Tool up Target FET Fab fab for Gen 3 SGMOS process leverage Reference Tool Fab tools for gaps • Tapeout eval vehicle and run learning cycles (by Q1 2026) • Tapeout SGMOS3 (Q4 202- and generate POR wafers • WAT and Product yield meet yield and parametric match entitlement criterion • Driver probe ready for yield and parametric data review • Develop plan to Close remaining tooling gaps for autonomous production support • Conduct Technology safe launch plan • CAPEX approval and investment for Target FET Fab tooling • Legacy FET Fab to Target FET Fab transfer tracking to commited plan from IM • Significant differences in performance between Legacy FET Fab and Target FET Fab FETs requiring more process tuning learning cycles than anticpated • Gen 3 FETs may not meet expected metrics on 12-inch, particularly with 50-micron backgrind • CAPEX approval delay for tooling investment • Tooling gaps between Target FET Fab and Reference Tool Fab may be larger than expected • Any unanticipated delays in process transfer M4 Lookahead Module Build Lookahead module with 8-inch FETs + 12-inch Driver Node X driver built, validated and look ahead qualified • Functional Module build , Mid End and Back-end processing • (8inch Legacy FET Fab + Reference Wafer Source is preferred path) • Module Build Validation and Look ahead qualification • Learnings/ Errata related to driver die funneled back to driver IC design team • Source 8-inch FET wafers from Legacy FET Fab.and driver die from Driver Foundry • Validate Driver die A0 silicon (WB package) • Substrate readiness (stencil changes) to enable Driver Node X driver • Embedded Laminate ready and staged at Assy • Assemble lookahead modules using Driver Node X driver + 8-inch FETs • Characterize and validate module • RCM with right matrity level for this variant • Create qual plan • Qualify and validate hardware sourced and ready • Complete SWIFT Gate 4 deliverables for Driver IC A0 • Complete SWIFT Gate 4 deliverables for Module for 8inch FET + Driver Node X A0 Driver • Complete SWIFT Gate 2 and Gate 3 deliverables for Driver IC • 1PCB POD is FET wafer size agnostic - 8-inch/12-inch mix is viable • Driver Node X HPC Lite 5V CMOS PDK reaches sufficient maturity (PDK V0.x?) • Driver Node X driver silicon available from before Target FET Fab FETs • Project Alpha team is able to spare some 8 inch laminates for Project Beta • team to use 8inch FET + Driver Node X Driver is part of Project Beta scope. Both variants will be released simulatnaeously • Driver Node X process is not fully matured (final PDK) by A0 tapeout resulting in dirver performance differences M5 12-inch Module Flow Target FET Fab 12 inch production flow with A0 driver built • Functional Module build on full 12inch flow • Process CZ reports from all OSATs on inline data • Packaging updates PG on remaining risk /process improvements • Module Validation and Lookahead qualification with A0 driver • End-to-end cycle time and yield targets demonstrated • Fab Driver Node X Driver die protolot and bump • Fab FET protolot through Target FET Fab, FSM, BGBM and embedding • Conduct SWIFT Gate 3 review for Driver B0 Die • Conduct Module Gate 4 review for 12 inch FET + Driver Node X A0 Driver • Any process optimizations for Mid End and Back-end from M2 are in place before running M5 • Glass bonding process yield and reliability unknown - new for this product • FSM/BGBM 12-inch schedules at Mid-end OSAT still TBD - late start could delay module builds • Equipment qualification at new sites may uncover unexpected process gaps • Multiple new process steps simultaneously increase integration risk M6 Project Beta Module Build Modules with 12-inch FETs + B0 Driver Node X driver built • B0 G55 drive tape out completed • 12-inch Target FET Fab FETs completed through post-fab processing (FSM/probe/BGBM) in final mfg flow • Embedded substrate processed through final mfg flow frozen • B0 Driver Node X driver probed/BGGM through final mfg flow • Module assembled through final mgf flow (POR flow frozen) • Tape out FETs to Target FET Fab-only process • Determine scope of B0 changes based on A0 results • Tape out B0 driver to Driver Foundry • Qualify post-fab flow and assembly for both Target FET Fab and Driver Node X • Complete post-fab processsing for both Target FET Fab FETs/Legacy FET Fab and Bo Driver Node X driver • Assemble modules through qualified mfg flow • Complete SWIFT Gate 2 and Gate 3 deliverables for B0 Driver IC • Target FET Fab and Driver Node X flows are frozen • 12-inch module flow proven out • Performance equivalence to Project Alpha is a pass/fail requirement • DC thermal performance may not match Project Alpha • Mold void under IC driver (DOE and mold flow simulation required) • Capacitor cracking or delamination during reflow • First-time integration of all 12-inch components M7 Customer Samples Customer samples shipped (ES or above) • E1 validation completed • LAR (or equivalent risk release) completed • Review data and get sample shipment approval • Engineering samples delivered to Customer Tier (Quantity TBD) • Determine sample quantity and plan builds accordingly • Complete SWIFT module Gate 4 deliverables • Project Alpha and Project Beta show no differences per internal validation • Might need to increase risk builds if yields are not up to standards at this point M8 Qual & Validation Legacy FET Fab and Target FET Fab FETs qualified and validated • Full qual completed for both POR flows per agreed upon qual plan • Si bench B0 validation completed across full operating conditions, temperature, and voltage range per RCM • ATE test program 100% complete and characterization completed across temperature and voltage per RCM • RCM fully satisfied and equivalent to Project Alpha • Develop Qual test program with transient completed • Seup ENG Handler • Conduct stress tests, review test data and analyze delta • Develop characterization test program • Characterize and review data • Validate (full bench) • Conduct Characterization and Validation reviews • Complete SWIFT module Gate 4 and 5 deliverables • End Customer and AI task force qual requirements are included in qual plan • Manufacturing flow differences (12-inch wafers, glass bonding vs Taiko, different fab sites) drive incremental quals • Qual hardware is available from IQT/LAR activities • ELFR study for 20 dppm will not gate release - follows after MP release • Qualification failure requiring design or process changes would add significant delay • Reliability failure on embedded substrate • IMON accuracy may not meet PRD specs (new trimming procedures under investigation) M9 PCN Issued & Product Release PCN issued to customers and Project Beta released to market • Process Change Notification submitted to Customer Tier • Manufacturing flow, test programs, and supply chain locked • Product declared mass production ready • Datasheets published and part numbers orderable • Production stocking in place • Prepare PCN documentation covering Project Alpha to Project Beta differences • Submit PCN to Customer Tier for approval • Lock test programs • Complete SWIFT module Gate 6 deliverables • Publish datasheets and enable ordering • Overlap period planned: both Project Alpha and Project Beta in production before Project Alpha phase out • Safe launch and ELFR study will not gate release - post-MP activities • Customer PCN approval delay or rejection • Customer requires additional testing or data beyond standard PCN package Generic re-skin · all program names, fabs, OSATs, foundries, and customers substituted Page 1 of 1 -- 37 of 44 -- Strategic Advisor › × Client Co PROGRAM MILESTONE TIMELINE Fab1 | Foundry Partner 1B DRAM + DRAM+ (FeCAP) | Region B | 14,000 sqm GMA | Project start: Jan 1, 2027 April 2026 status | Rev 2.0 Program: Jan 2027 – Mar 2031 (50 months) $4.9B total | Peak: ~1,000 onsite M1 Site Selected & Acquired Jan '27 50 staff M2 Foundry Partner license signed Feb '27 30 staff M3 Environmental Permit issued Mar '27 40 staff M4 EPC Partner L0 design start Apr '27 100 staff M5 Long-lead tool POs placed May '27 50 staff M6 Groundbreaking Jun '27 200 staff M7 Fab weathertight May '28 600 staff M8 Fab shell complete Nov '28 800 staff M9 RFE — EPC Partner target Dec '28 1000 staff M10 RFE — Federal Baseline Jun '29 1000 staff M11 Baseline DRAM qualified May '30 400 staff M12 First revenue / Phase 1 qual Sep '30 300 staff M13 DRAM+ (FeCAP) qualified Mar '31 350 staff 2027 Q1 Q2 Q3 Q4 2028 Q1 Q2 Q3 Q4 2029 Q1 Q2 Q3 Q4 2030 Q1 Q2 Q3 Q4 2031 Q1 Q2 Q3 Setup & Permit Construction Tool Install Process Qual Production KEY METRICS Exec Sponsor: Exec Sponsor / CEO | CEO: Exec Sponsor / CEO | Procurement: Procurement Lead | Finance: Finance Lead | EPC: EPC Partner (Reference Fab A / Reference Fab B reference) Foundry: Foundry Partner 1B DRAM license | Process: Classical DRAM + DRAM+ FeCAP | Capacity: 20,000 WSPM Phase 1, 100,000 WSPM Phase 2 | Funding: $4.9B (Sovereign Chips Grant $2.875B / 58%) Pre-project status (April 2026): site undecided (FAB-01), Foundry Partner unsigned (FAB-02), EPC Partner design not started (FAB-03) | Project start M0 = Jan 1, 2027 (Site Selected & Acquired) | First Revenue M44 = Sep 2030 -- 38 of 44 -- Strategic Advisor › × Client Co MILESTONE DETAILS Fab1 | 13 milestones | Site Selected & Acquired through DRAM+ (FeCAP) qualified April 2026 status | Rev 2.0 Project M0 = Jan 1, 2027 Sequencing: Jan '27 → Mar '31 M1 Jan '27 Site Selected & Acquired Region A vs Region B resolved. Land acquisition closed. SPV established. All downstream gates now unblocked. 50 staff | Project kickoff | M0 M2 Feb '27 Foundry Partner license signed Foundry Partner Technology license executed. Detailed tool list and process consumption data released to EPC Partner and Client Co. 30 staff | Foundry Partner transfer | M1 M3 Mar '27 Environmental Permit issued Full federal environmental permit (Environmental Permit) granted. Partial Permit enabled earth works at M2 ahead of full permit. 40 staff | Permitting + legal | M2 M4 Apr '27 EPC Partner L0 design start EPC Partner L0 Pre-Concept design contract issued and funded. Every month of L0 delay slips RFE one-for-one. 100 staff | EPC Partner design ramp | M3 M5 May '27 Long-lead tool POs placed Binding POs issued for Lithography Vendor lithography (28 tools) and ALD Vendor. 18 to 24 month lead times locked. $800M committed. 50 staff | Procurement + finance | M4 M6 Jun '27 Groundbreaking EPC Partner mobilisation. Earth works begin under partial permit (Partial Permit). Site cleared and foundations started. 200 staff | Construction mobilisation | M5 M7 May '28 Fab weathertight Building shell closed. Off-Site Manufacturing (OSM) MEP modules begin install. Cleanroom fit-out commences. 600 staff | Peak civil + MEP | M16 M8 Nov '28 Fab shell complete Full structural and envelope completion. Cleanroom and sub-fabs ready for tool delivery. 800 staff | Pre-RFE peak | M22 M9 Dec '28 RFE — EPC Partner target Ready For Equipment per EPC Partner 14,000 sqm GMA gantt. Achievable via OSM + Partial Permit. Stretch target. 1000 staff | Tool install ramp | M23 M10 Jun '29 RFE — Federal Baseline Federal Baseline RFE. 6 months later than EPC Partner target. Current optimistic scenario for qualification start. 1000 staff | Tool install peak | M29 M11 May '30 Baseline DRAM qualified Foundry Partner-licensed baseline DRAM process qualified on Fab1 tools. Gate to all downstream product runs. 400 staff | Process qual team | M40 M12 Sep '30 First revenue / Phase 1 qual Phase 1 product qualification complete. First revenue from 20k WSPM Classical DRAM. $300M to 900M per year by 2031. 300 staff | Production ramp | M44 M13 Mar '31 DRAM+ (FeCAP) qualified Ferroelectric capacitor (FeCAP) DRAM+ technology integrated and qualified. $1B+ per year by 2031 per Fab1 forecast. 350 staff | FeCAP integration | M50 -- 39 of 44 -- Strategic Advisor › × Client Co FAB1 — MACRO SCHEDULE WITH RISK ANALYSIS Fab1 | Foundry Partner 1B DRAM + DRAM+ (FeCAP) | Region B | 14,000 m² GMA | $4.9B | Project start: Jan 1, 2027 (Site Selected & Acquired) April 2026 status | Rev 2.0 Program: Jan 2027 – Mar 2031 (50 months) 13 milestones · 15 phases Phase / Activity Governance Permitting Engineering Procurement Construction Cleanroom/OSM Tool Install Qualification Production Revenue (green) At-risk (gray) Baseline (blue) Permitting (teal) Critical (red) 2027 Q1 Q2 Q3 Q4 2028 Q1 Q2 Q3 Q4 2029 Q1 Q2 Q3 Q4 2030 Q1 Q2 Q3 Q4 2031 Q1 Q2 Legal Entity, SPV & SBLC Financing M0–M9 Foundry Partner Tech License & Transfer M0–M15 Environmental Permit (Region B) M0–M3 Utility, Grid & Wind PPA Agreements M0–M5 EPC Partner Design L0–L3 M2–M11 Long-Lead Tool Orders (Litho, ALD, Etch, CMP) M3–M25 Earth Works & Site Prep (Partial Permit) M2–M6 Civil Works & Building Shell M5–M16 Cleanroom Fit-out & Sub-fabs (OSM) M16–M22 Utility Systems (DI Water, Gases, Power) M18–M23 Tool Delivery & Installation M22–M27 Tool Qualification (IQ/OQ/PQ) M23–M32 Baseline DRAM Technology Qual (Foundry Partner) M25–M40 Phase 1 DRAM Product Qualification M32–M44 DRAM+ (FeCAP) Technology Integration M36–M50 FAB-01 Site must be acquired by Jan 2027 — Region A/Region B decision gates all downstream FAB-02 Foundry Partner license must sign by M1 — detailed tool list gates design FAB-03 EPC Partner L0 design start at M3 — any slip delays RFE one-for-one FAB-05 Long-lead tool POs at M3 — Lithography Vendor 18–24 mo lead time M1 Jan 2027 M2 Feb 2027 M3 Mar 2027 M4 Apr 2027 M5 May 2027 M6 Jun 2027 M7 May 2028 M8 Nov 2028 M9 Dec 2028 M10 Jun 2029 M11 May 2030 M12 Sep 2030 M13 Mar 2031 Pre-project status as of April 2026 (9 months before M0) SITE: Region A preferred but land not acquired (April 2026). City refuses technical discussions until financial resolution. Region B active since Nov 2025. Target acquisition: Jan 2027 (M0). FOUNDRY PARTNER: License not yet signed. Expected Apr/May 2026. Detailed tool list and consumption data only available post-signing. Must close before M1 (Feb 2027). EPC PARTNER DESIGN: Not started. Monthly run rate for site support only. Fab design order gated on site + Foundry Partner. Must start by M2 (Mar 2027) to preserve schedule. IMPACT: 8-month slip from previous Q1 2026 baseline. New project anchors at Jan 2027 = M0 (Site Selected & Acquired). CRITICAL PATH: Site M0 → Foundry Partner M1 → Environmental Permit M2 → EPC Partner L0 M3 → Groundbreaking M5 → Weathertight M16 → RFE M23–M29 → First Revenue M44. Schedule Scenarios & Capacity EPC Partner scenario: RFE M23 (Dec 2028), First Silicon M32 (Sep 2029). OSM + Partial Permit enabled. Federal Baseline: RFE M29 (Jun 2029), production start M32 (Sep 2029) → First revenue M44 (Sep 2030). Phase 1: 20,000 WSPM — 14,000 m² GMA cleanroom (EPC Partner design basis). Phase 2: 100,000 WSPM — 2nd-gen DRAM/DRAM+ ('Developed in Sovereign Bloc') from 2033. LOI customers: Anchor OEMs + 1,000+ Sovereign Bloc OEMs. Financing Structure ($4.9B Total) Sovereign Chips Grant: $2.875B (~58%) — up from $1.3B Jan 2025 indication. PE Sponsor PE equity via SPV; $4.9B SBLC from bank consortium (Lead Bank lead). SBLC expires at First Silicon — drawdown structured against Sovereign Chips Grant milestones. OPEX buffer $302M; SBLC interest provision $350M. EPC Partner team: Reference Fab A + Reference Fab B reference; OSM reduces on-site schedule risk. Qualification Sequence & Revenue Forecast Baseline Foundry Partner DRAM qual (M25–M40): gate to all downstream — runs from RFE. Phase 1 product qual (M32–M44): first revenue Sep 2030 ($300M–900M/yr by 2031). DRAM+ (FeCAP) integration (M36–M50): $1B+/yr by 2031 per Fab1 forecast. Phase 2 (100k WSPM): 2nd-gen DRAM/DRAM+ from 2033, $3B+/yr by 2034. Baseline DRAM revenue de-risks SBLC and business case during FeCAP ramp. -- 40 of 44 -- Strategic Advisor › × Client Co PROGRAM CONTEXT Fab1 | Success criteria, key assumptions, and top risks | Sourced from Fab1 Project Narrative April 2026 (M4) | Rev 1.0 3 critical, 5 high, 3 medium, 1 low Sequencing: M0 = Q1 2026 SUCCESS CRITERIA Site decision finalised (Region A or Region B confirmed) and land acquisition completed by M6. Sovereign Chips Grant ($2.875B, ~58%) committed and disbursement schedule agreed with Federal Ministry. Foundry Partner technology license executed by M4 to M5 (Apr/May 2026); detailed tool list and consumption data received. EPC Partner fab design contract issued immediately after site + Foundry Partner confirmed; L0 no later than M6. $4.9B SBLC from bank consortium closed; PE Sponsor PE equity committed. Groundbreaking (EPC Partner mobilisation) by M9 (Q4 2026); fab shell complete by M26. Partial Permit enabling earth works at M3; fab weathertight by Q3 2027. Ready For Equipment (RFE): M27 (Apr 2028) EPC Partner target, M33 (Q4 2028) Federal Baseline. Full IQ/OQ/PQ completed within 3 months of RFE. KEY ASSUMPTIONS Site decision reached by M6: either Region A financial impasse resolved or Region B plot confirmed and acquired. Sovereign Chips Grant ($2.875B) disbursement aligns with construction cash-flow requirements. Foundry Partner license signs by end April / May 2026 (M4 to M5); detailed tool list and consumption data available. EPC Partner fab design contract issued and funded by M6; L0 start no later than M6 to preserve Federal Baseline. Partial Permit obtainable by M3 to enable early earth works before full Environmental Permit. ALD Vendor tooling available at required volume and delivery schedule; EPC Partner manages tool install. KEY RISKS CRITICAL Site undecided at M4: Region A blocked on financials; Region B alternative; no land acquired. Gates all permitting and design. CRITICAL Foundry Partner license not signed at M4; detailed tool list and consumption data unavailable; EPC Partner design cannot start without these inputs. CRITICAL EPC Partner design not started at M4; every month of delay to L0 start directly slips RFE. Federal Baseline M33 requires design start by M6. HIGH Lithography Vendor DUV lead times 18 to 24 months; POs cannot be placed without Foundry Partner tool list; already late vs M6 target. HIGH SBLC bank consortium does not close at required terms — construction cannot begin. HIGH ALD Vendor single-source dependency: slot unavailability delays process qual by 6+ months. HIGH EPC Partner: construction cost overrun or schedule slip beyond contract completion date. HIGH FeCAP novel technology: no production-scale precedent; yield ramp M44 to M54 uncertain. MEDIUM CAPEX inflation: current $4.9B estimate is a 49% increase vs Jan 2025 $3.3B baseline. MEDIUM Foundry Partner financial commitment not provided; Federal Ministry condition on Foundry Partner equity not resolved. MEDIUM Wind park PPA not secured; utility agreement gates Environmental Permit application. LOW DRAM market downturn 2026 to 2029 weakens LOI conversion to binding offtake contracts. -- 41 of 44 -- Strategic Advisor › × Client Co SCHEDULE NOTES — ANALYSIS & LOGIC Supporting analysis, schedule logic, qualification sequence, and open gates as of April 2026 (M4) April 2026 (M4) | Rev 1.0 Sourced from Fab1 Project Narrative Schedule Logic — Status as of April 2026 (M4) As of April 17, 2026 (M4), three design gates remain open: site is undecided (Region A vs Region B), the Foundry Partner license is not signed, and EPC Partner fab design has not started. The EPC Partner September 2025 proposal (RFE April 2028, M27) assumed L0 design start in October 2025 — this never happened. The Federal Baseline (RFE Q4 2028, M33) is the current optimistic scenario, achievable only if Foundry Partner signs by M4–M5, site is confirmed by M6, and EPC Partner L0 starts no later than M6–M7. Each month of further delay slips RFE by one month. Critical Path Items Tool procurement must begin at M4–M6 regardless of construction status. Lithography Vendor DUV lithography tools carry 18–24 month lead times. The Foundry Partner technology license must also be executed early — the DRAM process recipe transfer runs in parallel with construction and must be ready before RFE at M33. The Environmental Permit target of M6 (Q3 2026) is significantly more aggressive than the 12–18 month German norm. The Region B site's existing permitting alignment (Federal Baseline already issued) is the key enabler. Any 3-month slip compresses the construction programme and threatens the Q1 2029 First Silicon target. Open Gates as of April 2026 (M4) — Site Lead, Client Co SITE (Site Lead, April 17 2026): Region A selected but land not acquired. City blocked technical discussions until financial resolution; Client Co waiting. Region B contacted Client Co Nov 2025. Site 'not 100% closed.' FOUNDRY PARTNER: License expected end Apr / early May 2026. Only post-signing does Client Co receive detailed tool list + consumption data — the two remaining design inputs. EPC PARTNER DESIGN: Never started. Monthly run rate for site-selection support only. No fab design order issued. The EPC Partner L0→RFE schedule in the Sep 2025 workshop is a proposal, not active work. Qualification Sequence & Revenue Forecast Per Fab1 revenue forecast (Federal Baseline slide 7): 1. Baseline DRAM qual (M33–M44): Foundry Partner-licensed process on Fab1 tools. Gate to all downstream. Estimated $300M/yr at full Phase 1 utilisation. 2. Phase 1 DRAM product qual (M38–M50): revenue product qualification. First revenue ~2030 ($300M–900M/yr by 2031). 3. DRAM+ / FeCAP technology (M44–M54): novel technology, $1B+/yr by 2031 per Fab1 forecast. Phase 2 (100k WSPM) adds $3B+/yr from 2034. EPC Partner Construction Approach (Sep 2025 Workshop) EPC Partner's own project Gantt (14,000 m² GMA / 20k WSPM) targets RFE April 2028 (M27), 6 months faster than the Federal Baseline of Q4 2028 (M33). Key enablers: 1. Partial Permit: Earth works start M3, before full Environmental Permit at M6. This is standard German staged permitting (Staged Permit) — not in prior assumptions. 2. Off-Site Manufacturing (OSM): Pre-fabricated MEP modules assembled off-site in parallel with on-site construction, reducing peak on-site workforce and compressing schedule. Fab1-Specific Considerations EPC Partner as of September 2025 stated: 'Target first wafer out timing is potentially at risk, mitigation measures are required.' The risk: Sovereign Chips Grant, PE, and Foundry Partner were all still pending at that point. The pre-FID design approach (L0–L2) is the primary mitigation — design work proceeds on benchmarks until Foundry Partner data is available. Critical dependency: Foundry Partner must be on board before start of Concept (L2). If not, EPC Partner advises a 'project break could be considered to avoid costly rework.' EPC Partner scope extends beyond EPC basebuild to include tool install, qualifying the fab through to production-ready. EPC Partner team includes Reference Fab A and Reference Fab B experience — strongest Foundry Country-specific cleanroom construction reference available. -- 42 of 44 -- Strategic Advisor › × Client Co RISK REGISTER & CAPEX PROCUREMENT ANALYSIS Top schedule & execution risks ranked by impact | Tools & Technology CAPEX $2.41B | Procurement timeline April 2026 (M4) | Rev 1.0 Total project CAPEX: $4.9B 12 risks · 3 critical / 6 high / 3 medium ID Severity Risk Description & Detail Impact Mitigation FAB-01 CRITICAL Site undecided at M4 (Region A blocked, Region B alternative) Region A: land not acquired; city blocks technical discussions until financial resolution. Region B under active evaluation since Nov 2025. +6–18 mo Force Region A financial resolution OR formally pivot to Region B. Decision required by M6 to preserve Federal Baseline schedule. FAB-02 CRITICAL Foundry Partner license not signed at M4; design inputs unavailable License expected end Apr / early May 2026. Detailed tool list + consumption data only released post-signing. +4–12 mo Close Foundry Partner license by end of April. Immediately extract detailed tool list and consumption data post-signing (target: 2 weeks). FAB-03 CRITICAL EPC Partner design not started at M4 — Federal Baseline M33 now at risk EPC Partner never contracted for fab design. Sep 2025 M27 target lost. Every month of further delay slips RFE. +3–6 mo / month Issue EPC Partner L0 design contract immediately after Foundry Partner signs + site confirmed. Target contract execution by M5–M6. FAB-04 HIGH Foundry Partner technology transfer incomplete at RFE DRAM process must be qualified on Fab1 tools by M33. Foundry Partner financial commitment not yet resolved by Federal Ministry. +3–9 mo Execute Foundry Partner license by M5. Station Client Co engineers at Foundry Partner Foundry Country for parallel process learning during construction. FAB-05 HIGH SBLC bank consortium does not close at required terms $4.9B SBLC requires bank hold >50% LTC after Sovereign Chips Grant. Complex structure may delay beyond M9 target. +6–18 mo Engage Lead Bank and consortium banks immediately. Align LTC/Sovereign Chips Grant drawdown structure with SBLC terms. Weekly tracking. FAB-06 HIGH ALD Vendor single-source dependency at fab scale ALD Vendor (DRAM+): 1 tool. Already flagged as risk in DDR4 and Cache+ programs. Slot availability uncertain. +3–9 mo CEO-level ALD Vendor engagement. Validate fab-scale slot availability at Q2 2026. Backup evaluation for non-FeCAP. FAB-07 HIGH EPC Partner: construction or tool install overrun / delay EPC Partner responsible for basebuild + tool install to Fab-Ready. Delay compresses qualification timeline. +3–6 mo Tight contractual milestones with LDs. EPC Partner Gantt: M1 Kickoff to M14 Weathertight, M27 RFE. FAB-08 HIGH Foundry Partner not on board at Concept (L2) start — design break risk EPC Partner: if Foundry Partner not available at L2, 'project break could be considered to avoid costly rework.' +2–4 mo Foundry Partner license must be executed by M3. EPC Partner benchmarks fill gap if data arrives by L2 end (M5–M6). FAB-08b HIGH Cleanroom construction labor scarcity in Foundry Country region Fewer cleanroom specialists than Asia. EPC Partner, Competing Fab, and battery plants compete for same labor. +3–6 mo EPC Partner locks specialist subcontractors at contract award. OSM approach reduces on-site peak demand. FAB-09 MEDIUM CAPEX inflation vs Jan 2025 baseline (+49%) Total has risen from $3.3B to $4.9B. Sovereign Chips Grant eligible costs up from $2.2B to $4.9B. +0 mo (cost risk) $4.9B estimate includes contingency. Monitor EPC Partner EPC fixed-price structure. Lock procurement at M6. FAB-10 MEDIUM Foundry Partner financial commitment not provided (Federal Ministry condition) Federal Ministry requested Foundry Partner equity/commitment as condition of Sovereign Chips Grant profit/loss obligation. +6–12 mo Client Co developing Foundry Partner commitment proposal. Federal Baseline support requested at federal level. FAB-11 MEDIUM FeCAP novel technology extends yield ramp No production-scale FeCAP precedent. Yield ramp M44–M54 is already tight in financial plan. +6–12 mo Run FeCAP short-loop validation at Foundry Partner concurrently. Model yield vs. spec in financial plan. FAB-12 MEDIUM DRAM market downturn weakens LOI-to-offtake conversion LOI customers confirmed (Anchor OEMs + 1,000+). Binding contracts pending. +0 mo (revenue risk) Convert LOIs to binding offtake by M18. Prioritise Key Accounts (Anchor OEMs). Tools & Technology CAPEX — Total: $2.41B (Project total: $4.9B) 0 200 400 600 800 Photolithography (Lithography Vendor DUV) $800M Thin Films (ALD, CVD, PVD) $492M Implant / Diffusion $418M Etch (Cond./Dielectric/Ash) $373M Foundry Partner Tech License $223M CMP $62M Test / Sort $35M Other (Plating, Spin, SW) $6M Tool Procurement Timeline ($M) 0 100 200 300 400 Q3 2026 Q4 2026 Q1 2027 Q2 2027 Q3 2027 320 Q4 2027 180 Q1 2028 75 Q2 2028 93 205 298 358 405 PO commits start M6 (Q3 2026) Risk Summary 3 CRITICAL Site (01), Foundry Partner (02), EPC Partner design (03) 6 HIGH Foundry Partner transfer, SBLC, ALD Vendor, EPC Partner EPC, L2 break, labor 4 MEDIUM CAPEX inflation, Foundry Partner equity, FeCAP, LOI conversion Risk Status Overview — M4 (April 2026) > 3 critical gates open: site decision (Region A vs Region B), Foundry Partner license, EPC Partner fab design contract > EPC Partner M27 (Apr 2028) RFE target LOST — every month of further delay to L0 slips RFE one-for-one > Federal Baseline M33 (Q4 2028) baseline achievable only if Foundry Partner signs by M5 and EPC Partner L0 starts by M6–M7 > Tool POs at M6 (Q3 2026) are critical: Lithography Vendor DUV 18–24 mo lead time; $2.41B tools + $223M Foundry Partner license -- 43 of 44 -- Strategic Advisor › × Client Co TOOL INVENTORY & PRIORITY MITIGATION ACTIONS Complete tool inventory | Procurement timing | Mitigation actions ranked by schedule recovery potential April 2026 (M4) | Rev 1.0 ~331 tools · $2,187M 10 priority actions Tool Area Qty PO Delivery $ M Lead Risk ArFi Scanner + Track Litho 14 M6 M18–M27 627 CRITICAL ArF Dry Scanner + Track Litho 2 M6 M18 42 HIGH KrF Scanner + Track Litho 12 M6 M18–M30 131 HIGH ALD (standard) Thin Film 5 M6–M8 M18–M27 60 HIGH ALD Vendor (DRAM+) Thin Film 1 M8 M21 12 CRITICAL CVD (EPI, WCVD, multi) Thin Film 39 M8–M12 M21–M30 225 MEDIUM PVD Thin Film 8 M8 M18–M30 44 MEDIUM Dry Etch (Cond/Dielectric) Etch 37 M8–M12 M18–M27 283 MEDIUM Dry Etch (Ash) Etch 7 M8–M12 M18–M27 11 LOW CD-SEM Metro 8 M8 M18–M27 79 MEDIUM Implant Impl 11 M8–M12 M18–M27 84 MEDIUM Thermal Furnace Impl 12 M10–M12 M18–M30 39 LOW Thermal RTA Impl 8 M8–M12 M18–M30 26 LOW Wet Processing Impl 14 M8–M12 M18–M30 27 LOW Metrology (multi) Impl 45 M10–M12 M21–M27 214 MEDIUM Inspection (multi) Thin Film 45 M8–M12 M18–M27 123 MEDIUM CMP CMP 14 M8–M12 M18–M27 61 MEDIUM Sort / Functional Test Test 35 M12 M21–M30 38 LOW Plating Thin Film 2 M12 M21–M30 11 LOW Spin-On Thin Film 6 M12 M21–M27 16 LOW MES + Yield Mgmt SW IT 2 M10 M18–M21 4 LOW AMHS Facilities 1 M12 M21–M24 2 LOW TOTAL ~328 tools $2,159M Total Project CAPEX Breakdown > Building, Site, Shell, Cleanroom, Utilities (EPC Partner EPC) $1783M > Foundry Partner Technology License & Transfer $223M > Advanced Technology Tools (DRAM+) $213M > R&D CAPEX (Models + Tests) $119M > OPEX buffer (construction phase) $302M > SBLC interest provision $350M TOTAL PROJECT CAPEX ~$4.9B (up) from $3.3B in January 2025 baseline (+49%) Priority Mitigation Actions — Ranked by schedule recovery potential MIT-01 Force site decision NOW: resolve Region A or commit to Region B Exec Sponsor / CEO / Procurement Lead · Target: M4–M5 (immediate) Region A: issue financial ultimatum or pivot. Region B: confirm plot, commission land survey. No design can start without site. Saves up to 18 mo MIT-02 Close Foundry Partner license by end of April 2026 (M4) Exec Sponsor / CEO · Target: April 30 / May 2026 (M4–M5) License expected end April. Immediately extract detailed tool list + consumption data post-signing. Issue EPC Partner contract within 30 days. Saves up to 12 mo MIT-03 Place Lithography Vendor lithography POs at M6 Procurement Lead / Procurement · Target: M6 — PO binding Place binding POs for all 28 litho tools. Negotiate staged delivery. Escalate via Sovereign Chips Grant. Saves up to 12 mo MIT-04 Close Sovereign Chips Grant application — Federal Ministry / Federal Baseline priority Finance Lead / Exec Sponsor / CEO · Target: M3–M6 — Sovereign Chips Grant $2.875B Prerequisite for SBLC. Advance Stage 2 in parallel. Bridge for tool deposits. Saves up to 24 mo MIT-05 Close SBLC with bank consortium (Lead Bank lead) Finance Lead / Procurement Lead · Target: M4–M9 Engage Lead Bank and consortium. Align LTC/Sovereign Chips Grant drawdown structure with SBLC terms. Saves up to 18 mo MIT-06 Issue EPC Partner L0 design contract immediately after site + Foundry Partner confirm Procurement Lead / Finance Lead · Target: M5–M6 (latest) EPC Partner design NEVER STARTED. Issue L0 contract as soon as Foundry Partner signs and site confirmed. Every week of delay = one week of RFE slip. Saves up to 9 mo MIT-07 Secure ALD Vendor commitment at fab scale CTO / Exec Sponsor / CEO · Target: M4 — CEO-level engagement Validate fab-scale slot availability. Backup evaluation for non-FeCAP. Saves up to 9 mo MIT-08 Stagger specialty tool POs across 2027 Procurement / Procurement Lead · Target: M6–M12 — spread Q1–Q4 2027 Spread etch, CVD, implant POs across Q1–Q4 2027. Secure vendor commitments with deposits. Saves up to 6 mo MIT-09 Lock wind park PPA and utility agreements Procurement Lead / Legal · Target: M4–M6 — PPA concept exists Execute term sheet now. Utility agreements gate Environmental Permit application. Saves up to 12 mo MIT-10 Begin Foundry Partner DRAM short-loop validation at Foundry Partner facility Tech Transfer Lead / Tech Transfer Lead · Target: M6–M24 Validate Fab1 process parameters at Foundry Partner before fab ready. Model yield vs. spec in financial plan. Saves up to 12 mo -- 44 of 44 --

Client Projects·Case study·Semiconductor

Planning in three days, not three weeks

How a chip-development team compressed multi-year program planning from weeks to days, with AI doing 80% of the synthesis and the team scrubbing the rest.

Core thesis. AI-assisted macro planning compresses about 80% of the synthesis work into hours and routes the remaining 20% — judgment, calibration, local context — through the team. On a multi-year stacked-memory program, that split delivered a publishable charter, milestone matrix, and macro schedule in three days against a conventional cycle of three to four weeks.

May 6, 2026·44 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Case study The 12.12.12 pilot line How Alta Devices recovered an eight-month projected schedule miss and brought the world’s most efficient solar cell to manufacturing. Case study series. Alta Devices, Sunnyvale, CA. Q4 2011 – December 2012. Pilot manufacturing start-up. 5,000-activity integrated schedule. Eight-month schedule recovery. Prepared by lateralworks FTTM methodology Engagement window Q4 2011 – Q4 2012 Eleven-month planning horizon Online lateralworks.com Schedule acceleration series -- 1 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 2 Table of contents The 12.12.12 pilot line Abstract 03 01 / The challenge 04 02 / The approach 06 Pull quote / Chris Norris 08 03 / The result 09 04 / What this teaches 13 Sources 15 Core thesis. A pilot line on a hard deadline cannot be recovered by the departments running its four work streams in parallel. Recovery requires one integrated schedule, one weekly cadence, and the full management team – including the C-suite – in the room. On the Alta Devices program, that combination closed an eight-month projected gap inside an eleven-month planning window. -- 2 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 3 Overview Abstract In late 2011 Alta Devices held the world record for solar-cell efficiency and a checkbook from a top-tier investor list, and was on the path to running out of money. The company had to start its first pilot manufacturing line by the end of 2012 to release the next funding tranche, and in January of that year the integrated schedule was forecasting a finish date eight months past target. The company brought lateralworks in to recover the date. The hard part was not technical genius. Alta had that. The hard part was that a startup with a fraction of the resources was attempting what an established semiconductor manufacturer would task to a thousand-person organization: simultaneously mature a complex GaAs process, design and build proprietary tools, install and qualify a pilot line, and define the first product and its target markets. Departmental silos were managing each piece of that work in isolation. The integrated picture nobody owned was where every gating problem lived. lateralworks rebuilt the program as a single 5,000-activity integrated schedule, restructured the team around lateral deliverables instead of functional groups, and put the entire management team on a weekly cadence of plan, pull-in, and accountability. The team used the integrated picture to find gating problems weeks before they would block work. They called the discipline “pulling the pain forward.” On December 12, 2012 the line produced its first qualified material. The eight-month gap closed. The next funding round opened. Chris Norris, the CEO, later described the engagement as “the single most transformational event in how we do business since the company was started.” -- 3 of 15 -- › The 12.12.12 pilot line › › › 01 The challenge Pilot line as funding gate © 2026 lateralworks Page 4 Alta Devices was founded by Harry Atwater of Caltech and Eli Yablonovitch of UC Berkeley to commercialize a flexible, ultra-thin gallium-arsenide solar cell – at the time of the engagement, the most efficient cell ever produced. The investor list included Kleiner Perkins (Bill Joy and Wen Hsieh), August Capital (Andy Rappaport), NEA (Forest Baskett), and strategic capital from GE and Dow. Chris Norris, a veteran semiconductor executive, ran the company. He had raised roughly $100 million and the team had set world records for both cell and module efficiency. The next round was conditioned on a single demonstration: that the technology could be manufactured. Specifically, that Alta could start its Oakmead pilot line by the end of 2012 and produce qualified material from it. Without that proof, no investor would underwrite the multi-hundred-million-dollar production scale-up the technology required. With it, the company moved forward. There was no third option and no extension to the deadline. -- 4 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 5 The challenge, continued Four programs, one calendar Inside the company, four programs were running at the same time and competing for the same people. The GaAs process technology was still maturing. Several of the manufacturing tools did not exist commercially and had to be specified, built with vendors, and brought up. The pilot line itself – a building, a clean room, infrastructure, and the qualified tools inside it – had to be procured, installed, and qualified end-to-end. And the company had not yet decided which product the line would build first or which markets it would serve. Each of those programs had a department running it. In January 2012, with eleven months of planning window left, the integrated forecast for the pilot line’s first qualified material called for August 2013. The team was eight months behind a deadline that would not move. -- 5 of 15 -- › The 12.12.12 pilot line › › › 02 The approach One integrated program © 2026 lateralworks Page 6 The first move was structural. lateralworks dissolved the departmental schedules and stitched them into a single 5,000-activity integrated plan. Every dependency that had been managed through email between two department heads now lived in one network where the critical path was visible. Process development, tool development, line install and qualification, and product definition stopped being four programs and started being one program with four contributing streams. Around that integrated plan we redesigned how the team worked. Teams were re-formed around lateral deliverables – the things that had to be ready together for a milestone to land – rather than around functional reporting lines. The C-suite engagement worked in parallel: redefining the corporate mission, the first product’s functionality, and the target market it would serve. A pilot line cannot be qualified against a product that has not been chosen. -- 6 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 7 The approach, continued Weekly cadence and early warning The execution cadence ran weekly. The full management team – not delegates, not summaries – sat together to refresh the integrated schedule, examine the critical path, and pull in dates wherever the analysis allowed. The quality of that meeting set the pace of the program. When a department head started reporting status without owning the numbers, the meeting paused until the numbers were owned. The discipline required to run a 5,000-activity weekly pull-in with the management team in the room is the discipline the program needed everywhere else. Behind the cadence sat a single working idea: early warning is the asset that recovers a critical-path program. A schedule that surfaces a gating problem six weeks ahead gives the team six weeks to design around it; the same problem found when work is blocked costs months. The team named the practice “pulling the pain forward.” On the Alta program, gating tasks identified in advance through the planning system were almost always solvable; the same problems hitting the team unannounced typically were not. The fourth piece of the engagement was knowledge transfer. The methods had to live inside Alta after we left so the next generation of technology could be accelerated the same way. We trained the internal team to run the integrated planning system without us. -- 7 of 15 -- Client Chris Norris, CEO The single most transformational event in how we do business since the company was started. Chris Norris CEO, Alta Devices © 2026 lateralworks Page 8 -- 8 of 15 -- › The 12.12.12 pilot line › › › 03 The result First material out on 12.12.12 © 2026 lateralworks Page 9 The pilot line started up on schedule. On December 12, 2012, the integrated team – including process, tools, line operations, product, and the C-suite that had been involved every week – gathered at Oakmead while Norm Armour, VP of Global Manufacturing, held the first qualified material out of the line. -- 9 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 10 First material out 12.12.12 at Oakmead Figure 1. The Alta Devices team at Oakmead on December 12, 2012, the day the pilot line produced its first qualified material. -- 10 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 11 Schedule trace The wigglechart The wigglechart told the underlying story. Each dot on the chart is an estimated finish date for “first material out,” forecast at a single point in time from the rolling 5,000-activity critical-path schedule. The shape of the line is the program’s history. In January 2012 the curve sat at August 2013, eight months past the December 12 target. By the spring it had collapsed to within weeks of the target. In the fall it drifted up briefly as new gating tasks surfaced. In December the team pulled it back down, hard, to land on the date. Figure 2. Alta Devices pilot line startup wigglechart, fastProject output, December 10, 2012. Each marker is a forecast finish date for first material out from the rolling critical-path schedule. -- 11 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 12 Outcomes Beyond the milestone Four things drove the downward trend on the wigglechart: technical innovation, better workflow inside the integrated team, early warning of gating tasks, and obsessive focus on the critical path. None of those was unique. The combination, run weekly with the full management team in the room, was. Figure 3. Norm Armour, VP of Global Manufacturing, holding the first qualified material out of the Oakmead pilot line, December 12, 2012. Beyond the milestone itself: pilot line operational, with significant cash-burn reduction relative to the original baseline. Initial target markets defined, and the go-to-market strategy redefined to match. Customer contracts in place that consumed the entire first year of pilot-line output. The internal team trained on the planning method and able to run it without lateralworks for the next-generation program. Public confirmation of the technology’s commercial trajectory followed in the months after start-up – military solar charging products, automotive applications, and recognition in technology and energy press. -- 12 of 15 -- › The 12.12.12 pilot line › › › 04 What this teaches Recovering a critical-path program © 2026 lateralworks Page 13 Recovering an Alta-scale program is an integration problem before it is a technical one. The departments running the four work streams are each capable of executing their piece. The schedule that brought Alta home was the schedule that saw the four pieces together. Three patterns from the engagement generalize. -- 13 of 15 -- › The 12.12.12 pilot line › › › © 2026 lateralworks Page 14 Pattern one Departmental schedules hide the gating tasks A departmental schedule cannot recover an eight-month miss. It is slower to plan, but the deeper problem is that it hides the gating tasks: each department reports only what is inside its boundary, and the program’s gating tasks live in the handoffs between departments, where no department owns them. Building one integrated schedule is the first time certain critical-path problems become visible at all. Pattern two Pulling the pain forward Pulling the pain forward turns technical surprise into solved problems. In a state-of-the-art technology program, surprises are unavoidable. Late discovery of those surprises is not. Early warning gives the team a workaround instead of a delay, and the mechanism that produces early warning is the integrated weekly pull-in run by the full management team. Pattern three The host system in the room Mission, target markets, and product definition are gating tasks for a pilot line. When those decisions stay in a separate forum and the program-level meeting cannot reach them, they become the critical path nobody is tracking. The C-suite is part of the system being accelerated, not an audience for its status. For Alta, getting this right meant a funded company shipping qualified material from a pilot line on a date the industry would have called impossible eleven months earlier. The work was done by Alta’s own people. Our job was to give them a system in which the work they were already capable of doing could land on the date they needed. -- 14 of 15 -- › The 12.12.12 pilot line › › › A Sources References © 2026 lateralworks Page 15 [1] Alta Devices, Inc. Company website and press materials, 2012–2013. [2] Alta Devices Pilot Line Startup, fastProject wigglechart, December 10, 2012. Internal lateralworks engagement record. [3] “Alta Devices unveils solar charging mats for military, remote and automotive applications.” Solar Server, January 2013. [4] “Alta Devices brings flexible solar to military chargers.” Engadget, January 4, 2013. [5] “What mattered in energy innovation this year.” MIT Technology Review, December 2013. [6] Norris, C. EmTech / MIT presentation on Alta Devices’ mobile power technology, 2013. [7] lateralworks. Engagement records and CEO correspondence, Alta Devices program, Q4 2011 – Q4 2012. -- 15 of 15 --

Client Projects·Case study·Semiconductor

The 12.12.12 pilot line

How Alta Devices recovered an eight-month projected schedule miss and brought the world's most efficient solar cell to manufacturing.

Core thesis. A pilot line on a hard deadline cannot be recovered by the departments running its work streams in parallel — recovery requires one integrated schedule, one weekly cadence, and the full management team in the room. On the Alta Devices program, that combination closed an eight-month projected gap inside an eleven-month planning window.

May 4, 2026·15 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Case study Building a $7 billion fab in under two years How an empowered core team and integrated master schedule overcame a two-year projected delay FTTM case study series. GlobalFoundries Fab 8 start-up. Malta, New York, 2009–2011. The FTTM framework converted a projected two-year delay into a two-week early delivery. Prepared by lateralworks Fast Time To Market methodology Date April 2026 Case study Online lateralworks.com FTTM case study series -- 1 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 2 Table of contents Building a $7 billion fab in under two years Abstract 03 01 The context: a $7 billion race against time 04 02 The challenge: compounding crises 06 03 The solution: the FTTM framework 08 04 Why this structure outperforms 11 05 Results and impact 13 06 The lateralworks role 16 07 Key takeaways: the reusable pattern 18 08 Engagement summary 21 References 23 Core thesis. A two-year deficit doesn’t close incrementally. It closes when an empowered core team owns the outcome end-to-end, an integrated master schedule serves as the single source of truth, and refresh planning runs at a cadence frequent enough to expose gaps the same day they appear. -- 2 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 3 Overview Abstract In 2010, GlobalFoundries set out to build an advanced semiconductor fab in under two years. The company was newly formed, the site was a 225-acre greenfield in Luther Forest, a remote area of upstate New York, and the budget was $7 billion. The industry average for a project of this scale was three to four years. A major customer depended on the fab’s output for a high-profile product launch, and every day of delay represented $5 million in lost profit. The project was hit by compounding crises from day one. The 2010 global recession disrupted high-tech supply chains. The target semiconductor process changed twice in the first eight months — the first customer dropped out, and customer demand then drove a second shift to a process not yet qualified at the source fab in Dresden. Over half the tools and 70% of the utility and chemical infrastructure had to be redesigned. Remote-site logistics, union labor disputes, and intense media scrutiny added to the schedule pressure. lateralworks was engaged to structure the program, build the integrated plan, and drive schedule acceleration using the Fast Time To Market (FTTM) framework. The initial macro plan showed the project tracking about two years late. An empowered cross-functional core team, a macro-micro Integrated Master Schedule (IMS) that grew to more than 100,000 tasks, and twice-daily Refresh Planning across 24/7 shifts closed the gap, pulled more than a year out of the schedule, and accelerated construction by three months. First qualified silicon came off the production line on December 27, 2011, two weeks ahead of the January 10, 2012 target. The early delivery avoided about $70 million in delay costs. GlobalFoundries adopted the FTTM planning system as the standard for subsequent fab expansions and advanced process node programs worldwide. $7B Program budget 2 weeks Ahead of schedule $70M Saved from early delivery >1 year Schedule gap recovered -- 3 of 23 -- › Fab 8 case study › › › 01 The context A $7 billion race against time © 2026 lateralworks Page 4 GlobalFoundries was formed in 2009 when the sovereign wealth fund of Abu Dhabi acquired AMD’s manufacturing operations, creating a pure-play semiconductor foundry. Its first new build was Fab 8, on a 225-acre greenfield site at the Luther Forest Technology Campus in Malta, New York. The scope: build a complete fab facility and site infrastructure, procure 1,600 tools, transfer an advanced semiconductor process from GlobalFoundries’ existing Fab 1 in Dresden, qualify it at Fab 8, start high-volume manufacturing, and recruit, relocate, and train 2,500 specialized employees. All in under two years, on a budget of about $7 billion. -- 4 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 5 Figure 1. Fab 8, Malta, New York—the most advanced pure-play semiconductor foundry campus in the United States. Over 3,300 employees, 460,000 sq ft clean room, leading-edge 14nm and 7nm process technologies. On day one of 730, a five-person core team stood on an empty site in a remote corner of upstate New York. No local infrastructure, no labor pool, no supply chain. The target was one the industry considered impossible. The stakes A major customer had committed to take high-volume production from Fab 8 within two years, tying the fab’s output to a new product release. The cost of delay was $5 million per day in lost profit to GlobalFoundries — a contractual penalty, not an internal planning target. The project also carried public commitments. New York State had provided extensive tax credits and investment incentives, making Fab 8 the anchor of a high-tech economic revitalization program. GlobalFoundries had committed to hiring targets and infrastructure improvements as conditions of those subsidies, with financial penalties for missed commitments. Government oversight, regulatory constraint, and media scrutiny ran higher than on most industrial programs of comparable scale. -- 5 of 23 -- › Fab 8 case study › › › 02 The challenge Compounding crises on an impossible timeline © 2026 lateralworks Page 6 The two-year target was already considered impossible. Fab projects of this scale averaged three to four years in 2010. The compressed timeline was the smaller half of the problem; the larger half was compounding instability that struck from every direction at once. -- 6 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 7 Customer and process instability About six months in, the first customer dropped out. The fab start-up needed a new manufacturing process. Over half the tools were affected, and 70% of the utility, chemicals, and gases (GaC) matrix had to be redesigned. About eight months in, customer demand forced a second process change — this time to a process still in development at Fab 1 in Dresden, not yet qualified anywhere. The tool set and facility requirements were no longer fixed. Global supply chain disruption The project launched into the 2010 global recession. High-tech supply chains seized up; lead times for critical tools jumped. The team had to commit to tool orders before specifications were finalized — risk purchases, made to keep the schedule from slipping further. Remote location and labor challenges The remote site created its own logistics problem. Specialized construction workers and tool suppliers were hard to get to the campus. The local town restricted heavy vehicle traffic to specific hours, narrowing the delivery window. New York State contractors’ unions disputed the use of out-of-state non-union labor. Specialized engineering talent was difficult to recruit; the area had none of the educational infrastructure or industry ecosystem of established semiconductor hubs. External pressure Media scrutiny was constant. New York State had positioned Fab 8 as the anchor of its high-tech economic revitalization program, which added political pressure on top of the technical and schedule pressure. Government regulations, environmental restrictions, and oversight requirements weighed on every major decision. The diagnosis. The first end-to-end macro plan, built by lateralworks with the five-person core team, showed the project tracking about two years late. That was the diagnosis. The rest of the engagement was about closing the gap. -- 7 of 23 -- › Fab 8 case study › › › 03 The solution The FTTM framework © 2026 lateralworks Page 8 lateralworks applied the Fast Time To Market (FTTM) framework to restructure the program around two interlocking systems: an empowered cross-functional core team, and an integrated master schedule with a high-frequency refresh planning cadence. The two work as one operating system. The team structure carries the schedule discipline; the schedule creates the urgency and transparency that keep the team focused. -- 8 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 9 The empowered core team A single empowered leader — a Project Monarch — held full decision-making authority over technical and managerial issues across the entire scope. The Monarch protected the team from external “host interrupts”: the organizational noise, redirections, and competing priorities that pull a critical program apart inside a large corporation. The core team started at five members for macro planning, then grew to 15 as the program scaled, with sub-core-teams embedded in each process module — Etch, Diffusion, Lithography, and others. Every member was a subject-matter expert selected for direct, relevant experience. There was no functional hierarchy; only cross-functional core teams, mapped to the Integrated Master Schedule. Partners and key suppliers were integrated into the same structure: one team, one project. Culture mattered as much as structure. The program was a full-time mission for everyone on it. Team members were 100% dedicated, owned the outcome collectively, and were rewarded against project targets rather than functional ones. The Integrated Master Schedule (IMS) The IMS was the single source of truth for the program. It used a macro-micro architecture: the macro plan held about 10,000 tasks and the critical-path framework. Eight module-level micro schedules rolled up into it, eventually growing to over 100,000 tasks. The IMS did four things at once. It was the organizational framework — the plan defined how the project was structured. It was the simulation engine: when things changed, and they changed constantly, the IMS modeled alternative paths and quantified their schedule impact. It was the early warning system, surfacing problems before they grew. And it was the interface manager, making cross-team dependencies visible and actively managed rather than discovered late. Refresh Planning: the execution cadence The Refresh Planning cadence sets the FTTM system apart from a conventional master-schedule discipline. The macro schedule was updated weekly with the full core team. The module-level micro schedules were refreshed twice daily, synchronized across 24/7 shifts. The cadence kept the schedule synchronized with ground truth, made gaps visible the same day they opened, and pushed decision-making authority down to the people closest to the work. -- 9 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 10 At a glance The Fab 8 program Figure 2. Program overview—challenge, solution, and results. The FTTM framework (empowered core team, Integrated Master Schedule, daily Refresh Planning) transformed a two-year projected delay into a two-week early delivery. The visual sums up the program. On the left: a $7 billion budget, an industry-average 3–4 year timeline compressed to 2 years, $5 million per day cost of delay, and a stack of compounding crises (recession, customer changes, shifting technical requirements, labor issues). On the right: the FTTM apparatus and the two-week early delivery. -- 10 of 23 -- › Fab 8 case study › › › 04 Structure Why this team outperforms © 2026 lateralworks Page 11 A conventional corporate team and the FTTM core team deployed on Fab 8 differ in kind, not degree. The comparison on the next page captures the structural dimensions where the FTTM model diverges from standard practice. -- 11 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 12 # Dimension Normal corporate team Fab 8 FTTM core team 1 Leadership Part-time coordinator, multiple projects, little power; control rests in functional hierarchy Full-time Project Monarch with decision authority over technical and managerial scope 2 Focus Independent work-streams focused on their own deliverables; leader manages interfaces alone Integrated system; core team focused on integration points, working toward shared outcomes 3 Dedication Part-time; members work on multiple projects 100% dedicated; the project is their only job 4 Bias Function-bias; functional requirements always trump the project Project-bias; focus on project outcomes (mission, not a job) 5 Authority Representatives lack decision authority and technical expertise Members have decision authority, speak for their function, are subject-matter experts 6 Problem solving Time spent avoiding blame and covering for function failures Forward-looking; learning cycles, incremental improvement; failures shared and used to learn 7 Accountability Team does not own overall project outcomes; only functional deliverables Team owns the outcome, accountable for success or failure, rewarded together 8 Compensation Based on functional goals, not tied to project success Based on project achieving targets in product performance and schedule 9 Co-location Virtual or geographically distributed Co-located; when not possible, regular in-person meetings monthly 10 Identity Project is something people participate in; "real work" happens in function Project operates like a small business where team members are equity owners On Fab 8 these dimensions were structural choices, not aspirations. They were enforced from day one and maintained throughout the program. The team absorbed repeated process changes, supply chain disruptions, and labor crises without losing schedule momentum, because the operating model was built for instability. -- 12 of 23 -- › Fab 8 case study › › › 05 Results Schedule, cost, and scope outcomes © 2026 lateralworks Page 13 The first qualified customer wafer came off the production line on December 27, 2011, two weeks ahead of the January 10, 2012 target. That recovered more than a year of projected schedule deficit. The team accelerated construction by three months, brought process qualification from Fab 1 in Germany in ahead of schedule on a very advanced silicon node, and synchronized that qualification with the Fab 8 start-up. -- 13 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 14 Schedule performance The wigglechart below tracks the predicted finish date for First Silicon Starts over the life of the program. Each point on the X-axis is a refresh date; the Y-axis shows what the schedule predicted at that moment for first-silicon completion. The early spike toward late 2013 is the two-year deficit the initial macro plan exposed. The decline that follows is the gap closing — each plateau a step in the acceleration, each rise a setback the team absorbed and recovered from. Figure 3. lateralworks wigglechart: First Silicon Starts milestone trend. Y-axis shows predicted finish date; X-axis shows refresh date. The initial spike toward late 2013 represents the ~2-year projected delay. Systematic acceleration pulled the schedule back to target. Final 10-day pull-in from reduced tool processing time delivered completion on December 27, 2011—14 days early. -- 14 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 15 Financial impact By finishing 14 days ahead of schedule at a cost-of-delay rate of $5 million per day, Fab 8 avoided about $70 million in lost profit. Had the program continued on its initial trajectory, roughly two years late, the financial exposure would have exceeded $3 billion in delay costs alone. Operational scope The program delivered facility construction, procurement and installation of over 1,000 tools on the initial production line, process transfer and qualification from Germany, product qualification, and the staffing and training of 2,500 specialized employees. Fab 8 became the most advanced pure-play semiconductor foundry campus in the United States, with over 3,300 employees, 460,000 square feet of clean-room space, and 14nm and 7nm process capabilities. Lasting influence GlobalFoundries adopted the FTTM planning and acceleration system as the standard operating model for subsequent programs worldwide. The list includes: 20nm process development under the IBM Alliance Partnership, Fab 1 expansion planning and execution in Dresden, 28nm, 40nm, and 45nm process development FTTM teams, the Fab 9 master plan and start-up feasibility assessment for Abu Dhabi, 14nm process tool installations at Fab 8, and the Fab 11 start-up in Chengdu, China — which achieved the fastest worldwide fab start-up on record at 15 months from groundbreaking. 2 weeks Ahead of target $70M Delay costs avoided 100,000+ Scheduled tasks >1 year Schedule recovered Outcome. A project tracking two years late delivered two weeks early — converting a potential $3B+ exposure into $70M in savings — through structural intervention rather than heroics. The system worked because it was built for instability. -- 15 of 23 -- › Fab 8 case study › › › 06 lateralworks role Six interconnected functions © 2026 lateralworks Page 16 lateralworks served as the program’s external planning and acceleration partner across the two-year engagement, applying the FTTM framework from a third-party perspective. The role broke into six functions. -- 16 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 17 Structured complexity. Decomposed a program of unusual scope into a workable planning structure. The macro plan fed eight module-level micro schedules, and the architecture scaled from 5 core members to 15 sub-core-teams without losing coherence. Developed the plan. Programmed the initial end-to-end macro plan, organized the work breakdown structure, pulled estimates together across all workstreams, and integrated dependencies across module boundaries. The plan was the program’s operating system. Facilitated. Engaged every stakeholder — GlobalFoundries team, suppliers, contractors — to reach consensus on schedule commitments, resource allocation, and acceleration opportunities. Permitted truth to surface. Used the IMS to identify gaps with precision and transparency. The initial plan’s two-year deficit was the plan doing its job, surfacing the problem early enough to act on it. The system made problems visible before they became crises. Created urgency. A clear problem definition, grounded in quantified schedule gaps, creates urgency that is specific and actionable. The weekly scorecard told every team where they stood and what needed to change. Accelerated. Drove schedule accelerations continuously. Established weekly Refresh Planning at the macro level and twice-daily Refresh at the module level, coached the executive team, trained a large internal program-management team, and built a project planning and acceleration system that GlobalFoundries continues to use on later programs. Special expertise. lateralworks brings particular depth in managing what is hardest to plan: bleeding-edge technology innovation, where requirements shift, processes are unproven, and the schedule is the mechanism that forces uncertainty into the open early. -- 17 of 23 -- › Fab 8 case study › › › 07 Takeaways The reusable pattern © 2026 lateralworks Page 18 The Fab 8 program demonstrates principles that apply to any complex, time-critical program — semiconductor manufacturing, advanced technology development, large-scale construction, or any other domain where schedule compression and technical uncertainty meet organizational complexity. -- 18 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 19 Reveal the gap early. The first act of planning is to show the truth. The macro plan on Fab 8 revealed a two-year deficit, and that transparency was the precondition for every acceleration that followed. Programs that avoid confronting their real schedule position lose the time they need to recover. Design the operating model for instability. Fab 8’s requirements changed twice in the first eight months. The FTTM framework worked because it was built for instability from the outset. The IMS simulation capability, the high-frequency refresh cadence, and the empowered core team all assumed change. Empower a single leader with end-to-end ownership. The Project Monarch model cuts out the committee-driven compromise that slows decisions in matrix organizations. One person owns the outcome across all functions, protects the team from organizational noise, and makes tradeoffs at the speed the schedule demands. Keep the core team small and senior. Fifteen subject-matter experts, each 100% dedicated and each empowered to make real decisions, outperformed what a larger, part-time, hierarchically constrained team could have achieved. Small teams communicate at high bandwidth, which matters when the ground keeps shifting. Use the schedule as a management system, not a reporting tool. The IMS was the organizational framework, the simulation engine, the early warning system, and the interface manager, all in one artifact. When something changed, the schedule modeled alternatives and created urgency before the problem became a crisis. Run Refresh Planning at the cadence the program demands. Weekly macro updates and twice-daily micro refreshes across 24/7 shifts kept the schedule synchronized with ground truth and pushed decision authority to the people closest to the work. Integrate suppliers and partners as one team. Partners and key suppliers on Fab 8 sat inside the core team structure, shared the IMS, and ran on the refresh planning cadence. One team, one project, one schedule. The pattern is reusable. Empowered governance, cross-functional ownership, an integrated schedule system, and a high-frequency planning cadence beat siloed execution every time. Fab 8 proved it under conditions designed to make it fail. -- 19 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 20 Detailed view Challenge, solution, and outcome Figure 4. Detailed program summary—the monumental challenge, compounding crises, strategic solution (FTTM team structure comparison), and successful outcome. -- 20 of 23 -- › Fab 8 case study › › › 08 Engagement Summary of the program © 2026 lateralworks Page 21 The table on the next page records the program at a glance: the parties, the duration, the problem, the solution architecture, the lateralworks role, and the outcomes. Use it as a quick-reference summary. -- 21 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 22 Attribute Detail Project Fab 8 (Malta, NY) Client GlobalFoundries Type Fab start-up Duration 2 years (2009–2011) Problem Deliver a greenfield mega semiconductor fab in under 2 years to meet customer demand. $5M/day cost of delay. A major customer expecting initial capacity of advanced process technology. $7B program for newly formed GlobalFoundries after the AMD acquisition. Solution Integrated cross-functional planning system involving team and structure to implement FTTM best practices: schedule acceleration, transparency, early warning, and trend analysis. Involved not just the GlobalFoundries team but every supplier. Macro-micro schedule system with over 125,000 tasks, 8 major modules, and twice-daily refreshes. lateralworks role Programmed the initial macro plan (end-to-end), established the core team, established weekly Refresh Planning, drove schedule accelerations, developed and implemented macro and micro integrated plans, established twice-daily Refresh of module micro schedules, coached the executive team, trained a large internal program management team, and established a project planning and acceleration system used continuously on future programs (fab expansion and advanced process node development). Outcomes First silicon produced from initial >1,000 tool line 2 weeks ahead of schedule. $70M in savings due to early delivery. The program involved facility construction, tool procurement, installation and qualification, process transfer and product qualification, including initial 2,500-person fab staffing and operations start-up. -- 22 of 23 -- › Fab 8 case study › › › © 2026 lateralworks Page 23 Sources References [1] lateralworks. “Program account, GlobalFoundries Fab 8 engagement (2009–2011).” Internal engagement record. [2] lateralworks. “GlobalFoundries Fab 8 case study presentation.” Internal materials. [3] GlobalFoundries Inc. Corporate announcements and disclosures concerning the Fab 8 Malta campus, Luther Forest Technology Campus. [4] New York State Empire State Development. Records concerning the Luther Forest Technology Campus and Fab 8 incentive program. [5] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. The Free Press, 1992. [6] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [7] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd ed. Wiley, 1997. [8] Oncken, W., and Wass, D. L. “Who’s Got the Monkey?” Harvard Business Review, November-December 1999. [9] Repenning, N. P., and Sterman, J. D. “Nobody Ever Gets Credit for Fixing Problems That Never Happened.” California Management Review, Vol. 43, No. 4, Summer 2001, pp. 64–88. [10] Edmondson, A. C. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley, 2018. [11] Klein, G. Sources of Power: How People Make Decisions. MIT Press, 1998. [12] Weick, K. E., and Sutcliffe, K. M. Managing the Unexpected: Sustained Performance in a Complex World. 3rd ed. Wiley, 2015. [13] Mitchell, N. “FTTM (Fast Time To Market) methodology: framework and best practices.” lateralworks, 2018–2026. Program narrative based on the lateralworks engagement account. Public details cited where available. -- 23 of 23 --

Client Projects·Case study·Semiconductor

Building a $7 billion fab in under two years

How an empowered core team and integrated master schedule overcame a two-year projected delay

Core thesis. A two-year deficit doesn't close incrementally. It closes when an empowered core team owns the outcome end-to-end, an integrated master schedule serves as the single source of truth, and refresh planning runs at a cadence frequent enough to expose gaps the same day they appear.

May 3, 2026·23 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Case study The schedule mirrors the team Why functional project managers build functional schedules — and what it takes to move them FTTM coaching series. A representative case from a global semiconductor program serving AI data-center customers. Names and sector-identifying details have been removed. Prepared by lateralworks FTTM methodology Date April 2026 Coaching case study Online lateralworks.com FTTM coaching series -- 1 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 2 Table of contents The schedule mirrors the team The setup and the diagnostic 04 The team-levels lens 08 Seven philosophical splits 11 Why this is structural, not personal 14 A learning opportunity, not a critique 16 The coaching arc 19 Implications for technology executives 21 References 23 Core thesis. A schedule is the visible artifact of an invisible operating model. When a functional organization adopts cross-functional tools, the organization reshapes the tools faster than the tools reshape the organization. Real change comes from moving the team from lightweight coordination to heavyweight ownership; the schedule will follow. -- 2 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 3 Overview Abstract A schedule shows you how its author thinks about the work, and how the organization above the author expects the work to be run. This case study covers a coaching engagement at a global semiconductor company on a new-product program for AI data-center customers. The senior project manager assigned to the program left a Fast Time To Market (FTTM) workshop with a cross-functional schedule and a heavyweight team structure. Three weeks later she had quietly rebuilt that schedule into the functional shape she had used for twenty years. The pattern shows up in every senior project manager whose career has been spent inside a functional or lightweight organization. Lightweight PMs coordinate functional teams they do not own. Their schedules show it: tasks grouped by function, milestones stacked at the top for executive consumption, dependencies looping upward inside each functional cluster, and the plan read from a table instead of a Gantt. The schedule becomes a private database for the PM. The team has no way in. Heavyweight project managers, the third level on the Wheelwright-Clark team continuum [1, 2], own the cross-functional flow of the work and structure their schedules around how the product matures from concept to qualified volume. Functional views come from filtering the master plan. The Gantt is the team's shared picture of the work; the table is one way to query that picture. This paper covers seven philosophical splits that surfaced between the FTTM methodology and the senior PM's existing practice, shows why those splits are structural rather than personal, and outlines the coaching arc for moving mature PMs from lightweight to heavyweight ownership. It also clarifies a point that gets lost in technical argument. The methods being introduced come from years of work on products that reached market quickly. The team has not been asked to use them before. Every PM and core-team member who learns them now adds a capability that travels. The conclusion reaches beyond one program. In a legacy operating model, the schedule does not change until the team does, and the team does not change until the host gives the PM authority over the work and tells her clearly that this new mode is what the company is asking her to learn. -- 3 of 23 -- › The schedule mirrors the team › › › 01 Diagnostic The setup and the diagnostic © 2026 lateralworks Page 4 A senior project manager at a global semiconductor company, running a complex new-product program for AI data-center customers, left an FTTM workshop with a cross-functional schedule and a heavyweight team structure. Within weeks the schedule had been quietly rebuilt into the functional shape she had used for two decades. The structural logic the team agreed to at the workshop was still visible underneath. The operating model she worked in every day had written over the top of it. This section covers what we observed and what the schedule revealed about the organization underneath. -- 4 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 5 Context A complex program in a legacy operating environment The company is a top-five global semiconductor manufacturer with tens of thousands of employees across design centers, fabs, and qualification labs in three regions. Its product portfolio includes advanced nodes for AI data-center accelerators sold to hyperscalers and AI-infrastructure customers. These are programs measured in hundreds of millions of units, with multi-year design-in cycles and revenue opportunities that anchor the company's growth trajectory. A single qualification slip on one of them can move the parent's quarterly guidance. The program at the center of this case study is a new-product development with high-volume production targets, a tight competitive window against AI-accelerator alternatives from rival foundries and IDMs, and a schedule that touches every function in the company: design, foundry release, multi-site assembly and test, reliability qualification, system-level validation, and customer engagement. The project development team is staffed cross-functionally, but it is structured as a lightweight coordination layer. The PM has visibility into all functions and authority over none of them. Why FTTM was introduced Senior leadership engaged lateralworks because the company's prior programs had developed a familiar pattern: schedule slips that compounded in the back half, late integration discoveries that forced multiple silicon spins, and customer commitments delivered six to twelve months later than the original target. The diagnosis was consistent across post-mortems. Each function ran its own plan. Integration risk surfaced late. The cross-functional project manager spent more time chasing status than driving decisions. The leadership ask was specific: adopt a methodology that gets the company to market faster on the next AI data-center program, with predictable execution. FTTM is built for exactly this problem. It shifts the operating model from functional sequencing through coordination handoffs to cross-functional flow owned by an empowered core team. The methodology is grounded in heavyweight team principles articulated by Wheelwright and Clark in their study of fast-cycle product development [1, 2], extended through three decades of lateralworks engagement data across hardware, semiconductor, and complex-systems programs [3]. The senior PM The PM running the program is a 20-year veteran. She is technically fluent, organizationally credible, well-regarded by the functions, and trusted by the executive layer above her. She has also spent her career as a textbook lightweight PM: coordinating functional teams that report elsewhere, building schedules that answer to gates rather than drive flow, and answering executive questions with tabular data drawn from spreadsheets. She is good at the work she has been doing, and she has been promoted for it. She attended the FTTM workshop. She participated. She left with a schedule built around process flow and product maturity, with a cross-functional dependency structure, and with a heavyweight orientation toward the work. Three weeks later, when we sat down with her to review the refined version of that schedule, the cross-functional spine had been overwritten. The structure was still recognizable in places, but the spine had been replaced with the functional groupings she had used her entire career. -- 5 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 6 What the schedule revealed When we ran the FTTM Analyzer against the refined plan, the diagnosis was immediate. The schedule had been functionally restructured. The process-flow architecture from the workshop survived only as fragments: section labels, a few cross-functional links. The spine had been replaced. The most reliable diagnostic is the upward link. In a cross-functional schedule, dependencies flow forward and downward through the WBS as the product matures: design feeds engineering builds, builds feed qualification, qualification feeds customer release. The plan reads as a story of progressive product maturity. In a functional schedule, dependencies leap up and down inside each functional cluster — test tasks chain to test tasks, fab tasks chain to fab tasks — because the work has been grouped by who does it rather than by when it happens in the product's journey. The Analyzer flagged dozens of upward links across the refined plan. Reinertsen reaches a parallel conclusion in his treatment of product-development flow [4]. Invisible queues and hand-off discontinuities are the root cause of slow programs, and they are easiest to spot when the work is mapped as a forward flow rather than as a static functional inventory. A functional schedule hides queues inside each cluster. A cross-functional schedule exposes them at the seams where one function is waiting on the previous one. The Gantt-as-table problem A second pattern surfaced almost immediately. The PM does not use the Gantt view. She reads the schedule from the left-hand text rows and traces dependencies by referring back to the table. She reported, without irony, that she "can do that in the words." She has never used the Gantt as her primary view. A schedule read from a table is a private database for one person. A schedule read from a Gantt is a communication tool for a team. The Gantt carries information the table cannot show concisely: concurrency, critical-path geometry, slack, the visual signature of a healthy versus a stressed plan, and where pull-in opportunities live. A team that cannot read the Gantt cannot engage with the plan, and a team that cannot engage with the plan cannot own its commitments. The lightweight PM, running the schedule alone, can work from the table. The heavyweight PM, running the schedule as a team artifact, depends on the Gantt. Functional versus cross-functional structure The disagreement on schedule structure is really a disagreement about who owns the work. The lightweight PM organizes by function because, in her operating world, the functions are her counterparties: separate organizations she must coordinate, each with its own leader and its own priorities. Grouping the schedule by function mirrors how she actually moves through her week — a meeting with test, a meeting with fabs, a meeting with QA, a meeting with the customer. The schedule is an accounting of those conversations. The heavyweight PM organizes by product flow because, in her operating world, the product is the unit of work and the team is the unit of execution. Functions participate in the flow rather than running parallel lanes that the PM has to keep aligned. Each task carries a functional code, so a function-specific view is one filter away. But the master plan is structured around how the product matures from concept to qualified volume, because that is how the team experiences progress. -- 6 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 7 The mechanical truth. A cross-functional schedule yields a function-grouped view at any time through filtering. A function-grouped schedule cannot yield a clean cross-functional view without rebuilding. The asymmetry argues for the cross-functional spine. -- 7 of 23 -- › The schedule mirrors the team › › › 02 Framework The team-levels lens © 2026 lateralworks Page 8 The most useful frame for understanding what we observed is Wheelwright and Clark's four-level continuum of project team configurations [1, 2]. The continuum runs from a pure functional hierarchy, where there is no project ownership at all, to fully autonomous tiger teams that are extracted from the functional organization entirely. Most companies live somewhere in the middle two levels. lateralworks engagement data places legacy semiconductor companies almost invariably between Level 1 and Level 2. -- 8 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 9 Framework Four configurations on the Wheelwright-Clark continuum Figure 1. The four team configurations on the Wheelwright-Clark continuum. Functional hierarchy (1): no project accountability; the product flows through functional gates. Lightweight (2): a project manager coordinates functional teams without authority. This is where most legacy semiconductor PMs operate. Heavyweight (3): a strong project manager drives the functional teams; the core team is empowered and accountable. Autonomous (4): the team is extracted entirely from the functional organization. Where the PM in this case study lives The senior PM in this engagement is operating squarely at Level 2, the lightweight configuration. She is a credible, senior coordinator who does not own the functional teams she works with. The functional leaders own those teams; she influences. She runs status, escalates risk, coordinates dependencies, and defends the timeline upward to executives. The schedule she builds reflects that posture exactly: a coordination artifact rather than a team operating system. Twenty years of operating at Level 2 have produced a settled view of what a schedule is for, who reads it, and how it should be structured. The view is correct for Level 2. It does not transfer to Level 3, and FTTM assumes Level 3. Where the program needs the PM to live The AI data-center program cannot be run successfully at Level 2. The integration complexity is too high, the cross-functional coupling is too tight, the customer expectations are too aggressive, and the cost of late discovery is too large. Programs of this scope demand heavyweight ownership: a project manager who drives the functions toward integrated product maturity rather than coordinating their independent timelines, supported by a cross-functional core team whose members are accountable to the program rather than to their functional homes. Moving from Level 2 to Level 3 is an operating-model change, not a tooling change. New tools (a different schedule structure, a Gantt-first reading discipline, the Analyzer's diagnostics) matter, but they are downstream of the structural shift. The host has to grant the PM authority over the work. The PM has to take it. The functions have to release it. None of that happens because a schedule was redrawn at a workshop. -- 9 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 10 Implication for the host. Tools migrate downward. If the organization above the PM continues to operate Level 2 (managing the program through functional reviews, holding functional leaders accountable for functional milestones), the PM cannot operate Level 3. The schedule structure is the visible symptom. The authority structure above the PM is the cause. -- 10 of 23 -- › The schedule mirrors the team › › › 03 Specifics Seven philosophical splits © 2026 lateralworks Page 11 A two-hour working session with the PM produced seven specific disagreements about how the schedule should be structured and read. Six are real philosophical splits, coherent and well-defended, rooted in the lightweight operating model. The seventh was a tactical proposal that we conceded after pushback. Together they map the lightweight and heavyweight scheduling worldviews against each other. -- 11 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 12 The catalogue What surfaced in the session # Issue Heavyweight / FTTM position Lightweight / functional position 1 Functional grouping vs. cross-functional flow Organize the schedule around how work flows through the product maturity arc: cross-functional, with flow as the spine. Code each task with its function so a function-specific view is one filter away. Functional grouping forces dependencies up and down, undermines Gantt readability, and turns the schedule into a coordination artifact rather than a team communication tool. Group tasks by function: all test together, all fabs together, all qualification together. Easier to read by function, matches how the organization actually works, and tasks rarely run perfectly in sequence anyway. The cross-functional layout feels chaotic. 2 Milestones embedded vs. stacked at the top Milestones live where they naturally exist in the flow, marked as internal dependencies and pulled together via filters when a reporting view is needed. Embedding plus filtering yields both views from one structure. Keep gates, customer-readiness milestones, and qualification milestones grouped at the top of the file. Quick to screenshot for executives; easy to track from the timeline view. 3 Predecessors going up (uplinks) Allowed but exceptional. Uplinks hide errors. Once there are many of them, a bad one created accidentally becomes invisible. When something flows up, bring it down into its true grouping; package tasks where they actually flow together. Uplinks are unavoidable inside any sensible functional grouping (e.g., test tasks naturally chain to other test tasks). Breaking the function apart to avoid them is worse than the problem. 4 Blank rows vs. summary milestone pairs Use summary milestone pairs to separate phases. Same visual separation; gives proper structure with automatic dependency roll-up; lets the schedule collapse to a handful of high-level activities for executive views. Blank rows separate phases. Personal preference. Cleaner to view. The summary-milestone logic is acceptable but not compelling. 5 Reading the schedule: Gantt vs. text The Gantt is the primary view. Critical path is followed there, pull-in opportunities are found there, and the team sees the integrated plan there. The text view is a secondary tool for editing detail. Reads the text view exclusively. Traces dependencies through the rows. Does not use the Gantt; reports being able to "do that in the words." Has never used the Gantt as her working view. 6 Calendar: elapsed days vs. standard Days only, on a standard calendar. Add non-working time as standard-calendar exceptions. Elapsed-day units misrepresent true duration and break tools that expect calendar-aware math. Used elapsed days, weeks, and a custom calendar with non-working time blocked out. The conversion to standard days appeared to pull the program in by months and forced a rollback to the custom calendar. -- 12 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 13 # Issue Heavyweight / FTTM position Lightweight / functional position 7 Product-line grouping (high-spec / low-spec) Reorganize qualification lots so each product variant forms its own product group with its fab and qualification tasks together, rather than splitting all fabs from all qualifications across variants. Add a single end milestone gathering all lots. A consolidated end milestone is not actionable; only individual lot completions feeding into post-process matter. The PM pushed back; we conceded the specific reorganization. Figure 2. The seven splits surfaced in the schedule review. Items 1–6 are real philosophical disagreements rooted in lightweight versus heavyweight operating models. Item 7 was tactical and conceded after pushback. -- 13 of 23 -- › The schedule mirrors the team › › › 04 Interpretation Why this is structural, not personal © 2026 lateralworks Page 14 A reflexive reading of the case is that the PM is rigid, defensive, or unwilling to learn. That reading is wrong, and following it would lead the host into a counterproductive coaching posture. The PM is doing exactly what the operating model she has worked in for two decades trains a senior coordinator to do. Her schedule is internally consistent with that model. The model is mismatched to the program. -- 14 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 15 Diagnosis The pattern is structural, not personal The defensive-reasoning trap Argyris's study of why expert professionals struggle to learn applies directly here [5]. Senior professionals build their careers on competent execution. They rarely experience public learning-related failure. When their core practice is challenged, the natural response is defensive reasoning: rationalize the existing practice, shift the frame to one in which the existing practice is correct, or acknowledge the new framework in principle while continuing the old practice in detail. Argyris shows this is a predictable cognitive pattern in highly successful professionals, not a character flaw. We observed exactly this pattern in the session. The PM did not argue against FTTM in principle. She agreed with the workshop output. She rebuilt the schedule into the functional shape anyway. Asked directly whether her uplinks contradicted the methodology, she defended them on functional-grouping grounds. Asked about the Gantt, she reported being able to do everything from the text. Each response is internally coherent within her operating model, and each is a small act of conserving the model against the new framework. The pattern across mature PMs lateralworks engagement data, collected across more than a hundred programs at semiconductor, hardware, and complex-systems companies over the past decade, shows that this is the rule rather than the exception in mature PMs working in lightweight organizations [3]. The schedule structure tracks the operating model closely. PMs from heavyweight organizations build heavyweight schedules without coaching. PMs from lightweight organizations rebuild any schedule, however well structured at hand-off, into the lightweight shape within weeks. The implication is direct. A methodology rollout that targets the PM in isolation, while leaving the operating model around her unchanged, does not stick. The unit of intervention is the host, and the team is where you measure whether the intervention worked. -- 15 of 23 -- › The schedule mirrors the team › › › 05 Reframe A learning opportunity, not a critique © 2026 lateralworks Page 16 The way lateralworks plans and manages projects comes from decades of work with products that reached market quickly: fast-cycle programs in semiconductors, hardware, and complex systems where time-to-market gaps determined commercial outcomes. The host engaged us specifically to compress time-to-market on the AI data-center program. That is the mandate. The methods we bring exist because they have produced fast outcomes elsewhere; the company is asking the team to learn them. -- 16 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 17 Reframe The team has not failed. They are being asked to learn. Surfacing seven specific disagreements about how a schedule should be structured can drift into something it should never become: an evaluation of competence. The PMs at this company are highly capable in their existing operating context. The senior PM in this case study has earned a twenty-year career by being good at her job. Our diagnosis is not that she is a poor project manager. It is that she is a strong lightweight project manager working in a program that needs heavyweight ownership, and that nothing in her operating environment has previously required her to develop the methods being introduced. That distinction matters for engagement. Argyris's defensive-reasoning trap [5] fires most reliably when accomplished professionals perceive that their existing practice is being judged. It fires least reliably when those same professionals understand that they are being asked to add a capability they have not previously been asked to develop. Reframing the engagement around what the team is learning, rather than around what the team has been doing wrong, disarms the trap at the front end and makes every subsequent coaching conversation easier. It also matters for accuracy about what the methods are. FTTM is a body of practice developed and refined across hundreds of fast-cycle programs in industries where speed is the primary competitive lever. The specific techniques the senior PM is being asked to adopt (cross-functional flow as the schedule spine, Gantt-first reading, standard calendars, summary milestone pairs, embedded gates) are the operational signatures of teams that ship faster than their competitors. They are taught because they work, and because the host is paying for the company to learn them. A career advantage, not a compliance task There is a message here for the PMs and core-team members on this program that risks being lost in the technical argument. The methods being introduced are durable, transferable career capabilities. A project manager who has internalized fast-cycle methodology (who knows how to structure a cross-functional schedule, how to drive a heavyweight team, how to read a program from a Gantt) carries that capability forward to every program, every role, and every company they work at thereafter. The attention required to learn it now compounds for the rest of a career. For the PDT leads, PMs, and core teams currently inside this engagement: this is an opportunity to add a body of practice to your toolkit that most program managers in legacy semiconductor environments never get exposure to. The companies that compete on time-to-market in AI data-center products will be staffed, at every level, with people who run programs heavyweight. Being one of those people, starting now, is worth more than any specific outcome on this one program. What the host owes the team The reframe is genuine only if the host carries it through. If senior leadership engaged lateralworks to bring fast-cycle methods into the company, that intent has to reach the PDT leads, the PMs, and the core teams as an invitation to learn, with the structural changes the methodology presumes behind it. Asking the team to develop heavyweight capabilities while the operating model continues to hold them in lightweight roles is an unfunded mandate, not a reframe. -- 17 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 18 The message that needs to land. The host engaged lateralworks to help the company get to market faster. The PMs and core teams on this program have been asked to operate in the mode the company has historically used; adopting FTTM is a developmental step the company is investing in. Every PDT lead, PM, and core-team member who takes it on emerges with a capability that travels with them. -- 18 of 23 -- › The schedule mirrors the team › › › 06 Path forward The coaching arc © 2026 lateralworks Page 19 Moving a mature PM from lightweight Level 2 to heavyweight Level 3 is rarely a straight line. The literature on professional learning and our own engagement experience converge on a multi-step progression that respects the PM's expertise while reframing the context in which that expertise operates. This section outlines the five steps we use, in the order they tend to matter. -- 19 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 20 Sequence Five steps, in the order they matter Step one: reframe, do not replace The PM's lightweight competence is real and valuable. The coaching frame is not "what you have been doing is wrong"; it is "what you have been doing is right for the operating model you have been in, and we are now changing the operating model." This reframing matters more than any specific tooling change. It preserves the PM's standing, brings her expertise into the new model, and avoids triggering the defensive reasoning that derails most methodology rollouts. Step two: change the host signals The PM cannot operate heavyweight if her counterparties are still operating lightweight. Senior leadership has to send unambiguous signals through review cadences, escalation paths, and which milestones get attention in operating reviews. The signal is that the program is now run cross-functionally and that the PM owns the integrated outcome. Without it, the PM's adoption of cross-functional structure looks like cosmetic compliance and gets reversed at the first real conflict. Step three: small structural wins Once the host signals are aligned, structural changes become possible without theological argument. Move milestones into the flow rather than stacking them at the top. Convert blank rows to summary milestone pairs. Code tasks with functional tags so function-specific filters become trivial. These are small, reversible changes individually. Cumulatively they reshape the schedule from a coordination database into a team operating system. Step four: switch the primary view The hardest behavioral change is moving the PM's primary working view from the text rows to the Gantt. This rarely happens through argument. It happens when the team begins running working sessions in front of the Gantt, finding pull-in opportunities, identifying critical-path risks, debating sequencing, and the PM discovers that the Gantt is where the conversation actually happens. The text view becomes the editing interface it should always have been. Step five: openness as a behavior A finding from decades of FTTM work: willingness to learn is the single best predictor of which mature PMs make the transition to heavyweight ownership. PMs who can hold their existing practice lightly enough to test alternatives, including alternatives they initially disbelieve, make the move. PMs who cannot do not, regardless of credentials, tenure, or technical skill. Openness is a behavior the host can reinforce through how it responds to experiments, errors, and reversals. -- 20 of 23 -- › The schedule mirrors the team › › › 07 Takeaways Implications for technology executives © 2026 lateralworks Page 21 Three implications follow for executives running large complex programs in legacy operating environments, particularly semiconductor and hardware leaders pursuing AI data-center opportunities where time-to-market gaps translate directly into design-win outcomes. -- 21 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 22 Takeaways Three implications for senior leaders Read your schedules Schedules are diagnostic. A well-built schedule reveals the operating model of the team that built it. Cross-functional spine plus a Gantt-driven team session implies heavyweight ownership. Functional clustering, top-stacked milestones, and a PM who reads from the table imply lightweight coordination. Senior leaders who inspect schedules with this lens read the operating model directly off the document. Decide which level you are operating at, and act accordingly Most legacy semiconductor companies sit between Level 1 and Level 2. Moving even one level (to a true Level 2 or, more ambitiously, to Level 3) produces a measurable improvement in time-to-market and integration quality. The move requires concrete changes in authority, accountability, review cadence, and incentive alignment. A methodology rollout without those structural changes is theatre. Invest in the host, not just the team The most expensive misallocation in methodology rollouts is heavy investment at the team layer with little or no investment at the host layer above. The team can be trained, equipped, and given new tooling. None of it survives contact with a host that continues to reward lightweight behavior. Intervene at the host layer; measure at the team layer. Transmit the learning frame The message that needs to reach every PDT lead, PM, and core-team member is that the company is investing in giving them fast-cycle methodology, and the rollout is a development opportunity rather than an audit of past performance. Executives who transmit that frame clearly, and back it with the operating-model changes the methodology presumes, get adoption. Executives who leave the team to interpret the rollout on its own get cosmetic compliance. The bottom line. For high-stakes AI data-center programs where every quarter of slip costs hundreds of millions in design-win position, the right question is whether the operating model gives the PM the authority to drive the program cross-functionally, and whether she has been told clearly that the company is asking her to learn something new. The schedule will show you the answer. -- 22 of 23 -- › The schedule mirrors the team › › › © 2026 lateralworks Page 23 Sources References [1] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. New York: Free Press, 1992. [2] Clark, K. B., and Wheelwright, S. C. "Organizing and Leading 'Heavyweight' Development Teams." California Management Review 34, no. 3 (Spring 1992): 9–28. [3] lateralworks. "Internal engagement assessment database." Aggregate observations across semiconductor, hardware, and complex-systems programs, 2015–2026. [4] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Redondo Beach, CA: Celeritas Publishing, 2009. [5] Argyris, C. "Teaching Smart People How to Learn." Harvard Business Review, May–June 1991, pp. 99–109. https://hbr.org/1991/05/teaching-smart-people-how-to-learn [6] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd edition. New York: Wiley, 1998. [7] Pisano, G. P., and Wheelwright, S. C. "The New Logic of High-Tech R&D." Harvard Business Review, September–October 1995, pp. 93–105. [8] House, C. H., and Price, R. L. "The Return Map: Tracking Product Teams." Harvard Business Review, January–February 1991, pp. 92–101. [9] Ericsson, K. A., Krampe, R. T., and Tesch-Römer, C. "The Role of Deliberate Practice in the Acquisition of Expert Performance." Psychological Review 100, no. 3 (1993): 363–406. [10] Dweck, C. S. Mindset: The New Psychology of Success. New York: Random House, 2006. -- 23 of 23 --

FTTM Coaching·Case study·Semiconductor / AI data-center

The schedule mirrors the team

Why functional project managers build functional schedules — and what it takes to move them

Core thesis. A schedule is the visible artifact of an invisible operating model. When a functional organization adopts cross-functional tools, the organization reshapes the tools faster than the tools reshape the organization. Real change comes from moving the team from lightweight coordination to heavyweight ownership; the schedule will follow.

April 30, 2026·23 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Case study Charles Schwab IT infrastructure rationalization How program structure and portfolio prioritization halved the path to $15M in annual savings Program delivery series. Migration of 1,100 Solaris and AIX servers and 145 applications to a standardized Linux/Intel platform. $8.8M run-rate savings in 18 months. Independently validated by The Research Board across 22 major enterprises. Prepared by lateralworks Program delivery practice Date April 2026 Case study Online lateralworks.com Program delivery series -- 1 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 2 Table of contents Charles Schwab IT infrastructure rationalization Abstract 03 01 The context: infrastructure at a crossroads 04 02 The challenge: why this was failing 06 03 The solution: four interlocking interventions 08 04 The operating model 12 05 Results and impact 14 06 Why this succeeded where unstructured programs fail 17 07 Key takeaways: the reusable pattern 18 Sources 20 Core thesis. Time-to-savings programs fail when they lack portfolio prioritization, integrated planning, and financial visibility. lateralworks turned a 400-project backlog into a sequenced, measurable execution engine by applying the same program structuring discipline used in time-to-market product delivery, reframed around cost-savings velocity rather than ship dates. -- 2 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 3 Overview Abstract Charles Schwab launched the IR program to migrate over 1,100 Solaris and AIX servers and 145 software applications onto a standardized Linux/Intel ("Lintel") platform. The target was a $15–25 million reduction in annual IT operational run-rate, delivered fast, with minimal disruption to the customer-facing trading and brokerage systems that processed millions of transactions daily. When lateralworks engaged, the program was already underway but stalling. Over 400 loosely prioritized projects competed for limited resources. Meetings ran 20+ attendees with no clear ownership. The technical ideas were strong (virtualization, standard stacks on low-cost hardware), but the program lacked the governance structure and sequencing discipline to convert them into measurable savings. lateralworks restructured the program around four interlocking interventions: strategy-to-execution alignment workshops with Schwab executives; a macro plan built on six milestones with explicit doneness criteria; a portfolio prioritization model that revealed 70% of savings concentrated in three business groups; and a dynamic financial tracking system that gave the team real-time visibility into actual versus forecast savings. Within 18 months, the team realized $8.8 million in annual run-rate savings and migrated 60% of the server fleet. At completion, the server count dropped from 1,100 to 400, a 64% reduction, ahead of both savings targets and schedule. The program won Program of the Year at Schwab, and the execution model was adopted as a repeatable practice across the division. An independent study by The Research Board Inc., benchmarking rationalization initiatives across 22 major enterprises for American Airlines, identified lateralworks as the key vendor in the services portion of the initiative and documented Schwab’s results alongside programs at Bank of America, ExxonMobil, Lockheed Martin, Shell, and others. $8.8M Run-rate savings, 18 months 64% Server fleet reduction 1,100 → 400 Servers consolidated ~50% Schedule acceleration -- 3 of 20 -- › Charles Schwab IT infrastructure rationalization › › › 01 The context Infrastructure at a crossroads © 2026 lateralworks Page 4 In the early 2000s, Charles Schwab operated one of the largest online brokerage platforms in the United States, processing millions of trades and serving over seven million client accounts through data centers in Phoenix and San Francisco. The technology infrastructure had grown organically over years of rapid expansion. The result was a sprawling fleet of over 1,100 servers running Solaris and AIX, supporting 145 distinct software applications across multiple business groups. The pattern was common in financial services at the time. Server sprawl had spread across the industry: data centers filled with underutilized machines, each hosting a single application, utilization rates often below 30%. The cost of maintaining this heterogeneous infrastructure (licensing, power, cooling, physical space, specialist staff for multiple Unix variants) consumed a growing share of IT budgets. -- 4 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 5 Schwab’s leadership saw that migrating to a standardized Linux/Intel platform — the industry’s "Lintel" stack — could cut total cost of ownership sharply. CIO Geoff Penney advocated openly for the move, stating his intent to put Unix workloads onto commodity Intel hardware running Linux [5]. The logic he gave Network Computing was simple: commodity hardware wins on cost, and standardization simplifies operations. The IR program followed from this conviction. The mandate: cut $15–25 million from annual IT run-rate by migrating the distributed server fleet to Lintel in under three years. The measure of success was dollars per quarter, not ship dates. This was a time-to-savings program. -- 5 of 20 -- › Charles Schwab IT infrastructure rationalization › › › 02 The challenge Why this was failing © 2026 lateralworks Page 6 When lateralworks began its assessment, the IR program had already been running for several months. Technical talent was strong and the strategic direction was sound, but the program was foundering on the same organizational failure modes that kill large-scale transformation initiatives across industries. No structure, no ownership The team had ballooned into 20-person meetings with no clear ownership of deliverables, no team structure, and no integrated planning. Specialists had completed detailed technical analysis, but without a common framework, no one could see how individual contributions fit the overall program. The prevailing mood was urgency without direction: pressure to demonstrate activity regardless of whether it moved the savings target. -- 6 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 7 400 projects, no prioritization The 1,100 servers and 145 applications were grouped into roughly 400 projects, each tied to server clusters and the business groups that owned them. Every project had equal priority. The instinct was to start as many as possible at once, the recurring failure mode of large programs that confuse activity with progress. There was no model linking individual project completion to the overall savings target. Without that link, the team could not tell which projects would deliver the most savings, in the least time, with the least disruption. Existential risk to the franchise This was not a back-office cleanup. The server fleet included critical customer-facing systems, including those running schwab.com, the primary interface for millions of retail investors. Any downtime during migration could cost the company millions in lost revenue and damage client trust in a business built on reliable access to accounts and trading. The sequencing had to protect the franchise while accelerating cost savings. lateralworks’ assessment. The technical base was strong, but the program lacked a structure to channel the expertise. Without portfolio prioritization, integrated planning, and clear ownership, 400 projects would keep battling for resources with no measurable progress toward the savings target. -- 7 of 20 -- › Charles Schwab IT infrastructure rationalization › › › 03 The solution Four interlocking interventions © 2026 lateralworks Page 8 lateralworks restructured the IR program around four reinforcing interventions. Each addressed a distinct failure mode; together, they converted a stalled initiative into a disciplined execution engine. Schwab’s own account, documented in the independent Research Board study [2, 3], confirms the selection rationale. Schwab had used IBM, HP, and Sun for strategy and planning, then requested proposals from IBM, HP, and lateralworks for professional services to take the program from strategy into implementation and deployment. Schwab selected lateralworks. The program objectives, as Schwab stated them, went beyond cost reduction to include platform simplification, adoption of commodity-priced components, and a standard stack approach. -- 8 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 9 1. Strategy-to-execution alignment lateralworks ran a series of workshops with Schwab executives to establish a common vision, measurable goals, strategies to reach those goals, and tactics to execute the projects. The vision — to become a service-oriented technology provider, the ISCo model — had existed in fragments but had never been translated into a unified framework that connected strategic intent to project-level action. Alignment was the prerequisite. Without it, 400 projects would keep battling for resources with no shared direction. 2. Program structuring lateralworks worked with the newly formed core team to build a macro plan organized around six milestones — the high-level deliverables already committed to internal customers and Schwab’s management chain. For each milestone, the team defined explicit doneness criteria that scoped the work and identified the activities required for completion. Building the macro plan was like assembling the edges of a jigsaw first: it set the framework for the detail. The structure changed team dynamics. Instead of debating technical minutiae or fixating on each other’s weaknesses, the team focused on the schedule data and found common ground. The scoping process built the collaborative behaviors the team would need under execution pressure. 3. Portfolio prioritization and sequencing Schwab’s team later identified this as the single most important driver of program success. lateralworks built a decision model that evaluated all 1,100+ servers across four criteria: greatest savings potential, readiness to change, time to migrate, and importance to the business. The model extracted financial data from every server and ranked them by savings impact and cost to migrate. The analysis revealed a Pareto pattern. About 70% of total savings were concentrated in three business groups. Roughly 75% of those savings came from a small subset of servers within those groups. The execution strategy followed: rather than pursuing 400 projects at once, the team now had a clear sequence — which servers, in which business groups, to target first for maximum early savings. -- 9 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 10 Figure 1. About 70% of total savings sat in three business groups (cumulative line crosses the 70% threshold by Group C). The decision model surfaced this concentration and let the team sequence migrations to front-load the highest-value work. 4. Dynamic financial tracking lateralworks built a cost model that let the team analyze financial data by business group, application, tier, or any combination, and track actuals against forecast as migrations completed. The model plotted actual and projected savings over time alongside targets, with options to view data quarterly or cumulatively and to toggle baseline comparisons. The cost model was a decision-making instrument, not a reporting tool. Each week it answered the program’s central question: were we on track, or did we need to accelerate or add projects to hit the savings target? The trending data became the program’s health indicator and the vehicle for executive reporting. -- 10 of 20 -- Operating principle Schedule data over politics Let the schedule data drive decisions. Not politics, not seniority, not whoever shouts loudest in a 20-person meeting. lateralworks operating principle Charles Schwab IR program, 2003 – 2005 © 2026 lateralworks Page 11 -- 11 of 20 -- › Charles Schwab IT infrastructure rationalization › › › 04 Operating model How the program ran day to day © 2026 lateralworks Page 12 A structure only matters if it changes behavior. The IR operating model changed behavior in three ways. The model connected executive governance through alignment workshops to three reinforcing disciplines, then channeled everything into a single execution engine that tracked actuals against forecast every week. -- 12 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 13 Figure 2. The lateralworks operating model connected strategy alignment through prioritized execution to measurable outcomes. Execution mechanics Weekly schedule refresh with fast roll-ups. The program was too large for a single schedule, so each project maintained its own detailed schedule, refreshed weekly with the cross-functional migration teams. At the end of each week, the lowest-level activities rolled up into the macro plan. The whole process took under an hour per week and gave the program a continuously accurate view of every server and application migration without consuming the team’s bandwidth. Start small, scale deliberately. Because the program touched every part of Schwab’s organization, including systems supporting hundreds of millions of dollars in private and institutional trading, the team started with high-savings, low-disruption migrations. That sequencing built confidence and proved the model before the team tackled the most sensitive systems. Gradual team expansion with cross-checking. lateralworks expanded the team incrementally, scrubbing and refining the schedule with each new set of eyes. Every planning event was cross-checked against the vision/goal/strategy/tactic/project framework set during the alignment phase. Buy-in deepened with each iteration, and every team member came to understand the full magnitude of the program. -- 13 of 20 -- › Charles Schwab IT infrastructure rationalization › › › 05 Outcomes Results and impact © 2026 lateralworks Page 14 The IR program delivered on every dimension that mattered to Schwab: cost reduction, migration velocity, operational simplification, and organizational capability. Financial performance The team realized $8.8 million in annual run-rate savings within 18 months, attributed directly to the simplified management of the integrated Lintel stack and the reduction in vendors and products [3]. Savings targets were beaten ahead of schedule. The engagement accelerated $15–25 million in annual savings in roughly half the time originally projected. -- 14 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 15 Figure 3. Run-rate savings trajectory over the first 18 months of execution. Migration velocity and fleet consolidation Within 18 months, 60% of the server fleet had been migrated, with only 8% of in-scope servers not yet scheduled. At program completion, the fleet was consolidated from 1,100 to roughly 400 servers, a 64% reduction. The standardized Lintel stack reduced complexity and lowered the cost of every future deployment. Figure 4. Server fleet before and after the IR program. -- 15 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 16 Recognition The IR program won Schwab’s internal Program of the Year award. Managing Director Robin McGlothin and Program Manager Jodi Speegle were publicly recognized by Charles Schwab himself for their work on the program. Independent validation: the Research Board study In the same year, The Research Board Inc. conducted an independent inquiry into consolidation and rationalization initiatives across its membership, triggered by American Airlines’ preparation for a similar program [2]. The study drew responses from 22 major enterprises, including Allianz, Bank of America, Bosch, Colgate-Palmolive, Commerzbank, Delphi, Dow, Discover, DuPont, ExxonMobil, Lockheed Martin, Novartis, Northrop Grumman, Pitney Bowes, Shell, Southern California Edison, and Wells Fargo. Schwab’s response provided a detailed account of the IR program and lateralworks’ role in it. In the executive summary of that report, The Research Board described Schwab’s program alongside peer initiatives from some of the world’s largest companies and identified lateralworks as the key vendor in the services portion of the initiative [3]. Schwab’s response to the inquiry described what lateralworks delivered in precise terms. On scope and method, Schwab wrote that lateralworks was selected over IBM and HP for professional services assistance at the launch of the implementation phase. On differentiation, Schwab stated that lateralworks’ approach focused on prioritizing the work effort, delivering fast time-to-implementation, and putting in place a repeatable process for deployment, rather than relying on a tool or methodology related to rationalization. On results, Schwab reported direct benefits of $8.8 million in run-rate savings, management of an integrated standard stack for future Lintel deployments, and environment simplification through reduction in vendors and products. Schwab also cited indirect benefits: improved deployment quality, elimination of redundant products and services, and reduced licensing costs. The Research Board’s summary placed Schwab’s results in context. Among 22 respondents covering very different industries and rationalization approaches (Bosch’s SAP consolidation, ExxonMobil’s 13 global service lines, Northrop Grumman’s data center reduction from 122 to 9), Schwab’s program stood out for execution velocity and the clarity of its savings attribution. From the Schwab response to The Research Board (verbatim): "Schwab selected LateralWorks for professional services assistance at the launch of the program. LateralWorks’ focus was not on a tool or methodology related to rationalization, but rather on an approach to prioritizing the work effort, focused fast time to implementation deliverables and implementing a repeatable process for the implementation/deployment effort." [2] -- 16 of 20 -- › Charles Schwab IT infrastructure rationalization › › › 06 Failure modes Why this succeeded where others fail © 2026 lateralworks Page 17 Large-scale IT rationalization programs fail for reasons that have little to do with technology. They fail because the work is not prioritized, the financial linkage between projects and targets is invisible, and the governance model cannot distinguish between activity and progress. The Schwab IR program succeeded because lateralworks attacked each of these failure modes directly. Unstructured program lateralworks-structured program All projects treated as equal priority; resources spread thin Decision model ranks by savings impact, readiness, time, and business criticality No linkage between project completion and savings targets Dynamic cost model tracks actual vs. forecast savings in real time 20+ person meetings; unclear ownership of deliverables Small core team with clear ownership; graduated team expansion No integrated plan; activity mistaken for progress Macro plan with six milestones, doneness criteria, and weekly refresh Technical debates consume planning time Schedule data drives decisions; team focuses on the plan, not on each other Status reporting takes days; picture always stale Roll-up process takes under an hour per week; picture always current -- 17 of 20 -- › Charles Schwab IT infrastructure rationalization › › › 07 The pattern Reusable principles for any program © 2026 lateralworks Page 18 The Schwab IR program demonstrates principles that apply to any large-scale cost-reduction, migration, or infrastructure transformation, whether server rationalization, cloud migration, application modernization, or technical debt reduction. -- 18 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 19 Prioritize by impact, not by ease. The decision model that ranked servers by savings potential, readiness, migration time, and business criticality was the single most important intervention. It replaced equal-priority chaos with a data-driven sequence that front-loaded the highest-value work. Build the framework before the detail. The macro plan (six milestones with doneness criteria) gave the team a shared structure before they drilled into project-level detail. Like assembling the edges of a jigsaw first, it set the context that made the detail meaningful. Make savings visible and trackable. A time-to-savings program lives or dies by its ability to show whether individual projects are advancing the aggregate target. The dynamic cost model gave the team and leadership continuous visibility into the gap between where they were and where they needed to be. Start small, scale fast. Beginning with high-savings, low-disruption migrations, the team built momentum, showed value to leadership, and refined the execution process before taking on the riskiest customer-facing systems. Separate signal from noise in team meetings. Shrinking meetings from 20+ people to a focused core team with clear ownership eliminated the coordination overhead that was consuming the program’s bandwidth. The schedule became the shared artifact that replaced interpersonal debate. Build repeatable capability, not one-time heroics. The decision model, tracking tools, and execution cadence developed for IR were reused across Schwab’s division. A good program builds the organization’s capability to run the next program, not just the current one. Schwab’s own retrospective, documented in the Research Board study [2], reinforces these principles. Asked what they would change, the Schwab team wrote that they would schedule periodic checkpoints to review baseline assumptions and technology decisions during implementation, because the business is not static, and once execution begins it is easy to become internally focused without noticing how the environment is shifting. The discipline of execution must coexist with strategic awareness, not replace it. The pattern. When the mandate is time-to-savings, treat the portfolio like a product backlog. Prioritize by impact. Build an integrated plan with clear milestones. Track actuals against targets with financial precision. Start with high-ROI migrations. Expand the team gradually. Let the schedule data drive decisions, not politics, not seniority, not whoever shouts loudest in a 20-person meeting. -- 19 of 20 -- › Charles Schwab IT infrastructure rationalization › › › © 2026 lateralworks Page 20 Sources References [1] lateralworks. "Infrastructure Rationalization Program — Charles Schwab." lateralworks client account. [2] The Research Board Inc. "Consolidation/Rationalization Initiatives: RB Inquiry Summary." Independent study commissioned by American Airlines; 22 respondents including Schwab, Bank of America, ExxonMobil, Lockheed Martin, Shell, and others. Schwab response (pp. 34–35) identifies lateralworks as key vendor for implementation/deployment. [3] The Research Board Inc. Executive Summary (p. 2): confirms lateralworks as "the key vendor in the services portion of the initiative" and reports $8.8M run-rate savings attributed to Lintel stack standardization. [4] Sasson, G. "Streamlining Schwab." Institutional Investor, 2005. Profile of Schwab CIO describing technology infrastructure simplification effort. [5] Penney, G., cited in "Charles Schwab’s IT Mission." Network Computing / ITPro Today, c. 2004. CIO discusses migration from AIX/Solaris to Linux/Intel. [6] Computerworld. "Schwab goes live with grid computing technology." Dec 19, 2003. Describes Schwab’s Phoenix data center and Linux/Intel infrastructure strategy. [7] Charles Schwab Corp. "Cabling Infrastructure Investment." Cabling Installation & Maintenance. Describes Phoenix Regional Call Center infrastructure. [8] Tradeline, Inc. "Charles Schwab Builds New Data Center." Oct 5, 2000. $72M Chandler data center project. [9] Ricor, Inc. "Charles Schwab South Mountain Data Center." 340,000 sq ft campus description. [10] Charles Schwab Corp. Form 8-K filings, FY2003–FY2005. SEC filings documenting cost reduction initiatives and restructuring charges. [11] CIO Dive. "Charles Schwab credits increased AI use with cost savings." Jan 24, 2025. Documents Schwab’s ongoing technology cost-reduction culture. Program narrative based on lateralworks account. Public product and financial details cited where available. -- 20 of 20 --

Client Projects·Case study·IT

Charles Schwab IT infrastructure rationalization

How program structure and portfolio prioritization halved the path to $15M in annual savings

Core thesis. Time-to-savings programs fail when they lack portfolio prioritization, integrated planning, and financial visibility. lateralworks turned a 400-project backlog into a sequenced, measurable execution engine by applying the same program structuring discipline used in time-to-market product delivery, reframed around cost-savings velocity rather than ship dates.

April 15, 2026·20 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Case study Launching Windows CE at startup speed How an empowered product delivery team shipped a first-wave handheld PC in 13 months FTTM case study series. Philips Velo (Windows CE handheld PC), 1996–1997. lateralworks recommended a dedicated product delivery team operating outside the host hierarchy. The team shipped in 13 months — an 18-month acceleration over a typical Philips program. Prepared by lateralworks Fast Time To Market methodology Date February 2026 Case study Online lateralworks.com FTTM case study series -- 1 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 2 Table of contents Launching Windows CE at startup speed Abstract 03 01 The context: a narrow window of exclusivity 04 02 The challenge: why this would fail in a hierarchy 06 03 The solution: a dedicated product delivery team 08 04 The operating model 11 05 Results and impact 14 06 Why this beat siloed programs 16 07 Key takeaways: the reusable pattern 18 References 20 Core thesis. When the deadline is existential and the work spans multiple companies, the single most important design decision is organizational, not technical. Stand up a ring-fenced product delivery team with end-to-end ownership, governed above the hierarchy, and let an integrated master schedule do the coordination work that committees do too slowly. -- 2 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 3 Overview Abstract In 1996, Philips secured a limited exclusivity window to launch Microsoft’s new Windows CE mobile operating system. Smartphones did not yet exist. Hardware makers were lining up to ship the first generation of “Handheld PC” products, and the exclusivity window was the difference between defining the category and following someone else into it. lateralworks was brought in through a long-standing relationship with Philips Semiconductor and gave a blunt assessment: Philips would miss the window if the program ran through the standard business-unit hierarchy. The decision latency, ownership fragmentation, and silo-driven coordination costs were incompatible with the timeline. The recommendation was to stand up a dedicated Product Delivery Team (PDT) led by a single Product Delivery Leader — Tony Fadell — with end-to-end ownership from concept through high-volume production. The team would be ring-fenced from host-organization interrupts, governed by its own budget and steering structure, and would manage a predominantly outsourced execution model through a single integrated master schedule. A 20-person core team orchestrated more than 200 development partners to deliver the Philips Velo — a feature-rich Windows CE handheld PC — with full manufacturing ramp in 13 months. It was an early implementation in Silicon Valley of what is now the standard operating model for complex consumer electronics delivery. 13 Months to ship ~20 Core team 200+ Partners managed 18 mo. Schedule acceleration -- 3 of 20 -- › Philips Velo case study › › › 01 The context A narrow window of exclusivity © 2026 lateralworks Page 4 In the mid-1990s, mobile computing sat in an awkward in-between era. Laptops were bulky, smartphones did not exist, and PDAs were largely organizer-first devices. Microsoft’s Windows CE was an attempt to bring a familiar Windows experience onto small, battery-powered hardware, and it triggered a race to ship the first generation of “Handheld PC” products. -- 4 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 5 Philips had secured something rare: a limited exclusivity window to be among the first to ship on the new platform. The market window was binary. Ship early and well, define the category. Ship late, become an irrelevant follower in a market that was forming fast. The product that emerged was the Philips Velo 1: a clamshell handheld PC under one pound, running Pocket versions of Office applications, capable of web browsing, fax, and voice memo. The capability set anticipated what smartphones would deliver a decade later. The Smithsonian Institution later preserved Velo as a notable computing artifact. The Philips Velo 1: a full Windows CE handheld PC with Pocket Office, web browsing, fax, and voice memo capabilities. “The king of the HPC hill is Velo 1…” — Inc. Magazine, June 1997 -- 5 of 20 -- › Philips Velo case study › › › 02 The challenge Why this would fail inside a hierarchy © 2026 lateralworks Page 6 Philips faced what lateralworks recognized as a classic “corporate impossibility”: a breakthrough product, tied to an external platform launch, with a narrow market window and a long list of internal and external stakeholders. Four constraints made the situation acute. -- 6 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 7 Time compression Deliver a complete consumer electronics product — hardware, software, industrial design, manufacturing readiness, accessories, packaging, and go-to-market — on a schedule more typical of a focused silicon program than a full consumer launch. Every week of delay against the closing Microsoft exclusivity window was measurable competitive risk. Platform uncertainty Windows CE was new, still evolving, and had not yet found its definitive use-case narrative. Building a flagship product on an unproven platform introduced technical risk at every layer of the stack. Cross-company complexity The Velo required tight integration across Microsoft’s OS team, Toshiba, Selectron, and multiple specialist suppliers, spanning hardware design, RF and modem behavior, industrial design, peripherals, manufacturing, and distribution. The build was a multi-company orchestration challenge as much as a product engineering one. Organizational friction — the core risk This was the factor lateralworks flagged most forcefully at kickoff. Running Velo through Philips’ standard business-unit hierarchy would introduce fatal decision latency and ownership fragmentation. In a traditional matrix structure, every cross-functional decision would escalate through multiple chains of command. Procurement, legal, manufacturing, and engineering would operate on sequential gates. Integration pain would surface late, when it was most expensive and least recoverable. lateralworks had seen this failure mode repeatedly in large organizations: each function optimizes locally, milestones get designed for reporting optics rather than integration readiness, and the integrated product misses its market window while individual teams claim they hit their own targets. The lateralworks assessment. Do not run this through the normal Philips hierarchy. The decision latency and ownership fragmentation will overwhelm the schedule. Philips will fail. -- 7 of 20 -- › Philips Velo case study › › › 03 The solution A dedicated product delivery team © 2026 lateralworks Page 8 lateralworks recommended, and Philips agreed to implement, a different operating model. Rather than fitting Velo into the existing structure, Philips would create a dedicated Product Delivery Team that operated as a ring-fenced venture inside the company, insulated from host-organization interrupts and governed by its own rules. The model rested on five interlocking design choices. -- 8 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 9 1. Ring-fenced venture structure The PDT operated with its own budget, leadership, and governance. It reported directly to an executive steering team at the board level rather than through the standard business-unit hierarchy. That compressed decision cycles: fewer committees, fewer handoffs, fewer veto points. The board provided air cover and fast escalation but did not micromanage execution. 2. Single product delivery leader with end-to-end ownership lateralworks advised appointing Tony Fadell as the single accountable Product Delivery Leader, empowered to make product tradeoffs, resolve cross-functional conflicts, and drive the program from concept through high-volume manufacturing ramp. The “single throat to choke” model is uncomfortable for many corporations and is one of the clearest predictors of speed in novel product categories. Fadell’s end-to-end ownership eliminated the committee-driven compromise that dilutes product vision and slows execution. He later applied practices honed on Velo to help create the iPod, iTunes, iPhone, and iPad at Apple, and founded Nest Labs (acquired by Google). 3. Small, senior core team The core PDT was about 20 people, deliberately kept small to maximize communication bandwidth and decision speed. The team was cross-functional, spanning product management, engineering, operations, and program management. Every member was senior enough to make real decisions, not relay information. Small teams communicate at high bandwidth, which matters when you are constantly trading scope, schedule, and technical risk. 4. Outsource-first execution model Rather than staffing a large internal organization — which would have taken months Philips did not have — the model relied on specialist external partners to execute the major build and test workstreams. The core team retained ownership of architecture, integration, interfaces, and the schedule. Today the “extended enterprise” model is standard practice in consumer electronics; in the mid-1990s it was rare, and Velo was one of the first implementations of the model in Silicon Valley. 5. Integrated master schedule as the single source of truth One integrated plan replaced the twenty departmental plans a traditional structure would have produced. Every partner, every workstream, and every dependency sat on a single critical path. Tradeoffs were explicit: change X, slip Y. Cross-team dependencies stopped being someone else’s problem. The master schedule was the mechanism that made partnership scalable. -- 9 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 10 At a glance The product Figure 1. The Philips Velo 1 in hand. A full Windows CE handheld PC weighing under one pound, with web browsing, fax, voice memo, and Pocket Office applications. The Velo was preserved by the Smithsonian Institution as a notable computing artifact. Inc. Magazine described it in June 1997 as the leading device in its category. The capability set anticipated by nearly a decade what mobile users would later expect from smartphones. -- 10 of 20 -- › Philips Velo case study › › › 04 Operating model How the structure changed behavior © 2026 lateralworks Page 11 The PDT operating model created a single chain of authority from executive governance through the core team to the extended partner ecosystem. The diagram on the next page shows the structure. The three sections that follow describe the day-to-day execution mechanics that turned the structure into behavior. -- 11 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 12 Figure 2. The PDT operating model. A single chain of authority from the Philips executive board through the Product Delivery Leader and core PDT to the extended ecosystem of 200+ specialist partners. A structure only matters if it changes behavior. The Velo PDT changed behavior in three ways. -- 12 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 13 High-frequency cross-company cadence The core team ran 2–3x weekly schedule updates with scenario modeling: if supplier A slips, what do we cut, parallelize, or swap? Decisions were pushed to the smallest group that could responsibly make them, rather than escalated through hierarchical status reporting. Parallel execution streams Engineering, procurement, legal, and manufacturing moved in parallel. lateralworks helped accelerate procurement and legal paths to compress tooling, materials, and partner contracting timelines. That eliminated months of internal queue time a traditional gated process would have imposed. Integration-ready milestones Milestones were designed around integration readiness and shipment criteria, not reporting optics. The weekly integration rhythm forced early risk discovery and kept cross-partner dependencies visible and actively managed. -- 13 of 20 -- › Philips Velo case study › › › 05 Results Delivery, market, lasting influence © 2026 lateralworks Page 14 The Velo program achieved what most large organizations struggle to do: ship a tightly integrated, multi-partner product on a compressed timeline without drowning in internal coordination costs. -- 14 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 15 Delivery Full system development through manufacturing ramp was delivered in 13 months, missing the original 12-month target by one month and representing an 18-month acceleration over a typical Philips program. The 20-person core team orchestrated more than 200 development partners through one master schedule and a shared cross-company cadence. Market Velo released at COMDEX and won a COMDEX new product award. Industry media positioned it as a leading first-generation Windows CE device, with Inc. Magazine calling it the top device in its category. The shipping product included web browsing, fax, voice memos, Pocket Office applications, and an integrated modem — capabilities that anticipated smartphone-era expectations by nearly a decade. Lasting influence Tony Fadell, who served as Product Delivery Leader, later applied the practices honed on Velo to help create the iPod, iTunes, iPhone, and iPad at Apple, and founded Nest Labs (acquired by Google). The PDT model — small core team, outsource-first execution, executive-level governance — became a blueprint for the now-standard approach to complex consumer electronics delivery. The Philips Velo is preserved by the Smithsonian Institution as a notable computing artifact. 13 mo. Full delivery to ramp 18 mo. Schedule acceleration 200+ Partners orchestrated 1996 Pre-iPhone, pre-iPad Outcome. A 20-person core team, a single empowered leader, and an integrated master schedule shipped a first-wave Windows CE product in 13 months — 18 months faster than a typical Philips program of comparable scope. -- 15 of 20 -- › Philips Velo case study › › › 06 Comparison Why this beat siloed programs © 2026 lateralworks Page 16 Most corporate programs fail for reasons that have nothing to do with engineering: unclear ownership, slow decisions, and competing incentives across silos. Velo worked because its operating model attacked those failure modes directly. The comparison on the next page captures the structural differences. -- 16 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 17 Traditional siloed program Velo product delivery team Ownership fragmented across functions and business units Single accountable PDT with executive-board line of sight Decisions escalate through hierarchy; committee-driven compromise Fast decision loop; explicit decision rights; empowered Product Delivery Leader Large team size increases coordination overhead Small (~20) cross-functional core team; high-bandwidth communication Suppliers managed locally; dependencies discovered late Outsource-first with integrated master schedule and explicit interfaces Milestones optimized for reporting optics Milestones optimized for integration readiness and shipment criteria Sequential gating: engineering, procurement, legal, manufacturing Parallel execution: all streams move at the same time Host organization interrupts and redirects resources Ring-fenced PDT insulated from organizational noise Each row in the table is an independent design decision. Velo made the right call on every one of them, which is why the program shipped in 13 months while most large-organization programs of comparable scope take 24 to 36. -- 17 of 20 -- › Philips Velo case study › › › 07 Takeaways The reusable pattern © 2026 lateralworks Page 18 The Velo program demonstrates principles that apply directly to any complex, time-critical product delivery challenge — consumer electronics, semiconductors, connected devices, AI-enabled systems. -- 18 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 19 Design the organization like you design the product. Governance, decision rights, incentive structures, and team topology are architecture. If the organizational design is wrong, no amount of engineering talent compensates. Remove the team from the host organization’s interrupts. A ring-fenced venture with its own budget, priorities, and decision rights eliminates the constant tug-of-war for resources and attention that kills programs inside large enterprises. Appoint a single product delivery leader with end-to-end ownership. One accountable leader, from concept through high-volume production, prevents the slow death of alignment by compromise and keeps product vision coherent through execution. Keep the core team small and senior. Fewer people, clearer accountability, faster decisions. Every member of the core PDT should be empowered to make real decisions rather than relay information. Outsource execution; do not outsource ownership. Partners build. The core team owns the product, the interfaces, and the schedule. The integrated master schedule is the mechanism that makes the partnership scalable. Report above the hierarchy when the window is existential. Direct executive visibility and fast escalation remove layers of negotiation that would otherwise consume the schedule. The pattern is reusable. Empowered governance, cross-functional ownership, and an integrated partner cadence beat siloed execution. Velo proved it in 1996, before the model had a name. The same operating choices apply today, in any category where a critical window forces speed and complex integration at the same time. -- 19 of 20 -- › Philips Velo case study › › › © 2026 lateralworks Page 20 Sources References [1] Smithsonian Institution, National Museum of American History. “Philips Velo 1” (object record). [2] Abrahamson, D. “Wee Windows Computer.” Inc., June 15, 1997. [3] Wired staff. “PDAs Have Ears to the Ground at Comdex.” WIRED, November 18, 1997. [4] “New Products: Philips Velo.” WinMag / KaiserNet, February 1997. [5] Yoshida, J. “Philips ships products for handheld PC.” EDN, June 17, 1997. [6] IT History Society. “Tony Fadell” (biography). [7] “Philips introduces handheld personal computer.” COMDEX press release, November 18, 1996. [8] Wayner, P. “This Hand-Held Stands Out.” BYTE, April 1997. [9] Pen Computing Magazine. “Philips Velo 500.” [10] Pen Computing Magazine. “Windows CE 2.0: Where does it stand after Year 1?” [11] Fadell, T. Build: An Unorthodox Guide to Making Things Worth Making. Harper Business, 2022. [12] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. The Free Press, 1992. [13] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [14] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd ed. Wiley, 1997. [15] Mitchell, N. “FTTM (Fast Time To Market) methodology: framework and best practices.” lateralworks, 2018–2026. Program narrative based on the lateralworks engagement account. Public product details cited where available. -- 20 of 20 --

Client Projects·Case study·Systems

Launching Windows CE at startup speed

How an empowered product delivery team shipped a first-wave handheld PC in 13 months

Core thesis. When the deadline is existential and the work spans multiple companies, the single most important design decision is organizational, not technical. Stand up a ring-fenced product delivery team with end-to-end ownership, governed above the hierarchy, and let an integrated master schedule do the coordination work that committees do too slowly.

February 1, 2026·20 pages

View PDF →Download

6 case studies. New cases are added when they are created. Most case studies we can publish are >10 year old projects. Our current work involves advanced technology at the bleeding edge. We are not able to share these details for obvious reasons.