Abstract

Most development teams meet a slipping schedule with one of two responses. They work harder inside the existing plan, or they trade away scope to protect the date. Both responses leave the underlying plan untouched, and both quietly accept that the current way of working is the only way. The result is a team that runs faster on the same track while the gap to the target keeps growing. This paper describes a third response that lateralworks teaches and uses in the field: the challenge process. Challenge is a structured way to question the assumptions a team has built its plan on, and then to generate faster alternatives that still meet the goal. It is the central technique in a small family of idea-generation methods that lateralworks adapts from the lateral thinking of Edward de Bono. The argument runs in four steps. First, teams get stuck because thinking settles into fixed patterns, and a schedule under pressure makes those patterns harder to see, not easier. Second, escaping a pattern needs a deliberate method rather than an exhortation to be creative. Third, the challenge process supplies that method by surfacing assumptions, asking why each one is held, and converting the weak ones into faster ways of working. Fourth, the same process that closes a schedule gap also breaks the difficult technical problems that sit behind most gaps. Throughout, the paper connects the lateralworks practice to the wider literature on problem framing, decision making, and product flow. The connection matters. It shows that a method developed at the workbench of real programs rests on the same foundations that researchers reached from a different direction. Figure 1. The escape from current thinking. A problem defined by today’s assumptions runs along a normal line of thought toward an obvious solution. Challenge steps off that line, ignores a constraint, and opens an alternative path. Adapted from the lateralworks critical thinking workshop, after de Bono.

The problem — Why good teams get stuck

A schedule that trends away from its target is the most common reason a team is asked to think differently. The gap is visible, the pressure is real, and the usual moves have already failed. This is exactly the moment when thinking tends to narrow rather than widen. The reason is structural. Human perception organizes information into patterns, and once a pattern forms it becomes the path of least resistance. De Bono built his work on this observation: the mind is a self-organizing system that is brilliant at recognizing established patterns and poor at crossing between them. The same property that lets an experienced team move quickly along a known plan is the property that traps it when the known plan is too slow. Figure 2. Critical thinking is for the complex, multivariable problems a schedule is made of. It works by restructuring the problem and changing the frame of reference — which needs a repeatable system and a team environment that permits exploring even an idea that sounds absurd at first. Most corporate systems push the other way, toward conformity. From the lateralworks critical thinking workshop.

The two responses that change nothing When a schedule slips, two responses dominate. The first is to prove the team is late: assemble the evidence, escalate the risk, and ask for relief. The second is to relax the requirements, cutting features or quality to fit the work back inside the date. Each response feels rational. Each accepts the current plan as the boundary of what is possible, and so neither changes the trajectory. There is a quieter cost. A team that responds this way learns that a gap is something to survive, not something to use. The next slip produces the same two moves, a little faster. lateralworks teaches a different reflex. A gap is information about the distance between the current plan and the target, and that distance is the pressure that justifies questioning the plan itself. Why the pressure should help, and usually does not Reinertsen’s work on product development flow gives the economic case for treating a gap as urgent. Once a team quantifies the cost of delay, the value of pulling a schedule in becomes visible and large, and decisions that were treated as fixed turn out to be economic choices worth revisiting. The pressure of a gap is therefore not noise. It is a signal that the assumptions behind the plan deserve scrutiny. The trouble is that pressure tends to harden thinking. Under load, a group leans on the consensus it already holds. Janis documented the extreme form of this in his study of policy fiascoes: cohesive groups suppress doubt, ignore alternatives, and converge early on a shared view, often with confidence that the view is sound. Festinger’s account of cognitive dissonance explains the mechanism at the individual level, where contradictory information is uncomfortable enough that the mind quietly screens it out. Kahneman places the same tendency inside a broader catalogue of biases, including the anchoring that keeps an early estimate in force long after it should be revised. Challenge is built to counter these forces on purpose, because they will not yield on their own. The schedule gap as the area of focus lateralworks frames the choice plainly. Knowing the schedule gap leads to one of two paths. Down one path, the team uses the gap to prove it is late and to argue that requirements must be relaxed. Down the other, the team uses the gap to challenge its current thinking, create urgency, and discover ideas that do not compromise the goal. The technique that follows is designed to keep teams on the second path.

