Overview

Abstract

Late programs rarely lack effort; they lack new thinking. In 2014 a major disk-drive storage company with extremely high volume and aggressive time-to-market pressure had several of its most important development programs trending late at the same time. One roadmap-defining product family was roughly ten months behind its first major deliverable. A flagship drive program was three months late and drifting further. An advanced recording-technology effort carried a six-week gap with a progressive slipping trend and, worse, a plan that assumed its experiments would work the first time. Each team had already spent months trying to pull the schedule in. Each had concluded, reasonably, that everything that could be done was being done. This paper documents what happened when those teams were taken offsite, one day per program, and run through the lateralworks challenge process — a structured application of Edward de Bono’s lateral thinking to engineering schedules. The process is simple to describe: make the schedule gap visible and undeniable, surface the assumptions that define the current plan, select the ones that actually control the outcome, ask why each is believed, and then generate alternatives with the constraints deliberately switched off. Ideas are harvested, treated, and driven into the schedule within seven days, while the reasoning is fresh and the team still owns it. The three workshops produced three different kinds of breakthrough. The Watson team challenged two technology-gating decisions, modeled each alternative directly in the schedule, and found a combination worth roughly fifteen months of pull-in; it then rebuilt its roadmap around the result within one week. The Rainier team discovered that a headline technology everyone treated as mandatory was desirable but not required, removed it along with the gating components it dragged in, and moved its desktop deliverable from October to July and its enterprise deliverable from December to August. The Slider Bias team, facing unknowns no schedule trick could remove, restructured its experiments to double its learning cycles inside the same window — trading a marginal three-week pull-in for a structural change in how fast it could learn, which later matured into a four-month pull-in of the learning-complete date. The paper explains the challenge process itself, then walks through each engagement: the situation before the workshop, what was done in the room, and what the team achieved afterward — with the original workshop photographs, flip charts, and schedule trend charts as evidence. It closes with the patterns the three teams shared, and the reason the method transfers: none of the breakthroughs came from added people or money, and none compromised a requirement. They came from permission to re-examine what everyone already believed.

The method — The challenge process

Every project plan is a stack of assumptions wearing the costume of facts. Most are invisible to the team that holds them — not because they are hidden, but because they have been true for so long that nobody remembers deciding them. The challenge process exists to drag those assumptions into daylight, test whether their reasons still hold, and use the ones that fail as openings for new ideas. The method descends from Edward de Bono’s lateral thinking, which lateralworks adapted for engineering programs over three decades of consulting work. De Bono’s challenge technique starts from a deliberately non-threatening question: not “this is wrong,” but “why is this done the way it is done — and are the reasons still valid?” The question matters because challenge is never an attack. It works best with cohesive teams who are given explicit permission to break free from the accepted way of doing something, and it fails in rooms where an idea can be shot down before it has lived for thirty seconds. Ed Catmull describes the same precondition at Pixar: people who feel unsafe suggesting ideas do not suggest them, and the organization loses exactly the ideas it needs most.

Two moves Why challenge works on schedules Applied to a late program, the challenge process makes two moves that ordinary schedule reviews never make. First, it reframes the schedule gap. A gap normally functions as an accusation — proof the team is late — and teams respond to accusations by defending estimates or negotiating requirements downward. In a challenge workshop the gap is repurposed as fuel: it creates the urgency to find solutions, and the facilitators take the two easy exits off the table. The team may not prove it is late, and it may not relax requirements to meet the date. What remains is the hard, productive question: what would have to be true for this schedule to close without compromising the goals? Second, it separates idea generation from idea evaluation. During the generative phase the thinking is deliberately unconstrained (green lights only, no “red-lighting” of ideas) because evaluation reflexes are precisely the machinery that keeps a team inside its current frame. Constraints re-enter later, during harvest and treatment, when each surviving idea is shaped, strengthened, and corrected against reality. The sequence sounds trivial. It is the difference between a brainstorm that produces wall decorations and a workshop that produces a new baseline schedule. Figure 1. The challenge process. The generative half runs unconstrained; constraints are re-applied only after ideas exist. Obvious items are done or cut on the spot, and the cycle refreshes every two to three months. Surfacing the current thinking A workshop begins days before the room. Team members brainstorm their “current thinking” in advance: every belief that shapes the plan, written as short declarative statements on cards. The facilitation gives the statements a grammar, because vague worries cannot be challenged. Four sentence stems do most of the work: it is essential that… (what must always be included), …dominates our thinking (what ideas control us), we must avoid… (what we are steering around), and we must stay within… (the boundary conditions we accept). The taxonomy — essential factors, dominant ideas, avoidance factors, boundaries — comes

