Case studies

12 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 Project Rubicon A five-engineer team, a microinverter built into the cable, and a working prototype in under six months. Engagement series. How lateralworks invested in and ran a corporate innovation program — organizing five engineers to prove a radical idea fast, define the right product with customers, and reach a validated proof of concept against a schedule half the industry norm. Prepared by lateralworks Investor and program manager Sector Solar power electronics Module-level power electronics Online lateralworks.com Fast-time-to-market practice -- 1 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 2 Table of contents Project Rubicon Overview 03 The engagement at a glance 04 01 — The market, and what was at stake 05 02 — An inverter inside the cable 08 03 — Voice of the customer 12 04 — Removing every constraint 16 05 — Five engineers, one schedule 19 06 — Proof, validated in the field 21 07 — Shrinking to fit the cable 24 08 — What the prototype proved 28 09 — Why the program stopped 31 10 — The practices behind the result 33 References 36 Core thesis. The product a team ships is decided long before the engineering is done — by the conditions leadership sets, the customers the team listens to, and the schedule it runs against. Project Rubicon put five engineers in the right conditions, pointed them at a customer-defined target, and got a working proof of concept in under six months. The parent company chose not to commercialize it. The method still did exactly what it is built to do. -- 2 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 3 Overview Overview A large industrial wire manufacturer had a small power-electronics division and a radical idea: build the solar inverter into the cable itself. The company asked lateralworks to invest in the idea and to run the program. Our job was to organize a five-engineer team, prove the concept, and define a product the market would actually buy — fast enough to matter in a market that was moving underneath everyone. The result was a working proof of concept in under six months, reached with about a third of the planned budget and in roughly half the time a program like this normally takes. The team breadboarded the core idea within three weeks of conceiving it, validated it on the bench as a simulated string, and then ran it outdoors into the grid on a working solar array. On cost per watt, the program’s model put the design below the leading microinverters of the day. Its topology was also simpler and ran cooler, which is where reliability comes from in this class of product. The parent company later paused, and ultimately declined to continue. That was a portfolio decision, not a verdict on the technology or the team. What the engagement demonstrates is the method: how a host organization, a small team, a customer-defined product, and a disciplined schedule combine to produce the right product at the right time — the outcome lateralworks calls fast-time-to-market, or FTTM. This case study walks through the market the idea was aimed at, the customer research that shaped it, the creative-thinking challenge that produced the core invention, the way the program was organized and scheduled, the proof that emerged from the lab and the field, and the specific lateralworks practices that made a six-month result possible. It closes with an honest account of why the program stopped, and why the method behind it still counts as a success. The practices referenced throughout are the ones lateralworks has developed since 1991 and documents at lateralworks.com. What the numbers say. Under six months to a working prototype. Three weeks from idea to breadboard. About one-third of the planned budget. Roughly half the schedule of a typical program. A cost-per-watt target below the category leaders. One idea, complete on the first attempt — which is rare, and is what the right conditions are supposed to produce. -- 3 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 4 Summary The engagement at a glance Role Investor and program manager lateralworks co-funded the proof of concept and ran the program end to end — assembling the team, setting the conditions, and managing the schedule. Scope Prove a radical idea, define the right product Take a distributed, cable-integrated microinverter concept from a challenge workshop to a validated proof of concept — while defining the product with customers in parallel. The hard part A third of the cost, small enough for a cable Beat the category leaders on cost per watt, fit the electronics inside a solar cable, and prove reliability — all at once, on a compressed schedule and a constrained budget. What we delivered A working prototype in under six months A breadboard proof in three weeks, a bench-validated string, a field test into the grid, an industrial design, and a cost model below competitive products at launch — at roughly a third of the planned budget. Figure 1. The concept in one image: a distributed microinverter node built onto the trunk cable itself, terminating in standard connectors. The parent was a wire company — so the cable became the product. -- 4 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 01 Section one The market, and what was at stake © 2026 lateralworks Page 5 In 2016 the solar microinverter was a maturing product with an unsettled market. Module-level power electronics — microinverters and DC optimizers, or MLPE — had gone from novelty to default on American rooftops in less than a decade. Enphase Energy had effectively created the category when it shipped the first commercial microinverter in 2008 [1]. By 2014, some form of MLPE was built into more than half of all U.S. residential solar installations [2]. -- 5 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 6 Section one A category that was winning and a leader that was hurting The tailwinds were real. A residential rooftop is a hard place for a single string inverter: multiple roof planes, shifting shade from chimneys and trees, and small system sizes — typically five to seven kilowatts. Putting a small converter on every module lets each one track its own maximum power point, so one shaded panel no longer drags down the whole string, and it hands the installer per-panel monitoring and a simpler design. Code accelerated the shift: the 2014 National Electrical Code introduced the rapid-shutdown rule of section 690.12, and the 2017 revision tightened it to an array-boundary limit that, in practice, pushed installers toward module-level hardware [3, 4]. Two companies had pulled away from the field. By the third quarter of 2015, Enphase and SolarEdge — the DC-optimizer challenger that had gone public that March — together held roughly 80 percent of the U.S. residential inverter market [5]. SolarEdge was climbing; by 2016 its revenue had passed Enphase’s [6]. The category had two clear leaders, and a long tail of everyone else. The leader was under pressure Enphase, the name most customers knew, was struggling where it hurts. It finished 2015 with revenue of about $357 million but a net loss of $22 million, after a profitable 2014 [7, 8]. It shipped a record 706 megawatts that year — more than three million microinverters — and passed its ten-millionth unit in the fourth quarter [7]. Yet gross margin was collapsing under a price war: from about 30 percent for the full year to the high teens by mid-2016 [7, 8]. The company had cut microinverter prices roughly 19 percent in November 2015, and its chief executive was publicly committing to cut device cost in half and chase parity with string inverters at around ten cents a watt [8, 9]. That is the opening a challenger looks for: a category that customers had accepted, a dominant brand whose economics were strained, and a cost target — well under twenty cents a watt for an integrated device — that no incumbent had yet reached. A wire company with a distributed, cable-integrated design and a genuinely lower bill of materials could enter exactly there. -- 6 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 7 Figure 2. Where the program aimed. The two bars on the left are the leading products the team benchmarked against; the three on the right are Project Rubicon’s internal cost-per-watt targets across three generations. The dashed line is the integrated-device price customers said the category needed to reach. Benchmark and target figures are lateralworks and program internal estimates from 2015–2016; competitor list prices varied by channel and volume. The reliability question Underneath the cost war ran a quieter argument about reliability, and it cut both ways. Putting power electronics on the roof, behind each panel, means exposing them to heat and weather for the life of the array — and replacing a failed unit means pulling a module. Electrolytic capacitors, the components most sensitive to heat, were the classic knock against microinverters [10]. Enphase answered with a 25-year warranty designed to match the panel’s life and carried tens of millions of dollars of warranty liability on its balance sheet to back it [7, 11]. Installers had lived the difference: several told trade researchers in 2015 that early microinverters had failed in the field at rates that pushed them toward optimizers, where the inverting happens off the roof [2]. A design that ran cooler and simpler had a real story to tell here — and the Rubicon topology was built to tell it. -- 7 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 02 Section two An inverter inside the cable © 2026 lateralworks Page 8 The insight that started the program was almost embarrassingly literal. The sponsor was a wire company. If the inverter could be made small enough, it did not need its own box bolted to the racking — it could live on the cable that was already going to be there. The company would be selling its own core product, with the electronics along for the ride. -- 8 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 9 Section two No central inverter, only building blocks The conventional architectures each carried a penalty. A string inverter is cheap but centralizes the conversion, so shade anywhere hurts everywhere. A microinverter fixes that by putting a full inverter behind every panel, but a full inverter is expensive and hot. A DC optimizer splits the difference and still needs a central inverter somewhere in the system. Project Rubicon took a different route. Instead of one big inverter, it distributed the inverting function across many small AC building blocks strung in series along the cable. Each node did its own maximum-power-point tracking and contributed a slice of the conversion; the nodes added up along the string; and all that remained at the end was a small grid interface box near the service panel, sized so that eight to twelve nodes made a branch within a 20-amp limit [12]. There was no central inverter to buy, and no full inverter behind each panel to pay for and cool. Figure 3. The distributed architecture. Small AC-optimizer nodes on the trunk cable each perform module-level tracking and partial conversion; they add in series along the string; a single small grid interface box completes the tie to the grid. No central inverter, and no full inverter behind each module. Why the cable changes the economics Building the electronics into the cable did three things at once. It removed the separate enclosure, the separate mounting hardware, and the separate installation step — the cable, the optimizer, and the inverter became one item to buy and one thing to install [12]. It gave the distributed design somewhere to shed heat along its length rather than in a single hot box. And it turned the sponsor’s existing manufacturing and channel strength — making and selling cable at volume — into the product’s cost advantage rather than a side business. -- 9 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 10 Figure 4. A single node inline on the cable. The unit tracks its module and contributes its share of the conversion, then passes AC down the trunk to the next node in the string. On paper the datasheet claim was blunt: the level of integration and the cost per watt had no direct competitor. It offered the shading immunity and per-module tracking of a microinverter or optimizer, at closer to the cost of a plain string inverter, with the simplicity of a system that needed only a small grid interface box rather than a central inverter [12]. The task for the next several months was to prove that the paper claim was real — and to make sure it was the product customers actually wanted. -- 10 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 11 Figure 5. The node shown mounted along a rail with the module cabling — the installed picture the industrial design had to serve: no separate box, no extra bracket, nothing to ground on its own. -- 11 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 03 Section three Voice of the customer © 2026 lateralworks Page 12 A radical architecture is worth nothing if it solves the wrong problem. Before and during the build, lateralworks and the team ran a deliberate voice-of-the-customer effort — talking to the people who specify, finance, and install these systems, and letting what they said reshape the product. -- 12 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 13 Section three What the buyers actually told us they needed The developers and module makers were consistent and specific. In a 2013 conversation that set the tone, a senior strategist at one of the largest solar developers laid out his buying criteria in order: cost, reliability, bankability — the confidence that the warranty company will still exist in five years to stand behind a twenty-year system. His verdict on the integrated microinverter was a hard threshold: it had to be built into the module, it had to prove twenty-year reliability, and it had to come in under twenty cents a watt. Above that price, in his words, it would never happen. A module maker’s U.S. general manager, interviewed the same year, drew the same line from the other side of the table. He saw the market moving toward inverters integrated into the junction box once the reliability risk was understood and the price reached the low twenties of cents per watt, and he weighed cost at the system level — inverter, cable, and monitoring together. The residential system, four to seven kilowatts, was the sweet spot everyone named. What the customer set as the target. Integrated with the module. Under twenty cents a watt for the integrated device. Twenty-year reliability, proven. Bankable. Simple enough to be a consumer product. Those four requirements — not an internal specification — became the fixed end state the team designed against. Credibility opened the doors The team could ask hard questions because it had standing to ask them. One member had co-founded a leading inverter company and advised many others; he brought both a sharp read on the breakthrough requirements and direct relationships with the segment’s most demanding buyers — the large residential installers and developers and the established power-electronics firms. That access turned VOC from a survey into a working collaboration: customers helped refine the product definition and the market timing rather than simply rating a concept. The listening had a cost the team accepted on purpose. Customer input kept changing the design during development — the normal, healthy pattern of a fast program, and uncomfortable for engineers who would rather freeze and finish. The discipline lateralworks holds here is simple and hard: the wrong product at the right time fails just as surely as the right product at the wrong time, so the team keeps talking to customers and keeps absorbing change, right up until the point where converging matters more than improving. -- 13 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 14 The clock had a price To make those trade-offs concretely rather than by argument, the program ran a cost-of-delay model built on the business case — the method Reinertsen and Smith formalized and that lateralworks has used for years to put a number on time [13, 14]. For this product the model put the cost of delay at about $173,000 a day: roughly $5.2 million in profit for every month the product reached the market late. A number that size changes behavior. It tells an engineer that paying to save a week is almost always right, and it lets the whole team weigh a new feature, a cost reduction, or a schedule slip on the same scale — the business case — instead of by opinion. -- 14 of 36 -- The idea Ignore the constraints Innovation comes when thinkers ignore the constraints — which is exactly backwards from how development normally begins. lateralworks program assessment Project Rubicon, 2016 © 2026 lateralworks Page 15 -- 15 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 04 Section four Removing every constraint © 2026 lateralworks Page 16 The core invention did not come from a specification. It came from a room deliberately set up to break one. In September 2015 lateralworks opened the program with a structured creative-thinking challenge — a proven technique for getting a team to suspend the assumptions it does not know it is making. -- 16 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 17 Section four The workshop that produced the idea The method is counter-intuitive, and that is the point. Normal development starts with constraints and tries to solve within them. The challenge workshop does the opposite: it states the end goal in the most demanding terms — here, a device a third the cost of the competition and small enough to fit inside a cable — and then removes every assumed constraint about how to get there. We asked the engineers to list every assumption behind their earlier attempt at an inverter, and then to challenge each one and free-think the alternatives. One engineer on the team, released from the conventional way of thinking about inverters, arrived at the idea that carried the whole program: a half-sine-wave switching scheme and a distributed topology that spread the conversion across many small nodes instead of concentrating it in one. Because the performance targets were radical, they demanded an equally radical concept — and that is exactly what the right conditions and the right person produced. Figure 6. The half-sine-wave signature on the bench oscilloscope — the switching behavior at the heart of the distributed design. Seeing the waveform hold on the scope was the first hard evidence the concept was real. Three weeks from idea to breadboard The team did not wait to see whether the idea would survive review. By October — less than three weeks after conceiving it — they had breadboarded the concept and shown that it worked. It met the performance targets, it was cost competitive, and it could hit the size target. A team arriving at an idea that complete on the first attempt is rare; it is the outcome the challenge method is designed to produce, and it happened here because the team had total freedom to create and no constraints to design around. -- 17 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 18 Figure 7. The working breadboard. A benchtop supply, a hand-wired gate driver board, and a multimeter — the unglamorous hardware behind a three-week proof that the half-sine, distributed concept converted power as intended. Everything after that first three weeks — roughly the next several months — was a different kind of work: refining the idea into a product, keeping it from diverging, and getting it ready for field test and customer validation. The invention was fast. Turning it into the right product, without losing the cost and size that made it worth building, was the long part. -- 18 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 05 Section five Five engineers, one schedule © 2026 lateralworks Page 19 A good idea is necessary and not sufficient. The reason Rubicon moved at the speed it did is that the program was organized — the team, the host conditions, and the schedule — to let the idea travel without friction. This is the part of the story that transfers to any program, in any industry. -- 19 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 20 Section five A small team, isolated, and fully provisioned The core team was small — five engineers — and, unusually, intact: they had worked together for years and had many products behind them. lateralworks immediately separated them from the parent’s day-to-day operations and co-located them, relieved them of all other duties, and let them think about exactly one thing: how to make a very low-cost, very small inverter. Normal corporate reporting and overhead were removed. The team’s only job was the product and the technical problems in front of it. Around that core we built a team of external specialists rather than hiring a large internal one — mechanical and industrial design, contract manufacturing and supply chain, industry and technical advisors. The default was to outsource, which saved time and brought in more diverse expertise than any five people could hold. Critically, the contractors were treated as full members of the team, not as vendors: they planned with everyone else and owned the outcome with everyone else. One integrated schedule, used to drive — not to report The whole program ran on a single integrated schedule that every member helped build, internal and external alike. It was refreshed every week. The team used the schedule’s trend to see where it was slipping and to create urgency before the fact, not after. It always knew the gap between when a result was wanted and when it could realistically arrive — a real plan, never a happy one built for someone else to read. That last distinction matters. The schedule existed for the team to manage itself, not to feed a management reporting cycle. Reporting to the host happened only when budget or schedule crossed an agreed threshold. The weekly planning refresh doubled as an automatic status report to anyone outside the team, at no extra cost to the people doing the work — so the reporting overhead that slows most programs simply was not there. Figure 8. The schedule that resulted. Against a typical ~16-month path to a validated prototype, Rubicon reached a working proof of concept in under six months and field validation at roughly eight — from a challenge workshop, to a breadboard three weeks later, to a bench-simulated string, to a field test into the grid. -- 20 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 21 None of these moves is exotic. Isolate and focus the team, provision it fully, reward challenge, integrate the outsiders, and run one honest schedule to drive the work — they are ordinary practices, applied together and without exception. Section ten sets them out in full. -- 21 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 06 Section six Proof, validated in the field © 2026 lateralworks Page 22 A concept that works on a single breadboard is a long way from one that works as a system, outdoors, tied to the grid. The team closed that distance in steps, each one raising the stakes and each one passed. -- 22 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 23 Section six From the breadboard to the grid The first step was to prove the distributed idea as a distributed system. On the bench, the team wired several optimizer boards together to simulate the start of a real string — nodes adding in series, exactly as they would on a roof — and confirmed that the architecture behaved as intended when the building blocks were stacked. This is where a distributed topology either holds together or falls apart, and it held. Figure 9. The system on the bench: multiple optimizer nodes wired as a simulated string, instrumented and driven, feeding the full chain that a real array would present. Proving the nodes add up in series was the milestone that turned a circuit into an architecture. The final step was to take it outside. The team ran the system on a working solar array — real modules, real sun, real grid connection — and watched it perform the way the model and the bench had promised. Testing a power-electronics prototype in the field, in daylight, into a live grid, is the moment a program stops being a lab exercise. Rubicon reached it in months, not years. -- 23 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 24 Figure 10. Field testing on a solar array — instrumenting the prototype outdoors, under load, into the grid. The step that separates a promising circuit from a product candidate. What field validation established. The distributed nodes tracked and converted as designed; they added correctly in series along the cable; and the system delivered into the grid from a real array. The proof of concept was no longer a claim on a datasheet — it was a working system, validated where it would have to live. -- 24 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 07 Section seven Shrinking to fit the cable © 2026 lateralworks Page 25 Proving the circuit was only half the product. The other half was physical: the electronics had to survive on a rooftop for decades, shed their own heat, and still be small enough to belong on a cable. This is where the program’s discipline about the fixed end state was tested hardest. -- 25 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 26 Section seven Keeping it small when physics pushed back The predictable tension appeared as soon as thermal reality met the size target. To manage heat, the node wanted to grow. When it did — when the enclosure crept up in size to solve the thermal problem — the team was sent back to the challenge mindset and asked to make it smaller again, and removable. They did both, and held the cost target while doing it. Neither cost nor size was traded away to make a problem easier; the end state did not move. Figure 11. The volumetric study. As the design matured, every millimeter was argued against the thermal and connector requirements. The rule was constant: solve the physics without surrendering the size or the cost that made the product worth building. Two ideas kept the package honest. A drop-in cable grommet let the node be assembled onto standard cable rather than demanding a bespoke molding on the critical path — a change that reduced risk, shortened the schedule, and preserved serviceability. And the industrial design deliberately broke from the category’s houseful of anonymous gray boxes: the goal was a device that looked engineered, not improvised, because a product a customer trusts on their roof for twenty-five years has to look the part. -- 26 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 27 Figure 12. The grid interface box. Because the architecture pushed the inverting out to the distributed nodes, the only central hardware left was this small, simple unit near the service panel — one per branch, not one per system. The mechanical work also surfaced the program’s clearest lesson about outside help. The mechanical partner was one of the best engineering firms in Silicon Valley, but a service-based contract rewards billable hours, not breakthroughs — and on the hardest, most inventive part of the package, that misalignment showed. lateralworks’ conclusion was blunt and reusable: when significant innovation is asked of a third party, the incentive has to be aligned with cash and equity, not a time-and-materials rate. Novel work needs skin in the game. -- 27 of 36 -- The result Right product, fast A working prototype, at a third of the budget, in about half the time — defined by the customer, not by the org chart. lateralworks program assessment Project Rubicon, 2016 © 2026 lateralworks Page 28 -- 28 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 08 Section eight What the prototype proved © 2026 lateralworks Page 29 Set against what it set out to do, the program delivered. It is worth being precise about what "delivered" means here, because the honest accounting is more persuasive than a rounded-up one. -- 29 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 30 Section eight What the prototype actually proved Start with the schedule and the money. From the challenge workshop, the team reached a working proof of concept in under six months, and a field-validated system at roughly eight — against a typical program norm of about sixteen. It did so on roughly a third of the planned budget; the project was, in plain terms, underfunded by about two-thirds, yet it never behaved as though it were, because lack of resources was not permitted as an excuse and the host supplied what the team asked for when it asked. Take cost first, the criterion the customer named first. The program’s model put the first-generation design meaningfully under the category leaders, with a roadmap that drove cost per watt down further across later generations toward the sub-twenty-cent integrated-device price customers said the market required. The competitive benchmark the team worked against put the leaders well above that line. The cable integration and the distributed topology, not a spreadsheet assumption, were what made the number reachable. Reliability decides bankability, and here the argument was structural. The distributed design ran cooler and used a simpler topology than a full microinverter behind every panel, and heat and complexity are the two things that shorten the life of rooftop electronics [10]. Field testing had to continue to turn that argument into qualified twenty-year data; the program never claimed otherwise. But the design started from the right side of the physics. The scorecard. Under six months to a working prototype, three weeks to the first breadboard, about a third of the planned budget, roughly half the typical schedule, a cost-per-watt target below the category leaders, and a topology built to run cooler and simpler. One idea, complete on the first attempt, then held to its cost and size through every trade-off. What remained ahead was the work every hardware program faces after proof of concept: converging and freezing the design, standing up manufacturing and supply chain — always the longest pole — and completing the qualification and certification that turn a validated prototype into a shippable product. Those were known risks with known owners. The program had earned the right to take them on. -- 30 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 09 Section nine Why the program stopped © 2026 lateralworks Page 31 The program did not fail on the bench or in the field. It stopped in the boardroom. The parent company paused the project and ultimately chose not to carry it into commercialization. An honest case study has to sit with that, because the reasons are as instructive as the successes. -- 31 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 32 Section nine A portfolio decision, not a technical one The decision to pause came at close to the worst possible moment — as the design needed to converge and the manufacturing runway needed to be started. lateralworks flagged the cost of it plainly at the time: slowing a program and restarting it typically adds six to eight months, so every month of pause tends to cost roughly two months at the end of a schedule that was already a quarter behind. Deferring the contract-manufacturing setup compounded it, because supply chain is the longest lead item in any high-volume hardware program. And the thinnest funding fell exactly where thin funding does the most damage — at the transition from proof of concept into verification, validation, and ramp. There were softer lessons too. A large, established company is optimized for its core business, and a genuinely new venture usually needs to be stood up as its own entity, with its own board and its own win-win incentives, to survive the narrow windows a new market allows. Rapid technology development rarely thrives inside a parent tuned for something else. And, as section seven noted, a service-based contract with a key innovation partner left incentives misaligned on the hardest part of the work. None of these is a criticism of the engineering; all of them are reasons a strong technical result can still be set down. Why it still counts Judge the engagement against what lateralworks was there to do, and it succeeded. The method was asked to prove a radical idea quickly, to define the right product with the people who would buy it, and to fold what they said back into a disciplined schedule. It did all three: an idea complete on the first attempt, a product shaped by real customer requirements rather than internal assumption, and a validated proof of concept in a fraction of the usual time and budget. A parent’s portfolio choice is a different question from whether the work was good. The work was good, and the way it was produced is repeatable. -- 32 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › 10 Section ten The practices behind the result © 2026 lateralworks Page 33 Everything in this case study rests on a body of practice lateralworks has developed since its first study of fast development teams in 1991, and documents at lateralworks.com. The practices are not a philosophy; they are a checklist that separates fast, successful programs from ordinary ones. Rubicon applied them, close to in full. -- 33 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 34 Section ten The practices behind the result lateralworks groups the practices into four conditions that all have to be in play at once to get fast-time-to-market — the right product at the right time. They are the host, the team, the product, and the time. Miss any one and speed leaks away; hold all four and a six-month proof of concept stops being remarkable and starts being expected. Figure 13. The four FTTM conditions and the practices Rubicon applied under each. The full framework and its history are set out at lateralworks.com. Host — the conditions leadership sets The host isolated and co-located the team, held it to a single strategic focus that never changed, provisioned it as though resources were never the constraint, and rewarded challenge rather than treating it as insubordination. The cable-integration goal set on day one was the same goal at field test. When the design drifted, the answer was to challenge the drift, not to relax the target. Team — who does the work A small, intact team with a shared track record; external specialists carried as full members rather than vendors; no hierarchy and no reporting overhead; and a participatory plan every member owned. Fewer people with more skills beat more people with fewer skills, and everyone knowing the gap beat anyone managing the appearance of progress. -- 34 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 35 Product — what gets built A fixed end state — cost, size, reliability — with continuous iteration on how to reach it; fast failure and faster recovery; and a standing willingness to change the design when the customer said so. The end state never moved; almost everything else did, on purpose. Time — how the schedule is used Realistic planning that always exposed the gap to target; one integrated schedule spanning internal and external work; a weekly trend used to create urgency before the fact; and a schedule owned by the team to drive itself, not built to satisfy a reporting request. Time was treated as the scarce resource it is — priced, in this program, at about $173,000 a day. How to read this case. The technology was specific to solar power electronics; the method was not. The host, team, product, and time practices apply to any program that has to turn a hard idea into the right product before the window closes. That is the transferable lesson of Project Rubicon, and the reason it earns a place in the lateralworks engagement series. The full framework is at lateralworks.com. -- 35 of 36 -- › Project Rubicon — a lateralworks engagement case study › › › © 2026 lateralworks Page 36 Sources References [1] Enphase Energy, Inc. "Company history and first-generation microinverter (2008)." Corporate and investor materials, enphase.com. [2] GTM Research, as reported in industry trade press. Module-level power electronics adoption in U.S. residential solar (MLPE in more than half of residential installations by 2014); installer field-reliability commentary, 2015. [3] National Fire Protection Association. National Electrical Code (NFPA 70), Article 690.12 "Rapid Shutdown of PV Systems on Buildings," 2014 edition and 2017 revision. [4] GreenLancer / ExpertCE. "Solar rapid shutdown requirements: NEC 690.12," industry explainer summarizing the 2014 origin and 2017 array-boundary revision. [5] GTM Research. "SolarEdge and Enphase control roughly 80% of the U.S. residential solar inverter market," Q3 2015 data, reported by Greentech Media and photon.info. [6] Osborne, M. "SolarEdge revenue increased 15% in 2016." PV-Tech, February 16, 2017. https://www.pv-tech.org/solaredge-revenue-increased-15-in-2016/ [7] Enphase Energy, Inc. "Financial Results for the Fourth Quarter and Fiscal Year 2015." Form 8-K, Exhibit 99.1, filed February 23, 2016. U.S. Securities and Exchange Commission, EDGAR. [8] pv magazine. "Enphase posts $22 million losses during 'challenging' 2015." February 24, 2016. https://www.pv-magazine.com/2016/02/24/enphase-posts-22-million-losses-during-challenging-2015_100023354/ [9] Greentech Media. "Enphase aims to reduce microinverter cost by 50% in two years" (target of parity with string inverters near $0.10/W), 2015. [10] SolarQuotes. "Do electrolytic capacitors cripple microinverter reliability?" Discussion of rooftop heat exposure and capacitor lifetime, with manufacturer rebuttal. https://www.solarquotes.com.au/blog/do-electrolytic-capacitors-cripple-microinverter-reliability/ [11] Enphase Energy, Inc. "Enphase Microinverter 25-Year Limited Warranty." https://enphase.com/warranty/us [12] Project Rubicon. "Cable-integrated microinverter data sheet," Version 3.0, internal program document, October 2015. [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. Van Nostrand Reinhold, 1991 (2nd ed. Wiley, 1998). [15] Wheelwright, S. C., and Clark, K. B. "Organizing and leading heavyweight development teams." California Management Review, vol. 34, no. 3, Spring 1992. [16] lateralworks. "Fast-time-to-market (FTTM) framework: host, team, product, and time." Practice methodology, developed since 1991. lateralworks.com. [17] lateralworks. "External project assessment of Project Rubicon." Internal engagement assessment, revised August 2016. [18] lateralworks. "Microinverter voice-of-the-customer interviews." Internal engagement research, 2013–2016. -- 36 of 36 --