Figure 3. Why challenge. Knowing the schedule gap forces a choice. One response uses the gap to prove lateness and to relax requirements. The other uses the same gap to challenge current thinking and to find ideas that meet the goal without compromise. From the lateralworks critical thinking workshop. Framing the gap as the area of focus also reframes the problem. Wedell-Wedellsborg’s survey of senior executives found that 85 percent believed their organizations were poor at diagnosing problems, and that the cost of that weakness was significant. His remedy is reframing: before solving, ask whether a better problem is available. A team that asks "why is this task on the critical path?" rather than "how do we work faster?" has reframed the gap, and reframing is where faster answers come from. Figure 4. Framing the problem first. The team’s instinct under schedule pressure is to jump to solutions; the discipline is to spend the effort up front getting the question right. From the lateralworks critical thinking workshop.

Method — A discipline for generating ideas

Creativity on demand is not a matter of waiting for inspiration. De Bono’s lasting contribution was to treat the generation of new ideas as a skill with deliberate tools, usable by an ordinary team on an ordinary Tuesday. lateralworks packages those tools into a single workshop method with four techniques and a common backbone.

Figure 5. The premise behind the method, in four lines the workshop opens with. New results need new thinking, assumptions need a regular scrubbing, and an idea that sounds absurd at first is often the one worth chasing. From the lateralworks critical thinking workshop. One backbone, four techniques Every session follows the same arc. The team identifies an area of focus, selects a technique, generates ideas without constraint, captures the results, and acts. The first three steps are deliberately unconstrained, because judgment applied too early kills the ideas worth keeping. Constraints return at the capture step, where ideas are shaped into something a team can use. Figure 6. The method at a glance. Idea generation runs unconstrained from the area of focus through technique selection to a flow of ideas. Constraints return only at capture and action. Harvesting and treatment turn raw ideas into usable ones. From the lateralworks workshop, after de Bono. The four techniques suit different situations. Challenge applies when something already exists and the team wants a better way to do it; it is the focus of this paper. Concept triangle abstracts a concept from a first idea, then uses the concept to breed more ideas. Random entry introduces an unconnected word or image to break a team out of a blank-page situation. Escape provocation generates a deliberately unreasonable statement and moves from it to a usable idea. De Bono describes the same family under the labels challenge, the concept fan, the random word, and provocation, with provocation reached through escape, reversal, exaggeration, and wishful thinking.

Harvest and treat The step teams most often skip is the last one. Generating ideas is satisfying; turning them into commitments is work. De Bono named this stage harvesting, and lateralworks keeps the term. Harvesting sorts the output into specifics that can be implemented now, beginnings worth further investigation, and concepts that can generate further ideas. Treatment then strengthens an idea, shapes it against real constraints, corrects its faults, and sharpens the difference between the new way and the old. Without this step, a workshop produces enthusiasm and no change. De Bono’s techniques are not only a classroom exercise. His own consulting record includes industrial teams that applied the methods to hard technical problems and reported both lower operating costs and faster movement of new products to market. That outcome, faster products from better thinking, is precisely the result lateralworks pursues with the challenge process.

Core practice — The challenge process

Challenge is the practice of questioning the way something is done now. It begins with a simple sentence: we want to improve the way we do this. That sentence is permission. It separates the act of questioning a method from any criticism of the people who built it, which is the precondition for a team to challenge its own work without defensiveness. Challenge is never a personal attack. It works best with cohesive teams that are open to questioning the status quo, and it is aimed at breakthroughs rather than incremental tuning. The target is the current thinking itself: the assumptions, so familiar that they have stopped looking like choices, that quietly shape every estimate in the plan.