straight from de Bono’s toolkit, and it forces both explicit assumptions and the more dangerous implicit ones onto paper. Assumptions are not right or wrong at this stage. The aim is only to become aware of them, because an assumption nobody has written down is an assumption nobody can challenge. Figure 2. Workshop in progress: the team nominates assumptions to challenge with colored dots. Roughly eight assumptions typically survive the vote. lateralworks engagement archive. Select, ask why, do or cut The full assumption wall usually holds forty or more statements — far too many to work. Dot voting cuts it to a short list of roughly eight. Each survivor then faces the same three questions: Why do we think this? What are the reasons? Are the reasons still valid? Some items collapse immediately into action — if it can be done now, do it; if it can be cut now, cut it — and go to a Do/Cut chart. The interesting ones are those whose reasons have quietly expired: a spec inherited from a previous product, a boundary set by a supplier constraint that no longer exists, a “must” that turns out to be a preference with seniority. Those become the openings. For each, the team brainstorms how the thing could be done differently, and the ideas are captured with their reasoning intact.

Challenge principle What the gap is for “Do not use the gap to prove you are late. Use it to force new thinking.” Facilitation principle, challenge workshops lateralworks program archive, 2014

Case one — Watson: a roadmap rebuilt in a week

Watson was the program that defined the client’s next product family, and it was in the worst shape of the three: roughly ten months late against its first major deliverable, on a schedule the team itself rated high risk. The plan stacked too many new technologies into the same first product — a new controller, a new unified firmware architecture, a new recording mode, a new drive-security feature — so every immature element gated every other one. Three months of performance-to-schedule history and repeated acceleration attempts had produced no solution. The working assumption inside the team had hardened into fatalism: the project was late, little could be done, and the technical risks meant it would probably get later. Figure 7. The Watson challenge workshop: schedule on the projector, challenge charts taped across the wall. lateralworks engagement archive.

In the room Challenging the gates The workshop followed the standard arc — assumptions, dot vote, why, ideas — but what distinguished Watson was where the votes landed. The team’s short list converged on the technology-gating decisions embedded in the first product definition. Five “big hitters” came out of the challenge round: do not gate the program on the new controller silicon; decouple the new unified firmware architecture from the first release; drop the new drive-security feature from the initial release; make the first product the 3.5-inch desktop drive rather than the hardest form factor; and do not attempt the mobile variant first. Each of these had lived in the plan as a requirement. Under the question “are the reasons still valid?” each turned out to be a choice. Figure 8. Watson challenge charts: release-content assumptions worked through alternatives — using the proven architecture as a base, first product on the desktop platform, replacing a phase with existing programs. What was done. Rather than debate the ideas, the team modeled them. Each acceleration idea was explored for practicality with management constraints deliberately removed, then implemented individually in the schedule to measure its real pull-in potential. Taken one at a time the results were sobering — a few days each, under two weeks in the best case. The breakthrough came from combination: challenging the new controller in the first test vehicle (use the proven alternative instead), challenging the new firmware architecture in the first release (carry the existing generation forward), and sequencing both so the new recording mode could be learned on a lower-risk platform. Combined, the ideas accelerated the recording-technology learning and produced a net modeled pull-in of roughly fifteen months.

Case two — Rainier: the technology that was not required

Rainier was a flagship 3.5-inch, two-platter, 7200-rpm program with a desktop deliverable due in June 2015 and an enterprise variant a month behind it. When the team walked into its challenge workshop it was approximately three months late and trending worse, for a familiar reason: the plan required a stack of new technologies — new mechanics, a new servo scheme, a new head-media interface, a dual-stage feature the whole roadmap treated as its centerpiece, a new preamp, and new firmware — and every one of them was on the critical path. Figure 13. The Rainier challenge workshop. Schedule scrub on the projector, challenge and assumption charts on the boards behind.