Client Projects·Case study·Solar power electronics

Project Rubicon

A five-engineer team, a microinverter built into the cable, and a working prototype in under six months

Core thesis. The product a team ships is decided long before the engineering is done — by the conditions leadership sets, the customers the team listens to, and the schedule it runs against. Project Rubicon put five engineers in the right conditions, pointed them at a customer-defined target, and reached a working proof of concept in under six months. The parent company chose not to commercialize it. The method still did exactly what it is built to do.

July 1, 2026·36 pages

Read case study →Download PDF

© 2026 lateralworks Page 1 › › Case study Integrating a multi- supplier lunar program How lateralworks rebuilt one integrated master schedule and a weekly refresh cadence to put a commercial lunar lander program back on a converging path. FTTM engagement series. A commercial lunar exploration company, roughly a year behind its first customer target, with critical work spread across international subcontractors, a prime contractor, and a government sponsor — and a schedule that had stopped converging. Prepared by lateralworks Program management Engagement Lunar lander program, 2023 Engagement review, 2026 edition Online lateralworks.com FTTM engagement series -- 1 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 2 Engagement summary What was at stake, and what was achieved A commercial lunar program was roughly a year behind its first customer commitment, and the gap was widening. The work was distributed across international subcontractors — the structural bus, the navigation system, propulsion, avionics, and flight software — but the risk of it failing to come together was held in one place, by the company. The program carried a negative margin, so every month of slip converted directly into financial exposure. In an industry where fixed-price lunar contracts have pushed more than one company into bankruptcy, an open-ended schedule gap was an existential risk, not a planning inconvenience. 404 days Initial critical-path gap to the first customer target 1 schedule All suppliers’ work integrated and refreshed weekly Every target Critical path re-identified and pulled in each week In-house Scheduling capability transferred to the client’s own team lateralworks rebuilt how the program was planned and run. The many disconnected schedules were replaced by a single integrated master schedule that every supplier’s work lived inside, refreshed in one room every week. At each refresh the critical path to every target was re-identified, the cause of every change was recorded, and pull-in actions were opened and tracked until the trend to each date turned. By the close of the engagement, the program had the machinery to converge. The first critical-path study had put the finish more than four hundred days past the first customer target; the gap was now quantified, owned, and being driven down through continuous pull-in rather than absorbed. Supplier schedules were folded into the integrated master schedule, with suppliers helping build it for the first time. A core scheduling team was seeded inside the company and the skills were transferred to its own managers. The schedule had stopped being a reporting artifact and become the place the program was run. The system to close the gap existed; using it was now the company’s work. Supplier integration had started but was not complete, the core team was a beginning rather than a finished structure, and two strategic questions — the size of the payload, and whether to fly the mission incrementally — were left deliberately open for the company to resolve. -- 2 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 3 Program at a glance One integrated schedule across every functional element The high-level integrated master schedule. Every functional element and subcontract — the structural bus, the navigation system, propulsion, commercial payloads, relay satellites, and mission operations — was laterally integrated into one system schedule with a single objective, baseline, and critical path, rather than tracked as separate supplier plans. This is the full scope the weekly refresh kept driving toward convergence. -- 3 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 4 01 The program What was at stake The client was a commercial space company building autonomous systems to land payloads on the lunar surface. Its near-term goal was concrete: land a set of customer experiments on the Moon and establish communications by mid-2025. Reaching it meant finishing a lander, qualifying its avionics, integrating flight software, and proving the whole stack through a sequence of reviews. No single organization held that work end to end. Most of it sat with subcontractors. Switch cards, avionics boxes, guidance and navigation, flight software, and the structural bus were each developed by different suppliers, on different schedules, against different assumptions. A prime contractor sat between the company and a government sponsor. The company carried the integration risk for all of it. When lateralworks was brought in, the program was roughly a year behind the customer target, and the gap was not closing. With significant technical unknowns still open, the schedule carried real financial exposure. Every month of slip widened an already negative margin. The question put to the engagement was direct: could the program be run differently so the gap shrank, without compromising what the first customer, the shareholders, and the supplier partners each needed? The honest answer started with a diagnosis. The program did not have one schedule. It had many, loosely stapled together, with no cadence that forced them to converge. -- 4 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 5 02 The as-found state Why the schedule had stopped converging An integrated master schedule existed, but it was not being used to run the program. It had been built in functional detail to satisfy the prime contractor's reporting requests, not to manage the critical path to a date. Supplier schedules lived outside it. Slips arrived week to week with no agreed cause and no recovery plan, and they were absorbed rather than fought. The deeper issues were behavioral, and the engagement recorded them plainly. The team tended to justify a slip rather than solve it. Time and money were treated as if they were abundant. Attention went to accounting for schedule margin rather than to protecting it, a habit that tends to make late finishes self-fulfilling. Decisions deferred to what the prime and the sponsor wanted instead of the company taking control of its own schedule. Program-management maturity was thin, ownership of outcomes was low, and meetings ran without focus. Concerns also ran above the program. Observers pointed to heavy capital intensity with no clear path to profitability, leadership gaps at the corporate level, and a design lead whose insistence on full detail blocked the “roughly right” thinking the schedule needed. None of this was hidden. The first job was simply to make the schedule gap visible, name its causes, and make closing it the team’s problem rather than something that happened to them. -- 5 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 6 03 The approach One integrated schedule, refreshed every week The fix was structural before it was cultural. lateralworks rebuilt the integrated master schedule so it managed the program rather than described it. The detailed functional view that served the prime's reporting was set aside. In its place went a schedule organized around the critical path to each target date, at a level a program could actually be steered with. A new baseline and a new set of targets were established and, importantly, accepted by the prime contractor as the going-forward plan. That acceptance mattered. It gave the team one set of dates to converge on instead of two. Supplier schedules were then pulled into the same model. For the first time, key subcontractors helped build the IMS rather than reporting against a plan handed to them. Each supplier’s deliverables entered the schedule as linked activities on the critical path, so a slip inside one supplier showed up immediately as movement on a target the whole program could see. The cadence that held it together was a weekly Refresh. Once a week the team, and increasingly the suppliers, updated the schedule together in one room. The Refresh did three things every time. It re-identified the critical path to each target. It captured the cause of every change, so a slip was never anonymous. And it drove pull-in actions on the paths that mattered, with the team asked what it would take to recover, not whether recovery was possible. -- 6 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 7 Each target carried a quantified gap, a health state, and a predicted finish (left). Every weekly change was logged with its cause, so movement was never anonymous (right). Trends to each target were tracked from week to week, so the program could see not just where a date stood but which way it was moving, and why. Predicted finish for each target, tracked weekly against the committed date. Trend, schedule gap, and the cause of the latest change sit side by side. This is the part worth dwelling on, because it is the transferable mechanism. Integration was not achieved by a meeting or a tool. It was achieved by putting every supplier’s work into one schedule, refreshing that schedule in one room every week, and tracking the trend to each target until the causes of slip had names and owners. -- 7 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 8 04 Finding time Challenging the assumptions behind the gap Rebuilding the schedule exposed the gap. Closing it needed time the plan did not obviously contain, so the engagement ran the team through lateralworks’ FTTM method for finding it. The method starts from a simple permission: to ask, of any part of the plan, why it is the way it is, and whether there is another way to do it. The team takes an area of focus — here, landing customer experiments and establishing communications by the target date — writes down the assumptions baked into the current approach, and challenges the ones that move the schedule most. Some assumptions survive the test and the plan stands. Others give way and open new ideas. Even when the answer is unchanged, the exercise tends to surface options the team could not see before. The assumption-challenging loop: take the problem, surface the assumptions, ask why, and either validate the plan or generate new ideas — banking time the program will need later. Underneath the method sits a model of what a healthy program holds in balance: the right product, the right time, and the right team, continuously defined and planned inside an environment that has to support all three. The engagement used it to frame what the program was missing — clearer product definition, a faster near-term schedule, deeper supplier integration, and senior talent on the team. -- 8 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 9 The three rights — product, time, and team — held in balance and continuously re-planned. The frame the engagement used to locate what the program was missing. The sharpest assumption was the one no one had answered: what is the payload? A lander is sized and designed around what it carries. With the payload undefined, the team was designing a large, expensive vehicle against requirements it could not yet state. The engagement pushed the question hard, and paired it with a second. Did the mission have to be attempted in one step? A national space agency had recently reached the Moon by deliberately limiting payload mass and scope, succeeding precisely because it narrowed its risk. The same logic suggested an incremental path: prove a smaller capability first, then scale, rather than betting everything on a single oversized increment. An incremental path: prove landing and communications with a smaller vehicle, then scale capability and payload across later increments, distributing risk instead of concentrating it. -- 9 of 18 -- © 2026 lateralworks Page 10 Integrating the suppliers was three-quarters of the problem. A single schedule, refreshed in one room every week, was the answer. lateralworks engagement review -- 10 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 11 05 Results What the engagement put in place By the close of the engagement, the program had the machinery to converge, even though it had not yet converged. What changed was concrete. n The integrated master schedule was restructured and was being used to run the program, not to satisfy a reporting request. n A new baseline and targets were established and accepted by the prime contractor as the forward plan. n The schedule gap was known and quantified, and trends to each target were tracked week to week. n Key supplier schedules were integrated into the IMS, with suppliers helping build it for the first time. n The weekly Refresh was running, with the schedule updated from live team inputs. n Core scheduling skills were transferred to the program’s own managers. n A starting FTTM core team was in place, and the engagement had fed concrete inputs into the company’s organizational design. The team had also begun to feel ownership of the schedule rather than treating it as someone else’s number. That shift, from absorbing slips to arguing about how to recover them, was the precondition for everything else. The engagement was equally clear about what these gains were not. Supplier participation had started but was far from complete. The core team was a start, not a finished structure. The schedule was visible and managed, but the gap was still open. The system to close it existed. Using it was now the company’s work. -- 11 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 12 06 The open items What remained to improve The engagement left a set of recommendations that were less about scheduling mechanics than about the conditions a converging program needs. Organization came first. The program needed a heavyweight program manager with a deputy who managed suppliers directly, freeing procurement to focus on sourcing and contracts. It needed a single technical authority, a chief engineer, and a single system architect, rather than design decisions diffused across the team. And it needed senior, experienced talent added to raise the program’s overall maturity. Supplier integration had to go the rest of the way. The engagement was blunt that this was about three-quarters of the whole problem. Each supplier needed a direct line to the deputy PM and the technical leads, more detailed schedules built jointly and folded into the IMS, weekly status into the same Refresh, and visibility into the whole program rather than only its own slice of it. Autonomy and focus were the harder asks. The recommendation was to accelerate toward an empowered set of operations that owned its program and its budget, escalating to corporate only when a deviation crossed a set threshold. Alongside it: act rather than wait for permission, change the default from acceptance to action, and resist taking on new programs that would pull people off work that was already under-resourced. Two strategic questions were left deliberately open, because the program could not answer them and needed to. What is the payload, and therefore how large does the lander actually need to be? And should the mission be pursued incrementally, proving a smaller capability first, to distribute risk rather than concentrate it in one oversized step? -- 12 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 13 07 The takeaway An integration model others can reuse The aerospace specifics are particular to this program. The integration model is not. Any hardware program split across multiple subcontractors faces the same structural problem this one did. The work is distributed, but the risk of it not coming together is held in one place. The instinct is to manage that risk with reporting: each supplier sends status, someone assembles it, and the assembly is mistaken for control. It is not. Status describes the past. It does not force the future to converge. What forces convergence is a single integrated master schedule that every supplier’s work actually lives inside, refreshed on a fixed weekly cadence in one room, with the critical path to each target re-identified every time, the cause of every change recorded, and the trend to each date tracked until slips have names and owners. The schedule stops being a document and becomes the place the program is run. That is the reusable result from this engagement. The lander, the avionics, and the lunar target are specific. One schedule, refreshed every week, with suppliers inside it and trends tracked to every target, is how a program made of many companies becomes one program. -- 13 of 18 -- © 2026 lateralworks Page 14 I can’t thank you enough for all the help you gave us. I felt the company was on a path toward disaster, and you made a huge course correction toward success. — Chief executive officer, the client -- 14 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 15 A Appendix — market context The commercial race to the Moon This engagement took place inside one of the hardest and youngest industries in modern aerospace. The context matters, because it explains why a year of schedule slip was not a planning inconvenience. It was an existential risk. A wave of private companies is now attempting what only national programs once did: land working spacecraft on the Moon and operate them on the surface. The model is largely a creature of public policy. A national space agency buys delivery to the lunar surface from private vendors under fixed-price contracts, betting that competition will break the cost of access that once ran to roughly a billion dollars a mission. The early results show how unforgiving that bet is. The technical wall. Landing autonomously on the Moon is brutally hard. There is no atmosphere to brake against, so a lander must shed orbital velocity — well over a kilometer per second — on its engines alone, throttling precisely enough to neither slam into the surface nor bounce off it. Earth is too far away to fly the final descent by remote control, so the vehicle has to sense hazards and choose a safe touchdown point on its own, in real time. The most scientifically valuable sites, near the south pole, are also the most treacherous, and more than one recent lander has touched down only to tip over on uneven ground. Those that land then face a thermal cycle that swings from roughly 120 degrees Celsius in daylight to below minus 130 at night, on a clock set by a fourteen-day lunar day that ends most unheated missions at the first sunset. The public record is sobering. Across the first years of commercial attempts, more missions have failed than succeeded. Landers have been lost to propellant leaks before reaching the Moon, to descent-software and sensor faults in the final minutes, and to tip-overs that cut short otherwise successful touchdowns. The first fully successful commercial soft landing did not come until early 2025. Commercial teams face the same physics as government programs, but with smaller budgets, thinner staffing, and little heritage hardware, and most are meeting these problems for the first time. The financial wall. The economics are as punishing as the physics. Building, testing, and flying lunar hardware costs hundreds of millions of dollars, with any return pushed years into the future, which leaves companies crossing a long “valley of death” on raised capital before a market exists. The fixed-price contracts that opened the field also transfer cost and schedule risk onto small, relatively young vendors. The sponsoring agency’s own inspector general found that across early commercial lunar task orders, costs rose by more than two hundred million dollars and missions slipped by an average of well over a year, with the real time from award to launch running closer to forty-four months than the thirty originally planned. That pressure has already pushed one awardee into bankruptcy and driven consolidation among the survivors. -- 15 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 16 Underneath all of it sits a single dominant customer. Government demand still drives the lunar economy, and it arrives one mission at a time, which makes revenue lumpy and forecasting hard; a vendor’s survival can hinge on the timing of the next task order. In that environment, schedule is not a reporting metric. Every month of slip burns fixed capital against a fixed price, and on a program already carrying a negative margin, slippage compounds directly into financial exposure. This is the backdrop to the engagement. A program running about a year behind its first customer commitment, with critical work spread across international suppliers and a negative margin, was not facing an ordinary planning problem. It was facing the central risk of its industry — that the schedule, and the money, run out before the vehicle is ready. Bringing the schedule under control was, in the most direct sense, a matter of the company’s survival. -- 16 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 17 B Appendix — the system in practice Anonymized scheduling artifacts The figures below show the actual scheduling system the program ran each week, with identifying details removed. They are the anonymized form of the machinery described in the approach and the results: one integrated schedule, reviewed on a fixed cadence, with the critical path to every target re-identified and the cause of every change recorded. The first critical-path study. Read end to end, the driving path put the landing finish more than four hundred days past the first customer target — the gap the engagement set out to close. The number got worse before it got better: each weekly refresh re-identified this path and opened pull-in actions against it, and the trend to the target was driven back over the months that followed. Critical path to a target, ranked. Each driving task is shown with its days from the critical path, its change since the last update, and its gap to the target date, alongside the pull-in actions opened to recover it. The same analysis was produced for every target the program tracked. -- 17 of 18 -- › Integrating a multi-supplier lunar program · · · © 2026 lateralworks Page 18 The weekly review in use. Each target carries a quantified gap, a health state, and a predicted finish (left), and every change to the schedule is logged with its cause (lower right), so movement on a date is never anonymous. Predicted finish for each target, tracked over time against its committed date. Read together, the trends show not just where each date stands but which way it is moving, and why — the signal the program used to drive recovery. Sources • U.S. government inspector-general audit of commercial lunar delivery services (2024–2025): cost growth exceeding two hundred million dollars across early task orders, average schedule slips of more than a year, and award-to-launch timelines closer to forty-four months than the thirty originally planned. • The Conversation, on the technical difficulty of autonomous lunar landing (2025): airless high-velocity descent, real-time hazard avoidance, south-pole terrain hazards, and the thermal swing of the fourteen-day lunar day. • IEEE Spectrum, Payload, and NASASpaceflight reporting on the commercial lunar landing record (2024–2025): the first fully successful commercial soft landing in early 2025, alongside missions lost to propellant, sensor, or descent-software faults or to post-touchdown tip-overs. • New Space Economy and related industry analyses (2022–2025): the capital intensity and “valley of death” facing commercial lunar ventures, a fixed-price awardee’s bankruptcy, and the consolidation that followed. -- 18 of 18 --