Creating a new frame Challenge works by changing the frame through which a team sees its own work. The team names what it wants to improve, describes the current thinking inside that frame, asks why those things are there, and then asks how the work could be done differently. Each question widens the box a little, until a new frame becomes visible. The physicist Max Planck captured the effect in a line the workshop borrows: when you change the way you look at things, the things you look at change. Figure 7. Creating a new frame. Naming what the team wants to improve exposes the current thinking inside the box, the reasons those things are there, and the opening to do the work differently. The final question generates a new frame. From the lateralworks workshop. Surfacing the assumptions A team cannot challenge an assumption it has not named. lateralworks surfaces assumptions with four prompts. Essential: what must always be included? Dominating: what ideas control our thinking? Avoid: what are we trying to keep away from? Boundary: what limits are we living within? Each prompt is started as a sentence, so the assumption is stated plainly enough to be argued with. "It is essential that the lead customer engages early." "Schedule above quality dominates our thinking." "We must avoid running several programs at once." "We must stay within current headcount." De Bono drew the same distinctions in his account of the forces that fix thinking: dominating ideas that all reasoning returns to, essential factors that every idea is made to include, and boundaries that teams look inward from without questioning. The value of writing them down is that a named boundary can be tested, while an unnamed one simply governs. Assumptions also divide into the explicit and the implicit. An explicit assumption is stated and observable. An implicit assumption is inherited from the nature of the work and never spoken, which makes it both more powerful and more dangerous. Much of the value of a challenge session comes from dragging implicit assumptions into the open, where the team can see that a constraint it treated as physics is in fact a habit. The challenge flow The process moves from the area of focus through a short, repeatable loop. The team lists its assumptions, selects the ones worth challenging, and tests each with the same question: why? Why do we think this?

What are the reasons? Are the reasons still valid? An assumption that survives is kept. An assumption that does not survive moves to a decision the workshop calls do or cut: if the work can be done now, do it; if it can be removed now, cut it. The ideas that result describe how the work can be done differently, and the team acts on them, then harvests and treats the output and repeats the loop on the next assumption. Figure 8. The challenge process. From an area of focus, the team surfaces assumptions, selects the ones worth testing, and asks why each is held. Surviving assumptions are kept; the rest move to do-or-cut. Resulting ideas feed action, harvesting, and treatment, and the loop repeats. This is the central diagram of the lateralworks challenge practice. Figure 9. What the loop looks like in a real room. Assumptions go up on the wall as sticky notes, get sorted with the do-or-cut decision, and each surviving one is tested with "why, what are the reasons?" before the team writes the ideas to do it differently. A typical session works through about eight assumptions and closes with a seven-day action plan. From a lateralworks challenge workshop. Why "why" is the engine

The repeated "why" is the part of the process that does the work, and it is not unique to lateralworks. Taiichi Ohno built the same move into the Toyota Production System as the five whys: ask why enough times and the visible problem gives way to the real cause behind it. Goldratt’s theory of constraints reaches the same place from the direction of conflict, using a structured method to surface the assumption hidden inside an apparent trade-off and then to break it. In each case the discipline is to keep asking until an assumption that looked like a fact reveals itself as a choice. Challenge applies that discipline to the assumptions inside a schedule. Challengeable and not Not every statement is worth challenging. A bare fact, such as a fixed task duration or a late program start, is not challengeable on its own; it is a condition. What is challengeable is the thinking around it. "We cannot reduce the feature set to accelerate the schedule" is challengeable, and the productive reframing is often already visible in the sentence: the product may ship without its newest features, but it may ship working, sooner. "We cannot reduce new firmware features" becomes "reduce the new firmware features that are not critical to the core function." The skill is to find the assumption sitting inside a statement of fact, and to aim the challenge there.

Principle Use the gap A schedule gap is information. Used well, it makes a team question what it assumed was fixed, and find a faster path that still meets the goal. lateralworks Best practices of fast teams

In application — Schedule gaps and technical problems

Two situations bring teams to the challenge process most often. The first is a schedule that has drifted away from its target by a large margin. The second is a difficult technical problem that is quietly setting the schedule from behind the scenes. The same loop handles both, because in practice they are the same problem seen from two angles.