In the room Desired is not required The workshop’s pivotal exchange was short. One of the required technologies — a head-media innovation everyone referred to as load-bearing — was put under the standard questions: why is it in the plan, and are the reasons still valid? The answer that emerged, once the capacity and performance math was worked on the wall, was that the technology was desired but not required to meet the program’s stated goals. It had entered the plan when targets were different, survived every review since, and nobody had re-examined it because challenging a headline technology feels like challenging the roadmap itself. This is the textbook dominant idea: perfectly valid once, invisible now, controlling everything. What was done. The team removed the technology from the program. The decision cascaded: dropping it also removed the gating items it dragged into the plan — a new suspension design and the new preamp generation — and it simplified the firmware effort that had been carrying compatibility for both configurations. Three critical-path chains disappeared in one decision. The follow-through was deliberately careful, because removing a technology is the kind of workshop decision that dies in the parking lot. The core team met afterward to confirm the conclusions still held, and brought in independent experts to re-verify the assumptions. The open concern — closing capacity without the removed technology as an enabler — was answered with systems thinking rather than heroics: adopt the new generation of the data-refresh firmware, which cut the performance cost of each refresh; use that headroom to relax the adjacent-track-interference requirement from 1,500 to 750, and then to 300 with modest additional risk; and offset the residual performance loss with actuator and seek-time improvements from the servo and mechanics side. One team member’s account of the week captures the mode of thinking: the removal initially threatened random-write performance under some workloads, the discussion got lively, and the servo and mechanics group volunteered compensating adjustments — in the team’s own words, “a good example by the team to identify how to help solve problems regardless of origin.” The team held to the removal despite the risks, “because that decision alone should allow us to keep the newer timeline”. Churchman’s systems dictum applies exactly: systems fail when their managers decide some part of the world is outside the system and not subject to control. This team widened the system until the problem fit inside it. What was achieved The desktop deliverable moved from October 2015 to July 2015. The enterprise deliverable moved from December 2015 to August 2015 — a three- and four-month pull-in respectively, on a program that had been drifting the other way. The wigglechart shows the mechanism: a red trend climbing toward January 2016, then a near-vertical drop as the challenge decisions landed, then the signature flat green line, fifty-three days early against the datacenter qualification window and holding steady week over week.

Case three — Slider Bias: learning twice as fast

Slider Bias was a different animal: an innovation project rather than a product program, chartered to prove out a head-technology building block ahead of the drive programs that would consume it. Its problem was not a stack of gates but a plan shaped like a product schedule wrapped around research work. It assumed one cycle of learning — right the first time — on questions where the team openly admitted it did not yet know what it did not know. Face-to-face time between the two development sites was scarce, assumptions went unchallenged, and the end milestone carried a six-week gap with a progressive slipping trend. Figure 16. The Slider Bias challenge workshop, with the challenge flow chart on the screen and the working lists building on the right.

In the room Attack the learning rate, not the date The workshop reframed the problem before it solved it. For an innovation effort, the template the team had built its plan on was wrong in one specific way: development programs mature a product, so their schedules optimize the rate of maturity — but innovation projects buy learning, so their schedules should optimize the frequency of the learn-and-fail cycle. Once the team saw its plan through that lens, the challenge targets picked themselves. Why does the design-of-experiments run as one monolithic block? Why do wafer designs wait for full definition before starting? Why is there one learning cycle when the whole point is to learn? What was done. Three structural decisions came out of the room: risk-start the wafer designs for the new head feature rather than waiting; break the design-of-experiments into smaller pieces so testing could start earlier and a second learning cycle would fit inside the same window; and run more activity in parallel, accepting a known resource-contention risk. Around them came supporting moves in the same spirit: four hours of face-to-face core-team time every week for the following month, alternating between the two development sites; an external supplier added to the plan to accelerate adoption on datacenter programs; the wafer tasks broken down to expose their real dependencies; and a scrub of the component-level test schedule. What was achieved Measured in calendar days the immediate pull-in was marginal — about three weeks against a milestone still trending sixty-two days late. Measured in learning it was a breakthrough: the team doubled its learning cycles inside the same time frame, which de-risked the schedule and doubled its chances of finding solutions to the unknowns that were the real threat. The energy shifted with it; the team’s own assessment afterward listed “forced us to think differently,” “focus on accelerated learning, not just the end date,” and “greater confidence in the schedule” among the changes it would keep. The structural change compounded: within weeks the program carried an early completion scenario for its learning — plans in place for the required wafer designs and risk mitigations — that represented a four-month pull-in of the learning-complete date, alongside a conservative scenario holding an additional design iteration in reserve.

Synthesis — What made the breakthroughs repeatable