Client Projects·Case study·Aerospace / commercial space

Integrating a multi-supplier lunar program

How lateralworks rebuilt one integrated master schedule and a weekly refresh cadence to put a commercial lunar lander program back on a converging path.

Core thesis. A hardware program split across many subcontractors distributes the work but holds the integration risk in one place, and status reporting can't force it to converge. Convergence comes from a single integrated master schedule that every supplier's work lives inside, refreshed weekly in one room, with the critical path and the cause of every slip tracked to each target.

June 30, 2026·18 pages

Read case study →Download PDF

© 2026 lateralworks Page 1 › › Case study One program, many companies Running a multi-site advanced-node development program as a single, integrated team Engagement series. How lateralworks acted as the technical program manager that pulled a research institute, a foundry partner, equipment suppliers, and a corporate sponsor into one empowered program — and told the truth when the program turned hard. Prepared by lateralworks FTTM engagement Sector Advanced-node semiconductors Consumer product device Online lateralworks.com Case study series -- 1 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 2 Table of contents One program, many companies Overview 03 01 — The challenge 05 02 — Run it, do not advise it 08 03 — The lateral program architecture 10 04 — Execution under lockdown 15 05 — The honest diagnosis 17 06 — What the model delivered 19 07 — Best practices applied 22 08 — The four common problems, solved 24 References 27 Core thesis. When a program depends on many companies, the work is not coordination — it is integration: building one team, one schedule, and one set of decisions out of organizations that arrive as strangers. The integrator’s highest-value output is an early, honest read of the two things that actually bind the schedule: the maturity of what you inherit and the capability of the partners you depend on. -- 2 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 3 Overview Abstract A large, Silicon Valley–headquartered technology company set out to build a new advanced-node device technology. It was one building block inside a billion-dollar development program that spanned dozens of major technology inventions. In plain terms, the program had to take a device that worked only in a laboratory and make it run on a factory line the company itself controlled — fast enough to feed decisions on a flagship consumer product, and on a path to volume manufacturing for years of product generations after that. The work was spread across many sites on three continents, it ran straight through the COVID-19 lockdowns, and it depended on companies that had never operated as one team: a European research institute, a foundry partner, equipment suppliers, a separate driver-chip program, and the sponsor’s own functions. lateralworks did not advise from the sidelines. We were brought in to run the program — to act as the technical program manager that pulled every company into a single integrated effort. Over three years we set up the program, built a co-development environment with the foundry partner, retrofitted a fab in the middle of lockdown, installed and qualified over one hundred process tools, qualified the line, and transferred the process out of the research institute. Two hard programs were fused into one: a facilities and fab build, and an advanced process-development program that needed major technical breakthroughs on a short clock. The fab and the tools were the easier part. Getting them installed on time, and bringing the line up to world-class operating standards, was only the foundation. The hard part was making the technology perform to its targets. The client scoped this as a two-year project. We assessed it at five. It took five, exactly as we said — and without the planning and orchestration that held it together, our estimate is that it would have taken eight. This is also an honest account. The program met limits no schedule could erase: a process that left research far less mature than anyone admitted, a foundry partner that could not change at the pace the program demanded, and the human cost of carrying that load. We name those problems plainly, because the value lateralworks delivered was not only the build — it was the early, candid diagnosis that gave the sponsor the truth in time to act on it. -- 3 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 4 The engagement at a glance Role Technical program manager — we ran the program, not just advised it Schedule call Client scoped two years; we assessed five; it took five. Without the program structure, an estimated eight Footprint Multiple sites across three continents, integrated into one program Build (the foundation) Brownfield fab retrofit through lockdown; over one hundred tools installed and qualified; line brought to world-class standards The hard part An advanced process-development program needing major breakthroughs on a short clock, matured from a research result on a controlled line What we told them An early, written diagnosis of the binding constraints, in time to act -- 4 of 27 -- › One program, many companies › › › 01 Section one The challenge © 2026 lateralworks Page 5 The sponsor had a research result and a deadline. The device worked in a European research institute, on a prototype line, at the maturity you would expect from a proof of concept: an unfinished flow, incomplete recipes, and tool requirements that were still moving. The business needed that same technology running on a development line it controlled, fast enough to feed product decisions and on a path to manufacturing well beyond the first product. -- 5 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 6 Section one A research result, a deadline, and many sites The gap between a research result and a controlled development line is where most advanced-technology programs lose their schedule. The sponsor faced that gap in its hardest form. The work touched facilities, tools, and process development at an advanced node all at once, and it was distributed across many sites: a Silicon Valley headquarters, a European research site, a European foundry site, an Asian equipment-supplier base, and the teams building the driver chip and the product itself. Two hard programs, fused into one This was never one project. It was a facilities and fab build fused with an advanced process-development program, and the two ran on very different kinds of difficulty. Standing up the fab and the tools — specifying them, ordering them, installing and qualifying them, and bringing the line up to world-class operating standards — was the easier part. Hard to schedule, capital-intensive, unforgiving on lead times, but ultimately a known kind of problem. It was the foundation, not the summit. The summit was the technology. The program needed an immature process to make major leaps in performance, on a short clock, to hit specified product targets — the kind of work where the breakthrough either comes or it does not, and no amount of project management manufactures it. That asymmetry defined the program. Many projects were combined into one, and the binding risk lived in the hardest of them. Careful planning, orchestration, and execution management could not invent the breakthroughs, but they could make sure everything else was ready the moment a breakthrough landed — and that nothing else was the reason the program slipped. An organization built for silos, not for this The organization that had to deliver this was not built for it. Each building block reported vertically, up its own chain and back down. There was no single owner of the integrated outcome, no process architect tying the technology blocks together, and no integrated schedule that could show how a delay in one place moved the finish line everywhere else. Teams were not dedicated, not co-located, and not empowered to decide. Silos produce a predictable result. Decisions climb the hierarchy and crawl back down. Integration happens late. The system-level problems surface near the end, exactly when there is no time left to fix them. Each silo optimizes its own corner — requirements, performance, cost, size — with no view of the impact on the whole. -- 6 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 7 Figure 1. The starting organization reported vertically with little lateral integration. lateralworks added the connective structure: an empowered core team and the architect and integrator roles that tie the building blocks into one program. And then the schedule got harder The program had to retrofit an existing fab — a brownfield site, not a clean sheet — lay it out for development and later production, run the hook-up design and bid packages, and install and qualify over one hundred tools. It had to do all of this through the COVID-19 lockdowns, with equipment suppliers, travel, and labor constrained at the same time. -- 7 of 27 -- › One program, many companies › › › 02 Section two Run it, do not advise it © 2026 lateralworks Page 8 The sponsor did not ask for recommendations. It asked lateralworks to take the program and make it come together on time. -- 8 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 9 Section two Own the schedule, own the bad news That distinction shaped everything. A consultant who advises hands over a deck and waits. A technical program manager who runs the program owns the schedule, drives the decisions, and stands in front of the sponsor when the news is bad. lateralworks took the second role. We set up the core team, ran the integrated schedule, drove the critical path, and managed the interfaces between every company in the program. A heavyweight team, fully empowered We built that core team as a heavyweight team in the precise sense the term carries in the product-development literature: a single team, led by a manager with real authority over the program, staffed by people dedicated to it full time and accountable for the whole outcome rather than their own function. The team was chartered to drive the program schedule, integrate every function, and make the trade-offs needed to hit the product targets on the revised timeline. It reported by exception, not by permission. A steering committee existed to break cross-functional ties, not to run the work. One team out of many companies The aim was simple to state and hard to do. Pull the research institute, the foundry partner, the facilities and industrial-engineering partner, the equipment suppliers, the driver-chip program, and the sponsor’s own functions into one program, with one schedule and one set of priorities. Close enough that, in a meeting, you could not tell which company a person came from. -- 9 of 27 -- › One program, many companies › › › 03 Section three The lateral program architecture © 2026 lateralworks Page 10 A multi-site program does not fail for lack of effort. It fails at the seams — the interfaces between organizations, where work is handed off and ownership goes vague. Managing those seams was the job. -- 10 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 11 Section three One schedule, the hidden path, and lateral glue From functional silos to a flow built around the technology The starting organization was functional. Facilities ran its project, tools ran theirs, process development ran a third, and the research learning cycles ran a fourth — each on its own clock, reporting up its own chain. We rebuilt it as a single lateral process flow, organized around the one thing that actually mattered: the maturing technology. Facilities, tool install and qualification, process development, and the research learning cycles stopped being four projects and became four streams of one flow, synchronized to the state of the device as it moved from a lab result toward a qualified line. The integrated schedule kept them in step, so that each stream delivered exactly when the technology was ready to use it — no sooner, building idle capacity, and no later, stalling the program. Figure 2. We re-cast four functionally separate projects — facilities, tools, process development, and research learning cycles — as four streams of one lateral flow, synchronized by the integrated schedule to the maturing technology. One integrated schedule, driven by the critical path We built a single critical-path schedule for the whole program and made it the source of truth. Every tool, every transfer step, every process and product qualification lived in one model. A working tool list — names, suppliers, costs, dependencies, lead times — fed the schedule and took its dates back from it, so the plan and the tracking never drifted apart. We refreshed the schedule twice a week. That cadence is not administrative habit; it is how a fast program keeps the plan honest against reality and catches a slip while there is still time to act on it. -- 11 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 12 Figure 3. The critical-path schedule was the driver. The working tool list, dependency map, cost model, and pull-in analysis all fed from it and back into it, refreshed twice weekly. Managing the critical path you cannot see The obvious critical path is rarely the one that derails a program. It is the second or third — the one hiding in plain sight — that does the damage. Here, the hidden path ran through facilities: until the fab was retrofitted and tools could go in, nothing downstream could start. We sequenced the program around that constraint, ordered long-lead tools at risk where the exposure was small, and treated schedule buffer as a managed resource to be spent deliberately rather than slack to be quietly consumed. Figure 4. The acceleration logic is a chain: securing the site lets you order tools, which lets you qualify them, transfer the process, and learn faster. Facilities was the hidden constraint that gated all of it. Lateral integration of the building blocks Vertical reporting was already in place. What the program lacked was lateral integration — the connective tissue between technology building blocks, and between technology and product. We added the roles that supply it. An integrator looked across the whole and tied it together. A process architect made the system-level trade-offs so that no single block was optimized at the expense of the program. A chief engineer owned the final technical calls. Those three roles turn a stack of silos into a lateral system. -- 12 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 13 Decisions, not status Speed in a program like this comes from decision quality, not from meeting frequency. We pushed decision authority down to the core team and kept the sponsor’s role to provisioning, fast tie-breaking, and exception handling. When outside groups tried to pull the team into endless justification, we insulated the team on purpose, routing external communication through the program lead so the people doing the work could keep doing it. -- 13 of 27 -- The integration test One team, many logos "In a meeting you could not tell which company a person came from. lateralworks engagement Advanced-node development program © 2026 lateralworks Page 14 -- 14 of 27 -- › One program, many companies › › › 04 Section four Execution under lockdown © 2026 lateralworks Page 15 The plan met the world in early 2020. -- 15 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 16 Section four Building a line while the world shut down A co-development environment with the foundry We set up a co-development environment with the sponsor’s primary foundry partner — shared tooling, shared process ownership, and a joint qualification path — so the device could be brought up and matured on a line the sponsor could actually steer, rather than handed over the wall. This was a deliberate departure from a copy-exact transfer. The process arriving from research was not finished; treating it as a clean transfer-and-ramp would have locked in an immature flow. We structured the work as a process bring-up with continued development, which let the line keep maturing the process past where research had left it. Retrofitting a fab in the middle of a lockdown We retrofitted the brownfield fab while the pandemic shut down travel and strained every supply chain. We laid out the line for development and for later production, ran the hook-up design and bid packages, and installed and qualified over one hundred process tools. When equipment suppliers and procurement were constrained, the program sent a team to finalize critical equipment agreements in person and pulled long-lead orders forward where the schedule justified the risk. Tool by tool, the line came up. Transferring the process and qualifying the line We transferred the process out of the research institute one super-module at a time — the large process blocks for substrate preparation, wafer bonding, planarization, device patterning, and back-end integration. For each, we installed and qualified the sponsor’s tools, moved the recipes onto them, and proved the module on a full-flow demonstrator before starting the next. The strategy was to take the highest-risk modules first, so the program could fail early, learn fast, and pull problems forward instead of meeting them at the end. -- 16 of 27 -- › One program, many companies › › › 05 Section five The honest diagnosis © 2026 lateralworks Page 17 A program manager who only reports good news is worthless at the moment the news turns. By the spring of 2022 it had turned, and lateralworks said so — directly, in writing, to the sponsor’s leadership. -- 17 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 18 Section five Three facts that no schedule could erase Three facts had collided. First, the transferred process was far less mature than the program had been led to believe. Bringing it to a baseline was a twelve-to-eighteen-month effort, not a six-month one; the target had been wrong from the start, and the expectations stacked on top of it were higher than the stage of development could support. Second, the foundry partner could not change at the pace the program demanded. A relationship that began as transactional had hardened, and the sponsor held less control over the outcome than its investment implied. Third, the people carrying the load were running out of road — worn down by the daily fight, short on support, and at real risk of leaving at the worst possible moment. Put it all on the table We did not soften it. We recommended radical transparency with the sponsor’s leadership, a realistic re-baselining of process maturity, decisive use of the contractual levers the sponsor held over the foundry, and an urgent, funded effort to hold the core team together. None of this was comfortable. All of it was true, and the sponsor heard it early enough to act — which is the entire point of putting a program manager, not a cheerleader, in the seat. Why the model surfaced it early This is where the lateralworks model earns its keep. The same integrated schedule and lateral structure that drove the build also surfaced the problems early and made them legible to leadership. A siloed program would have buried these failures inside functional reporting until the end. An integrated one names them while there is still time. -- 18 of 27 -- › One program, many companies › › › 06 Section six What the model delivered © 2026 lateralworks Page 19 Measured against scope, the program moved an extraordinary amount of work. Measured against the original product targets, it ran into limits that were structural, not managerial. -- 19 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 20 Section six What integration bought, and what it could not lateralworks set up and ran the program through its critical first three years. We stood up a co-development environment with the foundry partner. We retrofitted a brownfield fab through the COVID-19 lockdowns, installing and qualifying over one hundred process tools and qualifying the line. We transferred an unfinished, advanced-node process out of a research institute and matured it on a controlled development line. We built and ran a single integrated schedule across many sites and three continents, and we turned a set of vertically siloed organizations into one laterally integrated program. We called the schedule The clearest measure of the work is the schedule itself. The client scoped the program at two years. On our assessment of what an immature process, a brownfield fab, and a multi-company structure actually required, we put it at five. It took five — to the year. The planning and orchestration did not make the program faster than physics allowed; it made the program take the time it genuinely needed and no more. Our estimate is that without that structure, the same program would have run to eight years, lost to false starts, idle capacity, and problems found too late. Figure 5. The client scoped two years; we assessed five; the program took five. Our estimate of the same program without the integrated structure: roughly eight. Against the original product targets, the program met limits that were structural, not managerial: a process that needed far more development than the schedule assumed, and a foundry partner that could not move fast enough. lateralworks’ contribution was twofold — the integration that made the build possible at all, and the candor that gave the sponsor an accurate picture in time to change course. Both are the job. Neither is optional. The lesson generalizes On a program that depends on many companies, the binding constraints are usually the maturity of what you inherit and the capability of the partners you depend on. Neither is fixed by working harder. Both are exposed early by an integrated schedule, a lateral structure, and a program manager willing to say what is true. That early, honest read is the integrator’s highest-value output — worth more than any status report, -- 20 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 21 because it is the one thing a siloed program cannot produce. -- 21 of 27 -- › One program, many companies › › › 07 Section seven Best practices applied © 2026 lateralworks Page 22 The program ran on the lateralworks FTTM body of practice — best practices observed across hundreds of fast technology programs since 1988. The practices that shaped this engagement, and where they come from: -- 22 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 23 Section seven The practices behind the program A heavyweight, fully empowered core team. A single dedicated team with real authority and end-to-end accountability, reporting by exception. This is the heavyweight-team model documented by Clark and Wheelwright [1, 2], and the lateralworks standard for programs of this scale. Lateral integration of the building blocks. Adding the integrator, process architect, and chief-engineer roles that connect technology blocks to each other and to the product. This lateral structure sits at the center of the FTTM system [9], and is consistent with Allen’s findings on lateral communication in technical organizations [3]. One integrated, critical-path-driven schedule. A single source of truth, refreshed twice weekly, with a working tool list feeding it — lateralworks’ refresh-planning practice in action [9]. Managing the critical path you cannot see. Sequencing the program around the hidden facilities path rather than the obvious one. A core FTTM principle: the critical path is rarely where you think it is [9]. Buffer as a managed resource. Treating schedule buffer as something to be spent deliberately, not consumed by default — the discipline Reinertsen formalizes in the economics of product-development flow [4]. Speed from decision quality, with authority pushed down. Empowered decisions at the core team, exception reporting upward, and the team insulated from interrupts. This is the FTTM decision practice, reinforced by Oncken and Wass on where the responsibility — the "monkey" — belongs [5]. Fail faster to learn faster. Taking the highest-risk modules first to pull problems forward. The FTTM acceleration logic, which trades directly on Reinertsen’s economics of delay [4] and the break-even-time thinking of House and Price [6]. The right-product, right-team, right-time environment. Continuously defining the product, selecting and empowering the team, and planning the schedule as one connected system rather than three separate problems [9]. How to read this. Every practice above is a lateralworks observation first, grounded in the wider product-development literature second. The engagement did not apply a theory; it applied a body of field practice that the literature happens to corroborate. -- 23 of 27 -- › One program, many companies › › › 08 Section eight The four common problems, solved © 2026 lateralworks Page 24 lateralworks’ field research names four conditions as the hardest in technology development, and the most reliable way to sink a multi-party program. This program had all four at once. -- 24 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 25 Section eight Four hard conditions, met at once Most programs struggle with one of these conditions. This one carried all four simultaneously: work spread across many sites, many companies on the team, several corporate stakeholders with their own agendas, and the hardest combination of all — a technology that still had to make breakthroughs while a product was being built around it. Each condition has a known failure mode, and each has a documented lateralworks solution. We implemented all of them. The figure below maps the four problems to what we actually did on this program. Figure 6. The four common problems of multi-party technology programs, mapped to the lateralworks solutions applied on this engagement. -- 25 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 26 The fourth condition deserves a closing word, because it was the one that ultimately bound the program. Running technology innovation and product development at the same time is the trap that no amount of effort escapes. The discipline is to isolate the breakthrough work and dedicate an insulated team to it, manage it by learning milestones rather than product-performance milestones, and keep everything else known and ready. We did that. What it cannot do is manufacture a breakthrough on demand — which is exactly why the honest read of process maturity, delivered early, mattered as much as the build. -- 26 of 27 -- › One program, many companies › › › © 2026 lateralworks Page 27 Sources References [1] Clark, K. B., and Wheelwright, S. C. “Organizing and Leading ‘Heavyweight’ Development Teams.” California Management Review, vol. 34, no. 3, Spring 1992, pp. 9–28. [2] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. Free Press, 1992. [3] Allen, T. J. Managing the Flow of Technology: Technology Transfer and the Dissemination of Technological Information Within the R&D; Organization. MIT Press, 1977. [4] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [5] Oncken, W., and Wass, D. L. “Management Time: Who’s Got the Monkey?” Harvard Business Review, November–December 1974 (reprinted November–December 1999). [6] House, C. H., and Price, R. L. “The Return Map: Tracking Product Teams.” Harvard Business Review, January–February 1991, pp. 92–101. [7] Clark, K. B., and Fujimoto, T. Product Development Performance: Strategy, Organization, and Management in the World Auto Industry. Harvard Business School Press, 1991. [8] Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering. Anniversary edition, Addison-Wesley, 1995. [9] lateralworks. “The FTTM Framework.” lateralworks.com/methodology, accessed 2026. [10] lateralworks. “Internal engagement assessment.” Advanced-node development program, 2019–2022. Confidential; anonymized for publication. -- 27 of 27 --