Closing a large schedule gap When a schedule trends away from its target and the gap is large, the team has usually spent weeks trying to accelerate the existing plan, with little to show for it. That history is useful. It is evidence that the plan cannot be rescued by working harder inside it, which is the argument for challenging the plan instead. The team takes the milestone it is trying to hit as the area of focus and surfaces the assumptions behind the path to it. Typical assumptions concern which components must be used, which features must be present in the first release, and which activities must run in sequence. Each is tested with the why loop. Where an assumption fails, the team looks for the alternative the assumption was hiding: a proven component in place of a new one, a deferred feature, a parallel path in place of a serial one, a step removed entirely. Each alternative is then put into the schedule on its own to measure the pull-in it produces. Two findings recur. First, no single change is decisive; the pull-in from any one alternative is usually small, often a week or two. Second, the alternatives combine. A proven component plus a deferred feature plus a parallel path can move a milestone by months, even when each move alone moved it by days. The combination is the solution, and it is invisible to a team that evaluates ideas one at a time and discards the small ones. Appendix A follows one program through exactly this sequence. Breaking a technical problem that drives the schedule Many schedule gaps are technical problems wearing a calendar. A feature will not stabilize, a measurement will not converge, a process step keeps failing, and the milestone slips as a symptom. Attacking the date directly does nothing, because the date is downstream of the physics. Challenge handles this by making the technical obstacle the area of focus and questioning the assumptions around it. Often the decisive assumption is that a particular technology is required at all. When a team challenges "this feature is required for the program" and finds that the program’s real goals can be met without it, removing the feature can remove a chain of dependent problems at once, and the schedule recovers as a consequence. In other cases the breakthrough is not removal but rate: the team challenges the assumption that learning must proceed one cycle at a time and restructures the work to run more learning cycles in the same calendar. Doubling the rate of learning de-risks a program even when the raw pull-in is modest, because the odds of finding a solution rise with every extra cycle. What the team must refuse to do The discipline that makes challenge work is a refusal. The easy way to make a program go faster is to take features out until it fits the date, and that option is removed from the table at the start. With de-featuring off the table, the team is forced through the creative work of finding a faster path that still meets the goal. The point is not to prove the team is late, and not to relax the target. It is to use the gap as the pressure that produces a different and faster way to work. lateralworks engagement records across more than two decades of programs show this reframing producing real pull-in without loss of scope.

Widening the frame — From challenge to systems thinking

Challenge questions the assumptions inside a plan. Systems thinking questions the boundary the team drew around the problem in the first place. The two practices belong together: a team challenges its assumptions, then steps back to ask whether it has even framed the right system.

Start from the end state Conventional problem solving moves left to right: define the problem, analyze it, reach a solution. A systems thinker starts at the other end, from a clearly defined end state, and works back, treating feedback and change over time as part of the problem rather than noise around it. The shift matters most when the problem and its end state are not yet clearly defined, which is the normal condition of a hard program. Figure 10. Conventional thinking versus systems thinking. Conventional thinking runs forward from a problem to a solution. Systems thinking starts by defining the end state and reasons backward, treating feedback and change as part of the problem. From the lateralworks workshop. Optimize the system, not the parts The central lesson of systems thinking is that a set of locally optimized components rarely adds up to an optimized system. Ackoff made the point a foundation of the field, and Senge carried it into management practice: improving a part can degrade the whole when the parts interact. Meadows framed the same idea around leverage, where the highest-value change is often a change in the goal or the structure rather than in any single part. On a development program this shows up as a missing role. The program needs a single person who sees across the whole system, weighs the knock-on effects of a local decision, and makes the trade-offs that keep the program on schedule while meeting its targets. Churchman gave the warning that systems thinkers return to. Systems fail, he argued, when their managers come to believe that some aspect of the world lies outside the system and so beyond their control. A team that treats a supplier, a requirement, or an adjacent group as fixed has drawn its system boundary too tightly, and the most valuable challenge it can make is to widen that boundary. Macro and micro thinking work together here: the systems thinker holds the whole in view while still grasping the detail, comfortable at altitude and at ground level, and content to be roughly right rather than precisely wrong.

Sustaining it — Making challenge a habit

A technique used once is a workshop. A technique used on a cadence is a capability. The teams that get the most from challenge build it into the rhythm of the program rather than reaching for it only in a crisis.