Three teams, three different breakthroughs: a roadmap rebuilt around staged learning, a headline technology removed because its reasons had expired, and an experiment plan restructured to double its learning rate. None of the three required new headcount, new budget, or a single relaxed requirement. That is the point of the method, and it is worth being precise about why it worked here, because the preconditions are reproducible. Every team had the same three ingredients before the workshop. First, an accurate schedule with trend history — the wigglechart discipline of predicting the finish weekly and watching the slope — so the gap was a measured fact rather than an opinion. Second, leaders of a particular type: senior engineering program managers, technically respected, able to see outside their own project. Third, a team that had already tried everything inside its frame, missed its dates anyway, and knew it — teams, in other words, that were ready to be told the problem was the frame.

Patterns Why the method transfers The gap did the motivating; the process did the steering. In each room the facilitators removed the two standard escape routes — proving lateness and relaxing requirements — and the easy trade-off of de-featuring the product was explicitly taken off the table. What remained was creative pressure. People can think creatively to accelerate a schedule; doing so does not mean working harder, it means working differently against the same goals. The three cases put numbers on that claim: fifteen modeled months, three and four real months, and a doubled learning rate. The assumptions that mattered were never secrets. The controller gate, the mandatory technology, the monolithic experiment plan — every one sat in plain sight in the plan, defended by reasons that had once been good. That is exactly what the psychology of entrenched belief predicts: minds favor information that confirms what they already hold, and groups convert shared beliefs into identity, which is why declarations of confidence say more about the coherence of the story than its truth. A structured, non-threatening “why?” is the cheapest known instrument for breaking that grip — much cheaper than the crisis that otherwise does it. Speed of action preserved the gains. Every team converted workshop output into a seven-day plan with owners; Watson re-baselined its entire program inside a week. The refresh cadence — a one-day challenge offsite every two to three months — kept the plans from silting back up, and matches the practice documented across the fastest teams lateralworks has studied. And the culture in the room mattered as much as the mechanics: challenge was never personal, ideas were never red-lighted while being born, and the manager’s job was to make the risk safe to take rather than to prevent it — the condition Catmull identifies as the foundation of any self-correcting creative organization. The transferable lesson. Every late program is late inside a frame of assumptions it can no longer see. The challenge process is a repeatable, one-day instrument for seeing the frame: measure the gap honestly, refuse the easy exits, surface the assumptions, ask why until a reason fails, and rebuild the schedule around what the failure opens up — within seven days, while the team still owns it.

References

  1. lateralworks. “Introduction to Critical Thinking.” Client seminar and workshop materials, best practices of fast teams series, 2014–2022. Includes the challenge, concept triangle, random entry, and escape provocation techniques, workshop artifacts, and the three case records documented in this paper.
  2. de Bono, E. Lateral Thinking: Creativity Step by Step. Harper and Row, 1970.
  3. de Bono, E. Serious Creativity: Using the Power of Lateral Thinking to Create New Ideas. HarperBusiness, 1992.
  4. lateralworks. “Breakthroughs by Challenging Assumptions.” lateralworks.com, January 2019. https://lateralworks.com/ideas/2019/1/16/breakthroughs-by-challenging-assumptions
  5. Catmull, E., with Wallace, A. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration. Random House, 2014.
  6. lateralworks. “The Challenge Game.” lateralworks.com. https://lateralworks.com/ideas/the-challenge-game
  7. lateralworks. “10 Best Practices of Fast Teams.” Whitepaper, lateralworks.com. https://lateralworks.com/papers/10-best-practices-of-fast-teams.pdf
  8. Churchman, C. W. The Systems Approach. Delacorte Press, 1968.
  9. lateralworks. “My Schedule Keeps Slipping…” lateralworks.com. https://lateralworks.com/ideas/my-schedule-keeps-slipping
  10. lateralworks. Program archive: fastProject wigglecharts, workshop photographs, flip charts, and schedule records from the client engagement, 2014–2015. Client identity withheld by agreement.
  11. Kinzer, S. The Brothers: John Foster Dulles, Allen Dulles, and Their Secret World War. Times Books, 2013. On confirmation bias, groupthink, and belief as identity. A note on anonymization. The client for all three engagements is a major disk-drive storage company operating at extremely high volume under aggressive time-to-market pressure. Individual names have been removed from the text and blurred in chart artifacts; workshop photographs are reproduced as taken. Program codenames (Watson, Rainier, Slider Bias) are internal designations with no external meaning and are retained for readability. Technology names that could identify the client or its partners have been generalized in the text.