Client Projects·Case study·Advanced-node semiconductors

One program, many companies

Running a multi-site advanced-node development program as a single, integrated team

Core thesis. When a program depends on many companies, the work is not coordination but integration — building one team, one schedule, and one set of decisions out of organizations that arrive as strangers. The integrator's highest-value output is an early, honest read of the two things that bind the schedule: the maturity of what you inherit and the capability of the partners you depend on.

June 18, 2026·27 pages

Read case study →Download PDF

© 2026 lateralworks Page 1 › › Case study Recovering a worldwide security program How lateralworks brought Cisco’s late ACS 5.0 program back onto a converging schedule and protected a multi-hundred-million-dollar hardware roadmap. FTTM engagement series. A development program run across multiple sites and continents, hundreds of engineers, eleven end-to-end teams, coordinated from a single program office in Israel — and roughly a year behind. Prepared by lateralworks Program management Engagement Cisco ACS 5.0, 2008 Case study, 2026 edition Online lateralworks.com FTTM engagement series -- 1 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 2 Table of contents Recovering a worldwide security program Abstract 03 01 The program and what was at stake 04 02 A program that had stopped converging 07 03 How lateralworks recovered the schedule 11 04 Closing the gap, week by week 14 05 What changed, and what shipped 18 06 Why it mattered to Cisco 21 A The best-practice framework, applied 23 References 26 Core thesis. A late program rarely recovers because people start working harder. It recovers when the schedule becomes a living instrument the whole team can see and pull on. lateralworks made the gap visible, gave eleven teams ownership of their own end-to-end work, and refreshed and pulled in the plan two and three times a week until the predicted delivery date stopped drifting and started converging on the target. -- 2 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 3 Overview Abstract Cisco’s next-generation access-control platform was running about a year late. The Secure Access Control System 5.0 (ACS) was a ground-up rebuild of the policy server that authenticates and authorizes users and devices on enterprise networks — the AAA core that sits behind RADIUS and TACACS+. The previous generation could not carry Cisco’s roadmap forward, and several switching businesses were waiting on 5.0 to ship their own dependent products. The release was late, the feature set kept moving, and the program had lost the one thing a late program needs most: a credible, shared view of when it would actually finish. lateralworks was brought in to recover the schedule. The work was not a reorganization and not a new tool rollout. It was the disciplined installation of the lateralworks Fast Time to Market (FTTM) operating system on a live, distributed program: build one integrated macro-to-micro schedule with explicit doneness criteria, measure the real gap between the target and the honest prediction, then refresh and pull in the plan continuously with the people doing the work. [4, 5, 6] The program ran across multiple development sites on several continents, with hundreds of engineers and eleven end-to-end teams, coordinated from a single program office in Israel. Each end-to-end team owned its slice of the product from requirements through integrated, tested delivery — a lateral, cross-functional pattern that the FTTM method was built to support. [4] Within weeks the predicted delivery date stopped sliding and began moving toward the target. The program shipped, and the dependent hardware roadmap it gated was protected. This case study describes the starting condition, the FTTM approach as it was actually applied, the turnaround as the team experienced it, and what the program meant for Cisco both at the time and in the architecture that followed it. The named client and product are used with the engagement on the record; individual team members are referred to by role. -- 3 of 26 -- › Recovering a worldwide security program › › › 01 The program What was at stake © 2026 lateralworks Page 4 ACS 5.0 was not a routine point release. It was the platform on which Cisco intended to build the next decade of identity-driven network access, and it was load-bearing for businesses far larger than the access-control product itself. To a reader outside network security, the stakes are easy to miss, so it is worth stating plainly what the system does. Every time a person or a device asks to get onto an enterprise network, something has to decide whether to let them on and what they are allowed to reach. That decision engine is the access-control system — the authentication, authorization and accounting (AAA) server. It is quiet infrastructure, and it is also the gate in front of almost everything else. -- 4 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 5 Portfolio context A release other businesses were standing on The previous generation, ACS 4.x, had reached the end of its usefulness for Cisco’s cross-company stakeholders. The 5.0 rebuild introduced a rule-based policy model and a new administration platform, and it was the version Cisco’s switching business units were depending on. Their own products were sequenced behind it, which meant a slip in ACS did not stay inside ACS — it pushed out revenue across a much larger portfolio. By Cisco’s own reckoning at the time, the release sat upstream of a multi-billion-dollar business and hundreds of millions of dollars in dependent hardware sales, and it strengthened the company’s position in the enterprise market. [4] That is the right way to read the urgency. Success was never going to be measured in ACS license revenue. It would be measured in whether the businesses downstream could launch on time — the market-window logic the return-map literature formalized [9] — and in the confidence of the large internal stakeholders who were betting their own schedules on it. A late access-control release was a tax on the whole roadmap. Figure 1. The strategic position of ACS 5.0. A single late release sat upstream of the switching businesses, the emerging identity fabric, and the enterprise access roadmap. Cropped and genericized from the engagement assessment. Program shape Worldwide, lateral, and coordinated from one office The program was genuinely distributed: development ran across multiple sites and several continents, with hundreds of engineers, and it was coordinated from a single program office in Israel. The team had already adopted advanced engineering methods — extreme programming and agile development [12] — and organized the work into eleven end-to-end teams. Each end-to-end team owned its part of the product across the full path: requirements, design, code, and out through integration and test until its element was delivered to specification in the final build. [4] -- 5 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 6 This lateral, cross-functional ownership is a core fast-team principle — what Wheelwright and Clark named the heavyweight team [8] — and it is one the FTTM method was designed to support rather than replace. Many of the ideas behind extreme programming and agile — flexible requirements, self-organizing teams, continuous improvement — were anticipated by the lateralworks research into fast teams that began in Silicon Valley in 1990. [5] The program did not need a different philosophy. It needed a way to plan and steer that many moving parts toward one date. -- 6 of 26 -- › Recovering a worldwide security program › › › 02 The problem A program that had stopped converging © 2026 lateralworks Page 7 A program can be late for good reasons and still be in control. This one was late and had lost control of its own forecast. That distinction is the whole problem. lateralworks opened the engagement with a structured assessment of the program — not of the code, but of how the program understood itself. The assessment walked nine areas, from portfolio fit and market segmentation through scope, time-to-market drivers, success criteria, cost of delay, the customer and the value proposition, requirements stability, and the as-is data already in hand. -- 7 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 8 Figure 2. The program assessment. Nine lines of inquiry used to establish the real starting condition before any planning began. Genericized from the engagement assessment map. Diagnosis What the assessment found The findings were consistent and they reinforced each other. The 5.0 feature set for first customer shipment (FCS) was unstable and still changing. Requirements moved during development, and closed decisions were reopened. There was no product roadmap for the generations beyond 5.0, so every request felt equally urgent. Planning and tracking skills were thin at the team level, the program team structure — roles, leadership, control — was unclear, and there was no integrated plan, no schedule trending, and no tracking system that the whole program could see. A year of direction changes had stretched the program, and the target for FCS was aggressive given that history. The team’s own words from the pre-engagement survey were blunter than any diagnosis. Decisions were made by large groups with too many arguments. Too many people were involved in low-level decisions. The prevailing reflex, in one engineer’s words, was a “can’t do” attitude rather than a search for a way through. None of this is unusual on a program that has been slipping for a year. All of it is fatal to a date. The real symptom The forecast had stopped converging Underneath the cultural symptoms was a measurable one. When lateralworks built the first honest model of the schedule and compared it to the committed targets, the gap was large and, worse, it was not closing. Major milestones were predicted weeks to months beyond their targets, and because no one was tracking the prediction over time, the drift was invisible until a date was missed. A program that cannot see its own gap cannot create the urgency to close it. -- 8 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 9 Figure 3. The gap at engagement start. Each milestone’s honest prediction (diamond) sat well beyond its target (star). Without trend tracking, this drift had been invisible. Reconstructed from the engagement schedule analysis. -- 9 of 26 -- Pre-engagement, January 2008 The starting condition Mostly a “can’t do” attitude. Too many people in low-level decisions. No integrated plan, no schedule trending. Composite of ACS 5.0 team members lateralworks pre-engagement survey, January 2008 © 2026 lateralworks Page 10 -- 10 of 26 -- › Recovering a worldwide security program › › › 03 The approach How lateralworks recovered the schedule © 2026 lateralworks Page 11 The recovery was not improvised. It was the installation of a defined system — the lateralworks Fast Time to Market method — in the specific order that makes a late program start converging. FTTM rests on a simple, counterintuitive idea: the way to deliver the right product at the right time is not to freeze everything, but to keep changing the product and the schedule deliberately, in public, with the team. [5, 6] Speed is the consequence of a few disciplines installed together. The sections below describe the four that mattered most here, in the order they were applied. -- 11 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 12 Discipline one Build one schedule, macro then micro The team first built a macro map: a single top-level architecture for the whole program, anchored in explicit doneness criteria — the measurable exit conditions for each milestone and for FCS itself. Doneness is where FTTM planning starts, because you cannot schedule toward an end you have not defined. [6] The macro normalized several disconnected data streams into one integrated picture and exposed inconsistencies that had been hiding in separate spreadsheets. From the macro, the team developed the master schedule down to the next level of detail and then connected the eleven end-to-end schedules beneath it. Detailed team work rolled up into the master; cross-team interface points were driven down from the master into each team’s plan. The result was one information system, built and integrated with the lateralworks macro-micro scheduling tools [7], not a stack of schedules that disagreed with each other. Macro and micro were reconciled — top-down expectation against bottom-up reality — which is the alignment step FTTM treats as non-negotiable before a program is allowed to run hard. [6] Figure 4. The macro-micro schedule architecture. One integrated system: detailed end-to-end work rolls up; cross-team interfaces drive down. Genericized from the engagement schedules. Discipline two Find the real gap, then create urgency With one honest schedule in place, the team measured the gap between the target dates and the realistic prediction, and used the critical path to find where time could be recovered. This is the FTTM move that manufactures urgency before a deadline forces it: when a program is nominally on schedule, nothing changes, because nothing has to. When the real gap is visible and large, people start looking for different ways to work so the gap can close. [6] The team also looked past the single critical path to the second and -- 12 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 13 third paths, where unmanaged slack quietly turns into the next delay. The economics are well understood: a cost-of-delay view quantifies what each week of slip is worth, which is what gives pull-in its urgency. [10] Discipline three Refresh and pull in, two and three times a week The engine of the recovery was cadence. The program refreshed the schedule two to three times a week with the team: update what actually happened, analyze the gap to target, and then pull in — compress the critical path by resequencing, rescoping, or reallocating. Refresh is what keeps a schedule honest; pull-in is what makes it move. Run often enough, the pair converts the abstract urgency of the gap into concrete schedule compression every few days. [5, 6] Figure 5. The refresh and pull-in cycle. Update, analyze the gap, pull in the critical path, and trend the prediction — run two to three times a week with the full team. Discipline four Trend the prediction so drift is visible Every refresh produced a new prediction for each major milestone, and those predictions were plotted over time as a trend — the lateralworks wigglechart. Instead of a single date that is either met or missed, the program could now watch its forecast move week over week, see whether it was converging on the target or drifting away, and read how many days a week it still needed to pull in to land on time. Early-warning indicators flagged milestones that required more aggressive action. Drift that had been invisible for a year became a line on a chart that everyone could read. -- 13 of 26 -- › Recovering a worldwide security program › › › 04 Execution Closing the gap, week by week © 2026 lateralworks Page 14 The disciplines are simple to describe. Installing them against the drag of a distributed, year-late program is the hard part, and it is where the engagement lived day to day. -- 14 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 15 The signature view The forecast starts to converge The clearest evidence of the turnaround was the milestone trend itself. After an early period where the predicted delivery date jumped further out as the honest schedule absorbed reality, the refresh and pull-in cadence took hold and the prediction began a steady march back toward the target. At one tracking point the delivery-complete milestone needed thirty-two days pulled in over the next seventy to hit its target — a demanding but now quantified and shrinking number, the kind of gap a team can actually attack rather than fear. Figure 6. Milestone trend (wigglechart) for the delivery-complete milestone. The predicted date spikes as the schedule turns honest, then converges toward target as refresh and pull-in take hold. Marker color signals risk to target. Reconstructed from the engagement trend reports. Resourcing Matching the accelerated plan to capacity Pulling in a schedule is only real if the people exist to do the pulled-in work. As the plan accelerated, the team analyzed load against capacity and surfaced the over-allocation that an aggressive schedule always hides. Making the over-allocation visible let the program rebalance deliberately rather than discover the shortfall when a milestone slipped. FTTM treats balanced resourcing as a host responsibility: provision the team for the plan you are asking it to deliver, or change the plan. [5] -- 15 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 16 Figure 7. Schedule versus capacity. The accelerated plan pushed several months into over-allocation (orange) above sustainable capacity (dashed), which the program then rebalanced. Genericized from the engagement resource analysis. Scaling the method Pushing planning down to the teams The most durable change was making the method the teams’ own. Each end-to-end lead reported progress at the twice-weekly refresh, and their updates fed the master schedule. Two teams went further in a pilot: their detailed plans were integrated directly into the master so progress rolled up automatically and cross-team interface dates drove down to them, which removed a standing tax of manual schedule clean-up and coordination. The program office could then manage by exception, putting its attention on the teams actually driving the critical path. One team’s bottom-up plan from this period — scope, milestones, resource analysis, dependencies, and open issues, laid out by the team itself — shows the planning discipline taking root where the work happened, not just at the program office. [13] That same bottom-up planning forced the decision that mattered most for the date: what actually had to be in the first release. The teams worked an explicit FCS feature list and, just as plainly, a list of functionality deferred past first customer shipment. Pulling a schedule in is never only resequencing work; it is deciding the right feature set for the time available and moving the rest to a later release. Choosing what not to ship was as much a part of the recovery as any scheduling move — the FTTM principle of the right product at the right time, doing its job under deadline pressure. [13] By the closing weeks of the program the pattern was self-sustaining. The management team had adopted the refresh discipline, two remote teams were refreshing three times a week, the master schedule improved every week, and the conversation had shifted from whether the date was real to how many days were left to pull in. The gap was known, the path to the end was clear, and the focus was on closing it. -- 16 of 26 -- Post-program, late 2008 The instrument that changed behavior A master schedule, and we knew where we were every week. Focus on the critical path was powerful — we acted sooner. Composite of ACS 5.0 team members lateralworks program survey, 25 responses, Aug–Nov 2008 © 2026 lateralworks Page 17 -- 17 of 26 -- › Recovering a worldwide security program › › › 05 Results What changed, and what shipped © 2026 lateralworks Page 18 Two kinds of result matter here: what the program delivered, and what the people on it reported afterward. Both point the same way, and the honest version of each is more useful than a victory lap. -- 18 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 19 What shipped A converging program that delivered The program moved from an open-ended slip to a managed, converging schedule with a known and shrinking gap, and ACS 5.0 was delivered. That is the result that protected the businesses downstream: their products were sequenced behind a release that now had a credible date and a plan to hit it. It is worth being precise about the mechanism rather than claiming a tidy miracle. lateralworks did not make a year of slip disappear overnight. It restored the three things a late program needs — visibility, predictability, and urgency — and gave the team an instrument to drive itself toward the date instead of away from it. What the team reported The post-program survey Late in the program lateralworks surveyed the team. Twenty-five people responded between August and November 2008, rating the program across confidence, risk management, estimation, role clarity, communication, the end-to-end approach, and the process itself. The strongest marks went to role clarity and communication, each rated good or better by four in five respondents, and to confidence in meeting the target dates — a striking reading for a program that had been a byword for missed dates a year earlier. Figure 8. Post-program survey, top-two-box responses across the rated dimensions. Twenty-five responses, August to November 2008. Reconstructed from the engagement program survey. The survey was not uniformly glowing, and that is to its credit. The end-to-end concept was rated well by most but exposed real friction: responsibility grey areas between teams, leads who were also functional managers and so were overloaded, and the absence of a single lead architect with a view of the whole product. Risk management was the weakest area, with a substantial minority saying the program never built a real risk process. The team’s own recommendations for a next program were concrete — freeze scope sooner, push planning detail further into the teams, define interfaces so groups can work independently, and -- 19 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 20 run risk management as a standing discipline. A recovery that produces an honest critique of itself is a recovery that taught the organization something. What stayed behind A capability, not just a date The most valuable outcome was not the date; it was the capability. A standard planning and tracking process was in place, the team leads had stronger planning skills, and the refresh discipline continued after the engagement without lateralworks driving it. The program had learned to run itself the FTTM way, which is the only kind of process change that survives the consultant leaving the building. -- 20 of 26 -- › Recovering a worldwide security program › › › 06 Significance Why it mattered to Cisco © 2026 lateralworks Page 21 It is tempting to file a schedule recovery under project management and move on. The longer view is more interesting, because of where this particular release sat in Cisco’s architecture. -- 21 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 22 At the time Protecting the roadmap, not the product In the moment, the value of an on-time ACS 5.0 was almost entirely external to ACS. The switching businesses that had sequenced products behind it could proceed on their own dates; the large internal stakeholders who had bet on it kept their confidence; and Cisco avoided the worst case the team itself had named — a loss of customer confidence severe enough to consider replacing ACS with an acquisition or a third-party product. [13] The recovery defended a multi-billion-dollar business and the hundreds of millions in dependent hardware revenue that rode on it. [4] Since The foundation Cisco’s access strategy was built on The rule-based policy architecture introduced in 5.0 turned out to be the foundation for where Cisco took network access next. The 5.x line became the AAA policy server behind Cisco TrustSec, the company’s identity-driven, role-based access architecture: TrustSec’s AAA is supported by the Secure Access Control System from version 5.1 onward, with the access-control server acting as the authentication server that assigns devices to security groups. [1, 2] In other words, the platform whose schedule was recovered here became load-bearing for an architecture that outlived it. Cisco later carried that identity-and-policy strategy forward into the Identity Services Engine (ISE), and the Secure Access Control System was eventually retired as ISE became the center of gravity. [2, 3] Read across two decades, ACS 5.0 was a hinge: the generation that moved Cisco from legacy access control to a rule-based, identity-aware model, and the proving ground for ideas that the company’s current access portfolio still reflects. That is a program worth recovering. The lasting point. The engagement protected far more than one release date. It protected the businesses downstream of ACS 5.0 and the architecture that grew out of it. When a program sits at the base of a portfolio, recovering its schedule is portfolio strategy, not project hygiene. -- 22 of 26 -- › Recovering a worldwide security program › › › A Appendix The best-practice framework, applied © 2026 lateralworks Page 23 The engagement drew on the lateralworks best-practice framework, which reads a program along two axes: the four levers that determine whether work gets done, and the two parties responsible for them. The framework is reproduced here in genericized form, followed by the specific practices used on this program. -- 23 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 24 The framework Host and team across four levers Every delivery system depends on four levers — the systems and processes in place, the knowledge and skills available, the motivation to act, and the resources provisioned — and each lever has two owners. The host is the organization around the team that sets strategy, provisions people and budget, and either removes interrupts or creates them — and getting this wrong is expensive at scale; excess management has been estimated to cost the U.S. economy roughly three trillion dollars a year. [11] The team executes. Fast organizations get both rows right; slow ones fix the team and leave the host alone, and the improvement fades. [5] Figure 9. The lateralworks best-practice framework. Four levers (systems, knowledge and skills, motivation, resources) read across two owners (host and team). Genericized from the engagement analysis. -- 24 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 25 Applied here Which practices did the work lateralworks practice How it was used on ACS 5.0 Doneness criteria Defined measurable exit conditions for each milestone and for FCS before scheduling began. Macro-micro reconciliation Built one macro map, then a master schedule with eleven end-to-end schedules rolled up beneath it. Real schedule gap Measured target-versus-prediction to manufacture urgency before deadlines forced it. Critical-path pull-in Compressed the first, second, and third paths through resequencing and reallocation. Refresh cadence Updated and pulled in the schedule two to three times a week with the full team. Wigglechart trending Plotted each milestone’s predicted date over time so drift and convergence were visible. Lateral / end-to-end ownership Eleven teams owned requirements through integrated, tested delivery; interfaces driven from the master. Heavyweight core team Recommended a real core-team structure with a heavyweight program manager and faster decisions. Balanced provisioning Analyzed load against capacity and rebalanced the accelerated plan to sustainable levels. Skills transfer Left a standard planning and tracking process the teams continued to run independently. -- 25 of 26 -- › Recovering a worldwide security program › › › © 2026 lateralworks Page 26 Sources References [1] Cisco Systems. “Cisco TrustSec Switch Configuration Guide: Configuring the Cisco TrustSec Solution.” AAA for Cisco TrustSec is supported by the Cisco Secure Access Control System (ACS) version 5.1 and later. cisco.com. [2] Cisco Systems. “Cisco TrustSec Configuration Guide” (Catalyst 9300 / C9350). The authentication server in a TrustSec domain can be the Cisco Identity Services Engine (ISE) or the Cisco Secure Access Control System (ACS). cisco.com. [3] Cisco Systems. “Cisco Secure Access Control System — Retirement Notification.” The Secure Access Control System has been retired and is no longer supported. cisco.com. [4] lateralworks. “Projects: Cisco ACS 5.0.” Engagement summary describing the eleven end-to-end teams, the extreme-programming and agile context, and the competitive and revenue stakes. https://lateralworks.com/projects [5] lateralworks. “Research: the FTTM best-practice framework.” Host, team, and mindset; provisioning and interrupt removal; right product at the right time. https://lateralworks.com/research [6] lateralworks. “The FTTM system.” Macro-micro reconciliation, doneness criteria, before-the-fact urgency, refresh and pull-in. https://lateralworks.com/ideas/fttm-system [7] lateralworks. “FTTM Tools.” Macro-micro scheduling, gap identification, and consensus pull-in for portfolios and large programs. lateralworks-software.com. [8] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. Free Press, 1992. Origin of the heavyweight team / core team concept. [9] House, C. H., and Price, R. L. “The Return Map: Tracking Product Teams.” Harvard Business Review, January–February 1991, pp. 92–101. [10] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. Cost of delay and queueing in development. [11] Hamel, G., and Zanini, M. “Excess Management Is Costing the U.S. $3 Trillion Per Year.” Harvard Business Review, September 2016. [12] Beck, K. Extreme Programming Explained: Embrace Change. Addison-Wesley, 1999. Context for the engineering methods in use on the program. [13] lateralworks. “Internal engagement data: Cisco ACS 5.0 program.” End-of-engagement report; pre-engagement survey (January 2008); program survey (25 responses, August–November 2008); end-to-end high-level planning policy (January 2008). 2008. -- 26 of 26 --