A regular offsite The pattern lateralworks recommends is a short offsite every two to three months. Before the session, the team brainstorms its current thinking so the assumptions are on the wall when the day starts. During the session, the team runs the challenge loop and folds the resulting changes straight into the schedule. After the session, the team harvests and treats the ideas and sets up the meetings with stakeholders that turn decisions into commitments. The cadence keeps assumptions fresh, because the ones that were valid last quarter may not be valid this one. The conditions challenge needs Challenge depends on a team that is safe enough to question itself out loud. Edmondson’s research on psychological safety established the link directly: teams that believe it is safe to speak up learn faster and perform better, because members surface problems and doubts instead of hiding them. This is the same safety that challenge requires when it asks a team to call its own assumptions into question. Catmull made the cultivation of that safety a leadership responsibility. His account of sustaining creativity argues that a manager’s job is not to prevent risk but to make it safe to take, that failure is a necessary consequence of doing something new, and that a good team given a flawed idea will fix it. Janis pointed at the failure mode from the other side: cohesion without dissent decays into groupthink, where the desire for agreement overrides the realistic appraisal of alternatives. Challenge is, in part, a structured defense against that decay. By making the questioning of assumptions a scheduled, depersonalized routine, it builds the habit of dissent into the team before a crisis demands it. Used this way, critical thinking stops being an event and becomes a stance. The team expects to revisit its assumptions, expects some of them to fail the test, and expects to find a faster way as a result. That expectation, more than any single workshop, is what separates a fast team from a busy one.

A Case study Challenge in practice This case is drawn from a lateralworks engagement on the Watson hard disk drive program. The program is more than ten years old and the technology described is well past its commercial life, so it is reported here in full, with the actual product and technology names the team worked with. It is the clearest illustration we have of the challenge process closing a large schedule gap.

Figure 11. The Watson core team in the challenge session. The current schedule is on screen; the assumptions and candidate moves are captured on the chart paper behind the team. From the lateralworks engagement. The situation The Watson team was about ten months behind the target for its first major deliverable. The schedule was high risk, in large part because too many new things were being introduced at once. The team had three months of performance-to-schedule history and a string of attempts to accelerate the existing plan, none of which had found a solution. By the time lateralworks was brought in, the prevailing assumption had hardened into resignation: the project was late, there was little that could be done, and the remaining technical risks would only make it later. Inside the challenge session The team took the first deliverable as its area of focus and ran the challenge loop with one rule in force: explore every acceleration idea for practicality, but with no management constraints on the ideas and no de-featuring as a shortcut. The session surfaced roughly eight assumptions worth challenging, captured on chart paper, sorted with the do-or-cut decision, and worked through the why loop. The boards below show the actual output: candidate challenges such as releasing with Barts and LSEC versus an initial release with Antigua, choosing UFA against Arch6, and the ranked list of "big hitter" moves.

Figure 12. The challenge boards from the Watson session. Candidate assumptions to challenge, the reasons behind each, and ideas to do it differently — worked on the wall by the core team in real time. From the lateralworks engagement. The "big hitters" the team identified against the schedule were concrete: do not gate the program off the Barts SoC; decouple UFA; do not implement LSEC for the initial release; make the first product the 3.5-inch desktop drive; and do not attempt the mobile drive in the first release. Each was an assumption the original plan had treated as fixed. From single moves to a combined solution Each acceleration idea was implemented individually in the schedule to measure the pull-in it produced on its own. Measured that way, every idea was disappointing: the pull-in was a few days each, under two weeks in the best case. None of them, alone, justified disrupting the plan. The breakthrough came from combining them. The team challenged the use of Barts in the first mule and substituted Antigua; it challenged adopting UFA in the first version and substituted Arch6. Combined, these moves accelerated the SMR learning sequence and produced a net pull-in on the order of fifteen months — from a set of changes that each looked marginal in isolation.

Figure 13. The ranked acceleration moves from the session, with their schedule effects worked out on chart paper: use Arch6 as a base, first Watson product is the 3.5-inch, use Antigua, and replace the later phase. The combination, not any single move, was the solution. From the lateralworks engagement. The business case The team did not stop at the schedule. It built the business case for the change, modeling the sensitivity of profit before tax to a one-month schedule move against the other levers — unit sales, average selling price, cost of goods, and R&D; expense. The analysis showed the schedule pull-in was worth far more than the cost of the changes required to achieve it, which is what turned a workshop result into an executive decision.

Figure 14. The Watson business case. A sensitivity analysis of profit before tax to a one-month change in schedule and in each commercial lever, with the combined cost/benefit of the new plan. The schedule move dominated the cost of the changes that produced it. From the lateralworks engagement. Acting on the decisions The team committed to act on every workshop decision within seven days. It ran a series of one-to-one meetings with the functional stakeholders whose work the changes touched, then called a decision meeting the following week to converge on the new development strategy. The fact that the team had already done the analysis and reached a decision changed the conversation with executive staff, who moved from questioning the program to supporting the new approach. Within a single week the team had re-baselined the schedule around the faster, lower-risk plan. Figure 15. The Watson new product roadmap that came out of the session. The first product became the 500GB drive on a proven path, with the more aggressive configurations sequenced behind it rather than attempted all at once. From the lateralworks engagement.

The result The schedule trend tells the rest of the story. Before the session, the weekly predictions for the 4TB milestone were drifting late, ending at a 29-day slip. After the team re-baselined around Antigua, Arch6, and the deferred features, the same milestone tracked early — a roughly ten-day margin against target, with the prediction line holding flat instead of climbing. The gap did not close by working harder. It closed because the team questioned what it had assumed was fixed. The trend chart that made this visible is the same schedule-gap instrument lateralworks describes in "The Challenge Game". Figure 16. Watson schedule trend, before (left) and after (right) the challenge session, shown on lateralworks wigglecharts. Each point is a weekly prediction of the finish date against a fixed target. The drift toward a late finish reverses into a stable, on-time prediction after the re-baseline. From the lateralworks engagement. What the case shows Watson did not recover by working harder, and it did not recover by cutting the product to fit the date. It recovered because the team treated a ten-month gap as the reason to question what it had assumed was fixed. The decisive moves — a proven controller in place of the new one, the prior architecture in place of the next, a deferred feature set — were available before the session. They were hidden inside assumptions that no one had written down and tested. Challenge made the assumptions visible, the why loop showed which ones would not survive scrutiny, and disciplined combination turned a set of small pull-ins into a fifteen-month re-baseline. This is the challenge process working as intended.

Sources

References

  1. de Bono, E. Lateral Thinking: Creativity Step by Step. Harper & Row, 1970. (Originating work: The Use of Lateral Thinking, Jonathan Cape, 1967.)
  2. de Bono, E. Serious Creativity: Using the Power of Lateral Thinking to Create New Ideas. HarperBusiness, 1992.
  3. Wedell-Wedellsborg, T. "Are You Solving the Right Problems?" Harvard Business Review, vol. 95, no. 1, January–February 2017, pp. 76–83. https://hbr.org/2017/01/are-you-solving-the-right-problems
  4. Ackoff, R. L. "Systems, Organizations, and Interdisciplinary Research." General Systems, vol. V, 1960, pp. 1–8.
  5. Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
  6. Kahneman, D. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011.
  7. Festinger, L. A Theory of Cognitive Dissonance. Stanford University Press, 1957.
  8. Janis, I. L. Victims of Groupthink: A Psychological Study of Foreign-Policy Decisions and Fiascoes. Houghton Mifflin, 1972.
  9. Ohno, T. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988.
  10. Goldratt, E. M., and Cox, J. The Goal: A Process of Ongoing Improvement. North River Press, 1984.
  11. Goldratt, E. M. Critical Chain. North River Press, 1997.
  12. Churchman, C. W. The Systems Approach. Delacorte Press, 1968.
  13. Senge, P. M. The Fifth Discipline: The Art and Practice of the Learning Organization. Doubleday/Currency, 1990.
  14. Meadows, D. H. Thinking in Systems: A Primer. Chelsea Green Publishing, 2008.
  15. Eames, C., and Eames, R. Powers of Ten (film). IBM, 1977.
  16. Muir, J. My First Summer in the Sierra. Houghton Mifflin, 1911.
  17. Catmull, E., with Wallace, A. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration. Random House, 2014.
  18. Edmondson, A. C. "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, vol. 44, no. 2, 1999, pp. 350–383.
  19. Raiskums, B. W. An Analysis of the Concept Criticality in Adult Education. Doctoral dissertation, Capella University, 2008.
  20. lateralworks. "Research: best practices of fast teams (FTTM)." lateralworks.com. Multi-company study of more than 500 people on fast-to-market programs in Silicon Valley, begun in the early 1990s, with field engagements across hundreds of teams since. https://lateralworks.com/research
  21. lateralworks. "The Challenge Game." lateralworks.com, 2019. https://lateralworks.com/ideas/2019/1/16/the-challenge-game
  22. lateralworks. "Consulting: closing schedule gaps and using the cost of delay to generate urgency." lateralworks.com. https://lateralworks.com/consulting
  23. lateralworks. "Internal engagement records." Field observations across client development programs, 2000–2026.