Client Projects·Case study·Networking & security

Recovering a worldwide security program

How lateralworks recovered Cisco's year-late ACS 5.0 program and protected the hardware roadmap that depended on it

Core thesis. A late program rarely recovers because people start working harder. It recovers when the schedule becomes a living instrument the whole team can see and pull on. lateralworks made the gap visible, gave eleven teams ownership of their own end-to-end work, and refreshed and pulled in the plan two and three times a week until the predicted delivery date stopped drifting and started converging on the target.

June 17, 2026·26 pages

Read case study →Download PDF

Page 1 © 2026 lateralworks › › Case study Innovation Accelerated advanced display fab and technology development Three programs in one, delivered through COVID Advanced semiconductor program A research-grade process, transferred to a fab that did not exist at kick-off, accelerated to a breakthrough yield target on a reset three-year timeline — through a pandemic, on one core team colocated at the fab. Prepared by lateralworks Technical program management Program Advanced display device Five-year duration; lateralworks engaged 3+ years Online lateralworks.com Case study series -- 1 of 28 -- › Case study / Innovation Accelerated › › › Page 2 © 2026 lateralworks Table of contents Innovation Accelerated Abstract 03 01 Three programs, one core team 04 02 The engagement, end to end 08 03 Core team, charter, and a single point of ownership 11 04 One macro plan, many micro plans, twice-weekly refresh 16 05 Working the critical path, one week at a time 21 06 Breakthrough technology, delivered on the reset plan 25 07 Three things that made it work 27 Core thesis. You cannot accelerate a program you do not see. The first job was making the program visible end-to-end — one integrated plan, one core team, one refresh cycle — and then closing the gap one critical-path week at a time. -- 2 of 28 -- › Case study / Innovation Accelerated › › › Page 3 © 2026 lateralworks Overview Abstract A consumer-electronics client was building a next-generation product that required thirty-eight discrete inventions to come together at one time. The advanced display device was one of those inventions — and on its own, three programs run as one. The base technology had been demonstrated in a European research institute. Standing it up at production scale meant first building the fab that would do the research, then doing the research, then accelerating that research to a breakthrough yield, performance, and cycle-time target the product team’s insertion milestones would not bend on. Phase 1 was a brownfield fab retrofit — more than one hundred tools spec’d, ordered, installed, hooked up, and qualified, the bulk of it executed through COVID lockdowns. Phase 2 was a research-to-development process transfer for all three color emitters. Phase 3 was a worldwide engineering acceleration to tune the fab and the process to the breakthrough target. The same heavyweight core team owned all three. lateralworks ran the technical program management end-to-end, with the program lead colocated at the receiving fab for the full duration of the engagement. The first lateralworks deliverable was telling the client the original eighteen-month timeline was wrong. The second was a reset to a three-year plan grounded in honest learning-cycle accounting. The rest was the discipline of working that plan one critical-path week at a time, through a pandemic, inside a multinational with deep pockets, CEO-level commitment to the product, and many technical stakeholders pulling on the team. The team hit the revised target. The breakthrough technology was delivered. This case study describes how the program was framed, structured, and managed — and the decisions that mattered most along the way. -- 3 of 28 -- › Case study / Innovation Accelerated › › › 01 Three programs in one Three programs, one core team Page 4 © 2026 lateralworks The product behind this engagement was a consumer device that required thirty-eight discrete technology inventions to converge on a single launch window. Each invention was a program in its own right. This case study covers one of them: an advanced display device that combined a novel emissive front-plane bonded onto custom CMOS driver wafers — a stack the industry had not produced at scale, and a process the client did not yet own. On its own, this single invention was three programs run as one. That framing matters more than any single technical fact in the case study, because every structural decision in the engagement followed from it. -- 4 of 28 -- › Case study / Innovation Accelerated › › › Page 5 © 2026 lateralworks Three phases, one program, one team Figure 1. The three programs run as one. Phase 1 built the infrastructure (fab retrofit and tool buildout). Phase 2 transferred the research-grade process from the originating institute to the new development line. Phase 3 accelerated that process to a breakthrough yield target. The same heavyweight core team, colocated at the receiving fab, owned all three phases end-to-end — through the pandemic. Phase 1 — facilities and tools. The receiving site was a brownfield fab. It needed more than one hundred new tools spec’d to the transferred process, ordered, hooked up to a sub-fab that did not yet exist for this technology, installed, and qualified. The facilities work — utility runs, gas and chemical distribution, layout for development followed by production volume — ran as a parallel critical path against the tool deliveries. The bulk of this phase executed through COVID-era travel restrictions, supplier on-site limits, and reduced fab staffing. It was completed on schedule. Phase 2 — research-to-development process transfer. The originating institute’s proof-of-concept flow for all three color emitters had to be vendor-matched onto a 200mm tool set the receiving site had never used. Every step of the flow needed a complete process and integration record, mask data, and FMEAs in place before transfer. The transfer was structured so that what arrived at the receiving fab was a process the receiving team could actually own — not a recipe they would have to reverse-engineer. A parallel track of process improvement at the receiving fab ran alongside the baseline transfer; the two were managed as one technical program with shared accountability. Phase 3 — worldwide engineering acceleration. With the transferred process running on the development line, the work shifted from delivery of infrastructure to acceleration of learning. The product team’s insertion milestones required a breakthrough in yield, performance, and cycle time that no single team had ever achieved on this technology. The engineering effort was worldwide, with technical contributions from the originating institute, the receiving fab, the client’s design organization, and equipment and materials suppliers on three continents. Most of the technical breakthrough lived in this phase. The fab itself had to be tuned to world-class cycle-time efficiency so the engineering team could run enough learning cycles per quarter to make the breakthrough achievable inside the schedule. The decisive structural choice was that all three phases ran on the same heavyweight core team, with a single program leader colocated at the receiving fab, from kick-off through risk-production start. The team -- 5 of 28 -- › Case study / Innovation Accelerated › › › Page 6 © 2026 lateralworks that ordered the tools also ran the process transfer also drove the acceleration. There was no handoff. There was one program. Why this got harder — COVID and multinational complexity Two factors outside the technology made this program harder than other semiconductor transfers of comparable scope. First, the pandemic. Phase 1 executed almost entirely under COVID restrictions. Equipment suppliers could not travel for factory acceptance tests. Tool installers needed visa exemptions to enter the country. The fab itself ran reduced on-site staffing for months at a time. Phase 2 and the start of Phase 3 ran under the same conditions. The schedule absorbed all of this without slipping the Phase 1 commitment date. It absorbed it because the core team had built a planning system that surfaced consequences early and treated supplier interfaces as live, jointly-planned tasks rather than checkpoint hand-offs. Second, the organizational geometry. The client was a large multinational with CEO-level commitment to the product and the resources to back that commitment. That is an unmitigated advantage in some respects. It also meant the program had more technical stakeholders than any single core team could process if they had been treated as decision-makers: multiple design organizations, several in-house process and packaging teams, a research institute on a different continent, and the receiving fab as a separate legal entity. Ownership and boundaries were genuinely difficult to draw. The thing that made it work was that the program had one boss, colocated at the fab, running one core team on one mission. Stakeholders got information and a clear interface; they did not get a seat on the team. The project mission, stated and acted on from the first week: accelerate the client’s learning on a development line of its own, by failing faster. On a technology this immature, failing faster was the only way to reduce risk inside the schedule. Three intertwined problems — administration, facilities, technology Figure 2. The three problem clusters that defined the early plan, in order of difficulty. Each layer depends on the one above it. A delay anywhere upstream compresses the time available for the hardest problem. At kick-off lateralworks framed the program around three problem clusters that had to be solved in sequence but were tightly coupled. Administration was the easiest because it was about decisions the client could -- 6 of 28 -- › Case study / Innovation Accelerated › › › Page 7 © 2026 lateralworks make immediately: define the moving target tool list, spec the tools, negotiate the orders. Facilities was the next layer up, harder because it depended on a brownfield site that did not yet exist as a development fab — utilities, layout, hook-up, install-and-qual sequencing all interacted with tool specs. Technology was the hardest and last in order because it depended on the first two: transfer the process, gain control of it, then make it work at the volume and yield the business plan demanded. A delay anywhere upstream compressed the time available for the hardest problem. Why the original eighteen-month plan was wrong The early commitment to an eighteen-month timeline was a planning artifact, not a technical forecast. It set the date the product team needed and worked the development plan backwards from it. The plan did not include the number of learning cycles the process actually needed to mature, because the maturity of the transferred process was over-stated and the rate at which a new development line could learn was over-estimated. The result was a gap between target and reality that grew, week after week, with no mechanism in the planning system to surface why. The first real win of the engagement was getting that gap on the table. A program that thinks it is six months late will negotiate; a program that has not yet accepted it is years late cannot. -- 7 of 28 -- › Case study / Innovation Accelerated › › › 02 Scope The engagement, end to end Page 8 © 2026 lateralworks The scope of the engagement spanned the lifecycle of a semiconductor development program — from selecting where it would happen, to running the core team that delivered it. The work fell into seven streams that ran in parallel and reinforced each other. -- 8 of 28 -- › Case study / Innovation Accelerated › › › Page 9 © 2026 lateralworks Selecting a foundry codevelopment partner The client needed a partner that already had the silicon fabrication capability, clean-room infrastructure, and operating discipline to absorb the research-line process and run it at low-volume manufacturing scale. lateralworks structured the partner search, evaluated candidates against the program’s technical, commercial, and program-execution criteria, and supported the negotiation of the master agreement that anchored the codevelopment relationship. Transferring the process from the research institute The transfer was not a "copy exact." It was a vendor-matched transfer of the proof-of-concept flow for all three color emitters, onto a 200mm tool set, with the receiving fab purchasing tools that did not exist in the originating site. Every step of the flow needed a complete process and integration record, mask data, and FMEAs in place before transfer. lateralworks coordinated the transfer plan with technical leads at both the originating institute and the receiving fab so that what arrived was a process the receiving team could actually own. Expanding, retrofitting, and standing up the development fab The receiving site was a brownfield fab. It needed more than one hundred new tools installed and qualified to support the transferred flow, plus the facilities infrastructure to support those tools — utility runs, gas and chemical distribution, sub-fab build-out, layout optimized for both development and the production volume that would follow. lateralworks structured the facilities work as a parallel critical path tied to the tool ordering schedule, and made the tool list itself an active planning object — refreshed twice a week, costed, and visible to every function that depended on it. Developing the process to product KPIs Five process super-modules — coring, bonding, planarization, pixelation, post-pixelation — each had to be qualified individually and then together as a full flow. Qualification at the partner fab meant the module produced material that met the defined performance, yield and cycle-time targets handed down from the product KPIs. lateralworks held the master plan that tied module-level qualification milestones to the product team’s intercept points and refreshed the gap analysis weekly. Defining, structuring, and managing the program — the TPM role For more than three years lateralworks served as the strategic technical program manager for the development line. That meant owning the program’s planning architecture, running the core team, escalating the right issues to executive sponsors at the right time, and protecting the team’s ability to focus on the hard technical work by absorbing the program-management load. Forming and chartering the core team The core team spanned the client’s process and product organizations, the foundry partner’s development and manufacturing teams, the originating European research institute, multiple external equipment and materials suppliers, and an industrial-engineering services partner that handled facilities and capacity modeling. lateralworks chartered the team, defined its operating cadence, and held it to the discipline of working as one team rather than as a federation of organizations that occasionally met. -- 9 of 28 -- › Case study / Innovation Accelerated › › › Page 10 © 2026 lateralworks One integrated master schedule, end-to-end The single most important artifact of the engagement was a master plan that connected every work stream end-to-end and refreshed twice a week. From it lateralworks ran an aggressive acceleration program — pull-in actions identified every week, executed by the team that owned them, tracked against trend, escalated on exception. The acceleration program closed a multi-year gap to a realistic and committed schedule the team then delivered against. -- 10 of 28 -- › Case study / Innovation Accelerated › › › 03 Organization Core team, charter, and a single point of ownership Page 11 © 2026 lateralworks A semiconductor program of this complexity fails when the people doing the work report up through separate organizations and meet only to share information. lateralworks observed the textbook failure pattern on a parallel program inside the same client — a group of functional representatives with no shared ownership of outcomes, each function trying not to be the one labeled as the critical path. Patrick Lencioni’s five dysfunctions of a team — inattention to results, avoidance of accountability, lack of commitment, fear of conflict, absence of trust — were all present. The development line could not be run that way. The fix was structural. -- 11 of 28 -- › Case study / Innovation Accelerated › › › Page 12 © 2026 lateralworks A heavyweight core team, not a steering committee The team was five to ten people with complete authority over program outcomes. Each member represented a function — facilities, tools and process, transfer and research, infrastructure, procurement, development operations, product interface, industrial engineering — and each member could commit on behalf of that function in real time. The team owned the integrated schedule, owned the weekly refresh, owned the critical path, and owned the actions to close the gap. They identified blocking issues and brought resources to resolve them. They were not a reporting body; they were the program. Figure 3. The heavyweight core team. Eight functional members, each able to commit on behalf of their function in real time. The team owns the integrated schedule and the actions to close the gap. One leader, colocated at the fab, one mission Heavyweight team structures fail when the leader runs them remotely. The lateralworks program lead was colocated at the receiving fab for the duration of the engagement. Decisions made in the morning could be tested on the floor by the afternoon; equipment suppliers visiting for factory acceptance or hook-up walked into the same building as the program office. Colocation cost personal time. It bought speed nothing else could buy. The core team was 100 percent dedicated to this program — not matrixed, not shared with two other projects, not borrowed for a quarter. Functional members were resourced full-time. The receiving fab’s engineering organization ran as a paired partner team to the core team, with one interface and joint ownership of outcomes. There was one mission, and one team executing it. This single structural choice did more to make the program work than any planning technique in this document. -- 12 of 28 -- › Case study / Innovation Accelerated › › › Page 13 © 2026 lateralworks Three roles fast programs need defined Programs that move fast need three roles defined precisely, and they need to be different people. lateralworks worked with the client to name them, staff them, and protect the distinction between them. The integrator looks laterally and ties the work of every function together. The integrator does not own technical content; they own the connections between technical contents. The architect makes system-level trade-offs that do not compromise overall system performance. When a tool slips a week and three sub-modules need new sequencing, the architect decides what holds and what gives. The chief engineer makes the final technical decision. When the integrator has surfaced a question and the architect has framed the trade-off, the chief engineer says yes or no and the team moves. Programs that try to merge these roles — integrator and chief engineer in the same person, or architect and integrator — slow down. The three modes of thinking conflict. One technical voice, one strategic program voice The program designated a single chief engineer with technical authority over device integration and compliance with system-level performance requirements, and a single strategic TPM responsible for delivery from process transfer through the long-horizon product milestones. Both roles answered to the executive steering committee but neither was a committee. When trade-offs came up — and they came up constantly — the program knew where the decision lived. Engineering-driven planning lateralworks insisted that the integrated schedule be developed by the engineering subject-matter experts together with the TPM, not by the TPM alone. Schedules built by a program-management function without engineering ownership are accurate the day they are published and irrelevant the day after. Schedules built by the engineers who will execute them belong to the team and survive contact with reality. Suppliers as joint planners Equipment and materials suppliers were brought into joint planning sessions and ran on transparent schedules that included both their tasks and the client tasks each interface required. This was a departure from the more common pattern of checkpoint-only supplier engagement, in which the program only learns about a problem after the problem has occurred. With the joint-planning model in place, suppliers were a forward-looking part of the schedule rather than a source of unwelcome surprises. The cross-functional FTTM model The product was a system, and the technology programs that fed it were each their own system. Both layers ran on the same heavyweight core-team pattern — small empowered teams, single point of decision authority, one operating cadence. The lateral interfaces between the layers were held by two named roles: the product architect at the system level and the process architect at the technology level. The corporate host provisioned, decided fast, and stayed out of each team’s way. -- 13 of 28 -- › Case study / Innovation Accelerated › › › Page 14 © 2026 lateralworks Figure 4. The cross-functional team structure across both layers. Several technology programs ran in parallel — the focal display-device development fab being one of them — each feeding into the product core team. The Product Architect held system-level trade-offs; the Process Architect held the technology-level interfaces between fab, transfer, and integration. -- 14 of 28 -- › Case study / Innovation Accelerated › › › Page 15 © 2026 lateralworks Figure 5. The inner view of the product core team. The display device was one node among Hardware, Software, Mechanical, Manufacturing, Marketing, Integration & Test, Product Architect, and Product EPM. Each technology team mirrored this same pattern internally. -- 15 of 28 -- › Case study / Innovation Accelerated › › › 04 Planning architecture One macro plan, many micro plans, twice-weekly Page 16 © 2026 lateralworks The planning architecture was the operating system of the program. Every major decision — pull-in action, supplier negotiation, tool order, scope trade-off — ran through it. -- 16 of 28 -- › Case study / Innovation Accelerated › › › Page 17 © 2026 lateralworks Data architecture, all driven from the critical-path schedule Figure 6. Planning data architecture. The critical-path schedule is the master record. The working tool list feeds in and receives data back. Tool dependencies, costs, and the tool map sit alongside and refresh twice a week. The critical-path schedule was the master record. The working tool list — the program’s tool POR — fed into the schedule with names, suppliers, costs, and dependencies, and received dates and the refreshed critical path back out. The tool map showed which tools were needed for which super-module and sub-module qualification, with explicit tool-to-tool dependencies that propagated through the schedule. Cost data was prorated over the PO-placed, docked, and qualified milestones for every tool, so the program’s burn rate tracked alongside its critical path. Refresh frequency was twice a week, not once a quarter. Macro-micro schedule architecture The master schedule was the macro view: program-level critical paths to the major milestones — first prototype delivery, all modules qualified, risk production start. Beneath each critical path sat a micro schedule for the work-stream owning that path. Each micro schedule was refreshed weekly by the technical DRI and TPM responsible for it, with rollup into the macro on the same cadence. The result: a program with a single answer to "where are we?" at any level of zoom. -- 17 of 28 -- › Case study / Innovation Accelerated › › › Page 18 © 2026 lateralworks Figure 7. The macro-micro WBS structure. Top: the program-level view (master agreement, facility assessment, tool and module qualification, process and product qualification). Bottom: sub-modules under a single super-module, with target and predicted dates and the qualification milestone. The refresh process Figure 8. The weekly refresh cycle. A Monday review of pull-in actions and a Thursday session for the next week’s acceleration moves. Status reporting is a byproduct of the planning process, not a parallel activity. The week had two anchor meetings: a Monday review of pull-in actions taken since the previous Thursday and a Thursday pull-in session where the next week’s acceleration moves were identified and committed. -- 18 of 28 -- › Case study / Innovation Accelerated › › › Page 19 © 2026 lateralworks Between the two, the team conducted focused schedule-scrubbing sessions on specific work streams. The cadence was deliberate. Reviews and pull-ins were separated so that one meeting was not asked to do both jobs. Status reporting was a byproduct of the planning process, not a parallel activity. Tool dependencies and the move from tool list to schedule Figure 9. Tool-submodule dependency map (filtered example showing deposition tools only). Each tool feeds into the qualification of specific sub-modules; when a tool slips, the planning system propagates the consequence downstream automatically. The tool-to-tool and tool-to-submodule dependency tables propagated changes through the schedule automatically. When a single tool slipped — qualification delayed at the supplier, or a sub-fab utility hook-up running late — the schedule showed the downstream submodule, then the module, then the full-flow qualification, then the prototype delivery, in one connected view. The team did not have to chase the consequences of a slip; the planning system did it for them. -- 19 of 28 -- Turning point Reset the plan You cannot accelerate a program until the program agrees on where it actually is. Engagement reflection On resetting the development-line target from 18 months to 3+ years Page 20 © 2026 lateralworks -- 20 of 28 -- › Case study / Innovation Accelerated › › › 05 Closing the gap Working the critical path, one week at a time Page 21 © 2026 lateralworks The acceleration program existed because the gap to the original target was enormous and the gap to the revised target was still aggressive. Acceleration was not a one-time exercise; it was the operating mode of the program for the full duration of the engagement. -- 21 of 28 -- › Case study / Innovation Accelerated › › › Page 22 © 2026 lateralworks Force acceleration of each step — it is all connected Figure 10. The FTTM acceleration cascade. Each step compresses the next. The area of extreme risk — process transfer and learning at the receiving fab — sits in the middle of the chain. Acceleration upstream buys time for the hardest work downstream. The acceleration logic ran backwards from the product milestone. The sooner the fab was secured, the sooner the tools could be ordered. The sooner the tools were ordered, the sooner they could be qualified. The sooner the tools were qualified, the sooner the process could be transferred. The sooner the process was transferred, the sooner learning began. And accelerated learning was the only mechanism that delivered the product sooner. Each step compressed the next, and the area of extreme risk — process transfer and learning at the receiving fab — sat in the middle of the chain. Every week the program asked: what can we pull in upstream of that risk zone? Pull-in actions on the critical path -- 22 of 28 -- › Case study / Innovation Accelerated › › › Page 23 © 2026 lateralworks Figure 11. Weekly area-of-focus pull-in chart. In one representative week the program identified six tasks worth twenty-three days of pull-in if executed in parallel. Each task has an owner, a target date, and a current finish trend. The team negotiates execution, not value. Every weekly status report opened with the area where maximum pressure was being applied. In one representative week the program identified a cluster of tasks worth twenty-three days of pull-in if executed in parallel. The tasks were specific — negotiate a single NDA, finalize a startup process flow, obtain preliminary tool footprint information, develop the facilities utility matrix — and each had an owner, a target date, and a current finish-date trend. The team did not negotiate the value of the pull-in. They negotiated whether they could execute the plan that delivered it. Peeling back the critical path -- 23 of 28 -- › Case study / Innovation Accelerated › › › Page 24 © 2026 lateralworks Figure 12. Critical-path peel-back. The planning system surfaces CP2 and CP3 alongside CP1 so the team understands the trade-offs in any pull-in move. If CP1 accelerates by more than the gap to CP2, CP2 becomes the new driver. The first critical path is rarely the only critical path. The planning system surfaced the second and third critical paths as well, so the team understood the consequences of acting on the first. If the first critical path accelerated by more than the gap to the second, the second became the driver. If the first slipped, the program had more time before the second mattered. The peel-back view turned acceleration from a single-track activity into an informed sequence of trade-offs. Honest learning-cycle accounting The hardest planning decision the program made was to include the learning cycles each team actually needed to solve the known technical problems — not the cycles the original schedule had budgeted. Doing this widened the gap to the build-target milestones in the short term. It was the right call. The widened gap defined what the acceleration program needed to close; the previous "build schedule" approach had hidden the real gap behind whatever happened to be ready on the appointed day. -- 24 of 28 -- › Case study / Innovation Accelerated › › › 06 Results Breakthrough technology, delivered on the reset plan Page 25 © 2026 lateralworks The development line delivered the breakthrough technology on the revised three-year target. The original eighteen-month plan was unachievable; the team’s first job was demonstrating that. Once a realistic target was in place, the acceleration program worked: the team closed the gap from the new baseline and hit the milestones it had committed to. -- 25 of 28 -- › Case study / Innovation Accelerated › › › Page 26 © 2026 lateralworks What "delivered" meant The development line produced functional prototype wafers from back-to-back lot runs at a four-week cycle time, with performance specs meeting targets across all three color emitters. First-generation yield and performance data was available to the product team on schedule, and risk production started against the year-over-year roadmap with the eighty-percent yield and performance targets in hand. What "delivered" did not mean The case study would be dishonest if it framed the outcome as smooth. It was not. Process maturity at transfer was lower than expected; the receiving fab needed time and management changes to reach the learning rate the program required; partner-relationship dynamics introduced friction that no planning system can eliminate. lateralworks documented these issues honestly to the client throughout the engagement, including hard recommendations to invoke step-in clauses and replace partner leadership when the rate of improvement at the fab fell below what the program needed. Some of those recommendations were taken; some were not. The team’s ability to deliver against the revised plan owes a lot to the recommendations that were taken. What the planning system left behind At handoff the client had a single integrated master schedule with weekly refresh discipline and explicit critical-path management; a working tool list driving the schedule, with cost and dependency data live; a chartered core team with clearly defined roles, operating cadence, and decision authority; a planning architecture demonstrated in production for more than three years; and a learning-cycle-aware approach to setting milestones that the product organization could apply to the rest of the inventions inside the larger program. -- 26 of 28 -- › Case study / Innovation Accelerated › › › 07 Reflections Three things that made it work Page 27 © 2026 lateralworks Three patterns explain why the program landed where it did, and they travel beyond this particular semiconductor engagement. -- 27 of 28 -- › Case study / Innovation Accelerated › › › Page 28 © 2026 lateralworks Three programs, one core team, end to end The single most consequential structural choice was that the same heavyweight core team owned the engagement across the facilities-and-tools phase, the process-transfer phase, and the engineering-acceleration phase. Most semiconductor programs hand off between phases — the facilities team finishes and goes home, the transfer team brings the process in and leaves, the engineering team takes over to qualify. Every handoff costs context, momentum, and the institutional memory of why earlier decisions were made. This program had no handoffs. The team that ordered the tools also ran the transfer also drove the acceleration. The cost of running a stable team for three-plus years was real. The cost of not doing it would have been far higher. One leader, colocated, on one mission The development line had a steering committee — the right one for the program, with the right authority — but the program ran on a core team that owned outcomes, owned the schedule, and made decisions inside its remit without waiting for the next escalation forum. That core team worked because it had one boss colocated at the receiving fab, full-time, for the duration; because every functional member was 100 percent dedicated to the program; and because the receiving fab’s engineering organization ran as a paired partner team with one interface and joint ownership of outcomes. One team. One mission. Inside a multinational with deep pockets and many stakeholders, this is what difference looks like. Make the gap visible — then live in the planning system Acceleration is impossible until the program agrees on the size of the gap it is accelerating against. The most consequential analytical work in the first months of the engagement was not the acceleration plan; it was the honest gap analysis that made the acceleration plan defensible. The original eighteen-month plan was not lying — it was answering the wrong question, namely "what date does the product team need?" The right question was "given the technical maturity of the transferred process and the rate at which the receiving fab can learn, when can we credibly deliver?" The two answers differed by years. Naming that difference is what unlocked the rest. The planning system that surfaced the gap then closed it. The macro-micro schedule with twice-weekly refresh, the tool-list and dependency tables, the critical-path peel-back, the Thursday pull-in cadence — none of it works as a deliverable. It works as an operating system the team uses every day. lateralworks did not hand the client a schedule; lateralworks ran the schedule alongside the team for three years, demonstrating what its weekly use looked like, until the planning architecture was theirs. The client’s program-management team carried it forward from there. The breakthrough technology was delivered. A research-grade process is now in production at a fab that did not exist three years earlier, inside a program system that the client has operated since handoff. The case study covers one of the thirty-eight inventions that had to converge for the larger product to ship — three programs run as one team, one mission, through a pandemic. It is also a working illustration of what fast time to market looks like when the structural choices are right at the start. -- 28 of 28 --

Client Projects·Case study·Semiconductors

Innovation Accelerated

advanced display fab and technology development

Core thesis. You cannot accelerate a program you do not see. The first job was making the program visible end-to-end — one integrated plan, one core team, one refresh cycle — and then closing the gap one critical-path week at a time.

May 17, 2026·28 pages

Read case study →Download PDF

› › Case study Sony PlayStation The 500K ASIC How a single-customer focus and the first cross-functional core team delivered the chip that defined a console generation in 24 months. In 1993 the home gaming market belonged to Nintendo and Sega, and every challenger that had tried to break in — Atari, 3DO, Philips, Commodore — had failed. Sony was the next challenger. The chip at the heart of their plan had not yet been built. LSI Logic took the design. lateralworks helped frame the program, stood up the first cross-functional core team in LSI’s history, and ran the planning cadence that pulled silicon out the door in 24 months. Case study series. LSI Logic Corporation — Sony Computer Entertainment first PlayStation (Sony CXD8530 / LSI CW33300). 1993 – 1995. 500,000-gate single-die ASIC. 5× leap in gate count on a new manufacturing process. First cross-functional core team in LSI history. Prepared by lateralworks FTTM methodology Engagement window 1993 – 1995 24-month delivery Online lateralworks.com Case study series © 2026 lateralworks Page 1 -- 1 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 2 Table of contents Sony PlayStation: The 500K ASIC Executive abstract 03 01 / The context 04 02 / The challenge 07 03 / The solution 08 04 / Why this structure outperforms 15 05 / Results and impact 16 06 / The lateralworks role 18 07 / Key takeaways 19 08 / Engagement summary 21 Sources 22 Core thesis. When a program demands more than the organization can deliver, the response must be structural. Pick one driving customer, integrate hardware and software workstreams under one empowered core team, and run the planning cadence at a frequency that surfaces gaps before they ossify. On the LSI 500K program, that combination delivered a 5× technology leap in 24 months against a hostile internal sponsor — and roughly doubled the company in a single year. -- 2 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 3 Overview Executive abstract In 1993, Sony Computer Entertainment was attempting to enter a home video game console market dominated by Nintendo and Sega and littered with failed alternatives — Panasonic's 3DO, the Atari Jaguar, the Philips CD-i. Sony's plan rested on a single chip: a custom 500,000-gate, single-die ASIC integrating a 32-bit RISC CPU, a 3D geometry engine, a motion decoder, DMA controllers, and bus interfaces on one piece of silicon. No semiconductor partner had attempted this scale of consumer-product integration. Competing offers required two chips [1, 2]. LSI Logic, then a sub-$500M ASIC company recovering from a multi-year financial downturn, won the design [1, 3]. The catch: LSI had only recently completed a 100K-gate ASIC. Sony's 500K was a 5× leap in gate count plus a new process, new design tools, a new cell library, and a new packaging approach — all to be delivered to volume production in 24 months. The LSI marketing organization initially defined a "super-product" combining requirements from seven vertical segments, estimated at five-plus years to build [4]. lateralworks advised the LSI executive team to abandon the super-product strategy. Pick one driving customer whose requirements cover ~80% of general market need, focus the program on that customer's success, expand to the remaining segments after launch. After internal debate, the team settled on Sony — over the initial objections of a marketing organization that dismissed gaming as a "toy" market [4]. lateralworks structured the program, stood up the first cross-functional core team in LSI history, established high-frequency refresh planning across hardware and software, ran weekly Voice-of-Customer with Sony, and coached the executive layer for the full two-year engagement. Engineering samples shipped to Sony 12 months ahead of the original system schedule. Volume production began 24 months after kickoff. The first PlayStation reached Japan on December 3, 1994 [5, 6]. The Sony engagement roughly doubled LSI Logic in a single year [4]. The 500K platform served as the foundation for seven years of LSI products. Every member of the core team — including John Daane, Brian Halla, Jean-Louis Bories, and Joe Zelayeta — went on to a senior executive or CEO role in Silicon Valley [7, 8, 9, 10]. 24 mo kickoff to volume production ~2× LSI Logic's size after one Sony year 12 mo Sony system development accelerated 7 yrs 500K platform life in market Core thesis. When a program demands more than the organization can deliver, the response must be structural: narrow the customer set to a single driving customer, integrate hardware and software workstreams under one empowered core team, and run a planning cadence frequent enough to confront reality before it ossifies. The 500K program proved this works on a 5× technology jump, with a new process node and a hostile internal sponsor. -- 3 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 4 01The context The gaming market on the cusp of the 3D era By 1993, the home video game market was on the cusp of a generational change. The 16-bit era — Nintendo's Super NES and Sega's Genesis / Mega Drive — was at its peak in installed base but already aging in capability. Together those two platforms held over 80% of the market [11, 12]. Behind them, a new cohort of 32-bit and 64-bit challengers was queuing up for the next generation. Failed challengers Several of those challengers had already launched and were failing in public. Panasonic's 3DO arrived in 1993 at a launch price of $699 — prohibitive for a mass-market console — and sold only about 2M lifetime units before being eclipsed [13]. The Atari Jaguar, marketed as the first "64-bit" console, launched in November 1993 to a thin software library and persistent developer complaints about its programming model; lifetime sales were under 250,000 units [14]. Philips' CD-i, Commodore's Amiga CD32, and a handful of others fared no better. None of them found a software ecosystem that could compete with the cartridge libraries of Nintendo and Sega. Sega had read this and was preparing the Saturn for a 1994 launch with a complicated dual-CPU architecture aimed at 2D sprite work [15]. Nintendo, in parallel, was working with Silicon Graphics on what would become the Nintendo 64, but their console would not ship until late 1996 — eighteen months after Sony [16]. Sony's entry Sony had taken a circuitous path into the gaming business. An earlier collaboration with Nintendo to build a CD-ROM peripheral for the Super NES had collapsed in 1991 [5]. Rather than abandon the work, Ken Kutaragi at Sony pushed internally for an independent console aimed squarely at 3D polygon rendering on CD-ROM media. The console he envisioned would require a system-on-a-chip integrating a 32-bit RISC CPU, a dedicated 3D geometry processor, a motion decoder for full-screen video, DMA controllers, and bus interfaces — all on a single die [1, 17]. Kutaragi met with most major semiconductor vendors in 1992 to find a partner. Some declined. Others said it could not be built on a single chip in the available time. LSI Logic's answer was different. The strategic frame. The home gaming market was about to shift from cartridge-based 2D platforms to CD-based 3D platforms. The shift was a single-generation window. Whoever arrived first with capable hardware and a strong third-party software ecosystem would set the standard for the next decade. Sony, the new entrant, had no margin for slip. -- 4 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 5 Figure 1. The fifth-generation console market, 1993–1996. Failed challengers (3DO, Atari Jaguar) in red; PlayStation launch milestones in orange. The Saturn launched in Japan one week ahead of PlayStation but lost the format war within 18 months; the Nintendo 64 arrived a full year after PlayStation and chose cartridges. Sources: Wikipedia, console market histories [11–16]. -- 5 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 6 Figure 2. The original PlayStation (SCPH-1000), launched in Japan on December 3, 1994. The unit shipped with the SCPH-1010 controller (shown). The chip at the heart of this console — the LSI Logic CW33300-based Sony CXD8530 — was the subject of the lateralworks engagement. LSI Logic in 1992-1993 LSI Logic Corporation, founded in 1981 by Wilf Corrigan as a pure-play ASIC company, was working through the toughest financial stretch of its history. Three of the previous four years had ended in red ink, with a one-time charge in 1992 driving a $110M loss [3, 18]. In response, Corrigan launched the CoreWare program in July 1992 — a library of pre-validated system-level building blocks (including a MIPS-derived RISC core, the CW33000) that customers could assemble into custom ASICs. CoreWare promised faster time-to-market and higher margins, and the program needed a landmark customer to prove the model [1, 3]. At the same time, Brian Halla, then running the LSI consumer products division, was working the Sony account. Halla later said of Kutaragi, "He's had more impact on my career than any other customer I've ever known" [1]. The Sony opportunity was the proof point CoreWare needed. The internal challenge was getting the LSI organization to agree. -- 6 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 7 02The challenge A 5× technology leap on a 24-month clock The 500K ASIC was named for its gate count — five times the largest ASIC LSI Logic had previously brought to production [4]. Every layer of the engineering stack had to be rebuilt at the same time. The team faced four compounding problems. A 5× gate-count leap LSI's prior generation topped out at approximately 100K gates. The Sony design called for 500K gates on a single die — roughly one million transistors at the 0.5-micron node [2]. The leap demanded new place-and-route tools, new timing-closure methodology, new cell libraries, and a new manufacturing process to be qualified in LSI's proto fab before volume production could begin. The integration target was unprecedented in consumer electronics: CPU, geometry engine, motion decoder, DMA, instruction cache, scratchpad cache, and bus controllers — all on one die [1, 2, 17]. A "super-product" definition that could not ship The LSI marketing organization had defined a product specification two years out that combined the requirements of seven distinct vertical markets: low-power mobile, networking, PC graphics, workstations, telecom, set-top boxes, and high-end EDP / supercomputing [4]. The intent was sound — get a single platform that could serve every important segment LSI cared about. The result was a product that could not be built. Internal estimates pegged the schedule at five-plus years, best case. Wilf Corrigan, the LSI CEO, was asking for two [4]. A hostile internal sponsor The marketing organization in Milpitas considered gaming a "toy" market unworthy of LSI's most advanced process. Its preferred driving customer was Cray Computer, the obvious choice for a workstation flagship. LSI's Design Center in Japan and the consumer products group both pushed for Sony because the gaming application would pull the chip through the company faster. The internal politics consumed weeks of executive attention before the decision was made [4]. No second-source safety net Sony told LSI that PlayStation's competitive position depended on shipping samples in time for system integration ahead of the Sega Saturn. A late chip meant a late console; a late console meant losing the 32-bit format war by default. LSI was the sole supplier. The initial assessment. The program as defined could not ship. The technology stack was unbuilt, the customer scope was too broad, the internal sponsor was conflicted, and the schedule was set by an external partner over whom LSI had no leverage. The first job was to change how the program itself was structured before any chip work could matter. -- 7 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 8 03The solution The FTTM driving-customer model lateralworks restructured the LSI 500K program around three reinforcing moves: a single-customer focus, an empowered cross-functional core team, and a high-frequency refresh-planning cadence. Together they formed the operating system for the program. Pick one driving customer The first FTTM principle applied to the 500K program was the driving-customer rule: identify the one customer whose requirements cover ~80% of general market need, focus the entire program on that customer's success, and expand to the remaining segments only after launch. The marketing organization's seven-segment super-product was the canonical failure mode: trying to satisfy every customer's wants in a constrained time window with constrained resources, and missing the market window for all of them [19]. Two candidates were evaluated. Cray Computer represented the high-end EDP requirement set, the most demanding technical specification but a thin volume base. Sony represented the consumer gaming requirement set, a larger volume opportunity with requirements that — once dissected — covered approximately 80% of the same general market need. Sony was also actively pushing for first-customer status and willing to commit to a Joint Development Agreement, which gave LSI a co-developed program with the depth of customer engagement the 500K design required. The decision went to Sony [4]. Stand up the first cross-functional core team LSI Logic had never run a program with a cross-functional core team. Engineering, design, marketing, libraries, CAD, fab process, and manufacturing each operated within their own functional reporting line. lateralworks worked with the LSI executive team to assemble the first such team in the company's history — seven members, each a senior subject-matter expert in their domain, each empowered to make commitments on behalf of their function. The team included names that would later run or help build other Silicon Valley semiconductor companies: John Daane — then managing IP, CAD, and libraries at LSI; later CEO and Chairman of Altera (2000-2015) [7]. Brian Halla — then EVP of LSI Logic Products and the program's customer lead and senior accountable executive; later CEO of National Semiconductor (1996-2009) and Cisco board director [8, 9]. Jean-Louis Bories — the program's Project Monarch and a senior LSI engineering leader; later an active early-stage technology investor through the Band of Angels [10]. Joe Zelayeta — then leading process technology and U.S. wafer fab operations; later EVP of Worldwide Operations at LSI Logic, and the architect of LSI's Gresham, Oregon fab [20, 21]. The team was co-located in Milpitas and operated under a single Project Monarch — Jean-Louis Bories — with authority over technical, schedule, and customer-facing decisions. Brian Halla served as the program's customer lead and senior accountable executive, working the Sony account and providing executive cover for the structural shifts the program required. Every team member treated the 500K as their primary job. -- 8 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 9 Section 03 (continued) Refresh planning and lateral integration High-frequency refresh planning The macro plan was reprogrammed end-to-end and updated weekly. The micro plans — at the workstream level — were refreshed at a high frequency across hardware and software. This cadence pushed the visibility of gaps and slips far enough forward in the program that the team could act on them before they cascaded. It also forced lateral integration across hardware, software, fab process, and libraries: the schedule data itself became the integration point, not a downstream report. Lateral integration across hardware and software The 500K chip was useless without the software stack Sony was building around it. lateralworks worked with the core team to integrate every aspect of Sony's hardware and software development into the LSI program plan. Real-time operating system milestones, library development, the C compiler and debugger toolchain (delivered with help from Psygnosis and SN Systems on the Sony side), engineering-sample readiness, and fab process qualification all sat on the same integrated schedule [5, 22]. When a software milestone slipped, the silicon team saw it the same day. Voice of Customer, weekly A weekly Voice-of-Customer process ran for the duration of the program. Sony's requirements were elicited and re-elicited rather than frozen at kickoff. lateralworks coached the LSI executive layer through the discipline of separating Sony's wants from the how of solving them — a distinction that, when collapsed, produces products that hit specifications nobody asked for. Where Sony's wants exceeded what 0.5-micron silicon could deliver in 24 months, the gaps were negotiated back to Sony as explicit trade-offs rather than absorbed silently as overruns. Outcome: a single chip where competitors needed two LSI's CoreWare architecture — supplemented by Sony-specific blocks for the Geometry Transformation Engine, the Motion Decoder, and the on-die scratchpad — delivered the entire PlayStation main processor on a single die. Competing offers to Sony had required two chips; LSI's single-chip integration was decisive in the 1993 selection [1]. The Sony CXD8530 / LSI CW33300 ASIC ran at 33.87 MHz, delivered 30 MIPS sustained performance, and integrated the components detailed in the figures that follow [2, 17]. -- 9 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 10 Section 03 (continued) Voice of customer — what does Sony want? The question every product team has to answer is the question LSI had to answer for the 500K program: what does the customer want, and when do they want it? Sony was targeting a 1994 console launch into a market window that would close within eighteen months. If the PlayStation was a ~1995 product, what made the LSI 500K ASIC a competitive product at that moment? That answer drove every architectural and process choice that followed, and it was the question lateralworks ran with the LSI core team for two years. The difference between a want and a how. Wants are the customer’s. Hows are the supplier’s. Sony told LSI what the console had to do: 3D polygon rendering on CD-ROM media, motion-decoded full-screen video, a programming model third-party developers could ship against, and a price point Sony could put on the shelf next to Saturn. How to deliver each of those — a 32-bit RISC core, a dedicated Geometry Transformation Engine, the MDEC, the 0.5-micron process, the cell library, the packaging — was LSI’s problem to solve. Teams often collapse the two and jump straight to the how. The product gets built around what the technology can do today, not around what the customer needs when the product ships. When the product reaches the market it fails — wrong product at the right time, or worse, wrong product late. Customers tell you what they want; it is the supplier’s job to figure out how to deliver it. Top-down wants, bottom-up hows. The discipline is to define the wants top-down, then determine the hows that close them, then assess the gaps. The trap is to do the product definition bottom-up, based on what is possible and known today. Products defined that way miss what the customer wants because the technology speaks louder than the requirement. Starting top-down with the wants — and explicitly identifying the gaps — gave LSI the basis to go back to Sony and negotiate trade-offs, or to ask Sony to assume some of the risk. Then the wants and the hows balance. The challenge for the team was to predict what the requirements would be two years out, when Sony’s console reached the market. This is why a driving customer like Sony was critical — to share that forecasting risk with someone who actually knew where the market was going. The weekly Voice-of-Customer process kept the wants alive and the gaps honest for the duration of the program. -- 10 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 11 Section 03 (continued) Pick the driving customer LSI did not develop the 500K only for Sony. The 500K platform had to serve a broader market — and ultimately did, across seven vertical segments over seven years. But the platform shipped first to one driving customer, on one schedule, with one set of requirements. The second failure teams make, after jumping straight to the how, is the inverse failure of scope: trying to design a product for many customers with many requirements at once, then expanding the timeline until the market window closes. They miss every segment because they couldn’t deliver any of them in the constrained time with the constrained resources available. Pick a market leader as the driving customer. The FTTM principle is to find a driving customer. As long as that customer is a market leader in their segment, you can rely on them to drive the market’s requirements. The followers in their segment will go the way the leader goes — they will follow, so the leader sets the requirements for everyone. Sony was that leader for the CD-based 3D console market that did not yet exist; the PlayStation defined the category, and the rest of the segment followed Sony into it. Pat Brockett, then at National Semiconductor, put it to lateralworks once in plain English [27]: “Focus on the market leader and the rats and dogs will follow.” — Pat Brockett, National Semiconductor [27] The order matters: focus first, expand second. The 500K platform shipped to Sony first. After volume production, the same platform expanded to networking, PC graphics, workstations, telecom, set-top boxes, mobile, and high-end EDP — the seven segments the original super-product specification had tried to address simultaneously. The order had been inverted: focus first, expand second. The expansion succeeded because the first customer was already a market winner, creating pull through the platform. -- 11 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 10 Figure 3. PlayStation SCPH-1000 motherboard — the PU-7 board, first-generation PlayStation hardware. The large chip at center-right is the Sony CXD8530BQ, the LSI Logic CW33300-based main processor; the "LSIL L9A0025" marking visible on the chip identifies LSI Logic as the manufacturer. This single ~1M-transistor die integrates the 32-bit MIPS R3000A CPU, the Geometry Transformation Engine, the Motion Decoder, and DMA controllers — work that competing offers had required two chips to perform. Surrounding chips include the CXD8514Q GPU, CXD2922Q sound processor, NEC system DRAM, and Samsung VRAM. Page 12 -- 12 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 11 Figure 4. The 500K ASIC at a glance. LSI Logic CW33300-based core (Sony CXD8530), 0.5-micron CMOS, ~1 million transistors. The chip integrated the CPU, geometry math engine, motion decoder, DMA controller, bus controllers, and on-die cache on a single die — a level of consumer-product integration that no other vendor had committed to deliver in the available time. Sources: PlayStation technical specifications (Wikipedia); Copetti, "PlayStation Architecture"; LSI Logic history [1, 2, 17]. Page 13 -- 13 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 12 Strategic pivot Seven segments collapsed to one driving customer Figure 5. The 500K program at a glance. The marketing-defined super-product combined requirements from seven vertical segments into a single specification that would have taken five-plus years to build. The FTTM intervention replaced it with a single-customer program for Sony, whose requirements covered ~80% of the general market need. Volume production arrived in 24 months. Sony's system development was accelerated by 12 months because engineering samples arrived a year ahead of schedule. The 500K platform subsequently expanded to all seven segments and powered LSI's product line for seven years. Page 14 -- 14 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 13 04Why this structure outperforms Super-product vs. driving-customer team The marketing-led "super-product" approach and the FTTM driving-customer model differ in kind, not in degree. Below is the structural comparison as it played out on the 500K program. # Dimension Super-product approach FTTM driving-customer team 1 Scope Combined requirements from 7 segments into one super-product specification. One driving customer (Sony) covering ~80% of general market need; expand later. 2 Schedule 5+ years to build, by internal engineering estimate. 24 months from kickoff to volume production. Engineering samples 12 months ahead of Sony's system schedule. 3 Team structure Functional reporting lines. Engineering, design, CAD, fab process, marketing — each separate. First cross-functional core team in LSI history. Seven senior members, co-located, single Project Monarch. 4 Sponsorship Marketing-defined; consumer gaming dismissed as "toy" unworthy of leading-edge silicon. CEO-sponsored after escalation. Japan design center and consumer products group pushed for Sony. 5 Customer engagement Specification handed to engineering as frozen requirement; little ongoing dialogue. Weekly VOC with Sony for two years. Gaps negotiated back as explicit trade-offs. 6 Integration Hardware and software treated as separate workstreams; sequential handoffs. Lateral integration. HW, SW, tools, libraries, fab process, and packaging on the same schedule. 7 Planning cadence Monthly status with quarterly executive reviews. Macro plan refreshed weekly; high-frequency refresh planning across hardware and software workstreams. 8 Risk posture Optimized for stability that never came. New process, tools, libraries, packaging all assumed to work. Designed for instability. Schedule simulates alternative paths whenever a workstream shifts. 9 Outcome on launch Would have missed Sony's system schedule by 12+ months. Likely missed the 32-bit console generation entirely. 24 months to volume production. PlayStation launched Dec 3, 1994 — and won the format war by 1996. 10 Outcome on platform Super-product as defined would have served all 7 segments — if it had shipped. 500K platform shipped to Sony first, expanded to all 7 segments over the next 7 years. The structural pattern. The FTTM model is faster because the system surfaces gaps early, forces lateral integration across functions, and concentrates the team's attention on one customer rather than seven theoretical segments — not because the people on the team are smarter than anyone else. Page 15 -- 15 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 14 05Results and impact A market created, a company transformed Schedule performance Engineering samples shipped to Sony approximately 12 months ahead of the system schedule Sony had built around them, enabling Sony to compress its own development cycle by a full year. Volume production began 24 months after program kickoff. The original LSI marketing super-product, had it been pursued, would have taken five-plus years by internal engineering estimate [4]. Financial impact At the time of the Sony win, LSI Logic was a sub-$500M company. The Sony engagement roughly doubled the company in a single year [4]. The market reaction was decisive: LSI's stock price moved from $4 7/8 to $126 over the period bracketing the design win and ramp [1]. By the first quarter of 1995, LSI had recorded its tenth consecutive quarter of revenue growth and posted $45.3M in quarterly net income — twice the annual profit of any year before CoreWare [3, 18]. Market impact The first PlayStation reached the Japanese market on December 3, 1994, one week after the Sega Saturn [5]. Initial Japanese shipments of 100,000 units sold out the day they reached stores [5]. Sony shipped its one-millionth PlayStation by May 1995. The North American launch on September 9, 1995 sold over 100,000 units in two days, with 17 launch titles available — against the Saturn's six [6, 23]. By November 1995, PlayStation was outselling Saturn in the United Kingdom three to one [5]. By the end of 1995, PlayStation held 20% of the American video game market [24]. Sega never recovered. Saturn sold 9.26M units worldwide before being discontinued, while Sega exited the console hardware business after the Dreamcast in 2001 [15]. The Nintendo 64, arriving in late 1996, chose cartridges over CD-ROM and ceded the cinematic-game ecosystem to PlayStation; Final Fantasy VII, originally planned for Nintendo, moved to PlayStation and became the title that brought RPGs to the mass market [13, 16]. The original PlayStation went on to ship 102M units lifetime — the first console ever to reach that threshold [5, 25]. ~2× LSI Logic doubled in a single year $4.875 → $126 LSI stock price over the engagement window 102M Lifetime PlayStation units shipped 20% U.S. console market share by end of 1995 Page 16 -- 16 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 15 Section 05 (continued) Platform leverage and lasting influence Seven years of platform leverage The 500K technology stack — the CoreWare integration model, the 0.5-micron process, the cell library, the design methodology, the packaging approach — served as the foundation for LSI's product line for the next seven years. Once Sony was in volume, the same platform was adapted to all seven of the vertical segments the original marketing super-product had tried to address in a single specification. The order had been inverted: focus first, expand second. The expansion succeeded because the first customer was already a market winner creating pull through the platform [1, 3]. Career outcomes for the core team Every member of the 500K core team went on to a senior executive or CEO role in Silicon Valley. John Daane became CEO and Chairman of Altera in November 2000 and ran the company through its $16.7B acquisition by Intel in December 2015; he received the Robert N. Noyce Award from the Semiconductor Industry Association in 2014 [7, 26]. Brian Halla became Chairman, President, and CEO of National Semiconductor in May 1996 and ran it until 2009, joining the Cisco board of directors in 2007 [8, 9]. Joe Zelayeta rose to EVP of Worldwide Operations at LSI Logic and remained at LSI until 2006, including responsibility for the joint TSMC 0.13-micron process development [20, 21]. Jean-Louis Bories continued as a senior engineering leader at LSI and is today an active early-stage technology investor through the Band of Angels [10]. LSI Logic at the end of the decade LSI Logic's revenue crossed $1B in 1995 — the same year as PlayStation's North American and European launches [3]. CoreWare became the company's flagship methodology, and the Sony engagement was the proof point that anchored every subsequent sales conversation. The 500K program transformed LSI from a gate-array vendor into a system-on-chip company and set the template the industry would follow for the next decade [1, 3, 18]. Outcome. A program initially specified as a five-year, seven-segment super-product shipped to a single driving customer in 24 months — and went on to serve all seven original segments anyway, with seven years of platform leverage and a transformed sponsor company. Page 17 -- 17 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 16 06The lateralworks role Program architect and core-team coach lateralworks served as the program's external planning and acceleration partner for the full two-year engagement, embedded as a member of the cross-functional core team. The role covered six functions. Reframed the strategic question. Reset the program around a single driving customer (Sony) whose requirements covered ~80% of the general market need, replacing the seven-segment super-product specification that could not have shipped in time. Structured the program. Programmed the initial macro plan end-to-end. Built the integrated master schedule covering hardware, software, fab process, CAD, libraries, packaging, and Sony system integration as a single dependency graph. Stood up the first cross-functional core team in LSI history. Seven senior subject-matter experts, co-located, with a single Project Monarch. Each member spoke for and committed on behalf of their function. Established the refresh-planning cadence. Macro plan refreshed weekly, with high-frequency micro-plan refresh across hardware and software workstreams. The schedule data itself became the integration point. Ran Voice of Customer with Sony, weekly. Distinguished Sony's wants from the hows of solving them. Negotiated gaps back as explicit trade-offs instead of absorbing them as overruns. Sustained the dialogue for the full two years. Coached the executive layer. Worked with Wilf Corrigan, Brian Halla, and the LSI executive team through the strategic choice of Sony over Cray, and through the structural shift from functional reporting to cross-functional core-team execution. Special expertise. lateralworks works on programs that are hard to plan — where the requirements shift, the process is unproven, and the schedule has to surface trouble early so the team can act on it. Page 18 -- 18 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 17 07Key takeaways The reusable pattern The 500K program demonstrates a set of principles that apply directly to any complex, time-critical product development program — semiconductor, software, hardware, or integrated systems — where schedule compression, technical uncertainty, and a hostile internal sponsor converge. Find the driving customer. Identify the one customer whose requirements cover ~80% of the general market need. Focus the entire program on that customer's success. Expand to other segments after launch. "Focus on the market leader and the rats and dogs will follow." — Pat Brockett, National Semiconductor [27]. Refuse the super-product trap. Combining requirements from many customers in a single specification feels safe and inclusive. It produces products that miss the market window for every segment they were meant to serve. Time-to-market beats feature-coverage. Separate wants from hows. Customers tell you what they want. The supplier figures out how to deliver it. Teams that jump straight to the how miss the want, and the product fails on launch. Top-down wants first, bottom-up hows second, gaps negotiated explicitly. Stand up one cross-functional core team. Senior subject-matter experts, co-located, single Project Monarch, 100% dedicated. No functional hierarchy inside the team. The program is the team's primary job, not an allocation against their day job. Run the schedule as the operating system. The integrated master schedule is the organizational framework, the simulation engine, the early-warning system, and the interface-management tool — not a status report. Refresh it at the cadence the program demands. Integrate laterally across hardware, software, tools, and process. Silicon, system software, design tools, cell libraries, fab process, and packaging belong on the same dependency graph. Sequential handoffs are how late chips ship. Sustain Voice of Customer for the duration. A specification frozen at kickoff is obsolete by the third month of a two-year program. Run weekly VOC and renegotiate trade-offs as constraints clarify. Expect the host organization to resist. A program that breaks the prevailing functional model will generate internal resistance proportional to its strategic importance. Plan for the escalation. Get the CEO's sponsorship in writing. The pattern is reusable. A single driving customer, an empowered cross-functional core team, an integrated master schedule, and a high-frequency planning cadence consistently beat siloed execution on time-critical programs. The 500K work proved it against a 5× technology jump on a 24-month clock with a hostile internal sponsor. Page 19 -- 19 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 18 Challenge, solution, and outcome Program summary Figure 6. Detailed program summary. The challenge column captures the four compounding problems the 500K program faced at kickoff: a 5× gate-count leap, a seven-segment super-product specification, new design tools and libraries, and a hostile internal sponsor. The solution column captures the FTTM intervention: a single driving customer, the first cross-functional core team in LSI history, lateral integration across hardware and software workstreams, and high-frequency refresh planning. The outcome column captures the results: 24 months to volume production, 12 months of acceleration for Sony's system development, LSI Logic roughly doubled in a single year, and a platform that powered LSI's product line for the next seven years. Page 20 -- 20 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 19 08Engagement summary Project, scope, role, and outcomes Project LSI Logic 500K-gate ASIC (CW33300 / Sony CXD8530) for Sony Computer Entertainment's first PlayStation Client LSI Logic Corporation End customer Sony Computer Entertainment Type New product development — single-die system-on-chip ASIC Duration 2 years (1993–1995) Problem Deliver an unprecedented 500,000-gate, single-die ASIC (MIPS R3000A core + GTE + MDEC + DMA + I/O on one die) to volume production in 24 months — a 5× leap in gate count on a new manufacturing process, new design tools, new cell library, and new packaging, against an LSI marketing organization initially advocating a five-year, seven-segment "super-product" specification. Solution Replace the super-product strategy with the FTTM driving-customer model: focus the entire program on Sony as the single driving customer (~80% of general market requirement coverage). Stand up the first cross-functional core team in LSI's history. Run high-frequency refresh planning across hardware, software, tools, libraries, and fab process. Maintain weekly Voice-of-Customer with Sony for the full two-year engagement. lateralworks role Programmed the initial macro plan end-to-end. Stood up the cross-functional core team. Established the high-frequency refresh-planning cadence across hardware and software. Coached the LSI executive layer through the Cray-vs-Sony strategic choice and through the structural shift to cross-functional execution. Ran Voice of Customer with Sony for two years. Trained the internal program management capability that LSI would carry into subsequent programs. Outcomes Engineering samples to Sony 12 months ahead of the original system schedule. Volume production in 24 months. PlayStation launched December 3, 1994. The Sony engagement roughly doubled LSI Logic in a single year. LSI stock $4 7/8 → $126 over the engagement window. The 500K platform served as the foundation for LSI's product line across seven years and hundreds of customer applications. Every core-team member went on to a senior Silicon Valley executive or CEO role. Page 21 -- 21 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 20 Sources References [1] Costlow, T. "Playstation creator courts serious fun." EE Times, March 1999. Account of Sony's 1992-1993 search for an ASIC partner; LSI Logic's CoreWare-based single-chip integration; LSI stock movement from $4 7/8 to $126 over the engagement window. https://www.eetimes.com/playstation-creator-courts-serious-fun/ [2] "PlayStation technical specifications." Wikipedia, last accessed May 2026. Documents the LSI CoreWare CW33300-based core (Sony CXD8530), 0.5-micron process node, ~1 million transistors, 30 MIPS operating performance, and 33.8688 MHz clock. https://en.wikipedia.org/wiki/PlayStation_technical_specifications [3] "LSI Logic Corporation — Company History." FundingUniverse. Documents the 1992 CoreWare program launch, the 1991-1992 financial downturn ($110M one-time charge in 1992), and the post-CoreWare recovery (ten consecutive quarters of revenue growth into Q1 1995, $45.3M quarterly net income). https://www.fundinguniverse.com/company-histories/lsi-logic-corporation-history/ [4] lateralworks. "LSI Logic 500K program — internal client account." Program narrative drawn from lateralworks engagement records, 1993-1995. Includes the seven vertical segment specification, the Cray-vs-Sony decision, the $700M first-year revenue figure, and the core team composition. [5] "PlayStation (console)." Wikipedia, last accessed May 2026. Documents the December 3, 1994 Japan launch; the sell-through of 100,000 units in two days; the cancellation of the Sony-Nintendo CD-ROM peripheral; and the three-to-one UK lead over Saturn by November 1995. https://en.wikipedia.org/wiki/PlayStation_(console) [6] "Sony PlayStation: The first 20 years." TechRadar, 2014. Documents the September 1995 North American launch at $300, the May 1995 one-million-units-in-Japan milestone, and the simultaneous UK launch at £299. https://www.techradar.com/news/gaming/consoles/sony-playstation-the-first-20-years-249792 [7] "John Daane, Chief Executive Officer, Altera." Altera corporate biography. Documents Daane's 15-year career at LSI Logic (1985-2000) starting as a summer intern and ending as EVP of the Communications Products Group with responsibility for ASIC technology development and the computer, consumer, and communications divisions. [8] "Cisco Appoints Brian L. Halla, Chairman and Chief Executive Officer of National Semiconductor Corporation, To Its Board Of Directors." Cisco press release, January 17, 2007. Documents Halla's career: 14 years at Intel, senior roles at LSI Logic culminating as EVP of LSI Logic Products, then Chairman / President / CEO of National Semiconductor from May 1996. [9] "Halla, Brian L. oral history." Computer History Museum, 102746664. Oral-history transcript covering Halla's career at Intel, LSI Logic, and National Semiconductor. [10] "Jean-Louis Bories — LinkedIn / Band of Angels membership." Public professional record. Documents post-LSI role as a Band of Angels member specializing in early-stage venture investing across semiconductor, networking, and biotech. [11] "Console war." Wikipedia, last accessed May 2026. Documents the 1994-1995 contraction in the video game industry (17%-19% year-over-year revenue declines per NPD Group), Sega's late-1994 Saturn launch, and Sony's December 1994 entry. https://en.wikipedia.org/wiki/Console_war [12] "What was the popular video game console from 1992 to 1995 in the western world?" Quora. Industry summary documenting SNES and Sega Genesis as the dominant 16-bit platforms during the period, holding combined 80%+ market share before the 32-bit transition. [13] "1990s Video Game Consoles: Console Wars, 3D Revolution & the Rise of Sony." Video Game Console Library. Documents 3DO launch at $699 (~2M lifetime units), Atari Jaguar lifetime sales under 250,000 units, and the Final Fantasy VII platform shift from Nintendo to PlayStation. https://www.videogameconsolelibrary.com/90s-game-consoles/ [14] "Atari Jaguar." Wikipedia, last accessed May 2026. Documents the November 1993 launch at $249.95, the $500M IBM manufacturing deal, and Atari's 1995 revenue decline from $38.7M to $14.6M. https://en.wikipedia.org/wiki/Atari_Jaguar [15] "Sega Saturn." Wikipedia, last accessed May 2026. Documents the November 22, 1994 Japan launch, the Hitachi SH-2 dual-CPU architecture, the late addition of a second video display processor in early 1994 in response to PlayStation specifications, and 9.26M lifetime worldwide units. https://en.wikipedia.org/wiki/Sega_Saturn [16] "Nintendo 64." Wikipedia, last accessed May 2026. Documents the Silicon Graphics partnership announced August 1993, the cartridge-vs-CD-ROM decision, and the June / September 1996 launches in Japan and North America. https://en.wikipedia.org/wiki/Nintendo_64 Page 22 -- 22 of 23 -- › Sony PlayStation: The 500K ASIC › › › © 2026 lateralworks Page 21 [17] Copetti, R. "PlayStation Architecture: A Practical Analysis." copetti.org. Detailed technical breakdown of the CXD8530 SoC, the LSI CoreWare lineage, and the MIPS R3000A relationship. https://www.copetti.org/writings/consoles/playstation/ [18] "LSI Logic." Wikipedia, last accessed May 2026. Documents the July 1992 CoreWare announcement and the 1993 Sony Computer Entertainment selection of LSI Logic as ASIC partner: "LSI's CoreWare could do it, while other offers made to Sony needed two chips." https://en.wikipedia.org/wiki/LSI_Logic [19] lateralworks. "Voice of Customer: differentiate wants from hows." lateralworks ideas archive. Statement of the FTTM principle distinguishing customer wants from supplier hows. https://lateralworks.com/ideas/voc-differentiate-wants-from-hows [20] "Joe Zelayeta Named Executive VP, Worldwide Operations." EE Times, September 1997. Documents Zelayeta's career at LSI Logic including responsibility for silicon process technology, U.S. wafer fab operations, and the Gresham, Oregon fab. [21] "LSI Logic and TSMC to Team on Process Technology and Manufacturing." TSMC press release, April 4, 2001. Documents Zelayeta's role as EVP of Worldwide Operations on the joint 0.13-micron process agreement with TSMC. https://pr.tsmc.com/english/news/2326 [22] "Playstation.txt." raphnet.net. Account of the PSY-Q development system, SN Systems' Andy Beveridge and Martin Day, and the C compiler / debugger toolchain that Sony shipped with the development kit. [23] Sasson, G. "For 30 years, the PlayStation has marked the biggest step forward in console gaming." The National, July 2024. Documents the 20% U.S. market share at end of 1995. https://www.thenationalnews.com/arts-culture/2024/07/07/playstation-ps1-history/ [24] "PlayStation | Console and Games." Britannica, last accessed May 2026. Documents the milestone of 100M lifetime units shipped — the first console ever to reach that threshold — by 2005. https://www.britannica.com/topic/PlayStation [25] "List of best-selling game consoles." Wikipedia, last accessed May 2026. Documents PlayStation lifetime sales of 102.49M units. https://en.wikipedia.org/wiki/List_of_best-selling_game_consoles [26] "Altera CEO John Daane to receive Robert N. Noyce Award." Semiconductor Digest, October 2014. Documents Daane's 2014 Noyce Award from the Semiconductor Industry Association. https://sst.semiconductor-digest.com/2014/10/altera-ceo-john-daane-to-receive-robert-n-noyce-award/ [27] Brockett, P. (National Semiconductor). Quoted in lateralworks account of the LSI 500K program. Patrick Brockett spent 22 years at National Semiconductor (1979 – 2001), most recently as Executive Vice President and General Manager of the Analog and Wireless Group. He later served as CEO of Zarlink Semiconductor (2001 – 2005), CEO of Summit Microelectronics (acquired by Qualcomm for $350M), and is currently CEO of Celera Semiconductor. Sources: EE Times, The Wall Street Transcript, Celera press release October 2023. https://www.eetimes.com/brockett-named-president-ceo-at-summit-micro/ Program narrative based on lateralworks account. Public details cited above where available; the LSI Logic 500K engagement preceded broad press coverage of the chip and is therefore documented in greater detail by lateralworks internal records than by public sources. Page 23 -- 23 of 23 --

Client Projects·Case study·Semiconductor

Sony PlayStation

The 500K ASIC

Core thesis. When a program demands more than the organization can deliver, the response must be structural. Pick one driving customer, integrate hardware and software workstreams under one empowered core team, and run the planning cadence at a frequency that surfaces gaps before they ossify.

May 13, 2026·23 pages

Read case study →Download PDF

© 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

Read case study →Download PDF

© 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

Read case study →Download PDF

© 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

Read case study →Download PDF

© 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

Read case study →Download PDF

© 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

Read case study →Download PDF

© 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

Read case study →Download PDF

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.