Papers

9 papers. 36 years of practice.

Research findings, methodology papers, and field-tested frameworks from the lateralworks team. New papers added regularly — check back.

SeriesAll FTTM Methodology FTTM Toolkit Innovation Portfolio

© 2026 lateralworks Page 1 › › Whitepaper Portfolio prioritization & starts control How to govern what enters the active pipeline so the work that starts actually finishes FTTM Best Practices Series. A lateralworks methodology paper on portfolio prioritization and starts control: AHP-based ranking without constraints, then resource reality applied to determine what actually starts. Connects the discipline to four decades of portfolio research from Saaty, Cooper, Reinertsen, Goldratt, Wheelwright and Clark, and Rogers and Blenko. Prepared by lateralworks FTTM methodology Date May 2026 Methodology paper Online lateralworks.com FTTM Best Practices Series -- 1 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 2 Table of contents Portfolio prioritization & starts control Abstract 03 01 Why projects start late 04 02 The portfolio decision-making flow 07 03 The AHP-based prioritization model 10 04 Starts control: the pipeline gate 14 05 Decision rights inside the portfolio 18 06 Outside research that anchors the discipline 22 07 Implementation: making it real 25 08 Conclusion 29 References 32 Appendix A — Altera (programmable logic) 34 Appendix B — SunPower (solar cells) 39 Core thesis. Most product organizations start more projects than they can finish. The cure is not better execution. It is a portfolio discipline that ranks every candidate against weighted strategic and economic criteria, then gates entry to the active pipeline against real resource capacity. Rank without constraints first. Apply constraints second. One person owns the call. Starting fewer projects is how more projects finish on time. -- 2 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 3 Overview Abstract The single most damaging failure in product development portfolio management is starting more projects than the organization can execute. The symptom is familiar: every project is a priority, every team is fully committed, and most milestones slip. The root cause is structural. No filter prevents low-value work from entering the pipeline, no mechanism orders what does enter against real resource capacity, and no single person owns the call. Each unit of unfunded work that still gets started consumes capacity from work that is already in flight. This paper describes the lateralworks FTTM portfolio discipline: a structured prioritization model based on the Analytic Hierarchy Process [1] paired with explicit starts control at the entry to the active pipeline. The flow is sequential. Strategic and economic filters rank every candidate without constraints. A six-step zero-based budgeting (ZBB) loop builds a baseline ranking, captures stakeholder weighting through pairwise comparisons, consolidates consensus, and only then applies budget and headcount limits. The projects above the resource line enter the active pipeline; the rest are deferred or killed. The discipline draws on independent research streams that converge on the same conclusion. Saaty's AHP [1] formalized the math of multi-criteria decision-making. Cooper, Edgett, and Kleinschmidt documented portfolio management as the highest-leverage practice distinguishing best-in-class new product development [2, 3]. Reinertsen showed why running engineering at high utilization makes queue times explode [4]. Goldratt's Theory of Constraints reached the same conclusion from operations research: limit work-in-progress, finish what you start [5]. Wheelwright and Clark made the case at Harvard Business School for portfolio-level aggregation as the lever on cycle time [6]. Rogers and Blenko's RAPID work [7] supplies the decision-rights model that prevents governance from collapsing into committee. For semiconductor and systems-product organizations, the prescription is operational. Build the unconstrained ranking first so strategic and economic priorities are not distorted by whoever's loudest about resource pain. Apply the constraint model second, transparently, with the line between funded and deferred visible to the organization. Name a single Decider. Run a quarterly review cadence with explicit emergency-review triggers. The organizations that adopt this discipline ship more products on original calendar; the ones that don't ship many products late. Key finding. A perfectly prioritized project list is operationally useless if every project on it enters the pipeline at once. The pipeline gate — starts control — is what turns a ranked list into a feasible plan. -- 3 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 4 01 Section one Why projects start late Late delivery is a systems problem, not a person problem. Eight recurring causes show up across organizations regardless of industry, size, or maturity. Every one of them is structural — embedded in how the portfolio is governed, how starts are decided, and how resources are allocated. Section one names the eight causes, then frames the rest of the paper as the structural answer. -- 4 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 5 Section one Why projects start late Ask the leadership team of a product organization why projects finish late and the typical answers are individual: a particular engineer left, a supplier missed a date, a customer changed scope. Aggregate the same answers across many programs over many years and a different picture emerges. The same eight causes appear over and over, and they are structural rather than personal. They describe how work enters the system, how it is prioritized, and how resources are matched to it. Project Management Institute research is consistent on this point. PMI's Pulse of the Profession surveys repeatedly find that organizations with mature portfolio management complete significantly more projects on time and on budget than those without [8]. The differentiator is not execution skill. It is the discipline that decides which projects enter the pipeline and in what order. Figure 1. What causes late projects — the recurring structural causes that aggregate across hundreds of programs. Each cause is embedded in how work enters the pipeline rather than in how teams execute it. The eight causes Project starts late. The simplest cause is also the most common: the calendar baseline assumed a start date that did not happen. Resources were tied up on the previous late program. The project lost its planned launch window before any technical work began. Late starts compound at every downstream milestone gate. Resources tied up on the last late one. When the previous program ran past its commit date, the engineers earmarked for the next program are still consumed by the old one. The cascade is mechanical: late finishing N produces late starting N+1, which produces late finishing N+1. No priority — every project equal. If everything is a priority, nothing is. When the organization cannot articulate which two or three programs matter most, the local optimization that happens at every team and -- 5 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 6 every gate has no signal to follow. Decisions get made on whichever stakeholder is most insistent. Priorities shift mid-flight. Even when a priority is declared, it often does not survive the first quarterly review. Reinertsen called this the "fog of priorities" — the cumulative cost of recurring re-prioritization is a hidden tax that does not show up in any program plan but shows up in every program's schedule slip [4]. Fuzzy front end ungoverned. The period between identifying an opportunity and formally starting a project is where most late projects are born. Smith and Reinertsen called this the fuzzy front end and showed that managing it as a focused, time-boxed activity is the single biggest lever on overall cycle time [9]. Under-resourced on skills. Headcount totals can look fine while specific skill gaps are crippling. A program that needs a particular kind of analog designer or RF integration lead can stall for months because the organization counts people but does not count capabilities. Over-committed on quantity. The mirror of the skill problem. The organization adds projects to the active list faster than it finishes them. Each engineer carries three or four concurrent assignments, switching costs dominate, and individual productivity collapses. The companion lateralworks paper on the optimal project load documents the quantitative penalty in detail [10]. No single owner of the portfolio. The most diagnostic of the eight. When portfolio decisions belong to a committee, the committee optimizes for consensus, not for cycle time. There is no one whose job is to say no, and so no one says no. Rogers and Blenko's research at Bain framed this as the foundational governance failure in slow organizations [7]. Key finding. Late projects are not a sign of weak teams. They are a sign of weak portfolios. The intervention point is upstream of execution: how work is selected, prioritized, and gated into the active pipeline. -- 6 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 7 02 Section two The portfolio decision-making flow The portfolio process operates as a progressive filter. Strategic fit eliminates work that does not belong in the pipeline at all. Economic test ranks the survivors by expected value. Constraint modeling translates the ranked list into a feasible set of starts. Failure analysis closes the loop, feeding what was learned back into the next round. Section two walks the flow from end to end. -- 7 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 8 Section two The portfolio decision-making flow The FTTM portfolio process answers four questions in sequence. Where should we focus? What should we start? In what order, given real constraints? What did we learn? Each question filters the work further. Each stage eliminates options that do not belong, so the organization does not waste planning effort on projects that will never make the cut anyway. Figure 2. The portfolio decision-making flow. Strategic filter (where should we focus?), economic filter (what should we start?), active pipeline (in what order under which constraints?), and success/failure analysis (what did we learn?) form the four-stage progressive filter that converts candidate ideas into shipped products. Strategic filter — where should we focus? The strategic filter establishes the boundaries of the portfolio. Which market segments, technology domains, and customer problems align with the long-term direction? Projects that fail this filter are eliminated before any economic analysis begins. This prevents the common failure mode where the organization funds work that looks economically attractive in the short term but does not belong in the long-term strategy. Cooper, Edgett, and Kleinschmidt's benchmark research at McMaster University documented this point repeatedly: the best-performing innovators are the ones with explicit strategic buckets and explicit rules about what gets in [2, 3]. The bucket definitions are written down. The rules are followed. Programs that do not fit — however attractive on their own merits — are not funded. Economic filter — what should we start? Projects that survive the strategic filter are then ranked against economic criteria. Revenue potential. Strategic fit. Market-maker engagement. Differentiation versus competition. Execution risk. Each criterion gets a weight, and projects are scored against the weighted criteria. The output is a ranked list ordered by composite value. This is the work that the AHP-based model in section three does formally. Active pipeline — in what order, given constraints? The transition from ranked list to active pipeline is where starts control operates. A perfectly ranked list is operationally useless if the organization tries to execute every project on it at once. The pipeline stage applies real constraints — engineering headcount, capital equipment, supplier capacity, dependency on predecessor work — to determine which projects actually start, when they start, and which must wait. Failure analysis — what did we learn? -- 8 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 9 Completed projects feed back into the strategic and economic models. Lessons on estimation accuracy, market assumptions, and execution challenges improve the fidelity of the next round's decisions. The feedback loop is what prevents the same misjudgments from being repeated. Without it, the model is open-loop and stays whatever it was when it was first calibrated. -- 9 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 10 03 Section three The AHP-based prioritization model The lateralworks portfolio discipline runs on the Analytic Hierarchy Process — a mathematical method developed by Thomas Saaty in the 1970s for converting subjective judgments about relative importance into a rigorous, weighted ranking [1]. The method scales to dozens of criteria and dozens of stakeholders, and it produces a consistency check that flags logically incoherent judgments. Section three walks the six-step process. -- 10 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 11 Section three The AHP-based prioritization model Saaty designed AHP to handle the most common failure of group decision-making: a stakeholder group that knows in principle that criterion A is more important than criterion B, but cannot agree on how much more. AHP turns the abstract question "which criteria matter most?" into a series of concrete pairwise comparisons. For every pair of criteria, a stakeholder makes one judgment: which matters more, and by how much. The math behind AHP guarantees that these binary judgments produce a consistent set of weights, even when the criterion list is large. Figure 3. The six-step zero-based budgeting flow. Steps 1–5 produce an unconstrained ranking by strategic and economic value. Step 6 applies the resource reality. Step 1 — gather the project list The process begins with a comprehensive inventory. Every candidate project goes on the list: new product initiatives, platform investments, customer-specific developments, technology programs. Each project carries its current status, expected deliverables, category, product series, and phase. The inventory is the input to the prioritization model. Skipping projects that the organization thinks are obvious "must-haves" defeats the purpose — the AHP model is designed to test those assumptions, not accept them. Step 2 — define objectives and criteria The criteria must be specific enough to differentiate between projects and broad enough to capture the full value system. A typical lateralworks engagement uses five to seven criteria. Common ones are listed below. -- 11 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 12 Criterion Definition Rating scale High revenue Sales-out dollar impact over the planning horizon. Absolute dollar value estimate. Strategic fit Alignment with market segment strategy and technology vision. Full / Partial / Weak — market and technology sub-criteria. Market-maker engagement Opportunity to win designs at target market-maker accounts. Agreement / High confidence / Uncertain. Value proposition Likelihood of winning via differentiation versus competition. >70% / 50–70% / <50% win probability. Execution risk Engineering confidence in schedule and budget. Low / Medium / High confidence. Table 1. Example portfolio criteria with definitions and rating scales. The exact set is calibrated per engagement. Step 3 — build the baseline (equal weights) Before any stakeholder weighting is applied, every project is rated against every criterion using equal weights — typically one over the criterion count, so 16.7% each for six criteria. The baseline exposes how projects rank on their raw attributes alone, before organizational politics or executive preference influence the output. Surprises at this step are diagnostic. A project everyone assumed was a top priority that ranks in the middle of the baseline is signaling something that the unconstrained model is catching. Step 4 — stakeholder pairwise weighting Figure 4. The AHP pairwise comparison. Each pair of criteria gets a single judgment on the 9-point Saaty scale. The math turns the binary calls into consistent weights. -- 12 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 13 Each stakeholder works through the criterion pairs independently. For each pair, the stakeholder picks which criterion matters more and how much more, on a defined intensity scale: same, moderate, strong, very strong, extreme. Saaty's key insight was that the pairwise judgments are easier to make accurately than direct weight assignments — humans are better at "A versus B" than at "distribute 100 points across these eight items" [1]. AHP also computes a consistency ratio for each stakeholder's judgments. If a stakeholder says A is more important than B, B is more important than C, but C is more important than A, the model flags the inconsistency. The stakeholder is asked to revisit the specific pair that broke transitivity. This is one of the most valuable mechanics of the method: it catches incoherent reasoning before it becomes a portfolio decision. Step 5 — consolidate and agree on priorities The consolidation workshop is where the real decision-making happens. Stakeholders come together to review how their individual weightings differ, see what those differences mean for project rankings, and then make new group pairwise judgments. The discussion is structured. Participants argue for their positions. They debate trade-offs. They converge on consensus weights. The final ranking is not imposed; it is negotiated with full transparency into how each criterion's weight affects the outcome. Common workshop activities include reviewing differences in individual weights and their effect on rankings; making new group pairwise judgments while debating positions; simulating how changing a single criterion weight reshuffles the priority order; filtering rankings by product category or product series to test sub-portfolio behavior; and discussing implications before agreeing on the final ranking. Step 6 — apply constraints Steps 1–5 produce the unconstrained ranking. Step 6 applies the resource reality — budget envelope, engineering headcount, shared infrastructure, supplier capacity, dependency on predecessor projects. The model loads projects in priority order until the cumulative resource demand crosses the constraint ceiling. Projects above the line are funded; projects below the line are deferred or killed. This is the work of section four. -- 13 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 14 04 Section four Starts control: the pipeline gate Starts control is the operational mechanism that turns a ranked list into a feasible plan. It is the single most damaging failure point in portfolio management when it is missing, and the single most concrete improvement when it is added. The principle is counterintuitive but well-established: starting fewer projects leads to more projects finishing on time. Section four covers the underlying mechanism. -- 14 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 15 Section four Starts control: the pipeline gate A prioritized project list, no matter how analytically rigorous, is operationally useless if every project on it enters the active pipeline at once. Engineering organizations have finite capacity. When the total resource demand of all active projects exceeds that capacity, every project slows down. Tasks queue for shared resources. Engineers context-switch between programs. Lead times extend. Defect rates rise. By trying to do everything, the organization accomplishes less than if it had focused on fewer initiatives. Figure 5. Starts control as the gate between candidate ideas and the active pipeline. Only projects that pass the gate consume engineering capacity. The resource capacity problem The mechanism is well-documented in queueing theory. Reinertsen applied the math of M/M/1 queueing systems to product development and showed that wait time grows nonlinearly with utilization [4]. At 60% utilization, queue time is short and predictable. At 90%, it has multiplied roughly nine-fold. At 95%, it spirals. The curve is exponential, not linear — small overcommitment produces large schedule damage. Goldratt reached the same conclusion from a different starting point [5]. His Theory of Constraints framed multitasking as the silent throughput killer in any system where work units are interdependent. His prescription — limit work-in-progress, focus on the bottleneck, finish what you start — is the operational complement to Reinertsen's quantification of why. The two frameworks reach the same place: accelerate complex work by reducing the number of things in flight, not by increasing them. Modeling constraints — budget and headcount Step 6 of the ZBB process translates the unconstrained ranking into a feasible portfolio. Two constraint forms cover most cases. The simplest is total R&D budget per project, expressed in dollars over the planning window. The more granular is engineering headcount per project per quarter, which captures the skill-mix reality the dollar number obscures. -- 15 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 16 Figure 6. Resource capacity assessment with cumulative headcount plotted against the available capacity ceiling. The line between funded (above) and deferred (below) is explicit. Projects are loaded in priority order. As each project is added, its resource demand accumulates. The point at which cumulative demand crosses the constraint ceiling defines the line. Projects above the line are funded and staffed. Projects below the line are deferred, descoped, or killed. The exercise is not static. The constraint model is re-evaluated whenever priorities shift, projects complete, or capacity changes. The cost-benefit sweet spot Cost-benefit analysis at the portfolio level reveals an effect that is intuitive once seen but rarely acted on: portfolio benefit does not scale linearly with investment. The first dollars deployed fund the highest-priority projects and deliver disproportionate value. As lower-priority projects get added, marginal return diminishes. At some point, the next project delivers negligible incremental benefit while consuming significant resources and adding management overhead. -- 16 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 17 Figure 7. The portfolio sweet spot. Below the spot, the organization is under-investing and leaving value on the table. Above it, additional investment yields diminishing returns and risks overloading execution capacity. The sweet spot is the investment level where the benefit curve begins to flatten. Cooper, Edgett, and Kleinschmidt's benchmarking data confirms this empirically across hundreds of companies: the best-performing portfolios are not the largest ones, they are the ones tuned to the marginal-benefit point [3]. The optimal portfolio is not the one that funds every good idea. It is the one that maximizes total delivered value within realistic constraints. Determining when projects start With the constrained portfolio defined, starts control governs the timing of project initiation. The decision inputs are explicit: the project's position in the priority ranking; availability of the specific engineering skills and infrastructure required; current utilization of shared resources; status of any predecessor projects or technology dependencies; and the business case including the cost of delay if the start is pushed. When a project completes or is killed, the freed capacity flows to the next project in the priority queue. This pull-based system keeps the pipeline loaded to capacity but never overloaded. It also creates natural urgency: teams know that finishing their current program faster directly enables the next priority to start, which most teams find motivating once the system is visible to them. Key finding. Starting fewer projects is the highest-leverage lever on cycle time available to the organization. The mechanism is mechanical — queue length governs flow — and the data has been documented across software, hardware, manufacturing, and service organizations for four decades. -- 17 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 18 05 Section five Decision rights inside the portfolio A portfolio process is only as effective as the governance that sits behind it. The most analytically rigorous AHP model produces no decisions if no one is accountable for making the call. Section five covers the decision-rights model that lateralworks uses to prevent governance collapse: the IRADP framework, adapted from Rogers and Blenko's RAPID work at Bain. -- 18 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 19 Section five Decision rights inside the portfolio The fundamental governance question for any portfolio is who decides what enters the active pipeline. The default answer in most organizations is "the leadership team" or "the executive staff." Both formulations describe a committee, and committees optimize for consensus rather than for cycle time. When a committee owns the portfolio, the path of least resistance is to add another project to the active list rather than to say no to the executive whose project would be deferred. Rogers and Blenko's research at Bain showed that organizational speed correlates strongly with decision-rights clarity, and that unclear rights account for the majority of slow strategic decisions in their dataset [7]. Their RAPID framework names five roles for any decision: Recommend, Agree, Perform, Input, and Decide. lateralworks uses an adapted variant called IRADP, which reorders the roles into the explanatory hierarchy below. Figure 8. What are the decision roles and who occupies them. Each role is named, each role is assigned to a specific person, and the Decider is singular. "A good decision executed quickly beats a brilliant decision implemented slowly." Who occupies each role Input is provided by anyone with relevant data or perspective. Functional managers contribute information on resource availability and skill mix. Customer-facing teams contribute voice-of-customer signal. Engineering leads contribute feasibility judgments. Input is consultation, not authority — the input role does not trigger debate or escalate decisions. Recommends is the role that does the actual analytical work. The recommender gathers data from the input network, builds proposals, runs the AHP model, and prepares the constraint analysis. The recommender also builds buy-in along the way — walking through the model with the people whose work it affects so the consolidation workshop is a refinement rather than a first exposure. -- 19 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 20 Agrees has veto power. The agree role triggers debate when a recommendation conflicts with a constraint that the recommender did not see. In a portfolio process, this is typically a functional VP whose organization would be asked to deliver beyond its capacity, or a finance leader whose budget envelope would break. Veto leads to a modified proposal or escalation to the Decider — not to indefinite stalemate. Decides is the role that makes the call. The Decider is singular. They resolve impasses, commit the organization, and are accountable for the outcome. In a portfolio context, the Decider is most often the general manager, division head, or product line leader who owns the P&L. In a startup, it is the CEO. The critical design choice is that the role is owned by one person. Without a single Decider, decisions devolve into consensus-seeking that avoids the hard trade-offs. Performs is the role that executes the decision. In portfolio governance, the recommenders are typically also the performers — they run the workshop, update the model, and communicate the outcome. The roles are different even when the people are the same, and naming them separately preserves the distinction. Why a single Decider matters The most diagnostic governance pathology in slow organizations is a portfolio that no one owns. When ownership is plural, every individual stakeholder is incentivized to protect their own projects, and the equilibrium is a bloated active list with no one accountable for the cycle-time outcome. A single Decider — with the authority to say no, the visibility into the trade-offs, and the accountability for the calendar — is the structural mechanism that breaks the equilibrium. In the IRADP context, the portfolio owner is the Decider for what enters the pipeline. Functional managers provide input on resource availability. Product managers and recommenders run the AHP model and propose start orderings. Engineering and finance leadership must agree the proposal is feasible. But one person decides, and the decision is binding for the planning horizon. Key finding. Governance without accountability produces no decisions. The organizational performance lever is naming a single Decider for the portfolio, with explicit authority and explicit cycle-time accountability. -- 20 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 21 On focus The constraint that matters The most important variable in product development is queue length, not utilization or efficiency. — Donald G. Reinertsen The Principles of Product Development Flow (2009) -- 21 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 22 06 Section six Outside research that anchors the discipline The lateralworks portfolio discipline is not an opinion. It is the operational synthesis of four decades of independent research streams that converge on the same conclusions: rank without constraints first, gate against capacity second, name a single Decider, do fewer things at once. Section six walks the streams and shows how each one supports a specific element of the FTTM practice. -- 22 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 23 Section six Outside research that anchors the discipline Six research streams supply the empirical foundation for the portfolio discipline described in sections two through five. Each stream developed independently, in a different field, and each reaches the same conclusion from a different starting point. The convergence across streams is the strongest argument for the discipline: it is not a theory from one school but a pattern that shows up wherever complex work is governed against finite capacity. Saaty and the Analytic Hierarchy Process Thomas Saaty developed AHP at the Wharton School in the 1970s to solve a class of decision problems that classical optimization could not handle: multi-criteria decisions where the criteria themselves had different weights, and where the weights were subjective rather than objective [1]. His insight was that humans make pairwise comparisons more reliably than they make absolute rankings, and that pairwise comparisons can be combined into a consistent eigenvector through a well-defined matrix operation. AHP has since been applied across thousands of domains — capital allocation, supplier selection, public policy, medical diagnosis. The portfolio prioritization use case is a direct application of Saaty's original framework. Cooper, Edgett, and Kleinschmidt on portfolio management Robert Cooper's Stage-Gate process [11] is the most widely adopted innovation framework in industry, and Cooper's subsequent benchmarking work with Edgett and Kleinschmidt at McMaster University documented portfolio management as the single highest-leverage practice that distinguishes best-in-class innovators from the rest [2, 3]. Their data, drawn from hundreds of firms across two decades, shows that the firms with explicit portfolio processes — strategic buckets, scoring models, go-kill discipline — ship significantly more new products on time and at higher hit rates than firms without. Their research is the empirical case for treating portfolio governance as a first-order strategic capability rather than as an administrative function. Reinertsen on queue length and cost of delay Donald Reinertsen's Principles of Product Development Flow [4] is the source for the queueing-theory analysis of starts control. Reinertsen showed that product development behaves mathematically like a telecommunications network: introduce variability and increase utilization, and queue times grow exponentially. His second contribution was the cost-of-delay framing — the right performance metric is not utilization but the revenue impact of each week of schedule slip. Both insights are foundational for starts control: the queue math explains why overloading creates so much schedule damage, and the cost-of-delay frame explains why leaving capacity unused is the rational choice. Goldratt and the Theory of Constraints Eliyahu Goldratt's Theory of Constraints, articulated in The Goal and extended in Critical Chain [5], reaches the same conclusions as Reinertsen from a different methodological starting point. Goldratt's focus was the manufacturing shop floor, where multitasking on machine tools and shared resources destroyed throughput. His prescription — limit work-in-progress, identify the system's constraint, subordinate everything else to the constraint — maps directly onto product development portfolio management. The starts control mechanism is the WIP limit. The shared engineering capacity is the constraint. The portfolio discipline subordinates everything else to keeping that constraint productive. Wheelwright and Clark on the aggregate project plan -- 23 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 24 Steven Wheelwright and Kim Clark's Revolutionizing Product Development [6] introduced the aggregate project plan: an organization-wide view of all active development projects, classified by type, sized by resource demand, and sequenced deliberately rather than accreted by accident. Their case studies across automotive, semiconductor, and consumer electronics firms documented 30 to 50 percent cycle-time reductions in organizations that adopted the aggregate-plan discipline. The lateralworks portfolio process is an operational implementation of the aggregate project plan with the AHP scoring layer added. Rogers and Blenko on decision rights Paul Rogers and Marcia Blenko's 2006 Harvard Business Review article "Who Has the D?" [7] is the source of the RAPID framework that lateralworks adapts as IRADP. Their research at Bain showed that decision-rights clarity correlates strongly with both organizational speed and execution quality, and that ambiguous rights are a leading explanation for slow strategic decisions. The single-Decider principle in section five is a direct application of their finding that without one accountable person, decisions devolve into committee dynamics. Convergence across streams The streams are independent. Saaty came from operations research at the University of Pennsylvania. Cooper's work was done at McMaster University in Ontario. Reinertsen built his framework as an industry consultant. Goldratt was a physicist who turned to manufacturing. Wheelwright and Clark were Harvard Business School researchers. Rogers and Blenko worked at Bain. They did not coordinate, they did not cite each other (in most cases), and they reached the same conclusions about how complex work is governed: rank candidates rigorously, limit work in progress, name single accountability, and subordinate everything else to finishing what you started. Key finding. The portfolio discipline is not derived from a single school. It is the operational pattern that emerges when multiple independent research streams are read together, and it has held up across forty years of empirical validation in software, hardware, manufacturing, and services. -- 24 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 25 07 Section seven Implementation: making it real Implementing the portfolio discipline is not a one-time event. It is a sustained organizational change that runs on a regular cadence, with explicit triggers for unscheduled review and explicit feedback loops to keep the model honest. Section seven walks the implementation sequence and the operating cadence that has worked across lateralworks engagements. -- 25 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 26 Section seven Implementation: making it real Figure 9. The portfolio modeling flow. The model without constraints ranks projects by strategic fit and economic test (projects below the line are eliminated). The model with constraints prioritizes starts against the reality of resources, budgets, risks, and dependencies. Execution refines the model with time-phased information; the loop iterates. Step one: stand up the model The first step is to populate the AHP model for a single product line or division. A lateralworks engagement typically runs this as a four-week sprint. Week one: gather the project list. Week two: define criteria and rating scales. Week three: stakeholders make individual pairwise judgments. Week four: consolidation workshop. The output is a constrained portfolio with named owners and a visible line between funded and deferred projects. The decisive choice in the first sprint is who facilitates the workshop. The right facilitator is neutral on the outcome — not invested in any specific project surviving the constraint cut. In most engagements this is an outside consultant or a corporate strategy lead with no operational stake. The wrong facilitator is a functional VP whose own programs are on the candidate list. They cannot help advocating, and the workshop loses its analytical character. Step two: implement starts control governance With the model standing, the governance structure is the next piece. Assign the portfolio Decider — one person, named in writing, with explicit authority over what enters the pipeline. Establish the review cadence: quarterly for strategic and economic reassessment, monthly for portfolio health checks, weekly for execution-level refresh planning. Define the emergency review triggers in advance. -- 26 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 27 Figure 10. Who owns the portfolio. The Decider runs the diagnostic on the left (strategic fit, business-product mapping, fuzzy front end governance, decision-making process, WOW product count, roadmap interface), the constraint diagnostic on the right (resource alignment, impact of new starts, cycle-time of front-end and development), and the cost-benefit sweet spot above. The strategic, economic, and start-priority columns make the constraint cut visible to everyone. Common emergency triggers include loss of a key customer, significant change in available engineering capacity, a major project delay that threatens to consume capacity earmarked for the next priority, and a competitive event that changes the cost-of-delay calculus. The triggers should be defined during the requirements and feasibility phases of each program so the threshold for escalation is objective rather than emotional. Step three: integrate with the broader system Figure 11. The complete FTTM portfolio management system. Business strategy and product strategy feed the model; new ideas and starts control gate the pipeline; execution and performance management close the loop. The portfolio process does not stand alone. It connects upstream to business strategy (which defines the strategic buckets), parallel to product strategy (which translates buckets into roadmaps), and downstream to -- 27 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 28 project execution and performance management. The connections matter as much as the model itself. A portfolio that produces good rankings but is disconnected from how the organization actually executes — because performance management still tracks utilization rather than cost of delay, or because product strategy is generating new opportunities faster than the gate can absorb them — will not deliver the cycle-time benefit that the analytics suggest. Step four: iterate and improve Hold quarterly reviews of projects, phases, and priorities for each segment. Include a feedback session on the process and tooling. Refine criteria weights as the organization learns which criteria actually predict project success and which were directional but not decisive. The model is not static. It is a living representation of how the organization makes its largest capital-allocation decisions, and it should improve every cycle as the data quality improves. Common implementation pitfalls Three failure modes recur often enough to be worth naming. The first is using AHP to ratify a predetermined answer. A leadership team that has already decided which two projects they want funded, and is running the model to validate the decision, will arrange the criteria weights to produce that output. The model is a transparency tool, not an arbitration tool, and it loses its value when used for the latter. The second is letting the constraint analysis become private. When the line between funded and deferred is hidden, the projects below the line continue to consume capacity informally — a half-headcount here, a side analysis there. The constraint discipline only works when the line is visible to everyone, including the engineers whose programs sit just below it. The third is letting the Decider role drift back to a committee. Within six months of a successful first cycle, the organization's default committee dynamics tend to reassert themselves. The portfolio Decider needs explicit reinforcement from the executive layer above — visible meetings, written authority, and consistency in escalation paths — or the role erodes back into consensus. -- 28 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 29 08 Section eight Conclusion The portfolio discipline solves one problem: ensuring that the right projects start at the right time, given the reality of finite resources. The mechanics are simple. The discipline to sustain them is what separates organizations that ship on calendar from organizations that do not. -- 29 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 30 Section eight Conclusion Six principles run through this paper. Each is structural, codifiable as policy, and observable in operating practice. Principle Application Rank without constraints first Use AHP pairwise comparisons to rank projects by strategic and economic value before applying resource limits. This prevents constraint-driven thinking from distorting the priority signal. Apply constraints second Model budget and headcount limits to determine what can actually be funded. The line between funded and deferred is explicit, transparent, and driven by data. Find the sweet spot Use cost-benefit analysis to identify where marginal returns diminish. Do not fund every good idea. Fund the portfolio that maximizes total delivered value. Gate pipeline entry Starts control prevents overloading. Projects enter the active pipeline only when capacity exists and priority warrants it. Starting fewer projects means more finish on time. Assign a single Decider One person owns the portfolio. They resolve impasses, make trade-offs, and commit the organization. Governance without accountability produces no decisions. Iterate continuously The portfolio model is not a static plan. Regular review cadences, emergency triggers, and feedback loops keep the portfolio aligned with reality. Table 2. Six core principles of FTTM portfolio prioritization and starts control. The methodology is tool-supported but not tool-dependent. lateralworks uses an Excel-based AHP implementation called fastDecisionAI that any product organization can adopt. The principles above — transparent prioritization, explicit constraint modeling, disciplined starts control, clear decision governance — apply to any product development organization that needs to do more with less by doing less at once. For semiconductor and systems-product organizations operating against external customer dates and competitive technology windows, the prescription is operational. Stand up the AHP model in a focused four-week sprint. Name the Decider. Make the constraint line visible. Run the cadence. The cycle-time benefit shows up within two quarters — not as a theoretical projection, but as an observable shift in the proportion of programs that hit their original dates. -- 30 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 31 The discipline is the deliverable. AHP is a method. Starts control is a mechanism. The IRADP framework is a structure. The organizational benefit comes from running all three together, on a cadence, with a single Decider, until the practice becomes the default mode of how the portfolio operates. -- 31 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 32 R Sources References The references below are the primary sources for the empirical and methodological claims in this paper. Citations are numbered in order of first appearance in the body. Reference 10 cross-links to the companion lateralworks paper on the optimal project load; reference 13 represents lateralworks engagement data across two decades of programs. -- 32 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 33 Sources References [1] Saaty, T. L. The Analytic Hierarchy Process: Planning, Priority Setting, Resource Allocation. McGraw-Hill, 1980. Republished by RWS Publications, 1990. [2] Cooper, R. G., Edgett, S. J., and Kleinschmidt, E. J. "Best Practices for Managing R&D Portfolios." Research-Technology Management, 41(4), 1998, pp. 20–33. [3] Cooper, R. G., Edgett, S. J., and Kleinschmidt, E. J. Portfolio Management for New Products. 2nd edition, Basic Books / Perseus, 2001. [4] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [5] Goldratt, E. M. Critical Chain. North River Press, 1997. [6] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. The Free Press, 1992. [7] Rogers, P., and Blenko, M. "Who Has the D? How Clear Decision Roles Enhance Organizational Performance." Harvard Business Review, January 2006, pp. 53–61. [8] Project Management Institute. Pulse of the Profession: The High Cost of Low Performance. PMI, 2014, and annual updates 2015–2024. [9] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd edition, John Wiley & Sons, 1998. [10] lateralworks. "The optimal project load: how dedicated resources accelerate new product development." Methodology paper, FTTM Best Practices Series, May 2026. [11] Cooper, R. G. "Stage-Gate Systems: A New Tool for Managing New Products." Business Horizons, 33(3), 1990, pp. 44–54. [12] Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975 (anniversary edition 1995). [13] lateralworks. "Internal engagement database." Field observations across client programs in semiconductors, systems, medical devices, and industrial products, 2010–2026. [14] McKinsey & Company. "What Makes Product Teams Effective?" McKinsey Digital, 2024. [15] Isaacson, W. Steve Jobs. Simon & Schuster, 2011. -- 33 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 34 A Appendix A Altera — programmable logic Altera Corporation, the programmable logic semiconductor company acquired by Intel in 2015, ran a multi-segment portfolio across industrial, automotive, military, communications, and computer/storage markets. Altera adopted the FTTM portfolio discipline at division level under the name "ABC Division Planning Process" and used it to govern the flow of FPGA, IP, and platform development programs through a sequence of phases from strategy to launch. The discipline survived the Intel acquisition and the patterns documented here are representative of how the methodology lands inside a multi-billion-dollar semiconductor business unit. This appendix walks the implementation. The strategic and economic filters from section two of this paper sit at the top of the flow. The AHP-based prioritization model from section three lands as the "fastDecisionAI" tool used by every product line manager. The starts control mechanism from section four operates as a sequence of phase gates — strategic, requirements, feasibility, execution, go-to-market — with explicit emergency-review triggers defined at each gate. The decision rights from section five map onto the named roles in the flow: PLM as the recommender and downstream phase owner, engineering manager as agreer at the requirements-to-feasibility gate, and the executive staff as Decider on segment-level budget. -- 34 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 35 Figure A1. The Altera ABC Division Planning Process: a nine-stage sequence from strategic plans to go-to-market, with named role ownership (PLM, Executives, Engineering Manager) at every stage. Section A.1 How the discipline maps to the FTTM model The Altera flow lines up with the FTTM portfolio discipline at every level. The first three stages — strategic plans, budget decision, and project prioritization — are exactly the strategic and economic filters described in section two. The strategic plan stage establishes which market segments and sub-segments belong in the portfolio at all (smart energy, ADAS, industrial communications, radar). The budget decision stage allocates resource and external spend envelopes across the segments. Project prioritization within each segment is then the unconstrained AHP ranking that section three describes — and Altera used the fastDecisionAI tool to do it. The downstream stages — requirements, feasibility, execution, and go-to-market — are the active pipeline. Once a project clears the project-prioritization gate, it consumes engineering and marketing capacity and proceeds through milestone reviews until release. The sign-off gates between phases function as starts-control checkpoints within the active pipeline: requirements signed off by the engineering manager before kickoff, functional description and engineering plan signed off by the PLM before development begins. Section A.2 -- 35 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 36 Five weighted criteria with sub-criteria Figure A2. Altera's five portfolio criteria with definitions and rating scales: high revenue, strong strategic fit, engage with market maker, strong value proposition, low execution risk. The strategic fit criterion is decomposed into market-alignment and technology-alignment sub-criteria to prevent subjective application. Two design choices in the Altera criterion set are worth noting. First, the strategic fit criterion is decomposed into market alignment and technology alignment sub-criteria — and the rating scale forces a count of which sub-criteria a project actually meets ("full" requires all of them, "partial" requires three of them, "weak" is below three). This prevents the ambiguity that the abstract phrase "strategic fit" invites. Second, the market-maker criterion has three discrete states — agreement, high confidence, uncertain — each with documented preconditions ("market maker has agreed to use Altera if their requirements are met", "customer commitment is proven through documentation"). This converts what would otherwise be a sales-team opinion into an evidence-based rating. -- 36 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 37 Key finding. Definitions that include preconditions, not adjectives, are what make AHP criteria operate consistently across stakeholders. "Agreement" with three documentary preconditions is a different kind of category than "strong customer interest" — the first survives a personnel change, the second does not. Section A.3 AHP weighting with the fastDecisionAI Altera implemented the AHP model in a Microsoft Excel-based tool called fastDecisionAI. Each PLM owned a workbook tab for their segment (industrial, automotive, military, computer/storage, communications), and the tool walked stakeholders through the pairwise comparison process described in section three. The output was a weighted criteria profile and a ranked list of projects, with a budget envelope and cost-benefit analysis built into the same workbook. Figure A3. The fastDecisionAI weight profile output for one Altera segment. High revenue carries the largest weight at 39.2%, strategic fit second at 25.2%, market-maker engagement third at 15.6%. Low execution risk receives only 4.5% weight in this segment — execution risk is real but is not a primary lever for priority order. The weighting profile in Figure A3 is one segment's consensus output. A different segment with different market dynamics produced a different profile — the market-maker criterion typically carried more weight in segments with one or two dominant key-account customers, and less weight in segments with many smaller buyers. The model supports this segment-specific calibration directly: each PLM held their own pairwise judgments in their own workbook tab, and the executive staff compared segments at the budget-decision gate using the model's cross-segment view. Per-PLM workbook ownership is the operational expression of the IRADP decision-rights model from section five. The PLM is the recommender inside their segment — they gather input from engineering, marketing, and key-account managers, run the AHP weighting workshop, and produce the ranked candidate list. The general manager and executive staff are the agreers and the Decider at the cross-segment level: they -- 37 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 38 accept or reject the budget allocations across segments, then trust each PLM's within-segment ranking. This split — within-segment rankings owned by the PLM, cross-segment allocation owned by the executive — keeps the governance load proportional to the decision being made. Section A.4 Phase tracking and emergency review The Altera flow runs each project through a sequence of phases — requirements, feasibility, execution, go-to-market — with formal sign-off gates between them. The fastDecisionAI tool tracked phase state alongside the priority ranking, so the executive view of the portfolio showed both ordering (what should we be doing) and state (what stage is each one in). This single-tool combination of strategic and operational view is the reason the discipline survived a decade of Altera leadership changes — the ranking and the pipeline state lived together rather than in separate spreadsheets owned by separate people. The emergency-review mechanism deserves particular attention. The Altera process required each project to declare up to three marketing triggers and up to three engineering triggers at the requirements and feasibility phases — concrete, objective conditions that, if breached, would force an unscheduled portfolio review. Common triggers were loss of a market-maker customer, change in market conditions that invalidated the original total-addressable-market estimate, significant engineering schedule slip, or loss of key engineering capacity. The triggers were not abstractions — they were named thresholds with defined values, set at the start of the project when judgments were sober rather than under the pressure of a slip already in progress. Key finding. The right time to define the threshold for an emergency portfolio review is before the project starts. Altera codified up to three marketing and three engineering triggers per program at the requirements and feasibility gates — concrete conditions whose breach would force unscheduled re-prioritization. Defining them early made the escalation objective. Trying to define them in the middle of a slip would have made the escalation political. The emergency review panel at Altera was not the full executive staff. It was a small group — division senior VP, general manager, and directors most affected by the project — convened on demand. This is the mechanism that prevents the trigger system from collapsing into "another standing meeting." Triggers fire rarely, the panel forms rarely, and when it does form it acts decisively because everyone present has clear authority over the decision being made. -- 38 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 39 B Appendix B SunPower — solar cells SunPower Corporation, the solar cell and module manufacturer, ran its Cell Technology Development (CTD) organization on a paired discipline: a stage-gate process for product development governance and a zero-based budgeting (ZBB) process for engineering capacity allocation. Together they form the operational implementation of starts control described in section four of this paper. The stage-gate process names the checkpoints; ZBB is what determines which of those checkpoints actually get staffed in any given month. The case below documents two artifacts. The first is the SunPower stage-gate framework itself, which spans SG0 (ideation) through SG5 (general release) and SG6 (end-of-life). The second is a published CTD ZBB worksheet showing how 23 engineers were allocated across six priority programs over a twelve-month planning horizon — and where, in that horizon, the cumulative resource demand crossed the available capacity ceiling. SunPower called the boundary the "ZBB Line," and visualized it in red across the worksheet. It is the most concrete published example of starts control at work. -- 39 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 40 Figure B1. The SunPower stage-gate product life cycle: SG0 exploration through SG5 launch, with key deliverables named at each gate (business need at SG0, plan-of-record at SG2, limited release at SG4, general release at SG5). Section B.1 A six-stage gate framework SunPower's stage-gate framework follows the Cooper Stage-Gate model [11] adapted to solar-cell manufacturing. Each gate carries a defined review board, a checklist of expected deliverables, and a decision about whether the program continues, holds, or stops. The framework is flexible by design — small programs run a "SG-lite" subset and large programs run "SG-full" — but the named gates are constant and the governance structure around each gate is the same. Figure B2. SunPower SG intent: what each gate is meant to achieve, from converging on customer concepts at SG0 to ramping production after SG5. The plan-of-record is set at SG2 — once committed, it is under change control until launch. -- 40 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 41 Two design choices in the SunPower framework deserve emphasis. The first is the cross-organizational SG approval board: every gate review requires sign-off from nine functional areas (sponsor, customers and stakeholders, development organization, supply chain, upstream manufacturing, downstream operations, finance, quality, reliability) with explicit attendance requirements at each gate. This prevents the common failure mode where engineering signs off on its own readiness and operations later discovers that the manufacturing process is unready. The second is the change-control discipline beginning at SG2. Once the plan-of-record is set — scope, schedule, and budget all committed in writing — material changes to any of the three trigger a formal POR change review. The change-review process itself defines the threshold between routine adjustment (handled by the project core team) and cross-segment reprioritization (escalated to the SG approval board). This is the same pattern as Altera's emergency-review triggers from Appendix A — but inserted into the active pipeline rather than at the pipeline gate. Key finding. A stage-gate framework without a defined change-control discipline at plan-of-record degrades into theater within two product cycles. SunPower put the discipline at SG2 — the first gate where scope, schedule, and budget are committed — and required formal POR change reviews for every material adjustment. The result is that the gate decisions made at SG2 mean something six months later, even after the inevitable changes. Section B.2 The ZBB Line: starts control made visible SunPower's Cell Technology Development organization had 23 engineers available each month. The CTD planning team translated the stage-gate pipeline into a monthly resource-loading worksheet, with every active and proposed program decomposed into named engineer-month allocations. Programs were loaded in priority order — the unconstrained ranking from the AHP-style filter — and cumulative engineer-months were subtracted from the available pool until the pool went negative. The point at which the pool ran out was called the "ZBB Line." Programs above the line were funded; programs below the line had to be deferred, descoped, or stopped. -- 41 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 42 Figure B3. SunPower's CTD ZBB worksheet. The cells show remaining engineering capacity after each priority program is added in rank order. The horizontal red line marks the "ZBB Line" — the boundary between programs that fit (above) and programs that do not (below). Cells in pink indicate negative remaining capacity. The line crosses priority 4 — half the program fits, half does not. Priorities 5 and 6 are entirely below the line. Two observations about the worksheet are worth making. First, the line is not at a single program boundary — it cuts horizontally through priority 4 (NGT 2.0 Development), with the back-end (BE) sub-program fitting and the front-end (FE) sub-program not fitting. This is a common pattern in real organizations: programs decompose into sub-programs that have different priority, different staffing, and different durations, and the practical line falls between sub-programs rather than between programs. Second, the negative-capacity cells in the lower right of the worksheet (pink-shaded) are the explicit, visual price of attempting to start priorities 4-FE, 5, and 6 in addition to priorities 1-3. The worksheet does not just say "you cannot do it" — it shows by how much. In February it shows the team would need 3.7 more engineers than it has, in April 3.7 again, and these gaps persist through August. This is the visualization mechanism that makes the cost of overcommitment undeniable in the room: no executive can argue that 23 engineers is enough to staff -3.7 more positions. The mechanism for closing the gap is what SunPower called pipelining: a structured per-engineer review in which lower-priority work is explicitly deferred, descoped, or moved to later quarters until the monthly capacity comes back into balance. The pipelining process took each engineer's assignments and stretched the lower-priority programs across more months at lower per-month allocation, until the cumulative demand stayed under the available-capacity ceiling. The output was a realistic plan that the engineering leadership could commit to. -- 42 of 43 -- › Portfolio prioritization & starts control › › › © 2026 lateralworks Page 43 Key finding. The ZBB Line is the most direct visual expression of starts control available. Programs above the line are funded, programs below are deferred, and the line moves only when capacity changes or priorities change. The pink cells are the price of pretending the line is somewhere else than where the math actually places it. Making the line visible to every leader in the organization is what converts a theoretical capacity argument into an operational decision. Section B.3 How the SunPower discipline maps to the FTTM model The mapping from the SunPower implementation to the discipline described in the body of this paper is direct. The AHP-style unconstrained ranking from section three is the priority ordering of the six CTD programs (NGT 1.0 deployment first, NGT 1.1 deployment second, cost reduction Fab4 third, NGT 2.0 development fourth, cost reduction Fab3 programs fifth and sixth). The constraint application from step six of the AHP process is the ZBB worksheet. The starts control gate from section four is the explicit ZBB Line where cumulative demand crosses the 23-engineer capacity ceiling. The decision-rights model from section five maps onto the cross-organizational SG approval board. The board's nine functional areas are the input and agree roles in the IRADP framework. The general manager, sponsor, or technology lead serves as the named Decider depending on the gate — for SG2 plan-of-record decisions the sponsor is the Decider, for SG4 limited-release decisions the SG approval board votes by super-majority with the CEO or general manager casting the deciding vote in event of a tie. The change-control mechanism on the plan-of-record at SG2 is the SunPower analog of Altera's emergency-review triggers. Both processes name the conditions under which an active program returns to governance for re-evaluation, both require those conditions to be defined when the program is approved (not retroactively when something breaks), and both keep the bar high enough that the trigger fires rarely but predictably when it does. The two implementations differ in detail — Altera tracked triggers explicitly inside fastDecisionAI, SunPower tracked POR change reviews inside the SG documentation system — but the discipline is the same. Key finding. The two case studies in this appendix are independent confirmations of the same pattern. Altera and SunPower built their portfolio disciplines in different decades, in different industries, and without reference to each other. Both arrived at the same essential structure: unconstrained AHP-style ranking, explicit constraint modeling against real engineering capacity, named decision-rights with a single accountable Decider, and a change-control discipline that protects commitments without freezing them. The pattern is what works. -- 43 of 43 --

Portfolio·Synthesis paper

Portfolio prioritization & starts control

How to govern what enters the active pipeline so the work that starts actually finishes

Core thesis. Most product organizations start more projects than they can finish. The cure is not better execution. It is a portfolio discipline that ranks every candidate against weighted strategic and economic criteria, then gates entry to the active pipeline against real resource capacity. Rank without constraints first. Apply constraints second. One person owns the call. Starting fewer projects is how more projects finish on time.

May 10, 2026·43 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Whitepaper The optimal project load How dedicated resources accelerate new product development in semiconductors FTTM Best Practices Series. A lateralworks synthesis paper drawing on four decades of research from Weinberg, the Carnegie Mellon Software Engineering Institute, Reinertsen, Clark and Wheelwright, McKinsey, and Steve Jobs’s 1997 portfolio cut at Apple. The argument: one to two projects per engineer is the research-backed optimum for cycle time, quality, and time to market. Prepared by lateralworks FTTM methodology Date May 2026 Synthesis paper Online lateralworks.com FTTM Best Practices Series -- 1 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 2 Table of contents The optimal project load Abstract 03 01 The hidden tax—context switching 04 02 The cognitive science of focused work 07 03 The economic model: Reinertsen’s queueing theory 09 04 Case study evidence: dedicated resources, faster delivery 12 05 Application to semiconductor NPI 17 06 Recommendations 21 07 Conclusion 24 References 26 Core thesis. One to two projects per engineer is the maximum sustainable load for complex new product development. Beyond two, context-switching consumes 40 to 75 percent of working time, queue delays compound at every milestone gate, and the calendar slips by months. Dedicated cross-functional product teams — governed by an explicit portfolio and clear decision rights — are the structural fix. -- 2 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 3 Overview Abstract Most semiconductor organizations spread their best engineers across three, four, or five projects at once, on the theory that high utilization equals high productivity. Four decades of research says the opposite. Past two concurrent projects, context-switching consumes 40 to 75 percent of an engineer’s working time, queue delays compound at every milestone gate, and the calendar slips by months — not weeks. This paper synthesizes evidence from Gerald Weinberg’s foundational research on engineering productivity [1], the Carnegie Mellon Software Engineering Institute’s applied validation [2], Frederick Brooks’s work on software project staffing [3], Donald Reinertsen’s queueing-theory analysis of product development [6], Clark and Wheelwright’s heavyweight-team studies at Harvard Business School [10, 11], and McKinsey’s 2024 product-team survey data [12]. The conclusion converges from independent streams: one to two projects per engineer is the maximum sustainable load for complex new product development. Beyond two, both speed and quality degrade in a nonlinear pattern that hits semiconductor NPI especially hard, where cycle times are long, interdependencies are deep, and the cost of delay is measured in quarters of lost revenue. The same arithmetic operates at the organizational level. Steve Jobs’s 1997 portfolio cut at Apple [13, 14], Goldratt’s Theory of Constraints [5], and Smith and Reinertsen’s discipline around the fuzzy front end [8, 9] all converge from different angles: do fewer things, with more dedicated people, and every program ships faster. For semiconductor leadership teams, the prescription is structural — transition from shared functional assignments to dedicated cross-functional product delivery teams, codify the project-load limit, and govern the portfolio explicitly so creeping load doesn’t undo the discipline. lateralworks engagement data across two decades of programs supports the argument [16]: organizations that adopt the dedicated team model and govern the portfolio against cost of delay deliver to original calendar at substantially higher rates than peers that do not. -- 3 of 27 -- › The optimal project load › › › 01 Section one The hidden tax— context switching © 2026 lateralworks Page 4 A semiconductor engineer holds a complex mental model. A process engineer tracking a new integration flow keeps in working memory the interactions among hundreds of process steps, material properties, equipment constraints, and device specifications. A device engineer characterizing a novel memory cell tracks electrical parameters, endurance, retention, and reliability margins simultaneously. Asking that engineer to switch contexts is not the same as asking a knowledge worker to switch email tabs. The mental reload cost is real, and it scales with the size of the model that has to come back online. -- 4 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 5 Section one The hidden tax—context switching Most semiconductor organizations treat engineers as fungible capacity. The reasoning is intuitive: if an engineer is waiting on wafers from the fab, they should be working on the next project’s design review. Idle hands are wasted capacity. The reasoning ignores a fact about human cognition. A computer can save and restore state in microseconds. A human engineer has to mentally unload one project and reload another. The cost of that swap is real, and it isn’t small. Weinberg’s foundational research In 1992, Gerald Weinberg quantified the penalty in Quality Software Management: Systems Thinking [1]. His model, drawn from decades of observation across engineering organizations, looks like this: at one project, an engineer puts 100 percent of their time into the work. At two, productive capacity drops to 80 percent and 20 percent goes to switching overhead. At three, productive capacity is 60 percent and switching consumes 40. At five, only 20 percent of working time is productive; 75 percent is the cost of swapping contexts. Figure 1. Productive time vs context-switching loss by number of simultaneous projects. The relationship is nonlinear: a second project doesn’t cost 10 or 15 percent of available time, it costs a full 20. By five projects, only 5 percent of working time goes to each project. Source: Weinberg, 1992 [1]. The relationship is nonlinear. A second project doesn’t cost 10 or 15 percent — it costs a full 20, dropping per-project capacity from 100 to 40. By five concurrent projects, the engineer is putting only 5 percent of their time into each one. The other 75 percent is overhead. Carnegie Mellon SEI validation The Software Engineering Institute at Carnegie Mellon validated Weinberg’s model in applied engineering settings [2]. Their research confirmed the curve and added a second finding: engineers carrying multiple projects don’t only slow down. They produce more defects, miss more tasks, and disengage from the -- 5 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 6 collaborative problem-solving that complex technical work depends on. In semiconductor NPI, where a missed yield risk or an incomplete qualification plan can delay a customer milestone by a full quarter, the quality penalty compounds the schedule penalty. The connection to Brooks’s Law The same pattern appears in Frederick Brooks’s 1975 study of software development at IBM, where he observed that adding manpower to a late project makes it later [3]. Brooks’s Law and Weinberg’s switching penalty are the same physical phenomenon described from two angles. Brooks looked at what happens when you increase headcount on a project; Weinberg looked at what happens when you split each engineer’s attention. Both end at the same place: more bodies on more things produces less output, not more, when the work is complex enough to require sustained focus. Key finding. Context switching does not merely slow engineers down — it degrades the quality of their work product. In semiconductor NPI, where a missed yield risk or an incomplete qualification plan can delay a customer milestone by a full quarter, the quality penalty compounds the schedule impact. -- 6 of 27 -- › The optimal project load › › › 02 Section two The cognitive science of focused work © 2026 lateralworks Page 7 The engineering observations Weinberg and the CMU SEI documented are consistent with decades of cognitive psychology research. Switching tasks is not free. It involves two distinct cognitive operations — deciding to switch, and reactivating a different set of rules — and both consume measurable time and mental energy. The penalty is sharper for engineers whose mental models are unusually large. -- 7 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 8 Section two The cognitive science of focused work Rubinstein, Meyer, and Evans (2001) showed that every task switch involves two distinct cognitive operations: goal shifting (deciding to switch) and rule activation (deactivating one set of cognitive rules and engaging another) [4]. Both consume measurable time and mental energy. Research published in the Journal of Experimental Psychology found that switching between tasks costs the average knowledge worker 20 to 40 percent of their productive capacity. The American Psychological Association has documented that roughly 2 percent of the population can effectively multitask; the remaining 98 percent show measurable performance degradation when working across multiple complex contexts at once. The penalty is sharper for semiconductor engineers because the mental models they maintain are unusually large. A process engineer working a new integration flow holds in working memory the interactions among hundreds of process steps, material properties, equipment constraints, and device specifications. A device engineer characterizing a novel memory cell tracks electrical parameters, endurance data, retention metrics, and reliability margins simultaneously. When that engineer is interrupted to switch to a different project — different process variant, different design rules, different critical path — the cost of rebuilding the mental model is not the same as a knowledge worker switching email tabs. Multitaskers make up to 50 percent more errors than those holding focus on a single complex task. In semiconductor NPI, where errors propagate through long manufacturing cycles, that error rate translates directly into respins, qualification delays, and customer schedule slip. Goldratt and the Theory of Constraints Eliyahu Goldratt reached the same conclusion from a different starting point [5]. Goldratt observed that multitasking is the silent throughput killer in any system where work units are interdependent. His prescription — limit work-in-progress, focus on the bottleneck, finish what you start — is the operational complement to Weinberg’s quantification of why. The two frameworks reach the same place: the way to accelerate complex work is not to start more of it, but to finish what is already in flight. -- 8 of 27 -- › The optimal project load › › › 03 Section three The economic model: Reinertsen’s queueing theory © 2026 lateralworks Page 9 Reinertsen’s contribution was to apply the math of queueing theory — the same math that governs telecommunications networks and computer operating systems — to product development. The result is a single unforgiving curve: when processes with variability are loaded toward 100 percent capacity utilization, queue times grow exponentially, not linearly. This is what makes overloading engineers so destructive. Small delays don’t add. They compound. -- 9 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 10 Section three The economic model: Reinertsen’s queueing theory Donald Reinertsen’s Principles of Product Development Flow (2009) provides the mathematical framework that explains why overloading engineers creates such disproportionate schedule damage [6]. The math under the curve is Little’s Law [7]: average work-in-progress equals average throughput times average cycle time. Hold throughput constant, and cutting WIP cuts cycle time proportionally. Add WIP back, and cycle time stretches. The queue curve is what happens when you push utilization toward 100 percent in a system with any variability at all — variability creates queue buildup, and at high utilization the queue cannot drain. Figure 2. Queue time vs resource utilization (M/M/1 queueing model). The curve is exponential, not linear: an engineer at 90 percent utilization waits roughly 9x longer in queue than one at 50 percent. Engineers loaded with three or more concurrent projects operate in the 85–95 percent zone where small variability cascades into large schedule slip. Source: based on Reinertsen, 2009 [6]. Engineers carrying three to five concurrent projects are operating at 85 to 100 percent capacity utilization. At those levels, any variability in task duration — a wafer lot that takes longer than expected, a supplier delay, an unexpected test failure — creates a queue that propagates across all of the engineer’s projects. The engineer becomes the bottleneck, and every project competes for fractional attention. Cost of delay versus utilization Reinertsen’s deeper point is that the right performance metric in product development is not utilization but cost of delay. In semiconductor NPI, the cost is severe. A one-quarter delay can decide whether a product wins or loses a design socket worth tens or hundreds of millions in lifetime revenue. The "savings" from running engineers at 100 percent utilization are dwarfed by the schedule cost the overload creates. -- 10 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 11 Reinertsen’s prescription is to keep resource utilization below 80 percent — ideally 60 to 70 percent — to preserve slack for absorbing variability without queue buildup. In human terms, that is the one-to-two-project optimum: an engineer with one primary project and limited secondary responsibilities operates in the productive zone where queue times stay manageable and schedule pull-in is achievable. The same logic underlies Smith and Reinertsen’s earlier work on the fuzzy front end [8] — the period before a full development team forms is itself a queueing system, and managing it as a focused, time-boxed project is what prevents the lost months from showing up later as compression on engineering. lateralworks documented this pattern in detail in a companion methodology paper [9]. -- 11 of 27 -- › The optimal project load › › › 04 Section four Case study evidence: dedicated resources and faster delivery © 2026 lateralworks Page 12 The research evidence comes from four streams. Each examined a different population — software engineers, hardware product teams, fintech delivery groups, music-streaming squads — and reached the same conclusion: dedicated resources outperform shared resources on speed, predictability, and quality. Section 4 walks each stream in turn, then closes with the organizational analogue: Steve Jobs’s 1997 portfolio cut at Apple. -- 12 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 13 Section four Case study evidence: dedicated resources, faster delivery Figure 3. The scope of FTTM portfolio decisions. This paper sits in Project Execution — specifically the engineer-level project load and team-level dedication that determines how fast a funded program reaches first customer ship. Source: lateralworks FTTM methodology [16]. 4.1 Clark and Wheelwright: heavyweight product development teams The most directly relevant research for semiconductor organizations comes from Kim Clark and Steven Wheelwright at Harvard Business School. Their 1992 study in California Management Review examined product development team structures across automotive, semiconductor, and electronics firms [10]. Clark and Wheelwright identified four team archetypes — functional, lightweight, heavyweight, and autonomous — and found that heavyweight teams consistently outperformed lightweight and functional structures on speed and quality. The defining characteristics of heavyweight teams map directly onto the dedicated-resource model: a strong, dedicated team leader with direct customer contact and authority to make cross-functional tradeoffs; team members dedicated to the project rather than split across functional assignments; team-level ownership of full scope from concept through manufacturing release. In their six-year worldwide study, Wheelwright and Clark documented 30 to 50 percent faster development cycle times in organizations using heavyweight team structures [11]. Critically, their case base included Applied Materials — a semiconductor equipment company — establishing direct relevance to the industry. 4.2 McKinsey: 100 percent dedicated teams and delivery predictability McKinsey’s 2024 research on product-team effectiveness, drawing on hundreds of teams globally, confirmed that teams with 100 percent dedicated members who don’t context-switch between projects build -- 13 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 14 consistency in their estimates, and their velocity and throughput improve [12]. A global fintech the firm studied moved to multidisciplinary teams with dedicated talent from product, technology, and operations. Within three months of the transition, delivery predictability moved from 60 to 95 percent. The shift came almost entirely from eliminating resource-sharing and context switching. 4.3 The Spotify model: autonomous squads Spotify’s well-documented organizational model offers a scaled implementation case. Organizing development into autonomous, cross-functional squads — each dedicated to a single product area with no shared resources — produced a reported 20 percent reduction in delivery time and a 20 percent gain in employee satisfaction. The dedication and ownership, not the resource pooling, drove both. 4.4 Steve Jobs and Apple: the portfolio-level imperative Figure 4. Portfolio decision-making flow. Strategic and economic filters determine what enters the pipeline; ordering inside the pipeline determines what gets attention; learning from outcomes feeds back into the next cycle. Apple’s 1997 portfolio cut is the canonical example of aggressive filtering at the entry stage. Source: lateralworks FTTM portfolio methodology. The research above operates at the individual level: limit each engineer to one or two projects and productivity rises. There is a parallel principle at the organizational level — limit the number of products the company pursues, and the entire engineering organization accelerates. The cleanest demonstration came from Steve Jobs’s return to Apple in 1997. Apple was producing a dozen versions of the Macintosh along with peripherals, printers, and failed experiments like the Newton PDA and the Pippin game console. Multiple teams with overlapping mandates competed for engineering talent. No product received the focus required to be excellent. After several weeks of product reviews, Jobs drew a two-by-two grid on a whiteboard. Columns: Consumer, Pro. Rows: Desktop, Portable. Apple would make four products, one per quadrant, and cancel everything else [13]. Walter Isaacson recorded Jobs’s framing: Deciding what not to do is as important as deciding what to do. That’s true for companies, and it’s true for products. Jobs reinforced the discipline annually — gathering his top 100 leaders, soliciting their ten most important priorities, then slashing seven, on the principle that Apple could only do three things well at once [14]. -- 14 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 15 The result was structural. Cutting 70 percent of the portfolio did not just reduce overhead; it changed the resource dynamics. Apple’s best engineers, previously scattered across a dozen mediocre products, were now concentrated on four. Cycle times compressed: major new product revisions began shipping every nine months instead of eighteen. The iMac, the first product of the focused strategy, shipped within a year and defined a category. The Apple case ties the threads together. Weinberg and CMU SEI explain the cost when individual engineers carry too many projects. Reinertsen explains the queue-time explosion when shared resources run at high utilization. Brooks’s Law explains why throwing more bodies at the problem makes it worse. Jobs demonstrated the organizational solution: with a fixed pool of engineering talent, the surest way to accelerate every product is to reduce the number of products competing for that talent. Fewer products means more dedicated attention per product, less context-switching at the individual level, shorter queues at the organizational level, and faster cycle times across the board. For semiconductor organizations, the lesson is direct. Pursuing every plausible product variant, technology node, or market segment looks attractive in isolation — each opportunity has independent value. But when the same finite pool of process engineers, device physicists, and design teams is spread across all of them, every program slows down, every milestone slips, and the organization delivers many products late rather than a few products on time. The discipline to define a focused portfolio — and to protect that focus against the constant pressure to add "just one more" — is the organizational complement to the individual project-load limit. -- 15 of 27 -- On focus What not to do Deciding what not to do is as important as deciding what to do. — Steve Jobs Recounted in Walter Isaacson, Steve Jobs (2011) © 2026 lateralworks Page 16 -- 16 of 27 -- › The optimal project load › › › 05 Section five Application to semiconductor NPI © 2026 lateralworks Page 17 Three structural ingredients distinguish a dedicated product team from a shared functional one: dedication itself (the one-to-two-project limit), explicit decision rights inside the team (so cross-functional tradeoffs don’t escalate upstream), and portfolio-level ownership above the team (so creeping load doesn’t silently undo the dedication). All three matter. Without dedication, capacity bleeds to context switching. Without decision rights, even dedicated teams stall in committee. Without portfolio ownership, project starts pile up faster than the organization can finish them. -- 17 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 18 Section five Application to semiconductor NPI The evidence converges on a clear conclusion: dedicated resources organized around products, not functions, produce faster and higher-quality new product development outcomes. For semiconductor organizations, the implication is structural — transition from shared functional assignments to dedicated cross-functional product teams, with named portfolio ownership above them and named decision rights inside them. 5.1 Why semiconductors are especially vulnerable Semiconductor NPI programs have several characteristics that make them especially susceptible to engineer overloading. Development cycles are long — typically 18 to 36 months from concept to production release — so context-switching delays compound across many months and many milestone gates. The work is deeply interdependent across functional disciplines: process development, device engineering, integration, design, and product qualification. A delay in one function creates queue delays in all the others. Manufacturing variability is inherent to the work — wafer processing, material properties, equipment performance — so the queue-time explosion Reinertsen models is not theoretical risk but daily operational reality. Semiconductor NPI now operates against external dates: customer platform launches, competitive technology windows. Missing a milestone doesn’t just push revenue out by a quarter. It can lose the design socket to a competitor outright, or close the differentiation window that justified the program in the first place. The cost of delay in this context is measured not in incremental development expense but in hundreds of millions in foregone lifetime product revenue. -- 18 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 19 Figure 5. Portfolio ownership: who decides what to start, in what order, against what economic and resource constraints. Strategic fit and economic test filter what enters the pipeline; the 80/20 cost–benefit logic determines start order; resource constraints — including the one-to-two-project-per-engineer limit — govern how many programs can be in flight at once. 5.2 Decision rights inside the dedicated team A dedicated team is necessary but not sufficient. Without explicit decision rights inside the team, the dedicated structure fragments back into committee dynamics — every cross-functional tradeoff goes back upstream for resolution, and the team’s structural advantage disappears. Figure 6. The IRADP framework adapted from Rogers and Blenko’s RAPID work [15]. Inside a dedicated product delivery team, the team lead occupies Decides for cross-functional tradeoffs the team owns; functional managers occupy Decides for the small number of decisions that genuinely cross product boundaries. Source: Rogers & Blenko, HBR 2006 [15], adapted by lateralworks. -- 19 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 20 The IRADP framework adapted from Rogers and Blenko’s RAPID work [15] makes the structure explicit: who provides Input (consulted, involved in implementation), who Recommends (gathers data, prepares proposals, builds buy-in), who Agrees (has veto power, triggers debate, can escalate), who Decides (makes the call, is accountable, commits the organization), and who Performs (executes the decision). Naming each role removes the ambiguity that makes shared-resource organizations slow. Inside a dedicated product delivery team, the team lead occupies Decides for cross-functional tradeoffs the team owns; functional managers occupy Decides for the small number of decisions that genuinely cross product boundaries. The 80/20 split between team-owned decisions and function-owned decisions is what operationalizes the boundary between team autonomy and functional management. This is the missing structural piece in many "dedicated team" rollouts. Companies form the team, dedicate the people, and discover that decisions still escalate to functional VPs — because nobody wrote down who decides what. Once IRADP is explicit, the team can move at its own velocity, and the functional layer’s role is clear: accountable for capability development, not for individual project decisions. 5.3 Time-to-market impact Three acceleration effects compound when engineers are dedicated to a single product family at the one-to-two-project limit. First, the 20 to 40 percent of capacity currently lost to context switching is recovered and applied to productive engineering work. Second, queue delays between milestone gates are eliminated, because engineers are not competing for fractional attention across multiple products. Third, deeper product knowledge from sustained focus produces better technical decisions, fewer errors, and more effective cross-functional collaboration — all of which contribute to schedule pull-in rather than schedule slip. Based on the research evidence and case-study precedents, the combined effect is a 25 to 40 percent acceleration in NPI cycle time — equivalent to 6 to 10 months on a typical 24-month semiconductor development program. In competitive markets where technology windows are finite and every quarter of delay reduces strategic position, that acceleration is not incremental. It is the difference between leading a generation and following one. -- 20 of 27 -- › The optimal project load › › › 06 Section six Recommendations © 2026 lateralworks Page 21 Four prescriptions follow from the research. Each is structural, not aspirational — codifiable as policy, observable in operating practice, and directly tied to the cycle-time outcome the organization is trying to produce. The recommendations apply to any semiconductor organization transitioning from shared functional assignments to dedicated cross-functional product teams. -- 21 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 22 Section six Recommendations Figure 7. The portfolio modeling loop. Strategic fit and economic test eliminate projects below the line; the constrained model prioritizes starts against real resources, budgets, risks, and dependencies. The loop iterates as time-phased information arrives — macro plans for resources, business plans for ROI and cost of delay. This is the operational discipline that prevents creeping load. 6.1 Establish the one-to-two-project maximum Every engineer on a dedicated product team should carry no more than two concurrent project assignments, with one designated primary. This is not a guideline — it is the research-backed optimum for preserving productive capacity and the quality of complex engineering work. Codify the limit as a non-negotiable organizational norm, embedded in resource planning processes and management operating systems. 6.2 Dedicate embedded leads to single product families Cross-functional team leads — whether organized as triads, squads, or heavyweight teams — should be dedicated to a single product or technology workstream. They should not be shared across multiple concurrent programs. Both the Clark and Wheelwright research [10, 11] and the McKinsey data [12] show that this single dedication is the highest-leverage structural change an organization can make to accelerate product development. 6.3 Protect against creeping load Organizations that establish project-load limits often erode them incrementally. A small side task here, a quick analysis there, a brief consultation on a third workstream — each insignificant in isolation, collectively pushing engineers back into the three-plus project zone where switching costs dominate. Team leaders must monitor and protect their team’s focus actively. The weekly planning cycle is the natural checkpoint; the modeling-flow loop above (strategic fit → economic test → prioritize starts → execute → iterate) is the -- 22 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 23 governance discipline that keeps creeping load from becoming the new normal. 6.4 Measure cost of delay, not utilization Following Reinertsen [6], shift the primary performance metric from resource utilization (how busy are our engineers?) to cost of delay (what is the revenue impact of each week of schedule slip?). When the organization sees that running engineers at 100 percent utilization creates queue delays worth millions in lost or delayed revenue, the case for dedicated resources stops being a debate and becomes self-evident. lateralworks engagement data across two decades of semiconductor and systems-product programs supports the claim [16]: organizations that adopt the dedicated team model and govern the portfolio against cost of delay deliver to original calendar at substantially higher rates than peers that do not. -- 23 of 27 -- › The optimal project load › › › 07 Section seven Conclusion © 2026 lateralworks Page 24 The evidence is clear and converges from multiple independent research streams across four decades. The arithmetic does not change with industry, with technology, or with management style. What changes is whether the organization chooses to act on it. -- 24 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 25 Section seven Conclusion Engineers on one to two projects retain 80 to 100 percent of their productive capacity. Engineers on three or more lose 40 to 75 percent to context-switching overhead. The losses are not only time. They include quality degradation, error propagation, queue delays, and compounding schedule slip. For semiconductor development programs where the cost of delay is measured in quarters of strategic position and narrowing market windows, the imperative is unambiguous: dedicate engineers to product and technology workstreams, limit concurrent project assignments to two, and protect that focus as a first-order strategic priority. The dedicated product team model implements the principle structurally — cross-functional teams aligned to each product or technology workstream, with clear ownership, accountable leads, and explicit decision rights. The research base in this paper provides the empirical foundation for the transition. The discipline to sustain it is the work of leadership. More dedicated resources equals faster time to market. The research is unequivocal. The question is not whether to dedicate resources to product teams — it is how quickly the transition can be executed. -- 25 of 27 -- › The optimal project load › › › R Sources References © 2026 lateralworks Page 26 The argument in this paper draws on four streams of research, each independently developed but reaching the same conclusion. Citations below are listed in order of first appearance in the body. Reference 9 cross-links to the companion lateralworks methodology paper on the fuzzy front end; reference 16 represents lateralworks’ own engagement data across two decades of semiconductor and systems-product programs. -- 26 of 27 -- › The optimal project load › › › © 2026 lateralworks Page 27 Sources References [1] Weinberg, G. M. Quality Software Management: Systems Thinking. Dorset House Publishing, 1992. [2] Waits, T. "Addressing the Detrimental Effects of Context Switching with DevOps." Carnegie Mellon University, Software Engineering Institute Blog, 2015. [3] Brooks, F. P. The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley, 1975 (anniversary edition 1995). [4] Rubinstein, J. S., Meyer, D. E., and Evans, J. E. "Executive Control of Cognitive Processes in Task Switching." Journal of Experimental Psychology: Human Perception and Performance, 27(4), 2001, pp. 763–797. [5] Goldratt, E. M. Critical Chain. North River Press, 1997. [6] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [7] Little, J. D. C. "A Proof for the Queuing Formula: L = λW." Operations Research, 9(3), 1961, pp. 383–387. [8] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd edition, John Wiley & Sons, 1998. [9] lateralworks. "Managing the Fuzzy Front End." Methodology paper, FTTM Best Practices Series, May 2026. [10] Clark, K. B., and Wheelwright, S. C. "Organizing and Leading Heavyweight Development Teams." California Management Review, 34(3), 1992, pp. 9–28. [11] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. The Free Press, 1992. [12] McKinsey & Company. "What Makes Product Teams Effective?" McKinsey Digital, 2024. [13] Isaacson, W. Steve Jobs. Simon & Schuster, 2011, pp. 337–339. [14] Isaacson, W. "The Real Leadership Lessons of Steve Jobs." Harvard Business Review, April 2012. [15] Rogers, P., and Blenko, M. "Who Has the D? How Clear Decision Roles Enhance Organizational Performance." Harvard Business Review, January 2006. [16] lateralworks. "Internal engagement database." Field observations across client programs in semiconductors, systems, medical devices, and industrial products, 2010–2026. -- 27 of 27 --

Portfolio·Synthesis paper

The optimal project load

How dedicated resources accelerate new product development

Core thesis. One to two projects per engineer is the maximum sustainable load for complex new product development; past two, context switching consumes 40 to 75 percent of working time, queue delays compound at every milestone gate, and calendars slip by months — the structural fix is dedicated cross-functional product teams governed by an explicit portfolio and clear decision rights.

May 9, 2026·27 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Whitepaper Managing the fuzzy front end Where the biggest schedule opportunity hides — and how to capture it through dedicated teams, a refreshed schedule, and a hard cycle-time target FTTM Best Practices Series. A lateralworks methodology paper on the time between portfolio commit and full-team formation — the period that consumes up to one-third of total development time and is rarely managed as a project at all. Prepared by lateralworks FTTM methodology Date May 2026 Methodology paper Online lateralworks.com FTTM Best Practices Series -- 1 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 2 Table of contents Managing the fuzzy front end Abstract 03 01 The hidden cost of an unmanaged front end 04 02 What causes FFE drift 07 03 Diverge and converge — why late costs more 11 04 McNealy at Sun: a 6-week constraint 15 05 The lateralworks FFE methodology 18 06 Managing the handoffs 21 07 Implementation: making it real 24 A Case study: a high-volume semiconductor program 27 References 32 Core thesis. The fuzzy front end is the largest, cheapest, and least-managed source of schedule slip in technology product development. Treat it as a real project — with a dedicated cross-functional team, a weekly-refreshed schedule, and a hard cycle-time target — and months come out of the development calendar without compressing the engineering work that follows. -- 2 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 3 Overview Abstract Most product development organizations spend 50 to 100 percent of their cycle time in a phase they do not manage. The fuzzy front end — the period between the portfolio gate that funds a project and the moment a full cross-functional team is formed and active — is, in most companies, owned by no one in particular. A part-time product marketing manager juggles the work alongside twenty other projects. Sales pushes for one product. Internal stakeholders lobby for another. Senior leaders weigh in by position power. Without a schedule, scope balloons. Without dedicated resources, progress drifts. When the full team finally forms, engineering inherits a poorly defined product and a fixed launch date. This paper makes three claims. First, the FFE is the single largest opportunity to reduce overall development cycle time, because lost months in this period are not visible until they appear as compression on the back end of the project, where compression is most expensive. Second, the cause of FFE drift is structural: ownership ambiguity, part-time staffing, and the absence of a refreshed schedule. Third, the fix is also structural — a dedicated cross-functional core team, a hard cycle-time constraint (typically six to eight weeks), and an explicit handoff between portfolio, FFE, and the development core team. The argument draws on three streams of work. Smith and Reinertsen introduced the term “fuzzy front end” in 1991 and argued that it is the cheapest place to take time out of a project [1]. Wheelwright and Clark documented heavyweight cross-functional teams and concept-development discipline as a competitive capability [2]. Khurana and Rosenthal’s field study of eleven companies isolated seven activities critical to front-end success and found that most organizations had serious deficiencies in product strategy at this stage [3]. Scott McNealy’s teams at Sun Microsystems applied these principles to beat IBM and DEC across multiple product generations — by McNealy’s own account, the FFE was the easiest place to cut months out of the schedule [4]. lateralworks engagements over a decade-plus span confirm the pattern. Clients who treat the FFE as a managed project — with a named owner, a six-week target, and an integrated schedule that connects FFE milestones to first-customer-ship — deliver products on the original calendar at substantially higher rates than peers who do not. The remainder of this paper describes the failure modes, the methodology, and the implementation pattern that makes the FFE manageable. -- 3 of 32 -- › Managing the fuzzy front end › › › 01 Section one The hidden cost of an unmanaged front end © 2026 lateralworks Page 4 A development project is a sequence with a fixed end. The launch date is set before any engineer writes a line of code. What is rarely set with the same discipline is the start. The time before the full team is in place gets spent on product definition, on market selection, and on requirements arguments. That time has already been spent when execution begins. It cannot be recovered. The end date does not move. -- 4 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 5 Section one The hidden cost of an unmanaged front end In the technology business, growth comes from new products that satisfy the customer. New product innovation is the engine of growth, whether the company is taking share in mature segments or racing competitors in emerging markets where time-to-market is the driver. Yet most technology companies allocate their best management attention to the back end of development, where the work is visible and the metrics are tracked. The front end, where the product is actually defined, is left to drift. The drift is invisible because the cost is invisible. There is no burndown chart for FFE delay. There is no daily standup for product definition arguments. The team is part-time, the schedule is not tracked, and the work is not gated. Weeks pass, then months. The project is technically “underway” — it has been funded, the portfolio committee approved it, the line item is on the roadmap. But no one is building anything yet, because no one has agreed on what to build. The cost of this drift surfaces only at the end. The launch date, set when the project was funded, does not move — it cannot move, because it is tied to a market window, a customer commitment, or a fiscal-year goal. When the development team finally forms and starts work, they discover that they have less time than the original plan allotted. The lost FFE months are now owed back to engineering and manufacturing during the hardest part of the project, when teams need more time to integrate and qualify, not less. This is what Reinertsen called “fuzziness consumes time” [5], and what every veteran program manager has felt as the “death march” to launch. Figure 1. The fuzzy front end and the project over-run are mirror images. Time lost before the full team forms is owed back to engineering as compression at the end of the project. Smith and Reinertsen estimated that a managed FFE typically saves as much cycle time as the entire FFE itself consumes [1]. That estimate matches lateralworks’ engagement data. When clients shorten the FFE from an unmanaged twelve-to-twenty week sprawl to a managed six-to-eight week project, the saved time flows directly to first-customer-ship without compromising product quality, because the engineering work itself was not the constraint. The constraint was the missing definition. -- 5 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 6 Khurana and Rosenthal’s 1997 field research at eleven companies reached a parallel conclusion: when senior managers were asked where the greatest weakness in product innovation was, they pointed consistently at the front end [3]. The symptoms they catalogued — new products canceled mid-stream because they don’t fit the company strategy, top-priority projects starved of attention, product concepts that drift after announcement — are the same symptoms lateralworks observes in current engagements two and a half decades later. The diagnosis is durable. The pattern is not company-specific or industry-specific. It is structural. Why the back end pays for the front end The compounding cost is what makes the FFE the highest-leverage place to intervene. A week saved at the front end is a week saved at the back end as well, because the launch date is fixed and the work must compress somewhere. A week lost at the front end is a week of compression visited on the most expensive phase of the project — the phase that includes integration, qualification, manufacturing ramp, and the discovery of late-breaking issues. Compression here is not a one-for-one trade. Engineers working compressed schedules produce more defects, and defects discovered late cost an order of magnitude more to fix than defects discovered early [7]. The arithmetic is asymmetric. The FFE is also where the cheapest decisions are made. Choosing the right market segment, the right customer, and the right feature set costs almost nothing in engineering hours — it costs meeting time, decision-analysis time, and management attention. Once those decisions are wrong and engineering has started building, correcting them requires reworking architecture, rewriting code, re-running qualification, and re-doing the work that was completed against the wrong target. House and Price documented this as the “break-even time” penalty: product-definition errors compound through every downstream phase and surface as either a launch slip or a market miss [11]. The right place to make these decisions is the FFE, when no engineering capital has yet been spent. Almost no organization treats it that way. -- 6 of 32 -- › Managing the fuzzy front end › › › 02 Section two What causes FFE drift © 2026 lateralworks Page 7 Drift is not a failure of intent. Most leaders know the FFE matters. The problem is that the conditions for managed work — single ownership, dedicated resources, a refreshed schedule, a fixed end date — are absent during this phase by default. The FFE drifts because nothing in the typical organization stops it from drifting. -- 7 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 8 Section two What causes FFE drift Ownership ambiguity In most technology companies, two functions claim partial ownership of the front end: marketing and engineering. Marketing writes the requirements document. Engineering reads it, ignores what is inconvenient, and proposes alternatives. Neither side owns the reconciliation. When two groups own anything, no one owns it in practice. The work proceeds, but no one is accountable for whether it is finishing on time, because no one signed up to deliver a completed FFE on a date. This pattern is well documented. Khurana and Rosenthal observed it as the absence of a “shared responsibility” structure across the front-end stages [3]. Wheelwright and Clark prescribed the heavyweight project manager and dedicated cross-functional team as the structural fix [2]. The fix is older than the diagnosis. Yet companies still try to run the FFE without a single owner, because creating one requires moving headcount and political capital that is otherwise allocated to running projects already in execution. Part-time staffing The most common pattern in our engagements: the FFE is led by a product marketing manager who has twenty other products in flight. The PM is well-intentioned and capable. But the PM is also the point of escalation for every customer issue on every shipping product, the editor of every customer-facing slide deck, and the voice in every roadmap review. The FFE work is whatever is left over after these obligations are met, which is to say, almost nothing. The PM is willing. The PM is just not available. The same pattern applies to engineering involvement. The senior engineers who could co-author the product definition are the same engineers who are debugging the previous late project. They cannot be peeled off until that project ships. Meanwhile the new project is supposedly underway, but the senior technical voices are absent from the room where the architectural decisions are being made. The decisions get made anyway, by people without the authority or context to make them well, and the consequences land in the execution phase where they are expensive to undo. Too many input channels The FFE is a magnet for opinions. Sales has a list of customer requests. Field marketing has competitive intelligence. Internal stakeholders — platform, applications, support — each have their own use cases. Customers, when consulted directly, want every feature they can think of. The C-suite weighs in by position power: a senior leader’s offhand comment in a quarterly review becomes a feature in the product. With no single owner empowered to filter and prioritize, every input is treated as a requirement. The result is feature ballooning. Without a schedule that shows what each feature costs in time, every feature looks free. Without a development team committed to a date, the implications of saying “yes” are deferred to a future engineering team that has no voice in the room. The FFE accumulates scope until it eventually collides with reality — typically at the first detailed engineering estimate, which arrives after the launch date has already been promised externally. By then it is too late to descope without political damage. -- 8 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 9 Figure 2. The two FFE patterns. The dedicated cross-functional team produces a short, managed FFE and a development phase that meets its target. The part-time marketing-led FFE produces drift and back-end compression. No schedule, no urgency Engineering projects have schedules. Marketing campaigns have schedules. Quarterly business reviews have schedules. The FFE, in most companies, does not. There is no plan that shows what activity happens in week three or week five, no milestone that says “target customers selected by Friday,” no progress check that compares actual completion to plan. The result is that the phase has no rhythm. People work on it when they have time. Decisions wait for the next meeting that happens to include the right attendees. Weeks pass without visible progress, and no alarm sounds because no one wrote down what progress should look like. The lateralworks engagement record shows that introducing a single artifact, a weekly-refreshed FFE schedule on one page visible to the team, produces a behavioral change before any other intervention. When the schedule shows that target-customer selection was supposed to be done two weeks ago and is not, the conversation in the room shifts. People stop volunteering new feature ideas and start asking what it will take to close the open work. The schedule does not need to be elegant. It needs to exist, and it needs to update every week. -- 9 of 32 -- From the literature The cost of fuzz The fuzzy front end is the least expensive place to reduce cycle time. — Smith and Reinertsen Developing Products in Half the Time, 2nd ed., 1998 © 2026 lateralworks Page 10 -- 10 of 32 -- › Managing the fuzzy front end › › › 03 Section three Diverge and converge © 2026 lateralworks Page 11 Smith and Reinertsen described product development as a sequence of divergence and convergence. The team explores broadly at the beginning — considering markets, customers, technology options, business cases. Then the team converges on a specific product to build. The harder question is when convergence finishes. In a managed FFE, divergence takes about a third of the available time and convergence takes the remaining two-thirds. In an unmanaged FFE, divergence consumes everything, and convergence happens late — sometimes after the development team is already supposed to be coding. -- 11 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 12 Section three Diverge and converge — why late costs more Two commits define the shape of the front end. The concept commit is the moment the team agrees on what they are going to make and roughly when they will make it. The execution commit is the moment they agree on how and specifically when. Concept commit is a product question. Execution commit is an engineering question. Both commits should happen within the FFE, so that the full team forms with both the product and the schedule already agreed. Figure 3. The diverge-and-converge pattern. A managed FFE closes inside the design-develop-make window with time to spare. An unmanaged FFE keeps diverging into the development phase, pushing convergence — and the launch — out. The visual encodes a structural fact. Once divergence runs past the point where the design-develop-make work needs to start, the project has two choices. Either it accepts the schedule slip and launches late, or it compresses the development phase by short-cutting integration, qualification, or quality assurance. The first choice loses the market window. The second choice ships a product with quality debt that will surface in the field. Neither choice is good. Both are common. The most pernicious version of late convergence is the version that is invisible. The FFE produces a document called a Marketing Requirements Document or Product Requirements Document, and that document is handed to engineering. Engineering reads it, recognizes that several requirements are infeasible inside the schedule, and silently descopes them. The descope is not negotiated with marketing or sales — it is simply done, because the alternative is admitting the schedule is not real. The product then ships with a feature set that surprises the field organization at launch. This is what Khurana and Rosenthal labeled the “moving target” pattern of front-end failure [3]. Reconcile early, not late -- 12 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 13 The structural fix is to do reconciliation inside the FFE, not at the boundary between FFE and development. Reconciliation means a specific activity: engineering, marketing, and finance sit in the same room and ask, of every requirement, can we deliver this inside the available schedule, and what is the cost of trying? The answer is sometimes yes, sometimes no, sometimes “yes if we drop something else.” The conversation is never comfortable, but it is far less expensive in the FFE than after development has started. Wheelwright and Clark called this the work of the heavyweight project manager: a single person with the authority to convene the cross-functional argument, run it to a conclusion, and commit the organization to the result [2]. The IRADP framework lateralworks uses across portfolio, FFE, and execution decisions makes this explicit — a single Decider, supported by Recommenders and Agreers, ends the argument and the team moves forward [6]. Without this role, reconciliation does not happen. It accumulates as unresolved tension and discharges later as schedule slip. Figure 4. Work pressure across the development cycle. A managed FFE produces a smooth curve that respects the engineering capacity ceiling. An unmanaged FFE produces a late spike that exceeds capacity — the visible signature of the back-end death march. The pressure curve in Figure 4 shows the cost of FFE drift in staffing terms. In the managed case, work pressure rises as the full team forms and peaks during integration before tapering to launch. In the unmanaged case, pressure stays low during the FFE because no one is actually fully staffed on it, then climbs sharply at the end as the team tries to compress lost time into the back of the schedule. The capacity ceiling marks the limit of what the team can sustainably produce. Above the ceiling, defects rise and quality compromises become routine [7]. -- 13 of 32 -- Field observation Where the schedule hides Half our competitors’ cycle time was lost in a poorly- managed front end. We managed it. They didn’t. — paraphrasing Scott McNealy, Sun Microsystems Recounted to lateralworks during program reviews © 2026 lateralworks Page 14 -- 14 of 32 -- › Managing the fuzzy front end › › › 04 Section four McNealy at Sun: a 6-week constraint © 2026 lateralworks Page 15 Scott McNealy ran Sun Microsystems through the workstation and server wars of the 1980s and 1990s, competing head-on with IBM and Digital Equipment Corporation. Across multiple product generations, Sun shipped first. McNealy attributed the cycle-time advantage to one specific structural choice — Sun managed the fuzzy front end, and the competitors did not. -- 15 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 16 Section four McNealy at Sun: a 6-week constraint In conversations recounted to lateralworks during program reviews, McNealy described the FFE as his greatest opportunity to reduce overall development cycle time. He observed that fifty to one hundred percent of the development cycle was being lost during what he called “a poorly-managed and under-resourced process.” The FFE was the easiest place to take months out of the schedule, because the work was being done badly by inertia rather than by intent. Fixing it required no technological breakthrough — only a structural change. Why McNealy was the case The McNealy story sits inside lateralworks’ founding research. The FTTM methodology emerged from the firm’s first best-practices study, which examined multiple successful product development teams at Sun across the workstation and server eras. McNealy was interviewed extensively because he was the central influence on Sun’s new product development practices [12]. He was the key to Sun’s cycle-time advantage, and not because of an organizational template he installed. He combined hands-on engineering judgment with business discipline as CEO. He understood the technical work well enough to make product decisions himself, and he understood the business consequences of late launches well enough to make the schedule his binding constraint. That combination is rare, and the structural choices documented in this section were attempts to scale his own leadership across many projects at once. Sun’s structural change had three components. First, they treated the FFE as part of the project rather than as pre-project drift. As McNealy put it, Sun “turned the clock on” at the moment the idea was first discussed. The early gestation period was managed and tracked, not waved away as “what happens before the project starts.” Second, Sun staffed the FFE with a dedicated cross-functional team of engineering, marketing, and finance — not a part-time marketing person. This team owned the product definition, the business case, and the schedule reconciliation. They did the work full-time because the work was actually full-time work. Pretending otherwise was a tax that competitors paid and Sun did not. Third, Sun set a hard cycle-time target. McNealy’s constraint was no more than six weeks from idea to concept commit. Six weeks is short enough to require focus and long enough to do the work properly. The deadline was not aspirational; it was binding. Projects that could not converge inside six weeks were either descoped to fit, or recycled — sent back through the portfolio gate as not-yet-ready. The constraint forced choices that the absence of a constraint had allowed teams to defer. -- 16 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 17 Figure 5. A six-week FFE timeline. Each week has a defined milestone. The schedule is refreshed weekly. At week six, the team commits or the project recycles — there is no middle option. The six-week constraint had a second, less obvious benefit: it protected the development team. Once concept commit happened, the full team formed and got to work on a product that had already been reconciled against the schedule. Engineering inherited a real plan, not a wish list. Manufacturing knew what to qualify. Sales knew what to sell. The handoff was clean because the upstream work was finished. Sun’s methodology drew heavily on Wheelwright’s and Clark’s research at Harvard Business School — specifically their work on heavyweight teams and concept development discipline [2]. Wheelwright’s contribution was the recognition that concept-stage management could be made rigorous. The work that looked like creative exploration was actually project work that had been mistaken for creative exploration. Once the team treated it as project work with milestones and a deadline, it became as manageable as any other phase. IBM and DEC, through the same era, ran their front ends as unmanaged drift. Marketing wrote requirements. Engineering estimated. Several rounds of revision happened informally over months. The full team formed eventually, by which time Sun had already shipped a product into the same market. The cycle-time advantage was structural and reproducible, and Sun reproduced it across multiple generations of workstations and servers until the industry caught up. -- 17 of 32 -- › Managing the fuzzy front end › › › 05 Section five The lateralworks FFE methodology © 2026 lateralworks Page 18 The lateralworks FFE methodology generalizes Sun’s structural choices and the underlying Wheelwright-Clark and Smith-Reinertsen frameworks into a repeatable practice. Seven elements, applied together, transform the FFE from drift into managed work. The elements are not optional, and they are not independent — leaving any one out tends to undo the benefit of the others. -- 18 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 19 Section five The lateralworks FFE methodology The seven best practices below describe the operational state of a managed FFE. They are descriptive of what the team is doing, not aspirational — if any one of them is missing, the FFE is not managed, regardless of how much management attention is being paid. The list compresses lateralworks engagement experience with the published research on FFE practice [1,3,8]. Figure 6. Seven best practices that define a managed FFE. Each practice corresponds to a structural condition; the absence of any one of them produces the failure modes of Section 02. 1. Dedicated cross-functional team Engineering, marketing, and finance have core team representation on the FFE, full-time. Not part-time on top of other work. Not “as needed.” The team is the FFE; the FFE is the team. When this practice is absent, every other practice degrades because the work falls back to whoever has spare time, and no one has spare time. Wheelwright and Clark documented the dedicated team as the structural prerequisite for fast development [2]. Reinertsen sharpened the argument with the observation that the cost of shared resources is non-linear: a person who is 80 percent allocated to other work is not 20 percent productive on the FFE, they are roughly zero percent productive [7]. 2. Selected and prioritized target markets Target customers and target markets are explicitly chosen, not inherited. The team uses decision-analysis tools — simple pairwise weighting, AHP-style ranking, or facilitated voting — to converge on a prioritized list that the whole team signs. “We will serve everyone” is rejected as a choice. The discipline of explicit selection prevents the “just meet all requirements” failure mode that drives feature ballooning. -- 19 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 20 3. Defined business case The business case is real, not fabricated to pass an internal gate. The team knows the cost of delay — the dollars per week that the company foregoes if the launch slips. That number changes the conversation. When a stakeholder asks for a feature that adds two weeks to the schedule, the cost-of-delay number tells the team what that feature has to be worth to be justified. Reinertsen’s cost-of-delay framework [7] is the canonical reference; the lateralworks DecisionAccelerator implements a practical version for FFE workshops. 4. Preliminary VOC, prioritized Voice of the customer is captured during the FFE — not assumed by marketing on the basis of past products. The capture method matters less than the discipline of doing it: structured interviews, on-site observation, lead-user workshops, jobs-to-be-done analysis. The output is a prioritized list of customer requirements that the team has converged on, not a wish list. This step is what Khurana and Rosenthal called “clarifying the product concept” in their seven-activity framework [3]. 5. Reconciled requirements What the customer wants is matched, explicitly, against what the development group can deliver in the available schedule. This is where most FFEs fail silently. Engineering looks at the requirements document, sees that several items are infeasible, and either descopes silently or signs up for an impossible plan. Reconciliation forces the conversation into the open: this requirement costs three months we don’t have, do we drop it or extend the schedule? Either answer is acceptable. Avoiding the question is not. 6. Weekly refreshed schedule There is a schedule. It updates every week. When the FFE schedule slips, the team can see the impact on first-customer-ship and on the business case. The schedule does not need to be elaborate. A one-page weekly view that lists the milestones, the responsible owner, and the planned vs actual completion is enough. The point is the cadence and the visibility, not the tooling. 7. Properly resourced with a fast-cycle target The team has the people it needs and a deadline that is short enough to require focus. Six to eight weeks is the typical target for a hardware or systems product; three to five weeks for software. The deadline is binding: at the deadline the team commits or the project recycles. There is no middle outcome, no “we need two more weeks” that becomes four. The discipline of the deadline is what makes the previous six practices stick. Without it, the team has no reason to converge, and divergence will continue indefinitely. These practices, applied together, produce a sub-set of the symptoms documented in lateralworks engagement data: faster concept-commit dates, fewer mid-development scope changes, cleaner handoffs to the development team, and shorter overall cycle times. They do not eliminate uncertainty — product development is intrinsically uncertain — but they confine uncertainty to the right phase of the project, where it is cheapest to resolve. -- 20 of 32 -- › Managing the fuzzy front end › › › 06 Section six Managing the handoffs © 2026 lateralworks Page 21 The FFE is not the only managed phase in a product development project; it is the middle one. Upstream of the FFE is the portfolio process that decides which projects to fund. Downstream is the development core team that designs, builds, and ships the product. Two handoffs connect these phases. Both are routinely botched, and both can be cleaned up with the same discipline that produces a managed FFE in the first place. -- 21 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 22 Section six Managing the handoffs A handoff is an artifact-bearing transition. The previous phase finishes its work and produces a defined deliverable. The next phase receives the deliverable and starts its own work from there. When handoffs are clean, the receiving team can begin immediately with high confidence in what they have inherited. When handoffs are botched, the receiving team spends weeks or months trying to reconstruct what was supposed to be settled, and the calendar slips invisibly. Figure 7. The two handoffs of the FFE — from portfolio in, and to development core team out. Each carries a defined artifact: a project charter on the way in, a product definition and schedule on the way out. Handoff 1: from portfolio to FFE The portfolio process produces a prioritized list of projects with allocated budget and headcount. The handoff from portfolio to FFE is the project charter: a document that says this project has been funded, here are the strategic goals, here is the resource envelope, here is the named FFE owner. Without a charter, the FFE team starts work without knowing what success looks like, and spends the first two weeks trying to figure it out by polling stakeholders — which is exactly the failure mode the FFE is supposed to prevent. The lateralworks portfolio methodology [9] addresses this handoff explicitly. The portfolio gate produces a charter; the FFE owner is named as part of the gate decision; the FFE budget is approved concurrently with the project budget; the FFE schedule is committed as part of the gate, not as a future negotiation. This means the FFE team can start immediately with a defined target, not a general intention. Handoff 2: from FFE to development core team The handoff out of the FFE is the harder one. It carries two artifacts: the product definition (what we are going to build) and the schedule (when we will build it and what milestones we will hit along the way). When both artifacts are real, the development team forms with a clear runway. They know the product has been reconciled against capacity, the customer requirements have been prioritized, and the schedule has been committed to by the upstream team. -- 22 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 23 The most common failure of this handoff is that the schedule is aspirational rather than committed. The FFE team produces a date that marketing wanted; engineering never signed up to it. Engineering inherits the date along with the product, discovers in week three that the date is impossible, and has to choose between admitting the slip and silently descoping. The fix is to involve engineering in the schedule commitment during the FFE, not after. Practice 5 (reconciled requirements) and Practice 7 (cycle-time target) of the methodology address this directly. A clean handoff also requires that the FFE team disbands at the handoff, with members re-rolling onto the development core team where appropriate. This sounds obvious but is often violated: organizations create an FFE team and then keep it intact through development as a parallel structure, which produces governance confusion and competing decision authorities. The FFE is a project; like all projects, it ends. The continuation of the work is a different team’s job. Decision rights at the handoffs Each handoff has an owner who decides whether the artifact is ready to transfer. At handoff 1, the FFE owner decides whether the charter is workable; if not, the project recycles back through the portfolio gate rather than starting in a degraded state. At handoff 2, the development core team leader decides whether the product definition and schedule are sufficient to begin execution; if not, the FFE recycles for one more week to close the gap. Naming these owners and giving them the authority to delay a handoff is the single most effective intervention lateralworks has observed for cleaning up sloppy transitions. -- 23 of 32 -- › Managing the fuzzy front end › › › 07 Section seven Implementation © 2026 lateralworks Page 24 Adopting the FFE methodology is a structural change, not a process tweak. The change affects who does the work, how the work is staffed, what artifacts the team produces, and how the schedule is governed. The change is visible to the rest of the organization, because it requires moving headcount and pulling senior engineers off other work, which is why most organizations have not made it. The benefit compounds across every project the company runs. -- 24 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 25 Section seven Implementation: making it real A successful adoption follows a sequence. The sequence is not optional and the steps cannot be skipped without producing a cargo-cult version of the methodology that fails to deliver the cycle-time benefit. The path below has been validated across multiple lateralworks engagements in semiconductors, systems, medical devices, and industrial products. 1. Pick one project. The first FFE adoption is a pilot, not a rollout. Choose a project that is high-priority enough to attract serious management attention, but small enough that the FFE can complete in eight weeks or less. A successful pilot generates internal evidence and internal advocates. A failed pilot — or a pilot that drags on for months — hardens organizational resistance. 2. Name a single FFE owner. One person, named, with the authority to make decisions and the time to do the work. Title is less important than capacity — the owner needs to be 100 percent allocated to the FFE for its duration. If the only candidates are 50 percent allocated, the pilot is set up to fail. Push back on this constraint with senior leadership. It is the structural prerequisite. Without it, none of the other practices can be sustained. 3. Form a dedicated cross-functional team. Engineering, marketing, and finance representation on the team, full-time. The team co-locates physically or virtually for the duration. Other obligations are formally re-assigned to other people during the FFE. This is the moment in the adoption that forces senior leadership to commit real headcount; it is also the moment that distinguishes companies that say they want faster time-to-market from companies that actually invest in achieving it. 4. Set the cycle-time target. Six weeks is the canonical target for a hardware or systems product. Adjust based on product complexity — simple software might target three weeks, very complex multi-die semiconductors might target ten. The target is binding. At the target date, the team commits or recycles. Recycling is a legitimate outcome and should be normalized, not treated as failure. A project that is not ready to converge inside the target window is a project that should not yet be in the FFE. 5. Stand up the weekly refresh cadence. A 30-minute weekly meeting. The schedule updates. Owners report planned vs actual. Slips are visible and discussed. New scope requests are evaluated against cost-of-delay, not added by default. The cadence is the heartbeat of the methodology; without it, the methodology decays back to drift within two or three weeks. 6. Run the handoffs explicitly. At the start, formally accept the charter from the portfolio process. At the end, formally hand the product definition and schedule to the development core team. Both handoffs are gated: the receiving team has the -- 25 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 26 right to refuse a malformed artifact. Documenting these gates is what prevents the FFE from being absorbed back into the surrounding organizational ambiguity. 7. Conduct a structured retrospective. After the pilot completes, the FFE team and the development core team review what worked and what did not. The retrospective produces an updated playbook for the next FFE. Over three or four pilots, the methodology becomes the company’s default way of running new product development. Mandates do not make it stick. People who have done it once will not voluntarily go back. Adoption produces resistance. Functional managers do not want to lose their best people to an FFE team for eight weeks. Project managers running the previous late project do not want to release engineers who are still debugging that project. Marketing does not want to share product definition authority with engineering and finance. These resistance patterns are real and should be expected; they are also temporary. After two or three successful cycles, the resistance gives way to advocacy, because the people who experienced the methodology firsthand will not voluntarily return to the alternative. What changes when you do this. Months come out of the development calendar without compressing engineering work. Launches land on the original date. Engineers stop inheriting impossible commitments. Marketing stops promising features that are not in the schedule. Senior leaders stop making position-power product decisions because the structural decision-making process has become legitimate. None of this is magic. A previously-unmanaged phase of work starts being managed, and the calendar pays out the difference. -- 26 of 32 -- › Managing the fuzzy front end › › › A Appendix A Case study: a high-volume semiconductor program © 2026 lateralworks Page 27 The case below is a generalized account of a current lateralworks engagement with a large multinational semiconductor company headquartered in Asia. The company is racing to develop and ramp a high-volume product line into the AI data-center market, under cycle-time and volume targets that have no precedent in the industry. The patterns surface as structural failures inside a specific program portfolio, each one already described earlier in this paper. Names of projects, individuals, and the company are omitted. The dialogue paraphrases a recent core team review. -- 27 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 28 Appendix A Case study: a high-volume semiconductor program The company sells into the AI data-center supply chain. Demand for its product family has scaled faster than the industry has built capacity to deliver. Customer ramp dates are committed externally. Volume targets, once set, are not negotiable. The engineering and manufacturing organizations are large, capable, and under extraordinary pressure. lateralworks was engaged to install the FTTM methodology across the active product portfolio and to accelerate the cycle time of new program starts. Three months into the engagement, the methodology mechanics were taking hold. The schedule analyzer was in use across the active projects. Weekly refresh meetings were running on cadence. Pull-in discipline was improving. Functional leaders were beginning to show up consistently with their domain status. From the outside, the program looked like an FTTM adoption proceeding on plan. What surfaced in the core team review During a quarterly calibration meeting, several participants raised a concern that the mechanics were not the constraint. The PD leader said it directly: the biggest problem we have isn’t executing to an agreed-upon plan; it’s actually getting to an agreed-upon plan and then staying with that plan. He continued, with the hard sentence that defined the rest of the discussion: this organization is exceptionally weak at making decisions and sticking to decisions. Several other functional leaders nodded. One named the lead project as the example. Two months earlier the team had walked out of an offsite agreeing on a target schedule for that project. Two months later the project still had not passed plan gate. The plan kept changing. The team was adapting to the changes rather than holding the original line. The moment lateralworks named the pattern, the room recognized it. The mechanics downstream were running cleanly. The problem sat upstream in the fuzzy front end. The team had spent two months in what should have been a six-week window, and the time had been consumed by exactly the pattern this paper has described — idea churn, drifting spec, decisions deferred, no schedule pressure on the FFE itself. -- 28 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 29 Figure 8. Symptoms reported in the core team review map directly to root causes named earlier in this paper. The mapping is one-to-one, not metaphorical. Specific patterns observed Decisions in individual heads. When the team described how requirements were being set, it became clear that what looked like decisions were actually assumptions held by individual stakeholders. No artifact recorded the decisions. No forum committed them. When two stakeholders held different assumptions, work continued in both directions until the contradiction surfaced in a downstream review, at which point one assumption was discarded and weeks of engineering work went with it. This is the ownership-ambiguity failure mode of Section 02. Two functions each thought they owned the product definition; in practice neither did. The senior-leader override. A senior executive periodically changed the product direction by communicating a preference inside a status review. The PMs interpreted these comments as instructions, partly because the executive had position power and partly because nobody else had been authorized to overrule them. The product redefined itself by accretion of senior comments, not by structured selection. This is the too-many-input-channels failure mode, in its most expensive form: an input channel with enough authority to reset the FFE without participating in it. No FFE schedule. The team had refresh discipline for the active development phases. The FFE had no equivalent. The plan gate was treated as the start of the schedule rather than a milestone inside it. Because there was no FFE schedule, there was no visible slip when convergence missed its target. The team had been two months late on convergence for two months, but the lateness was invisible until lateralworks named it. This is Practice 6 in the methodology: weekly refresh of the FFE schedule is what makes drift visible. Without the artifact, the drift is free. No cycle-time target on the FFE. No one had set a deadline by which the lead project had to commit or recycle. The implicit rule was “when we’re ready.” Practice 7 prescribes a binding target — typically six weeks for a hardware program. The team had drifted past eight weeks with no internal mechanism to either -- 29 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 30 force convergence or kill the project and start over. In the absence of a deadline, every individual decision could be deferred to the next meeting, and they were. Back-end pressure already accumulating. Halfway through the review, an engineering manager observed that the customer ramp was approaching and asked what shortcuts the team could take to release qualification material. He raised “risk-start” as a possible mechanism. This is the canonical signature of back-end compression: when the FFE drifts, the lost time is owed back to engineering and manufacturing in the form of compressed qualification and quality compromises that nobody would consider if the schedule had not already slipped. The engineering team understood that the cost was about to land on them and were trying to plan for it. Section 01 describes exactly this dynamic. Antibodies fight back. The PD leader observed that the organization had an active resistance to the kind of upstream discipline the FFE requires. People who tried to enforce decisions, lock specs, and refuse mid-flight changes were treated as obstacles. Section 07 describes this as a normal feature of adoption — the structural change requires moving headcount and decision rights, and the people who lose autonomy under the new system push back. It is temporary and predictable, but it has to be navigated by the senior advisor and by the PD leadership in concert. What lateralworks recommended The intervention follows the implementation sequence of Section 07, applied specifically to the lead project. First, name a single FFE owner with the authority and the time to drive the project to plan gate. The owner gets pulled off other obligations for the duration. Second, set a binding cycle-time target: four weeks to plan gate from the day the new owner takes the project. The target is short because the project has already been in the FFE for two months and the customer ramp is not moving. Third, stand up a weekly refresh of the FFE schedule itself — not just the downstream phases. The refresh exposes drift early. Fourth, install cost-of-delay as a control mechanism: every proposed change to the spec or to the schedule is evaluated against the dollars per week of slip. The senior-leader override does not stop, but it now has to face an explicit cost when it lands. The wiggle chart was named in the meeting as a forcing function. When the team starts plotting trend lines on the FFE and shows them to the executive layer, the trajectory becomes hard to ignore. As the senior advisor put it during the review: the minute you start measuring it and showing it, all of a sudden it’s not free anymore. The cost of FFE drift had been invisible because the artifacts that would have made it visible were not in place. Once they are, the same organization that tolerated two months of drift becomes intolerant of two weeks of it. Behavior follows visibility. A second recommendation cuts upstream. The portfolio process that feeds the FFE has been producing project charters with too much optionality — multiple acceptable outcomes, no single Decider, no committed cost-of-delay number. Section 06 prescribes the project charter as a defined artifact at the portfolio-to-FFE handoff. Tightening that charter gives the FFE owner something concrete to hold the line against when senior leaders attempt mid-flight changes. What this case illustrates The mechanics of FTTM — schedule analyzer, pull-in discipline, weekly refresh — are necessary but not sufficient. They manage the development phase well. They cannot fix a phase that has not yet started, and the FFE is exactly that. Teams that install the mechanics without also installing FFE governance will see the methodology working downstream and missing entirely from the front end. -- 30 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 31 The other lesson is about visibility. The team in this case knew something was wrong. The plan was changing. Decisions were not sticking. The lead project was not converging. They could feel the dysfunction, but they could not point at it, because no instrument was measuring it. The FFE schedule, the wiggle chart, and the cost-of-delay calculation are instruments. Once they are running, the dysfunction stops being a private feeling and becomes a tracked metric, and people respond to tracked metrics in a way they never respond to private feelings. A final observation, raised by one of the PD leaders during the review: at some point we have to say, the lead project isn’t converging. Who owns getting it to converge? That sentence is the FFE methodology in twelve words. Naming the owner, setting the target, refreshing the schedule, making drift visible — all of it follows from the answer to that one question. In this organization, before the engagement, the question had no answer. Naming an answer is the first step the methodology requires, and it is the step the rest of the system is designed to support. -- 31 of 32 -- › Managing the fuzzy front end › › › © 2026 lateralworks Page 32 Sources References [1] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd edition. John Wiley & Sons, 1998. The book that introduced the term “fuzzy front end” to the product-development literature. [2] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. The Free Press, 1992. Foundational treatment of heavyweight cross-functional teams and concept-stage management as a competitive capability. [3] Khurana, A., and Rosenthal, S. R. “Integrating the Fuzzy Front End of New Product Development.” Sloan Management Review 38(2), Winter 1997, pp. 103–120. Field study of eleven companies isolating seven activities critical to front-end success. [4] McNealy, S. Conversations recounted to lateralworks during program reviews regarding Sun Microsystems’ product development practices in the workstation and server era. [5] Reinertsen, D. G. Managing the Design Factory: A Product Developer’s Toolkit. The Free Press, 1997. Source for the “fuzziness consumes time” framing and the broader queueing-theory perspective on development cycle time. [6] Rogers, P., and Blenko, M. “Who Has the D? How Clear Decision Roles Enhance Organizational Performance.” Harvard Business Review, January 2006. Origin of the RAPID/IRADP decision-role framework lateralworks adapts for portfolio and FFE governance. [7] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. Treatment of cost-of-delay, capacity utilization, and the non-linear penalty of overloading shared resources. [8] Koen, P. A., et al. “Providing Clarity and a Common Language to the ‘Fuzzy Front End.’” Research-Technology Management 44(2), 2001, pp. 46–55. New Concept Development (NCD) model from the Industrial Research Institute consortium. [9] lateralworks. FTTM Portfolio Prioritization and Starts Control. Methodology paper, 2026. Companion paper covering the upstream portfolio process that produces the FFE charter. [10] lateralworks. “Internal engagement database.” Field observations and program data across client engagements, 2010–2026. [11] House, C. H., and Price, R. L. “The Return Map: Tracking Product Teams.” Harvard Business Review, January–February 1991, pp. 92–101. Origin of the break-even-time framework that quantifies the downstream cost of product-definition errors made in the front end. [12] lateralworks. FTTM Best Practices: Sun Microsystems Field Study. Founding lateralworks engagement, examining cycle-time practices across multiple successful workstation and server programs at Sun Microsystems. Includes extensive interview material with Scott McNealy and the program leadership of the workstation, server, and storage product lines. -- 32 of 32 --

Portfolio·Synthesis paper

Managing the fuzzy front end

Where the biggest schedule opportunity hides — and how to capture it through dedicated teams, a refreshed schedule, and a hard cycle-time target

Core thesis. The fuzzy front end is the largest, cheapest, and least-managed source of schedule slip in technology product development. Treat it as a real project — with a dedicated cross-functional team, a weekly-refreshed schedule, and a hard cycle-time target — and months come out of the development calendar without compressing the engineering work that follows.

May 9, 2026·32 pages

View PDF →Download

© 2026 lateralworks › › Whitepaper fastProjectAI Project Portfolio Dashboard Aggregating live project schedules into a single leadership view FTTM toolkit series. How leadership teams running multiple new-product programs can replace status-report theater with live, exception-based portfolio visibility — drawn from data their PMs already maintain as part of FTTM planning. Prepared by lateralworks FTTM toolkit Date April 2026 Synthesis paper Online lateralworks.com Portfolio dashboard series -- 1 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 2 Table of contents fastProjectAI Project Portfolio Dashboard Abstract 03 01 — Why portfolio status reports fail 04 02 — How fastProjectAI works 07 03 — Reporting by exception 11 Pull quote 15 04 — Live data, no overhead 16 05 — Worked example: site deployment 18 06 — LLM analysis across projects 22 07 — Adopting the dashboard 26 References 29 Core thesis. Most leadership teams running multiple programs cannot see their portfolio in time to act. fastProjectAI fixes this by aggregating live wigglechart data the PMs already maintain — surfacing the small number of projects that need attention this week, not the long tail that does not. -- 2 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 3 Overview Abstract Multi-project portfolio reviews fail in predictable ways. Status reports arrive weeks after the data was collected, get filtered through layers of optimism on the way up, and surface problems only after they have grown beyond easy recovery. Each project reports in its own format, against its own baselines, with its own definition of "on track." By the time the leadership team meets, the data is stale, distorted, and impossible to compare across the portfolio. fastProjectAI replaces this pattern. The dashboard automatically aggregates wigglecharts — a standard FTTM artifact PMs maintain as part of normal weekly planning — from every project in the portfolio. It computes a common gap-to-target metric and a six-week trend rate for every milestone, ranks them by risk, and presents the result through a small set of one-click filters. The economics matter. Because the data already exists in the PMs' live schedules, the dashboard adds zero data-entry overhead. The aggregator reads the same files the PMs are already maintaining for their own planning. This is why the data stays honest: there is no separate dashboard to fluff up before the executive review. The dashboard alone replaces meeting-by-meeting status theater with a working list of projects that genuinely need leadership attention this week. A second layer goes further: an LLM (in this paper, Claude) reads the dashboard each week and surfaces cross-portfolio patterns no single project view can reveal — concentration of failure modes, structural under-triage, recovery-trend asymmetries, and lessons not transferring between programs. The paper walks through the architecture, the filtering model, the free-data argument, a worked example from a 196-milestone site deployment portfolio, and the LLM analysis layer. It closes with practical guidance for adopting the dashboard inside an organization already running on FTTM-style planning. -- 3 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › 01 The problem Why portfolio status reports fail © 2026 lateralworks Page 4 Every leadership team running multiple new product development programs at once eventually arrives at the same observation: the portfolio reviews aren't telling them what they need to know in time to act. The numbers look reasonable on the slide, the projects all report progress, the executive sponsor nods, and three months later the program that was "on track" misses its launch by a quarter. This is a problem in how status flows through the layers of an organization, and in what happens to information at each layer. Reinertsen has documented the cost-of-delay framework for product development at length [1]: the financial cost of late projects is almost always far larger than the cost of accelerating them. Yet the gap between what leadership knows and what is actually happening on the ground is the rate-limiting step on every accelerator they could apply. Visibility precedes action. -- 4 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 5 Four predictable failure modes How portfolio status gets distorted The same four failure modes appear across organization after organization in lateralworks engagement data, regardless of industry or program type. They are structural. Information lag. A typical monthly status review uses data that was collected two to four weeks before the meeting. Project status snapshots get rolled up the chain, formatted into slides, scheduled into the leadership calendar, and presented well after the underlying situation has changed. By the time leadership sees that a milestone slipped a week, the project has been slipping for a month. Aggregation distortion. Each handoff between layers adds a layer of optimistic rounding. Engineers report "almost done" to PMs; PMs report "minor risk" to program leads; program leads report "on track with watch items" to executives. By the top of the chain, the variance has been compressed out of the data. The phenomenon is well-documented: status reports tend toward green even as the underlying schedules turn red — the so-called "watermelon report" pattern observed across government and private-sector program management studies [2, 3]. The mechanism is the same one Lee, Padmanabhan, and Whang documented in supply chains as the bullwhip effect [19]: each layer of aggregation amplifies the variance it sees while smoothing what it reports. Kahneman has shown the same optimistic-rounding bias operates at the individual-decision level [20]; what the watermelon report adds is the organizational amplifier. No common metric. Each project reports in its own format. One uses percent complete; another uses task burn-down; another tracks milestone slippage in days; another reports critical path float. None of them is wrong, but none of them is comparable across the portfolio. Leadership cannot ask "which of my fifteen programs is in worst shape this week" because there is no shared answer to "in worst shape compared to what." This is the comparability problem identified in Cooper, Edgett, and Kleinschmidt's work on portfolio management for new products [4]: without a common dimension, portfolios cannot be managed as portfolios. Recovery fiction. A point-in-time status reading does not distinguish a project that is two weeks late and recovering from one that is two weeks late and getting worse. Both look the same in the cell of a spreadsheet. Without a trend signal, leadership cannot tell which projects need intervention now and which are already self-correcting. The data shape that matters — the slope, not just the level — is invisible. Goldratt argued the same point in Critical Chain [25]: a status field that ignores the rate of change is structurally misleading. Pinto and Mantel's study of project failure causes reaches a related conclusion — the ability to detect derailment early is the strongest single predictor of recovery success [23]. -- 5 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 6 What this means. Status theater is the predictable consequence of these four failure modes acting together. The cure is to remove the layers between leadership and the live project-level data, and to express that data in a single common metric with a visible trend. Better-formatted slides will not get there. -- 6 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › 02 The solution How fastProjectAI works © 2026 lateralworks Page 7 fastProjectAI takes a different approach. Rather than introducing a separate reporting system, it reads from the planning artifacts PMs already maintain in the course of their normal FTTM work — specifically, the wigglechart at the milestone level — and aggregates them into a single live portfolio view. This section walks through the underlying data structure, the aggregation logic, and what the resulting dashboard looks like in practice. -- 7 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 8 The underlying artifact What a wigglechart captures Every project milestone in an FTTM-managed program has a wigglechart: a week-by-week plot of the milestone's forecast finish date against its committed target. Each week, the PM updates the forecast based on the latest schedule data; a new point is added; the line moves. This single chart captures three things a status table cannot: • The committed target — the date leadership and the team agreed the milestone would land. • The current gap — how far the forecast has drifted from that target, in days. • The trend — whether that gap is widening, holding, or closing, and at what rate. The wigglechart is not a lateralworks invention. The concept of plotting forecast schedule against committed schedule over time goes back at least to Smith and Reinertsen's work on fast product development cycles in the 1990s [1, 5]. Wheelwright and Clark argued in Revolutionizing Product Development that visible time-based metrics enable speed [16]; House and Price's "Return Map" framing pushed the same idea into the executive review by plotting committed dates against actuals on a single figure [17]. What FTTM adds is the discipline of maintaining one for every milestone, every week, as a non-negotiable PM practice. This discipline is what makes the aggregation possible. Figure 1. A real wigglechart from the worked-example portfolio: Pueblo West Go-Live, target 30-Apr-2025. The blue line is the committed target date. The black line is the weekly forecast date. The gray diagonal is the today line — where forecast meets today, time has run out. The vertical distance between the black and blue lines is the gap; the slope of the recent black line is the trend. Read together, gap and trend tell leadership which projects need attention this week. The wigglechart makes Section 01's failure modes visible at the project level. Information lag collapses to one week (the update cadence). Aggregation distortion is removed because the data is the live forecast. The common metric is gap-in-days. Recovery fiction is impossible because the trend is plotted directly. -- 8 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 9 From single charts to portfolio aggregation fastProjectAI takes the next step. If every project in a portfolio maintains wigglecharts at the milestone level, then a single piece of software can read all of those wigglecharts, extract the gap and trend for every milestone, and render the result as a portfolio dashboard. The aggregator is structurally simple: it ingests, normalizes, ranks, and presents. Figure 2. Data flow. Each PM maintains a live schedule as part of their normal FTTM work. The aggregator reads each schedule weekly, extracts the per-milestone target/forecast deltas, computes the six-week trend, and tags risk. Outputs feed both the leadership dashboard and the LLM pattern-analysis layer. What the leadership team sees is a single screen: a count of milestones, distributions of risk, a sortable table of every active milestone with its gap, its trend, and its risk flag. The screen is live. The data behind it was generated by the PMs in the course of their planning work this week. There is no separate filing or reporting step. -- 9 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 10 What leadership sees The dashboard at a glance Figure 3 shows the dashboard as it appears to leadership in a recent site-deployment portfolio. The top of the screen summarizes the health of 111 active milestones across 15 programs: 68% are projected to land within two weeks of their target, 21% within four weeks, and 11% are more than four weeks behind. The completed milestones panel on the right shows the historical record — 79% of completed milestones landed within two weeks of their committed date, suggesting the planning discipline is working in aggregate even as the active set carries pockets of trouble. Figure 3. The dashboard's summary panel. Active milestones (left) and completed milestones (right) are bucketed by gap-to-target. A single screen lets leadership read both the current state and the planning track record at the same time. Below the summary, the dashboard exposes a per-milestone detail table with the columns leadership actually needs: program, target milestone, target date, finish date, gap, likelihood of hitting target, risk flag, week-over-week change, six-week trend, cause of change, and current actions with named owners. Each row is one milestone, one wigglechart, one project's honest current state. Figure 4. Per-milestone detail. Each row is a single milestone with its target date, current forecast, gap, trend rate, and the action items the PM has logged this week. The mini-charts in the "average trend over 6 weeks" column are sparkline wigglecharts — the whole shape, not just the latest number. -- 10 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › 03 Method Reporting by exception © 2026 lateralworks Page 11 Aggregating the data is the first half of the problem. The second half is filtering it down to the small set of projects that actually need leadership attention this week. The principle is old — Drucker called it management by exception more than fifty years ago [6] — but its execution requires the right primitives. fastProjectAI provides them as one-click filters on the dashboard, each of which compresses the working set further. -- 11 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 12 The filtering model From 196 milestones to 10 Figure 5. The filtering funnel. Each stage corresponds to a single filter button on the dashboard. Leadership reviews the right-most cohort — the projects that genuinely need attention this week — not the full 196. In the worked example covered later in the paper, the portfolio contains 196 milestones. Of those, 111 are currently active. Of the active set, 63 are behind their target. Of the late ones, 31 are getting worse rather than recovering. Of the worsening ones, 10 are severely behind — more than four weeks — and need immediate intervention. That final cohort of 10 is what leadership should be reviewing, debating, and acting on. The other 186 either do not need attention this week or are already being managed at the project level. Why each filter matters. • The active filter removes finished and not-yet-started milestones from the working view. There is no point reviewing what cannot be influenced. • The late filter removes the on-track majority. Time spent reviewing on-track projects is time not spent on the ones that need help. • The trend filter removes recovering projects from the late set. A project that is late but pulling back toward target does not need leadership intervention; it needs to be left alone. • The severity filter separates the projects that can still be recovered with a course correction from the runaways that need rebaselining or escalation. The filters compose. Each one is a single click, and the dashboard updates the visible row set in place. There is no separate filing, no waiting for a refreshed report. Leadership can apply the filters live during the review and immediately see who is in trouble and who is not. The principle is older than the dashboard: Ohno made visual management the load-bearing element of the Toyota Production System on the same logic [24] — surface the abnormal, not the normal. -- 12 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 13 The leader's control surface One ribbon, seven filter groups The four-stage funnel describes the discipline. The ribbon below is how leaders apply it. Every filter is a single button on a custom dashboard ribbon — no formulas, no pivot-table reconfiguration, no waiting for an analyst. A leader running a portfolio review opens the workbook, clicks two or three buttons, and the visible row set collapses to the projects that need attention this week. Figure 6. The fastProjectAI dashboard ribbon. Each group is one dimension of triage; combinations of buttons across groups produce the working set. Filters compose live; the row set updates in place. What each group does. • Update. Refresh Dashboard pulls the latest weekly forecasts from every connected project schedule. This is the only data-entry step in the entire review process — one click, before the meeting starts. • Type. Time From Target sorts by absolute gap (how late, in days). Likelihood To Hit Target sorts by the probability the project still lands on date. The two views answer different questions: how bad is the slippage, and how recoverable is it. • Show. The trend filters — Slipping and Late, All Late, All Slipping, Completed — are the four-stage funnel made tactile. Slipping and Late is the leadership-action working set; All Late shows everything behind regardless of trend; All Slipping shows everything with a worsening trend regardless of current gap; Completed turns the dashboard into a planning-track-record review. • Risk. Sort Risk orders the visible set by the PM's own risk classification. Show High Risk filters to Risk-3 milestones only — the projects the program team has already flagged as needing escalation. • Due By. Time-window filters: This Month, Next Month, This Quarter, Next Quarter, Show All Due By. These are how a leader running the quarterly business review pulls just the milestones that hit inside the review window. Outside-window projects stay in the data but disappear from the working view. • Sort By. Target Date orders the visible set by committed milestone date; Finish Date orders by the current forecast. Program groups all milestones by program for a program-by-program walk. Clear All resets every filter to its default state — one click to recover the full portfolio view. • Schedule. Critical Path To Selected highlights the predecessor chain that drives the selected milestone. Show Wigglechart opens the per-milestone wigglechart (Figure 1) for the selected row — the leader can drill from the portfolio view to the live forecast curve in one click. The combinatorial point is what matters. Show: Slipping and Late + Risk: Show High Risk + Due By: This Quarter is a three-click query that returns the projects that are behind, getting worse, flagged by the PM, and on the executive's near-term critical list. That is the working agenda for the review. The same query, asked of a traditional status-report stack, would take an analyst hours and produce a snapshot already a week stale. -- 13 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 14 "Exception reporting asks what is going wrong, who owns fixing it, and whether the fix is on track." A second-order benefit emerges from this filtering pattern: leadership reviews become measurably shorter and more useful. In engagements where lateralworks has helped clients adopt the dashboard, weekly portfolio reviews have dropped from 90-minute walk-throughs of every program to 30-minute working sessions on the right-most cohort. The remaining time is reinvested in actually unblocking the troubled projects. -- 14 of 29 -- Core principle Visibility precedes action "You can't accelerate a portfolio you can't see in time to act." lateralworks engagement observation across multi-project leadership reviews © 2026 lateralworks Page 15 -- 15 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › 04 Economics Live data, no overhead © 2026 lateralworks Page 16 A common objection to portfolio dashboards is the overhead they create: yet another reporting system the PMs must keep up to date, separate from their own planning artifacts, with predictable drift and predictable resentment. fastProjectAI sidesteps the objection because it does not introduce new data. It reads the data the PMs are already producing, in the format they are already producing it in, on the cadence they already produce it. -- 16 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 17 Why the data is free No parallel reporting system In an FTTM-managed organization, every PM already maintains a live milestone schedule and updates the wigglechart for each milestone every week. The wigglechart is part of the planning discipline that makes FTTM work [7]; the PM keeps it to manage their own project, and the executive review is a downstream consumer. The wigglechart is how the PM knows whether the project is on track and which milestones need attention this week. fastProjectAI reads the same source files. There is no separate data-entry burden, no parallel system that drifts out of sync with reality, and no incentive for the PM to present a different version of the data to leadership than they keep for themselves. The data is already in the PM's own working planning artifact; the dashboard aggregates it across the portfolio. Three consequences. • The data stays honest. There is no separate dashboard to fluff up before the executive review, because the dashboard is reading the same file the PM uses to manage the project. Inflating the dashboard would mean inflating the PM's own working data — against the PM's own interest. • The data stays current. Updates to the project schedule flow through to the dashboard automatically on the next read cycle, typically weekly. There is no lag between the PM updating their plan and leadership seeing the updated plan. • The data stays cheap. The marginal cost of adding a new project to the dashboard is the cost of pointing the aggregator at one more file. There is no per-project setup, configuration, or training needed beyond the FTTM planning practice itself. The pattern echoes the broader observation in lean product development that adding measurement systems often degrades the thing being measured [8]. fastProjectAI sidesteps this by measuring the artifact PMs are already producing for their own planning rather than asking them to produce something extra for reporting. The economic argument also runs the other way: Hamel and Zanini have estimated the cost of excess management overhead in the U.S. economy at roughly three trillion dollars per year [15], much of it spent producing status data that is stale by the time it is read. A free-data dashboard recovers a sliver of that cost at the program level. The free-data principle. A dashboard that asks the PMs for nothing they aren't already doing has no resistance, no drift, and no reporting bias. The same dashboard that asks the PMs to maintain a separate status feed will be wrong within a month. -- 17 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › 05 Worked example Site deployment portfolio © 2026 lateralworks Page 18 This section walks through one full leadership review using the dashboard, drawn from a recent lateralworks engagement with a utility-scale site deployment portfolio. The portfolio contains 196 milestones across 15 programs, ranging from 2-milestone programs to 19-milestone programs. The example illustrates how the dashboard surfaces the projects that need attention and how the patterns connect across programs. -- 18 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 19 A 15-program portfolio Where the trouble lives The portfolio summary itself reads cleanly: 111 active milestones, 85 already completed, 68% of the active set within two weeks of target. Without the per-milestone detail, this would suggest a healthy portfolio. The detail tells a different story: 63 of the 111 active milestones (57%) are behind their target dates; 12 are severely behind; 31 are actively slipping rather than recovering. The trouble is concentrated. Figure 7. Program-level health summary. Each row is one of the 15 programs, with active milestone count, count of late milestones, count of Risk-3 milestones, average gap, and average six-week trend. The bottom two rows are running ahead of schedule with improving trends; everything above is behind. Five patterns become visible at this level of detail. First, the three Customer Colorado programs (Bryan, Brandon, DN) account for 48 of the 111 active milestones and contain all 11 of the portfolio's Risk-3 flagged projects. Second, three smaller new-market expansion programs — Wasatch Peaks Ranch, APS 2025, PSE 2025 — are 100% behind schedule with worsening trends. Third, the NW Mexico Lighthouse R1 program shows 11 milestones all behind schedule with zero Risk-3 flags — the risk assessment is clearly lagging the actual schedule. Fourth, the Customer SPS R3/R4 program is running 21 days ahead of schedule with an improving trend of +4.5 days per week. Fifth, the CO Excel-only BKP program is similarly ahead. Each of these observations is one filter-and-sort on the dashboard, completed in seconds. None of them is visible from a traditional green-yellow-red status report. -- 19 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 20 The most urgent projects Ten that need action this week Applying the severity filter narrows the working set further. Ten milestones need immediate leadership attention: Site Program Gap Trend Risk Pueblo West Customer CO Bryan -66 d -16.8 d/wk 3 Steele Hollow Customer CO Bryan -66 d -16.6 d/wk 3 Craig Customer CO Bryan -64 d -10.6 d/wk 2 Vail Customer CO DN -49 d -12.5 d/wk 3 Keystone Customer CO Brandon -46 d -10.8 d/wk 3 Sugar Loaf Customer CO DN -40 d 0 d/wk 3 Aurora Reservoir Customer CO Brandon -36 d -4.8 d/wk 3 Bellvue Customer CO Brandon -35 d 0 d/wk 3 Sunset Point APS 2025 Expansion -36 d -9.0 d/wk 1 Agate Customer CO Bryan -28 d -8.2 d/wk 3 Table 1. The ten most urgent milestones in the portfolio after applying active + late + worsening + severity filters. Six of the ten are in the same program family (Customer Colorado); three of those six have no documented corrective actions despite being the worst performers in the entire portfolio. The shape of the data tells the leadership team where to focus. Pueblo West and Steele Hollow are the same project type, in the same program, with the same trend, and with no documented action plans — suggesting a structural failure in how that program is responding to slippage. Sugar Loaf and Bellvue have stopped getting worse but are stuck deeply behind — they need rebaselining. Sunset Point, in a newer expansion program, is replicating the same failure mode the Customer Colorado programs are stuck in. -- 20 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 21 Trend distribution The widening gap Plotting the six-week trend rate for every active milestone reveals a pattern that is invisible in any single project view: the distribution of trends is bimodal. Projects that are on or ahead of schedule are pulling further ahead, while projects that are behind are falling further behind. The middle — projects recovering from moderate delays — is empty. Figure 8. Six-week trend distribution across the active portfolio. Projects polarize into two camps; the recovery zone in the middle is empty. This means once a project falls behind by more than two or three weeks, the recovery mechanisms are not working. This observation has direct implications for how the leadership team should allocate intervention resources. Adding more rigor to the projects already on track produces no return. Adding more rigor to projects in the worsening tail is the only place where leadership attention changes the outcome. The bimodal pattern recurs across most multi-project portfolios in lateralworks engagement data [26], and it has been observed in broader project management research as well: schedule slippage tends to compound rather than correct in the absence of explicit recovery mechanisms [9, 10]. -- 21 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › 06 Pattern detection LLM analysis across projects © 2026 lateralworks Page 22 The dashboard alone surfaces the projects that need attention. The next step is harder: identifying the structural patterns connecting them. This is where a large language model earns its keep. Given the structured weekly export of the dashboard, an LLM can read across all 196 projects at once, look for cross-project regularities, and surface findings no single-project view would reveal. The work in this paper used Claude (Anthropic's Claude Opus model) for the pattern analysis, but the approach is model-agnostic. -- 22 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 23 What the LLM is doing Pattern detection across 196 Projects The workflow is simple. Each week, the dashboard exports its current state as a structured table: program, milestone, target date, current forecast, gap, trend, risk, and current actions. That table is fed to the LLM with a structured prompt asking it to identify cross-project patterns, structural risks, and recommended interventions. The LLM returns a written analysis that is reviewed by the program leadership. Figure 9. The LLM analysis layer. The dashboard's weekly export is fed to the LLM with a structured prompt. The LLM produces a narrative analysis identifying cross-portfolio patterns. Each finding traces back to specific rows in the dashboard so the analysis is verifiable. What makes this work is the structure of the input. Because the dashboard data is already normalized into a common format — one row per milestone, with the same columns for every project — the LLM can apply the same analytical lens across the entire portfolio. There is no need to teach it the idiosyncrasies of each project's reporting format, because there are no idiosyncrasies. The aggregator already removed them. The body of academic and industry research on LLM-assisted analytical work has expanded rapidly since the few-shot results reported in the GPT-3 paper [21] and the broader survey work that followed [11, 12]. The pattern that has consistently emerged is that LLMs do their best work when fed clean, structured data with a clear analytical prompt — not when asked to extract structure from messy inputs. fastProjectAI's aggregation step is the precondition that makes the LLM analysis work. The analytical mode is closer to what Tukey called exploratory data analysis [18] than to hypothesis testing — the LLM is asked to look at the shape of the data and report what stands out, with each finding traceable back to specific dashboard rows. -- 23 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 24 Five findings What the LLM surfaced In the worked example portfolio, the LLM analysis identified five cross-portfolio patterns. Each is a property of the portfolio. The findings emerge in aggregate, not in any individual project view. 1. Third-party dependency is the primary schedule killer. Across the portfolio, the largest single driver of schedule slippage is dependence on external parties — lease negotiations with landowners, carrier approvals, county permitting, state agency sign-offs. These dependencies do not erode schedules gradually; they slip in large discrete jumps as external approvals arrive late or stall. The current scheduling model treats them as predictable durations when they are high-variance events. 2. Action documentation is inversely correlated with severity. The two worst projects in the portfolio — Pueblo West and Steele Hollow, both 66 days behind — have no documented corrective actions. Projects that are on or ahead of schedule have detailed action items with named owners and due dates. The projects that need the most intervention are getting the least. This is a known dysfunction in distressed-program management [13]: severely late projects tend to be implicitly written off and stop receiving the active management that less-distressed projects retain. 3. Geographic concentration creates systemic risk. The three Customer Colorado programs account for 48 of 111 active milestones and contain all 11 Risk-3 flagged projects. Meanwhile the Customer SPS R3/R4 program is running 21 days ahead with improving trends. The schedule challenges are concentrated in a single regional environment. Possible contributing factors include regional regulatory complexity, higher density of private-landowner negotiations, and resource contention across three programs sharing the same field teams. 4. New programs are replicating old failure modes. Three newer expansion programs — APS, PSE, Wasatch Peaks Ranch — are all 100% behind schedule with worsening trends. They are making the same third-party dependency estimation errors that have plagued the Customer Colorado programs. Lessons from the older programs are not being transferred to new market entries. This is a structural problem in how the organization captures and redistributes program-specific lessons learned [14]. 5. The recovery zone is empty. Confirming the bimodal trend pattern from Section 05: of the 63 milestones currently behind schedule, almost none show a positive recovery trend. Most are flat or worsening. The portfolio lacks an effective catch-up mechanism for distressed projects. Once a project falls behind by more than two or three weeks, structural recovery is rare. -- 24 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 25 From findings to action What the LLM recommends The same LLM run produces a recommended action list grounded in the findings. Each item is tied to specific rows in the dashboard. Five recommendations follow from the five findings: • Rebaseline the runaway projects. Pueblo West, Steele Hollow, Craig, Vail, and Keystone are 46-66 days behind and still worsening. Their current target dates are no longer meaningful. Rebaseline based on actual dependency-resolution timelines. • Mandate action plans for any project >2 weeks behind. Make this a hard gate on the weekly dashboard review. The current pattern where the worst projects have the fewest plans must be reversed. • Add buffer multipliers for third-party dependencies. Lease negotiations, carrier approvals, and permitting should be scheduled with 2-3x duration buffers based on actual historical variance, especially for new market entries. • Investigate what Customer SPS R3/R4 is doing differently. A program running 21 days ahead with a +4.5 day-per-week trend is a replicable success pattern. Understanding the difference is a playbook for the rest of the portfolio. • Triage NW Mexico Lighthouse R1. Eleven milestones all behind with zero Risk-3 flags means the risk assessment framework is not calibrating correctly for that program. A formal risk-recalibration review is needed before the program drifts further. These recommendations are first drafts. The leadership team reviews them, accepts or modifies them, and assigns ownership. The LLM's job is to compress the time between dashboard data and a structured candidate analysis — from the days a human analyst would need to a few minutes — while preserving traceability back to the source rows. What the LLM is and isn't. The LLM is reading the same dashboard the leadership team is reading, with the same data, on the same cadence. The difference is that it can hold all 196 projects in attention at once and look for patterns across all of them simultaneously, which a human reviewer cannot. The LLM complements human judgment, consistent with the human-oversight framing in current model-development practice [22]. -- 25 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › 07 Implementation Adopting the dashboard © 2026 lateralworks Page 26 Adopting fastProjectAI inside an organization is mostly a question of upstream prerequisites. The dashboard itself is straightforward to deploy; the precondition for it to add value is the FTTM planning discipline that produces the wigglecharts in the first place. This section covers the practical steps in order. -- 26 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 27 Practical adoption Three steps in order 1. Establish the planning discipline first. fastProjectAI is only useful if the underlying wigglecharts are real. If the PMs are not maintaining live milestone schedules with weekly forecast updates, no dashboard will fix the problem — it will just expose the absence of data more visibly. The first step is to ensure FTTM-style planning practice is in place at the project level. Without it, the dashboard reports zeros or stale inputs. 2. Standardize the milestone schema. Each milestone needs a target date, a current forecast date, an owner, and a risk flag — in a consistent column format across projects. The aggregator has to be able to read each project's schedule the same way. In practice, this is a one-time set-up cost: agree on the schema, create a template, roll it out across programs. Cooper, Edgett, and Kleinschmidt note that portfolio comparability is the precondition for portfolio management [4]; the milestone schema is what produces comparability. 3. Run the dashboard for four weeks before the LLM layer. The dashboard alone delivers most of the value. The LLM layer adds cross-project pattern detection, but it only earns its keep once the dashboard data is stable enough that the patterns are real. Running the dashboard for four weeks before adding the LLM analysis lets the leadership team calibrate against the underlying data first, and lets the PMs settle into the discipline of weekly updates without the additional pressure of an LLM critique. -- 27 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 28 What it costs And what it doesn't The marginal cost of running fastProjectAI inside an FTTM-managed organization is small. The PMs are already producing the data; the aggregator is a single piece of software that reads project schedules and renders the dashboard; the LLM analysis runs weekly against the structured export. Once set up, the running cost is dominated by the LLM API charges, which for a typical 15-program portfolio amounts to a few dollars per week. The setup cost is one-time and modest: schema standardization, aggregator deployment, dashboard configuration, prompt design for the LLM layer. Most of the work is upstream — establishing the FTTM planning discipline that makes the data meaningful. Organizations that have invested in that discipline find the dashboard layer trivial to add. Organizations that haven't will spend most of their effort on the planning discipline itself, which is the real foundational asset. What the dashboard does not replace: program leadership, PM judgment, executive decision-making, or the relationships and context that make a program work. It is a visibility layer, not a management layer. Its purpose is to tell leadership where to look and what to ask. The actual work of leading the projects remains where it always was — with the people running them. The economic logic. The dashboard is free if the planning discipline is already in place. The planning discipline is not free, but it is the foundational asset every other capability rests on. Organizations that try to install the dashboard without the planning discipline will get either empty rows or fictional ones; either way, no value. -- 28 of 29 -- › fastProjectAI Project Portfolio Dashboard › › › © 2026 lateralworks Page 29 Sources References [1] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [2] Lewis, J. P. Mastering Project Management: Applying Advanced Concepts to Systems Thinking, Control and Evaluation, and Resource Allocation. McGraw-Hill, 2nd ed., 2008. [3] U.S. Government Accountability Office. "Schedule Assessment Guide: Best Practices for Project Schedules." GAO-16-89G, December 2015. https://www.gao.gov/products/gao-16-89g [4] Cooper, R. G., Edgett, S. J., and Kleinschmidt, E. J. Portfolio Management for New Products. Basic Books, 2nd ed., 2001. [5] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. Wiley, 2nd ed., 1997. [6] Drucker, P. F. The Effective Executive. Harper & Row, 1967. [7] lateralworks. "FTTM Reference Guide: Self-Paced Tutorial." Internal methodology document, 2024. lateralworks.com. [8] Reinertsen, D. G. Managing the Design Factory: A Product Developer's Toolkit. Free Press, 1997. [9] Vanhoucke, M. Measuring Time: Improving Project Performance Using Earned Value Management. Springer, 2010. [10] Lipke, W. "Schedule is Different." The Measurable News, Summer 2003, College of Performance Management, pp. 31-34. [11] Bommasani, R., et al. "On the Opportunities and Risks of Foundation Models." Stanford CRFM Technical Report, 2021. https://crfm.stanford.edu/report.html [12] Bubeck, S., et al. "Sparks of Artificial General Intelligence: Early experiments with GPT-4." Microsoft Research, 2023. arXiv:2303.12712. [13] Keil, M., and Robey, D. "Turning Around Troubled Software Projects: An Exploratory Study of the Deescalation of Commitment to Failing Courses of Action." Journal of Management Information Systems, vol. 15, no. 4, 1999, pp. 63-87. [14] Argote, L. Organizational Learning: Creating, Retaining and Transferring Knowledge. Springer, 2nd ed., 2013. [15] Hamel, G., and Zanini, M. "Excess Management Is Costing the U.S. $3 Trillion Per Year." Harvard Business Review, September 2016. https://hbr.org/2016/09/excess-management-is-costing-the-us-3-trillion-per-year [16] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. Free Press, 1992. [17] House, C. H., and Price, R. L. "The Return Map: Tracking Product Teams." Harvard Business Review, January-February 1991, pp. 92-101. [18] Tukey, J. W. Exploratory Data Analysis. Addison-Wesley, 1977. [19] Lee, H. L., Padmanabhan, V., and Whang, S. "Information Distortion in a Supply Chain: The Bullwhip Effect." Management Science, vol. 43, no. 4, 1997, pp. 546-558. [20] Kahneman, D. Thinking, Fast and Slow. Farrar, Straus and Giroux, 2011. [21] Brown, T., et al. "Language Models are Few-Shot Learners." Advances in Neural Information Processing Systems, vol. 33, 2020, pp. 1877-1901. arXiv:2005.14165. [22] Anthropic. "Constitutional AI: Harmlessness from AI Feedback." arXiv:2212.08073, 2022. [23] Pinto, J. K., and Mantel, S. J. "The Causes of Project Failure." IEEE Transactions on Engineering Management, vol. 37, no. 4, 1990, pp. 269-276. [24] Ohno, T. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. [25] Goldratt, E. M. Critical Chain. North River Press, 1997. [26] lateralworks. "Internal assessment database: portfolio visibility engagements." Engagement data across client programs, 2018-2026. -- 29 of 29 --

FTTM Toolkit·Synthesis paper

fastProjectAI Project Portfolio Dashboard

Aggregating live project schedules into a single leadership view

Core thesis. Most leadership teams running multiple programs cannot see their portfolio in time to act. fastProjectAI fixes this by aggregating live wigglechart data the PMs already maintain — surfacing the small number of projects that need attention this week, not the long tail that does not.

May 1, 2026·29 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Whitepaper FTTM Process Maturity A framework for measuring and improving team performance. FTTM methodology series. A measurement framework for the FTTM (Fast-Time-To-Market) methodology, with definitions of the four maturity levels, a self-assessment scorecard, migration guidance, and the seven factors that determine how quickly teams advance. Prepared by lateralworks FTTM methodology Date April 2026 Methodology paper Online lateralworks.com FTTM series -- 1 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 2 Table of contents FTTM Process Maturity Abstract 03 The three stages of acceleration 04 Process maturity levels 06 Self-assessment scorecard 10 Maturity migration 13 Factors that influence the speed of maturity 18 Appendix A — Scoring rubric 21 References 23 Core thesis. A team’s schedule maturity is observable, measurable, and migratable. Teams move through four levels — from ML0 (no schedule) to ML3 (active acceleration) — by changing specific behaviors in the weekly refresh. Knowing where a team sits on this curve is the prerequisite to changing it. -- 2 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 3 Overview Abstract Most teams do not know how mature their planning process is. They know whether the project is on schedule or behind. They know whether the last meeting was painful or productive. But they cannot answer the harder question: are we set up to see problems before they hit, or only after? The Fast-Time-To-Market (FTTM) Process Maturity framework answers that question with a four-level metric, a structured self-assessment, and explicit migration paths. The framework distinguishes four levels of process maturity: ML0 (minimal schedule, gap not known), ML1 (accurate plan, gap known), ML2 (weekly refresh, tracking trends, team functioning independently), and ML3 (actively accelerating the schedule, continuously improving the process). These levels map to three stages of performance control — looking back, looking forward, and influencing forward — and to a predictable migration timeline of roughly one to two months from ML0 to ML1, two to three months from ML1 to ML2, and three to five months from ML2 to ML3. The framework is a near-relative of the Capability Maturity Model developed at Carnegie Mellon’s Software Engineering Institute in the late 1980s [1, 2]. Both frameworks share the central insight that process capability is observable, measurable, and progressive. The FTTM maturity model differs in two ways: it focuses specifically on the weekly schedule refresh as the unit of measurement, and it explicitly connects maturity to acceleration — not just process control. ML2 gives a team predictability; ML3 gives it speed. This paper provides the definitions of each level, a 30-criterion self-assessment scorecard with a 1–5 scoring rubric, and a description of the seven organizational and behavioral factors that determine how quickly a team can advance. It also lays out a four-month progression playbook that maps month-by-month activities onto the maturity levels reached. It is intended for product delivery teams, program managers, and the executive sponsors whose engagement is often the deciding variable in whether a team gets past ML1. -- 3 of 23 -- › FTTM Process Maturity › › › 01 Performance The three stages of acceleration © 2026 lateralworks Page 4 Every team’s journey toward faster delivery passes through three distinct stages. Each stage represents a fundamentally different relationship between the team and its schedule. Knowing which stage a team operates in is the first step toward improvement — and the most common source of confusion in coaching engagements is teams that believe they have crossed a stage boundary they have not actually crossed. The stages are not arbitrary. They correspond to whether the team is reacting to events that have already happened, anticipating events that have not yet happened, or actively shaping events that have not yet happened. The boundary between stage one and stage two is the most important shift a team can make. Reinertsen frames this as the difference between economic decision-making and proxy-variable management [3]. A team that only updates after the fact is using yesterday’s information to react to today’s problems. The boundary between stage two and stage three is rarer and harder. It requires the team to spend time on opportunities to accelerate, not on incidents to recover from. Most teams never make this crossing because the urgency that surfaces problems also crowds out the time needed to plan acceleration. -- 4 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 5 Stage one Look back — after-the-fact control The team creates an accurate schedule, records progress, and knows where it is. The primary activity is updating the plan with what has happened. The team produces an Update Report that looks one week back. This is better than having no schedule at all — but the team is fundamentally reactive. It discovers problems after they have caused delays, and can only report on slips, not prevent them. Stage two: Look forward — before-the-fact control The team knows where it is going, knows what is critical and next, and gives people early warning. The team looks back to recover time through pull-back, mitigates the impact of slips, and improves the probability of on-time completion. The transition from stage one to stage two is the most consequential shift a team can make. It is the difference between being a passenger in the schedule and being the driver. Williams and colleagues, in their study of early warning signs in complex projects, found that teams able to act on early signals systematically outperformed teams that relied on after-the-fact reporting [4]. Stage three: Influence forward — active acceleration The team knows what to accelerate, actually pulls work in, and finishes early or banks time for unknowns. It produces a Focus Report that looks one week forward. The schedule is no longer just a tracking tool; it is the primary mechanism for identifying and executing acceleration opportunities. This is the highest level of schedule-driven performance and is very difficult to achieve. Figure 1. The Refresh Planning Process — the operational system that has to be in place for a team to move up the maturity curve. The process spans three time windows. The day before the meeting the PM publishes the Update Report so owners can prepare. During the meeting the team runs four steps in sequence — update (1/3, look-back), pull-in (2/3, accelerate the top three critical paths), wigglechart (track milestone trends), and look-ahead (tasks for the coming week). After the meeting the PM runs CP analysis with pull-in actions and publishes the Project Status Report. Break-down work happens in or off the meeting with specific owners. ML1 requires the update and look-ahead steps to be reliable; ML2 adds disciplined pull-in and wigglechart trend tracking; ML3 adds CP analysis and live break-down. Without the process, the maturity behaviors have nowhere to land. -- 5 of 23 -- › FTTM Process Maturity › › › 02 Measurement Process maturity levels © 2026 lateralworks Page 6 The framework defines four levels of process maturity — ML0, ML1, ML2, and ML3 — that map to the three stages of acceleration. These levels exist as observable behaviors in the weekly refresh, not as theoretical constructs. Any experienced coach watching a team for thirty minutes can place it within one level of accuracy. The structure mirrors the levels in the Capability Maturity Model Integration framework administered by the CMMI Institute [2], which evolved from Watts Humphrey’s original Process Maturity Framework developed at the Software Engineering Institute beginning in 1986 [1]. The shared logic is that organizations move from ad hoc to managed to optimizing through observable progressions, and that the migration requires sustained behavioral change rather than reorganization. What distinguishes the FTTM levels from CMMI levels is unit of measurement. CMMI assesses an organization across many process areas. FTTM maturity is measured in a single forum — the weekly schedule refresh — against a focused set of behaviors. This makes the assessment fast, frequent, and actionable. -- 6 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 7 Figure 2. Maturity level progression with typical migration timing. ML0 to ML1 is a foundational artifacts build; ML1 to ML2 requires multiple learning cycles; ML2 to ML3 requires team-level cultural change. The transition from after-the-fact to before-the-fact control occurs between ML1 and ML2. ML0. Minimal schedule — inaccurate, not current, gap not known The team has a minimal or non-existent schedule. What exists is inaccurate, not current, and the gap between target and reality is unknown. Work is reactive: issues are discovered after they have already caused delays. There is no shared management tool driving the team’s work, and decisions are made anecdotally. Characteristics: No structured schedule, or a schedule severely out of date. No milestone tracking. No refresh cadence. Functional teams operate in silos. No critical path analysis. Status reporting is anecdotal. ML1. Basic schedule, accurate based on known data, gap known The team has built an accurate plan from known data and updates it with what has actually happened. The gap between the target date and the realistic critical path finish is quantified. The team produces an Update Report that looks one week back. This is after-the-fact control — the team knows where it is and where it is going, but is primarily recording rather than anticipating. Reaching ML1 typically takes a few weeks of focused effort. Characteristics: Credible schedule with bottom-up durations from functional owners. Milestones aligned to customer gates. Doneness criteria defined. Weekly refresh established. Critical path identified. Gap quantified. Update Report distributed. ML2. Weekly refresh, accurate schedule, tracking trends, team functioning independently The team performs weekly refreshes consistently and the schedule is accurate and current. The team tracks trends, looks back to recover time, mitigates the impact of slips, and improves the probability of on-time completion. This is before-the-fact control — the team looks forward, anticipates issues, and takes corrective action before problems materialize. The team functions independently without constant coaching. Moving from ML1 to ML2 takes months of consistent practice and multiple learning cycles. Characteristics: Refresh occurs same time and place every week. Full team prepared. PM reads out activities efficiently. Discussions parked for breakouts. Schedule drives work. Critical paths focus discussions. Near-term activities broken down via short-interval scheduling. Milestone trends tracked. -- 7 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 8 Maturity levels ML3 — the rare level ML3. Accelerating the schedule, continuously improving the process The team actively accelerates the schedule and continuously improves its own process. This is influence forward — the team knows what to accelerate, actually pulls work in, and finishes early or banks time. It produces a Focus Report that looks one week forward. Pull-in is deliberate and systematic, targeting the top three to five near-critical paths. The framing is closely aligned with Reinertsen’s argument that product development teams should optimize for flow and use cost-of-delay as a primary decision input [3]. ML3 is very hard to achieve and requires a high-performing team that has fully internalized the FTTM methodology. Characteristics: Team uses gap and critical paths to actively pull in. Main and secondary CPs are scrubbed. Baseline used to discuss near-term activities. Wiggle chart actively discussed. Team assumes acceleration, not slip. Sub-group meetings during the week for deeper scrubbing. Focus Report produced. Business case and cost-of-delay drive decisions. ML1 and ML2 teams are still mostly looking back. ML3 teams look forward. The shift between looking-back and looking-forward postures is what makes the ML2-to-ML3 migration so difficult — it requires reallocating attention from recovery to acceleration, even when there are slips that could be recovered. Most teams find this counterintuitive and revert to recovery work as soon as the next slip surfaces. -- 8 of 23 -- Maturity migration Why ML3 is rare ML3 teams look forward, not back. They assume acceleration, not slip. — FTTM methodology, lateralworks Process Maturity framework © 2026 lateralworks Page 9 -- 9 of 23 -- › FTTM Process Maturity › › › 03 Diagnosis Self-assessment scorecard © 2026 lateralworks Page 10 Maturity is observable in behavior, and behavior is measurable. The self-assessment scorecard rates a team across 30 specific criteria grouped into seven dimensions: schedule quality, refresh execution, pull-in behavior, core team effectiveness, communication, issues and risks, and decisions. Each criterion is scored 1 (poor) to 5 (excellent). The radar chart of dimension averages reveals where to focus improvement. A team generally cannot be rated higher than its weakest critical dimension. A perfect schedule with no refresh cadence is still ML0. A strong refresh on top of an inaccurate schedule is still ML0. Both schedule quality and refresh execution must reach threshold levels before the team can be considered ML1. The discipline of self-assessment is itself a maturity indicator. Teams able to score themselves honestly — surfacing weaknesses instead of defending them — are signaling the kind of psychological safety that Edmondson identified as a precondition for organizational learning [5]. The scorecard works only when the team treats it as a diagnosis, not a verdict. -- 10 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 11 Scorecard The seven dimensions Dimension What it measures Schedule quality Bottom-up durations, customer-aligned milestones, doneness criteria, analyzer score. Refresh execution Cadence, attendance, preparedness, PM efficiency, fast read-out, parked discussions. Pull-in behavior Critical path walks, gap discussion, scrub of main and secondary CPs, milestone trend tracking. Core team effectiveness Right roles, ownership, alignment on methodology, ability to perform and adapt independently. Communication Post-refresh updates, audience targeting, completeness, timeliness. Issues and risks Structured register, ownership, mitigation, surfaced versus hidden. Decisions Schedule used to model scenarios. Cost-of-delay applied. Decisions documented. -- 11 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 12 Visualization The maturity radar Plot the seven dimension averages on the radar chart below to visualize the team’s maturity profile. Most teams are not uniformly strong or weak across all dimensions — the shape of the radar reveals where to focus improvement effort. A team with strong schedule quality and weak pull-in behavior sits at ML1; a team with strong pull-in but weak communication is operationally effective but failing to share its progress. Figure 3. Self-assessment radar with maturity-level reference rings. A team’s profile (overlaid) shows which dimensions are pulling its overall maturity rating up or down. -- 12 of 23 -- › FTTM Process Maturity › › › 04 Progression Maturity migration © 2026 lateralworks Page 13 Migration between levels is not instantaneous. It requires sustained behavioral change across the entire core team — not just the program manager. The first migration is primarily about building artifacts. The second and third are primarily about changing behavior. This is why budgets and timelines for maturity work consistently underestimate the later migrations. The pattern is consistent with Kotter’s observation that lasting organizational change requires sequential phases of urgency, coalition, vision, action, short-term wins, consolidation, and anchoring — and that anchoring change in culture is the slowest and hardest phase [6]. The same logic applies inside a single product delivery team: the artifacts arrive in weeks, the behaviors in months, the culture last and only with sustained reinforcement. -- 13 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 14 Migration paths From ML0 to ML3 ML0 to ML1: build the artifacts (1–2 months) This migration is primarily about building foundational artifacts. Scrub the schedule with functional owners in small-group breakouts to replace top-down placeholder durations with realistic, bottom-up estimates. Establish the target date and compute the critical path gap. Define doneness criteria for every major milestone. Set up a fixed weekly refresh meeting with the full core team. Send an Update Report after each refresh summarizing what changed, the current critical path, and top actions. The primary obstacle is rarely technical — it is getting the team to invest in schedule quality before the pressure of daily execution crowds it out. ML1 to ML2: internalize the rhythm (2–3 months) This migration requires the team to internalize the refresh process so it runs efficiently without coaching. The PM must be fluent in the scheduling tool. Team members must come prepared. Discussions must be parked for breakouts. The schedule must become the team’s shared management tool, not a PM artifact that is tolerated. The team begins tracking milestone trends via the wiggle chart and using them to anticipate problems. Near-term long-duration activities are broken down into one- to ten-day tasks via short-interval scheduling. The team uses the critical path to focus technical discussions and begins looking back to recover time when slips occur. ML2 to ML3: shift attention to acceleration (3–5 months) This is the hardest migration. The team must shift from looking back and recovering to looking forward and actively accelerating. It must use the schedule to model scenarios and drive decisions. Pull-in must become systematic and deliberate, targeting the top three to five near-critical paths. The team must assume acceleration, not slip — banking time when on track rather than relaxing into the float. -- 14 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 15 Figure 4. The team’s maturity curve. Process maturity rises with the team’s ability to act earlier in the cycle. ML0 is no updating; ML1 records slip and pull-in; ML2 recovers time lost; ML3 accelerates before slipping and banks time against unknowns. The transition from after-the-fact to before-the-fact control occurs between ML2 and ML3. Inside the team-level view above sits a more granular progression — the discrete habits that define the program manager’s role at each maturity level. Figure 5 zooms in on the PM-specific behaviors that compound into team maturity. Figure 5. The Project Manager’s maturity curve. PM behaviors progress through seven discrete steps — come to meeting, come on time, come prepared, study the critical path, pull-back after slipping, follow-through on pull-back actions, and finally pull-in before it slips. Gray markers are the prerequisite habits before ML1; the blue ML markers fix the levels at which each behavior becomes routine (study CP at ML1, follow-through at ML2, pull-in before slip at ML3); green markers identify the active acceleration behaviors that distinguish ML3. Each step must be fully landed before the next can hold; teams that skip steps regress to the last stable behavior. -- 15 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 16 Migration playbook The four-month progression The migration timeline maps onto a concrete four-month playbook. Each month introduces a defined set of behaviors and produces a recognizable maturity step. The playbook is cumulative — each month does everything the prior month did, plus one new layer. Teams that try to skip a month’s practices to reach a later behavior almost always regress; the staircase only holds when each step is fully landed before the next is added. This sequencing is the operational consequence of the learning-cycle pattern Argyris described as the prerequisite for double-loop change [13]. Figure 6. The four-month progression curve. Month 1 lands the team at ML1; Month 2 brings the first deliberate pull-in actions and reaches ML2; Month 3 widens pull-in to secondary critical paths; Month 4 shifts the team into live, dynamic breakdown and pull-in characteristic of ML3. Month 1 — update and review schedule status (reaches ML1) The first month builds the operating cadence. Send PreFresh reports before the meeting and teach activity owners how to read and use them. Run refresh meetings on time — same day, same time, starting and ending on time. Get full attendance of all core team members and activity owners. All attendees come with completed PreFresh reports so progress updates land quickly. The PM updates the schedule in 10–15 minutes by asking the update questions and nothing more, limiting extra talking. The team reviews change — slip and pull-in — for each target, walks the first critical path (CP1) to each target, and discusses the cause of slip or pull-in. The wigglechart is run and comments are added explaining the cause of change. PostFresh reports go out after the meeting; team members are taught how to use them. -- 16 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 17 Month 2 — pull-in CP1 and schedule scrub (reaches ML2) Month 2 adds deliberate pull-in to the routine. For each target, walk CP1 starting from the first task and look for opportunities to pull in. Implement pull-in actions into the schedule immediately whenever possible. Where actions cannot be implemented in the meeting, record them in the task’s notes (using the action button) and send them to all owners after the meeting. Pull-in actions should be implemented by the end of the day following the refresh, and must be implemented before the next refresh. Break down and scrub activities on or near CP1 occurring within the next six weeks, working with their respective owners. By the end of month 2, the team is consistently looking forward, anticipating slips before they happen, and the schedule is driving work rather than recording it. Month 3 — pull-in CP2–5 and CP analysis Month 3 widens pull-in beyond the primary critical path. For each target, after pulling in CP1, peel back to CPs 2–5 on each target and look for pull-in actions on each. Implement actions immediately where possible; otherwise record them and follow through before the next refresh. Run CP analysis, review it with the team, and walk the pull-in actions on CP1–5. The intent is to surface the second and third near-critical paths before they become the new critical path — a problem that, as Goldratt observed in his treatment of the theory of constraints applied to scheduling, is most visible in the transition from a single-CP focus to a multi-path one [12]. Month 3 is still ML2 territory, but it is the month in which the team’s attention starts to migrate from recovery to acceleration. Month 4 — live dynamic breakdown and pull-in (reaches ML3) Month 4 is the threshold of ML3. The team breaks down and pulls in the schedule live in the refresh meeting and looks forward to anticipate problems and mitigate them before they happen. Sub-group meetings during the week scrub specific paths in greater depth. The Focus Report replaces the Update Report as the dominant artifact. Cost-of-delay enters decision-making. Reinertsen’s argument that product development teams should optimize for flow [3] is now operational — the team is no longer waiting for a slip to take action; it is acting to bank time against unknowns. Most teams do not get to month 4 on the first attempt. Reaching ML3 typically requires sustained executive pull and the kind of psychological safety that allows the team to surface an opportunity to accelerate even when no one is asking for one [5]. -- 17 of 23 -- › FTTM Process Maturity › › › 05 Conditions Factors that influence the speed of maturity © 2026 lateralworks Page 18 Seven organizational and behavioral factors determine how quickly a team can move up the maturity curve. These factors are not within the program manager’s sole control — they require alignment between the team, its leadership, and the broader organization. Of the seven factors, executive pull is the single most powerful accelerator. When senior leadership routinely asks "what is the gap?" and "what are we doing to pull in?" the team learns that the schedule matters and that investment in planning will be recognized. When leadership ignores the schedule or treats it as a status-reporting exercise, even the most disciplined teams stall at ML1. Figure 7. The seven factors that influence the speed of maturity migration. No single factor is sufficient on its own; weakness in any one factor caps the team’s achievable maturity. -- 18 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 19 Factor detail What each factor controls Team structure. Are members dedicated to the project, or split across many? Do they report to the project leader? Dedicated, co-scheduled teams mature faster because they invest focused time without the overhead of context-switching. Time committed to planning. Is planning an afterthought squeezed into the margins of the week, or is it the team’s main focus? Teams that treat planning as a first-class activity mature far faster than teams that view it as overhead. Team leadership. Is the project leader technically respected, empowered, and in control of resources? Empowered leaders make trade-offs at the team level instead of escalating, accelerating decision velocity. Contact with customer. Is the team customer-driven, with a real sense of customer needs and time-to-market pressure? Internal targets carry less force than a real customer deadline. House and Price showed that teams tracking to customer break-even time outperformed teams tracking to internal milestones [7]. Sense of urgency. Is the team always pushing, working to an early schedule, with an early-warning system in place? Urgency is not panic — it is the disciplined practice of working to pull the schedule in rather than waiting for it to slip. Discipline. Does the team maintain the rhythm of refresh without giving up when it gets hard? The first few refreshes are always rough. Teams that push through the discomfort improve rapidly. Teams that cancel or reschedule when busy stall at ML0. Executive pull. Does senior management demand the process, ask questions about the schedule and critical path, and use the outputs to make decisions? Executive engagement is the single most powerful accelerator. The pattern matches Kotter’s finding that change efforts without sustained executive sponsorship dissolve into isolated projects [6]. -- 19 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 20 Why migration takes time The geometry of change The reason ML2-to-ML3 migration cannot be compressed is that it requires culture change, not just process change. Lower-order changes — technology, process, skills — can be made in weeks. Higher-order changes — strategy, behavior, culture — take months to years. The diagram below maps the dependency: any large performance improvement nests culture change inside it, and culture is the outer ring that must be moved last and slowest. Figure 8. Time required to create sustainable change. Each ring represents a layer of organizational change; magnitude of performance improvement and time required scale together. ML2-to-ML3 migration sits in the outer rings. This nesting structure echoes Schein’s model of organizational culture as artifacts, espoused values, and underlying assumptions [8]. Process changes operate in the artifacts layer. ML3 maturity requires a change in the underlying assumptions about what the schedule is for — from a status-reporting tool to a decision-making one. -- 20 of 23 -- › FTTM Process Maturity › › › A Reference Scoring rubric © 2026 lateralworks Page 21 The scoring rubric is the operational definition of each score level on the self-assessment scorecard. Use it to calibrate scoring across teams and across time — a "3" should mean the same thing in every assessment. Calibration is what separates a useful maturity assessment from a theatrical one. Without a shared rubric, scores drift toward the self-image of whoever is doing the rating. PMs who pride themselves on discipline tend to inflate their refresh-execution scores. Teams who feel underappreciated tend to deflate their core-team scores. The rubric is the discipline that prevents both. It also makes cross-team comparison meaningful: a portfolio leader looking at twelve teams’ maturity profiles can only spot the patterns that matter — weakest dimensions, fastest movers, stalled teams — when the underlying scores are calibrated to the same standard. The rubric below covers the five core dimensions. Issues-and-risks and decisions follow analogous patterns: a "1" means the practice is not happening; a "5" means it is mastered and is being used to improve the team’s own process. -- 21 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 22 Reference Scoring rubric Figure A1. Scoring rubric for the self-assessment. Each score level (1–5) is defined across the five core dimensions. Use the rubric to keep ratings consistent across teams and over time. In practice, the most useful pattern is to score a team in three passes. Pass one is the PM’s self-rating after the refresh. Pass two is a 30-minute team conversation against the rubric. Pass three is an external coaching review. The convergence — or divergence — between the three passes is itself diagnostic. Teams whose internal and external ratings differ by more than one level on multiple dimensions are usually in denial about a specific weakness. -- 22 of 23 -- › FTTM Process Maturity › › › © 2026 lateralworks Page 23 Sources References [1] Humphrey, W. S. Managing the Software Process. Addison-Wesley, 1989. The original formulation of the Process Maturity Framework that became the Capability Maturity Model. [2] CMMI Institute. "CMMI Model V3.0." Capability Maturity Model Integration Institute, 2023. https://cmmiinstitute.com [3] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. Especially chapters on cost of delay and queue management. [4] Williams, T., Klakegg, O. J., Walker, D. H. T., Andersen, B., and Magnussen, O. M. "Identifying and Acting on Early Warning Signs in Complex Projects." Project Management Journal, vol. 53, no. 2, 2012, pp. 37–53. [5] Edmondson, A. C. "Psychological Safety and Learning Behavior in Work Teams." Administrative Science Quarterly, vol. 44, no. 2, 1999, pp. 350–383. [6] Kotter, J. P. Leading Change. Harvard Business School Press, 1996. Originally previewed in "Leading Change: Why Transformation Efforts Fail," Harvard Business Review, March–April 1995. [7] House, C. H., and Price, R. L. "The Return Map: Tracking Product Teams." Harvard Business Review, January–February 1991, pp. 92–101. [8] Schein, E. H. Organizational Culture and Leadership, 4th edition. Jossey-Bass, 2010. [9] Kelley, J. E., Jr., and Walker, M. R. "Critical-Path Planning and Scheduling." Proceedings of the Eastern Joint IRE-AIEE-ACM Computer Conference, 1959. The foundational paper on the critical path method. [10] Ohno, T. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. The original articulation of pull-system thinking that informs FTTM’s pull-in concept. [11] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. Free Press, 1992. The original characterization of heavyweight cross-functional teams. [12] Goldratt, E. M. Critical Chain. North River Press, 1997. The application of theory of constraints to project scheduling, with extensive treatment of buffer management. [13] Argyris, C. "Teaching Smart People How to Learn." Harvard Business Review, May–June 1991. The framing of single-loop and double-loop learning that underlies the FTTM "learning cycles" concept. [14] Nikander, I. O. "Early Warnings: A Phenomenon in Project Management." Doctoral dissertation, Helsinki University of Technology, 2002. [15] Software Engineering Institute. "CMMI for Development, Version 1.3." Carnegie Mellon University, November 2010. https://resources.sei.cmu.edu [16] McKinsey & Company. Cited in House and Price [7]: companies lose on average 33 percent of after-tax profit when they ship products six months late, compared with 3.5 percent when they overspend 50 percent on product development. [17] Detert, J. R., and Edmondson, A. C. "Implicit Voice Theories: Taken-for-Granted Rules of Self-Censorship at Work." Academy of Management Journal, vol. 54, no. 3, 2011, pp. 461–488. [18] Anderson, D. J. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010. [19] Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide), 7th edition. PMI, 2021. [20] lateralworks. Internal assessment database. Engagement data across client programs, 2015–2026. -- 23 of 23 --

FTTM Methodology·Methodology paper

FTTM Process Maturity

A framework for measuring and improving team performance

Core thesis. A team’s schedule maturity is observable, measurable, and migratable. Teams move through four levels — from ML0 (no schedule) to ML3 (active acceleration) — by changing specific behaviors in the weekly refresh. Knowing where a team sits on this curve is the prerequisite to changing it.

April 29, 2026·23 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Whitepaper Host best practices How executives create the conditions for fast product development FTTM methodology series. A lateralworks Fast Time To Market (FTTM) methodology paper — the 13 host practices that separate fast organizations from slow ones. Revised edition. Prepared by lateralworks FTTM methodology Date April 2026 Revised edition Online lateralworks.com FTTM series -- 1 of 48 -- › Host best practices › › › © 2026 lateralworks Page 2 Table of contents Host best practices Abstract 03 List of figures 04 01 — The host: what it is, why it matters 05 02 — Mindset 12 03 — Environment 18 The host is the ceiling 26 04 — Portfolio 27 05 — Putting it to work 34 References 37 Appendix A — Case study: storage technology 39 Appendix B — Empowerment matrix 46 Core thesis. Teams deliver products; the host creates the conditions under which they deliver fast. Fix the host and speed becomes the default. Leave the host alone and team-level improvement fades within a year. -- 2 of 48 -- › Host best practices › › › © 2026 lateralworks Page 3 Overview Abstract Most companies chase faster product development by pushing the team harder. Training, project managers, new tools, tighter schedules — very little improves. The reason is structural. A project team operates inside an environment, a host, and the host decides what the team can actually do. A slow host produces slow teams regardless of how skilled those teams are. A fast host lets otherwise-ordinary teams move quickly. This paper describes the 13 host practices that lateralworks has found, across more than three decades of consulting with technology companies, to separate fast organizations from slow ones. The practices fall into three groups: the mindset executives hold about speed, the environment they build around teams, and the portfolio of projects they manage. Each practice is presented as a contrast: what normal organizations do, and what fast ones do differently. The difference is usually not effort or talent. It is design. The practices come from direct observation of fast-to-market teams, beginning with a multi-company study of more than 500 practitioners in the early 1990s. They connect to a broader body of research: Reinertsen on product development flow [2], Wheelwright and Clark on team structure [11], Saaty on prioritization [14], House and Price on break-even time at Hewlett-Packard [5], and Ohno on waste elimination [1]. The paper is written for executives who suspect their company is slower than it should be and want a concrete checklist. It is also written for product leaders and program managers who need to make the case to their executives that the environment, not the team, is the constraint. Appendix A presents an anonymized case study drawn from a large storage technology company that applied this assessment methodology to its own host. Figure 1. The 13 host best practices at a glance. Mindset, Environment, and Portfolio form a single interlocking system; weakness in one layer undermines strength in the others. -- 3 of 48 -- › Host best practices › › › © 2026 lateralworks Page 4 Figures List of figures This paper uses figures as first-class explanatory elements rather than decoration. Every figure summarizes or extends a claim made in the surrounding prose and is designed to stand on its own. The list below points to every figure in the paper, in the order it appears. Figure 1 The 13 host best practices at a glance 03 Figure 2 Host behavior — provisioning vs interrupting 06 Figure 3 The three layers of the host 07 Figure 3b The full FTTM framework — host and team 07 Figure 4 Seven forms of provisioning from a best-in-class host 08 Figure 5 Six recurring categories of host interrupt 10 Figure 6 The interrupt and provisioning matrices — weekly ERB view 22 Figure 7 On-time vs late market entry — the cost-of-delay envelope 13 Figure 8 Speed vs control — why too much control slows the work 15 Figure 9 Pull pain forward — normal vs best-in-class pain curves 17 Figure 10 Four team structures (Wheelwright & Clark) 20 Figure 11 Three modes of decision-making 24 Figure 12 Gestation, design, and overrun — three phases 28 Figure 13 Priority scoring and functional capacity 29 Figure 14 Break-even time (BET) — measuring a product end-to-end 32 Figure A1 Maturity of the 13 host practices — team self vs external 40 Figure A2 Concurrent project load per engineer — multiplexing 43 Figure A3 Multiplexing buckets — engineers by concurrent-project count 43 Freedom scale Bill Oncken’s five levels of delegated freedom 23 -- 4 of 48 -- › Host best practices › › › 01 Foundation The host: what it is, why it matters © 2026 lateralworks Page 5 A product development team is never the whole story. It sits inside a larger organization: the functional hierarchy, the executive staff, the business units, and the support groups. That organization is the team’s host. The host decides what resources the team gets, what decisions it is allowed to make, what information reaches it, and what is expected of it. Host behavior either speeds the team up or slows it down; the middle ground is rare. Two kinds of host behavior dominate the relationship between the organization and the team. The host either provisions the team by giving it what it needs to move forward, or it interrupts the team, taking away momentum the team had built. Fast organizations are usually not the ones with the most talented individuals; they are the ones whose hosts reliably provision and rarely interrupt. -- 5 of 48 -- › Host best practices › › › © 2026 lateralworks Page 6 Figure 2. The host is the organization that surrounds the team. Its job is to provision the team — feeding resources, information, and fast decisions into the team’s forward path. When it fails, it interrupts the team — deflecting the path and forcing lost time and rework. Same team, two different hosts, two different outcomes. The idea has a long lineage. Taiichi Ohno built the Toyota Production System around teaching managers to see waste: the time a workpiece spent sitting idle, waiting for something a manager had failed to provide [1]. Donald Reinertsen makes the same point for knowledge work. The cost of delay is nearly always larger than the cost of the resources that would have prevented the delay, and organizations still under-invest in preventing it [2]. Clayton Christensen extended the argument to resource allocation: decisions about who gets what, and when, predict outcomes better than the tactical choices teams make about how to execute [3]. The environment shapes the outcome, and executives design the environment whether they notice they are doing it or not. Three layers of the host The 13 practices organize into three layers. The foundation is the environment: the development framework, the organization structure, and the decision-making system. Above that sits the portfolio: the set of projects the organization has chosen to work on and the discipline that keeps the set prioritized, aligned with real capacity, and pruned when projects stop making sense. At the top sits the mindset: the beliefs executives hold about speed, cost, failure, and what good management looks like. Mindset is the hardest layer to change and the most determinative; environment and portfolio follow from it. -- 6 of 48 -- › Host best practices › › › © 2026 lateralworks Page 7 Figure 3. The three layers of the host. Mindset sits on top because it shapes every decision below it. Environment is at the base because it is where the day-to-day work happens. The FTTM framework: host and team The 13 host practices in this paper are half of the full FTTM system. The other half lives on the team side, documented in the companion lateralworks Team Best Practices paper [34]. Both halves sit under a shared mindset layer. The three-way split is the shape of the full framework. Figure 3b. The full FTTM framework. Mindset is shared between executives and teams and shapes everything below it. Host practices (the focus of this paper) set the ceiling on what a team can achieve. Team practices (the companion paper) describe how the team operates under that ceiling — right product, right team, right time. This paper focuses on the host side — the practices executives and functional leaders control, which set the organizational ceiling on delivery speed. The team side covers the practices the project team itself controls: -- 7 of 48 -- › Host best practices › › › © 2026 lateralworks Page 8 how it co-develops with tier-one customers, how it translates requirements, how it builds and runs its schedule, how it plans aggressively and refreshes continuously. A reader who wants the full FTTM picture should read the two papers together. The split matters. When a delivery problem surfaces, the host typically looks to the team for an explanation, and the team typically looks to the host for a resource or decision. Naming both sides and documenting both sets of practices makes the conversation tractable: each party knows which practices are theirs to improve, and which belong to the other side of the relationship. Host provisioning in depth Provisioning is the active, deliberate work of giving a product development team what it needs to move forward. A host does not just permit a team to do its work; it provisions it, the way a ship is provisioned before a long voyage: a clear inventory of what the team will need, sourced ahead of time, and delivered on the team’s schedule rather than the host’s convenience. In fast organizations, provisioning is not a side activity of the executive staff. It is the executive staff’s primary responsibility to the project teams. Executives who touch a product line know what a day of waiting costs the company in dollars, not as a slogan but as a number they can quote. Figure 4. Seven forms of provisioning that the best hosts deliver to a core team. The team behaves like a funded startup — because the host has set it up that way. Ownership of the product The team owns the product end-to-end, from concept through break-even, rather than owning a piece of it or handing work to another function. The host treats the team the way a venture investor treats a portfolio company: aligned on outcomes, hands-off on execution. Information Market data, competitive intelligence, financial targets, supplier roadmaps, customer commitments, inter-company dependencies: the team receives all of it on time, without having to ask twice. Information -- 8 of 48 -- › Host best practices › › › © 2026 lateralworks Page 9 hoarding by functions is one of the most destructive host behaviors. Budget for the duration The team has a budget it can count on through the end of the project, not a budget renegotiated every quarter. Budget uncertainty forces teams to pad estimates, hoard resources, and avoid the small, well-placed risks that accelerate delivery. The right skills, at the right time The team has the people it needs when it needs them, not three months late or on loan for eight hours a week. Skill provisioning requires the host to forecast and pre-position people, which requires an honest picture of its own capacity. Most slow organizations lack that picture. Tools, test equipment, and facilities Engineering tools, test equipment, lab space, and collaboration facilities are sized to the project and available when the team needs them. In a fast host, nobody is negotiating time on a shared test rig. Delegated authority The team has the authority to decide and act on anything required to stay on or ahead of schedule, within a published envelope of business direction and technology policy. Without it, everything escalates and everything waits. Appendix B gives the full empowerment matrix that fast organizations use to make this envelope explicit. Direct customer and supplier access The team talks to customers and suppliers directly, not through sales managers or procurement intermediaries. Every filtering layer adds days or weeks to the feedback loop and injects its own opinions into what the team hears. The provisioning standard. A provisioned team operates like a funded startup. The host acts like a board of directors plus a shared-services group: committed, informed, helpful, and mostly out of the way. Host interrupting in depth An interrupt is anything the host does, or fails to do, that takes momentum away from the team. Interrupts are rarely dramatic and rarely intentional. They are usually a byproduct of structures built for another purpose (cost control, audit readiness, functional specialization, hierarchical decision-making) that keep running regardless of what they cost a given project. A slow host does not see its own interrupts. It sees missed schedules and attributes them to team execution; it sees over-budget projects and blames estimating; it sees quality problems and points to engineering rigor. What it does not see is the fourteen-signature approval chain, the silently redirected project resources, or the week-long audit. These things are normal to the host, the texture of how the company operates. They are also the reason the project is late. -- 9 of 48 -- › Host best practices › › › © 2026 lateralworks Page 10 Figure 5. Six recurring categories of host interrupt. All of them are fixable. None of them are the team’s fault. Most of them are cheap to eliminate once they are named. Specific examples from lateralworks engagements The examples below come from real lateralworks engagements, anonymized. Each one looks small in isolation. Together, they explain how a technically capable team full of smart, motivated people still ships a year late. Fourteen signatures, four months The host required 14 signatures and roughly 4 months to approve two engineering purchase requisitions on the project’s test plan. The purchases were not controversial, sat inside the approved project budget, and were required by a schedule the executive team had committed to. The signature chain had been designed for audit control; cycle time had never been part of its design. The team lost four months on the critical path, and nobody in the chain considered themselves responsible. Silent resource diversion During a business downturn, functional managers redirected critical project resources away from the team without notifying the program manager. The team kept planning against a resource level that no longer existed. The shortfall surfaced at a schedule review three months later; by then the project was eight weeks behind, and the only recovery path was compression that later proved unsustainable. Audits as denial-of-service Executive confidence in the team was low, so the host commissioned periodic audits and information requests that shut down productive work for days at a time. The audits surfaced nothing new; they reproduced, expensively, what was already in the team’s weekly status reports. The auditing became the reason the next milestone slipped, which justified another audit. Artificial gates as control theater The host imposed phase gates and review meetings as a way to stay involved in daily decision-making. The gates did not gate anything; every project passed every one. They operated as reporting occasions, and each cost the team two weeks of preparation and one of recovery. Removing the non-functional gates recovered about six weeks per year per project with no measurable decline in decision quality. Slow central decisions on fast-moving technical choices -- 10 of 48 -- › Host best practices › › › © 2026 lateralworks Page 11 Teams that had framed the decision cleanly (options plus recommendation) waited three to six weeks for a response. By the time the response arrived, market conditions had shifted and the chosen option was no longer the best, forcing another analysis round and another delay. The team eventually stopped escalating and made decisions quietly; that preserved speed but raised the risk of strategic drift. Whiplash re-prioritization The host changed product strategy and re-prioritized the "key" projects throughout the project, usually in response to the most recent customer complaint or competitor announcement. Each re-prioritization forced the team to rebuild its plan. The net effect was substantial planning overhead, a frustrated team, and a product that ended up close to the original specification rather than to any of the interim revisions. Artificial limits on customer contact Marketing and sales restricted the team’s direct contact with customers. Customer feedback reached the team through sales managers who summarized, filtered, and occasionally fabricated what had been said. The team built features for a fictional customer. At beta, the real customers said something different. Perpetually vague requirements Requirements stayed vague because no one in the host would commit to specifics. "We’ll know it when we see it" became the operating model. The team built prototypes, got feedback that contradicted the prior round, rebuilt, and repeated. Each cycle was productive engineering. Aggregated, it was a schedule doubled by requirements drift that a disciplined front end would have resolved in weeks. Why interrupts persist Interrupts persist because each one serves someone’s purpose, even when no one intended the aggregate result. Every signature in the 14-signature chain exists because some senior manager once wanted visibility. Every phase gate exists because some project failed and a gate looked like a remedy. Every customer-contact restriction exists because an engineer once said something the sales team wished they had not. Removing these structures means admitting they are not working and negotiating with whoever installed them — two awkward conversations, which is why the structures accumulate. The lateralworks approach makes the accumulation visible. Each team logs its top three active interrupts weekly. The executive review board acknowledges each one and commits to resolution within seven days. Items that are not resolved in seven days become explicit improvement projects owned at the executive level. Visibility alone fixes a surprising amount; accountability fixes most of the rest. Warning sign. When executives describe their teams as "never delivering on time" and the teams describe the executives as "the main impediment to speed," the host is interrupting the team. That is not a team problem. It is a host problem, and team-level improvement will not resolve it. -- 11 of 48 -- › Host best practices › › › 02 Mindset How executives think about speed © 2026 lateralworks Page 12 Four practices describe what fast-company executives believe about speed. The beliefs are not motivational. They are economic. They are about how much money is lost when a product is late, about who owns the roadmap, about what kinds of structures actually slow work down, and about when in a project it is best to feel pain. -- 12 of 48 -- › Host best practices › › › © 2026 lateralworks Page 13 1. Grasp the financial impact of being late The executives who run the fastest organizations can describe, in dollars, what a day of schedule slip costs the company. Not in the abstract, not as a percentage. In dollars. They have done the math on the product’s market window, its ramp, its expected margin, and the shape of the demand curve. They know that a product that arrives one quarter late does not earn a quarter less; it often earns half as much or less, because it misses the steep part of the adoption curve and enters a market that is already partly supplied. Reinertsen calls this the "cost of delay" and argues that it should be the single most important number used to make trade-off decisions during development [2]. Figure 7. A product that misses the market window captures a smaller, compressed revenue cycle. The lost revenue and shortened life are not recoverable by cutting development cost later. Normal organization Schedule slips are treated as unfortunate but normal. "We don’t want to ship something that isn’t ready." Cost and quality are always the reasons for the slip, and they are accepted because the alternative (the cost of being late) has never been quantified. When a project slips, the team adds resources late, which raises development cost without recovering the revenue that has already been lost. The business runs on the implicit assumption that slip is free. Best organization The cost of delay is quantified before development starts and reviewed at every major checkpoint. Executives know what a day is worth in dollars. When a trade-off must be made — pay for an extra engineer or slip a week — the math is explicit and the answer is usually "pay." The business operates on the explicit principle that a day saved is worth more than a dollar saved, because the day cannot be bought back. -- 13 of 48 -- › Host best practices › › › © 2026 lateralworks Page 14 Connection to the broader literature. Smith and Reinertsen’s Developing Products in Half the Time [4] showed that for most technology products, a six-month delay to market is more damaging to lifetime profit than a 50 percent development cost overrun. Hewlett-Packard’s internal Break-Even-Time (BET) metric [5] operationalizes this by tracking a product from idea to the point at which cumulative cash flow crosses zero — the executives who ran the best HP divisions in the 1990s managed to BET, not to development cost. 2. Oversee the product roadmap up close Fast companies have one person (an executive, not a committee) who owns the product roadmap. That person can be held accountable for what the company chooses to build. Everyone below them knows who recommends, who must agree, who provides input, who decides, and who is responsible for executing each decision. The roadmap is refreshed on a regular cadence, usually monthly, and the refresh is driven by customer input rather than internal opinion. Slow companies diffuse roadmap ownership across marketing, engineering, and business-unit leadership. The decision-making process is complex enough that only a few people understand it, and when things go wrong no one can be held responsible. This ambiguity is comfortable: it protects careers. It is also expensive, because in the absence of a clear owner, the roadmap defaults to whatever the loudest person in the room asked for last. Normal organization Roadmap responsibility is shared between marketing and engineering and sometimes product management. No single executive can say yes or no on behalf of the company. The planning cycle is annual and produces a thick document that is out of date by the time it is signed. Customer input is filtered through internal experts who "know what customers really need." Decisions default to the CEO as tie-breaker, and the CEO does not have time to understand the details. Best organization One executive owns the roadmap, with clearly defined recommend / agree / input / decide / execute (RAIDE) roles for every step. The roadmap is refreshed monthly, fluid, and tied directly to customer signals and competitive data. Prototypes validate assumptions on paper before they become commitments. A feedback loop from failure analysis feeds back into roadmap revisions. Connection to the broader literature. The RAIDE model of decision rights is a descendant of the RACI framework used in process management [6]. Bain & Company’s research on decision effectiveness [7] showed that companies where decision rights were explicit outperformed their peers by a factor of roughly two on measures of execution speed. The ambiguity that slow companies tolerate is not neutral — it is measurably expensive. 3. Dismantle slow structures -- 14 of 48 -- › Host best practices › › › © 2026 lateralworks Page 15 Most organizations, faced with delivery problems, respond by adding control. More phase gates, more sign-off levels, more reporting templates, more PMO checkpoints. The intuition is that tighter control produces better outcomes. The evidence is the opposite: past a certain point, control slows work down without improving quality, and the cost of the added control dwarfs the cost of the problems it was meant to catch. Figure 8. Speed does not rise monotonically with control. Organizations with too little structure move slowly because nothing is coordinated; organizations with too much structure move slowly because everything requires approval. The fastest organizations sit in the middle — enough process to prevent chaos, not so much that it becomes the work. Fast organizations treat their own management systems as products that need continuous improvement. They inventory the interrupts that teams experience — missing resources, missing decisions, missing information, shifting priorities — and they systematically remove them. They raise approval thresholds so lower-level managers can authorize spending without waiting in a queue. They map their business processes end-to-end and cut the steps that add no value. They report by exception, leaving projects alone when they are within tolerance of their targets. -- 15 of 48 -- › Host best practices › › › © 2026 lateralworks Page 16 Normal organization The dominant behavior is cost control. Development is governed by heavy phase-gate life cycles that were designed to limit spending, not to accelerate delivery. A PMO exists to enforce the gates. Teams spend substantial time feeding information into tracking systems that few people read. When projects run late, more money is thrown at them — by then it is too late to recover, because there was no early warning. Removing the interrupts would eliminate a convenient source of excuses, so no one removes them. Best organization The default is speed, not control. Executives know that the cost of delay far exceeds any savings from tight OPEX governance. Interrupts are inventoried and eliminated. Approval levels are raised. Reporting is by exception. Process improvement is horizontal, mapping the end-to-end flow rather than vertical silos. Control is pushed down to the team, which moves faster and, counter-intuitively, spends less. Connection to the broader literature. Hamel and Zanini’s Humanocracy [17] synthesizes survey data from more than 10,000 managers and estimates that excess bureaucracy costs the US economy approximately $3 trillion per year in lost output — more than the GDP of most G20 economies. Graeber’s The Utopia of Rules [18] documents the same pattern from a different angle, showing that rule-making expands faster than the problems it is meant to solve, because adding a rule is cheap for the executive who proposes it and expensive for every team that must comply with it thereafter. Both lines of research support the same conclusion: control structures accumulate by default, and dismantling them requires deliberate, sustained executive effort. 4. Reward early warning, push pain forward Every development project has a certain amount of pain built into it. Problems that will be discovered, trade-offs that will have to be made, assumptions that will turn out to be wrong. The only question is when that pain will be felt. Normal organizations push it into the future. Problems are minimized, risks are downplayed, aggressive forecasts are rewarded, and the person who raises a concern early is labeled a non-team-player. The pain arrives anyway, usually at the worst possible moment, close to the target ship date, when there is no time left to recover. -- 16 of 48 -- › Host best practices › › › © 2026 lateralworks Page 17 Figure 9. In normal organizations, everything looks great until the crisis hits right before ship. In best-in-class organizations, pain is pulled forward into the project’s early phases, where there is time and money to respond to it. Fast organizations invert this. They build management systems that reward people for identifying problems early. They treat failure as a source of learning rather than blame. The R&D budget includes explicit funding for learning cycles, because the team that has budgeted to fail three times on its way to a working solution will get there faster than a team that is trying to succeed on the first try. Normal organization Pain is pushed later. Pointing out future problems is seen as defeatist. Aggressive forecasts and "can-do" optimism dominate the early phases. When the inevitable problems arrive late in the project, they are attributed to unforeseeable technical difficulty. Learning from failure is discouraged because failure implies blame. Best organization Pain is pulled forward. Management systems reward people for identifying potential problems before they materialize. Learning cycles are budgeted into the schedule. Transparency and honest reporting are encouraged and rewarded. Teams live by the rule "the sooner we find it, the more time we have to fix it." Connection to the broader literature. Eric Ries’s The Lean Startup [8] formalized the idea of learning cycles as a first-class budget item. Edmondson’s research on psychological safety [9] showed that teams which reliably report bad news early outperform teams that protect their leaders from it, sometimes by large margins. The practice of pulling pain forward is a deliberate act of engineering psychological safety into the management system rather than leaving it to individual manager personalities. -- 17 of 48 -- › Host best practices › › › 03 Environment Where teams live © 2026 lateralworks Page 18 The environment is where teams live. It is the development framework they are required to follow, the organizational structure they sit inside, and the decision-making systems they interact with daily. An executive mindset that is fully aligned with speed cannot produce fast outcomes if the environment is built to slow work down. Environment is where mindset becomes material. -- 18 of 48 -- › Host best practices › › › © 2026 lateralworks Page 19 5. Own one simple development framework A product development framework should fit on one page. It should describe the end-to-end flow from idea to end-of-life, as a single integrated system rather than a sequence of organizational hand-offs. And it should be owned by one person — not a committee, not a rotating chair — whose job it is to continuously redesign the framework to make development go faster. Slow organizations accumulate frameworks the way ships accumulate barnacles. Each generation of leadership adds its own phase gates, its own review boards, its own documentation requirements. Nothing is removed, because no one owns the whole thing. The resulting process is complex enough that individual contributors stop trying to understand it and instead try to work around it. Normal organization The development framework is complex, owned by no one, and designed primarily to control spending and concentrate decision-making at the top of the hierarchy. Platforms and reuse are discussed but not implemented, because implementation would require orchestration across silos that does not exist. Life cycles are rarely redesigned; when they are, the work is done by people on the sidelines and is never adopted. Best organization The development life cycle is owned by one person or function, reports to the executive staff, and is continuously redesigned to reduce friction. The framework fits on one page. It is macro and flexible — all projects look the same at the top level, but each team fills in its own detail. Design for reuse, platforms, and fast derivatives are built into the framework itself rather than being retrofitted project by project. Connection to the broader literature. Womack and Jones’s description of value-stream mapping [10] makes the same case from the manufacturing side: a value stream has an owner whose job is to remove waste across functional boundaries, because no individual function is in a position to see the whole flow. The lateralworks insight is that the same logic applies to product development — the framework needs a value-stream owner, not just a PMO. 6. Build heavyweight cross-functional core teams Not every cross-functional team is the same. Wheelwright and Clark identified four different organizing forms for product development teams [11]: functional, lightweight, heavyweight, and autonomous. They are not interchangeable. Each sits at a different point on the curve of speed versus team ownership, and the fastest organizations deliberately choose heavyweight or autonomous structures for their most important projects. -- 19 of 48 -- › Host best practices › › › © 2026 lateralworks Page 20 Figure 10. The four team structures, adapted from Wheelwright and Clark. Functional teams have no lateral flow. Lightweight teams coordinate but do not drive. Heavyweight teams drive the project across functions. Autonomous teams operate as startups inside the company. Best practice is heavyweight or autonomous on the projects that matter most. The word "heavyweight" refers to the authority of the team leader and the dedication of the team members, not to the number of people on the team. A heavyweight team is led by a senior engineer or program manager with enough technical and business experience to make difficult trade-off decisions in real time. The team is dedicated (ideally 100 percent) to a single project, and is colocated, at least at the core. Team members receive the majority of their performance review from the team leader, not from their functional manager. The power structure shifts from the functions to the team. Normal organization Cross-functional teams exist in name only. Members are on eight to fifteen projects simultaneously, take direction from their functional hierarchy, and attend team meetings as a courtesy. The "real work" happens back in the functions. Core teams become bloated with 20+ part-time representatives. Nobody is responsible for the integration of functional deliverables into a product. The team’s role is coordination, not delivery. Best organization Heavyweight teams form early (during feasibility) on the projects that matter. Members are dedicated, colocated, and led by a senior program manager with real authority. A single engineering leader owns technical trade-offs across the system. Performance reviews flow through the team. The team behaves like a startup: it owns the product, it shares in the reward of success, and it is accountable for failure. -- 20 of 48 -- › Host best practices › › › © 2026 lateralworks Page 21 Connection to the broader literature. Wheelwright and Clark’s Revolutionizing Product Development [11] documented a factor-of-three speed difference between lightweight and heavyweight teams across a large sample of Japanese and American auto and electronics manufacturers. Toyota’s chief engineer system, studied by Morgan and Liker [12], is the canonical example of a heavyweight structure: a single engineer owns a vehicle program end-to-end, with authority that cuts across the functional hierarchy. 7. Provision teams; remove interrupts The foundation of this practice is laid out in detail in the two earlier sections on host provisioning and host interrupting. The short version: even the best heavyweight team can be paralyzed by an interrupting host. If decisions take weeks, if resources arrive late, if test equipment is shared with five other teams, if customer access is gated by a sales function that does not trust engineers, then the team’s structural advantage is spent on working around the organization rather than on delivering the product. The host is the ceiling on what any team can achieve. Normal organization The host views the team as a mechanism for hand-offs between functions. It controls the budget, stretches resources too thinly across too many projects, and provides information, decisions, and customer access on its own timeline. Equipment and tools are shared, dated, or unavailable when the team needs them. The relationship is adversarial: the team views the host as the main impediment to speed, and the host views the team as a source of missed commitments. Best organization The host gives the team true ownership of the product, as if it were a funded startup. It provides timely market, financial, supplier, and customer information. The team has enough budget for the duration of the project. The right skills arrive at the right time. Tools, test equipment, and facilities are sized to the need. The team has delegated authority to decide and act on everything required to stay ahead of schedule. The interrupt and provisioning matrix lateralworks teams use a pair of simple matrices to make the provisioning and interrupting dynamic explicit. Each week during the core team refresh-planning meeting, the team logs its top three active interrupts — the specific things slowing it down right now — and its top three provisioning needs — the specific things it needs from the host in the coming week. Every line item has a seven-day life. If an interrupt or provisioning need is still open after a week, it becomes a managed improvement project outside the refresh cadence. The matrix is reviewed weekly by the executive review board (ERB). Each team gets ten minutes to walk the board through its matrix, make its case, and leave with either a resolution or a commitment to one within seven days. The ERB is a communication forum, not a problem-solving forum; teams are coached to resolve team-level interrupts inside the team and bring to the ERB only the items that require host action. The matrix makes the abstract idea of provisioning concrete, auditable, and time-boxed. Interrupt matrix -- 21 of 48 -- › Host best practices › › › © 2026 lateralworks Page 22 Top active interrupts Source Team / host Syst. / sit. Negative impact Preventive action Respons ible Target PR for test equipment in approval queue 6 weeks Finance / p rocuremen t Host Syste mic 3-wk critical-path slip on qualification test Raise sub-$25K signature authority to PM CFO + PM Within 7 days Two HW engineers pulled to sustaining work without notice HW functional mgr Host Situati onal Board bring-up delayed; schedule slipping 1 day/day Return engineers or formally cancel competing project VP engin eering Within 3 days Customer feedback filtered through sales; beta contradicts specs Sales org Host Syste mic Requirements churn; rebuild of two subsystems likely Establish direct engineer-to-cust omer channel VP mktg + PM Within 7 days Shared signal-integrity bench booked; no slots for 3 weeks Lab scheduling Host Situati onal 2-week slip on eye-diagram characterization Reprioritize bench; add overnight shift or 2nd bench Lab manager Within 5 days Product spec open on interface choice; engineering waiting Product mgmt Host Syste mic Design work stalled; growing rework exposure Force decision at next ERB; document default Product GM At next ERB Provisioning matrix Top provisioning needs Schedule impact Responsible provisioner Provisioning actions Target Dedicated ASIC verification engineer for 12-week tapeout sprint High — on critical path VP engineering Pull engineer from lower-priority program; backfill sustaining Within 10 days Direct lead-customer access for feature-prioritization workshop High — drives scope VP marketing Introduce PM and lead engineer to customer CTO; bypass account team Within 7 days Second signal-integrity bench for parallel characterization High — 2-wk slip avoided Lab mgr + CFO Approve capital purchase; stand up bench in existing lab Within 3 weeks Supplier roadmap and committed delivery for critical component Medium — affects build plan VP operations Executive-to-executive call with supplier; secure allocation Within 7 days Delegated spending authority raised to $25K for core team Medium — removes friction CFO Update spending policy; publish empowerment matrix change Within 14 days Figure 6. The interrupt and provisioning matrices with representative entries. Teams fill in the top three active items each week and commit to a seven-day resolution cycle. The rows shown here are anonymized examples from recent lateralworks engagements; each team populates its own matrix with its own current interrupts and provisioning needs. Empowerment and the freedom scale -- 22 of 48 -- › Host best practices › › › © 2026 lateralworks Page 23 Provisioning is only half the story. The team also needs a clear, explicit envelope of authority — what it can decide and act on without asking permission, and where it must still recommend or wait. lateralworks uses Bill Oncken’s freedom scale to make this envelope concrete. The scale has five levels that describe the delegation relationship between a team and its host. The Oncken freedom scale. Levels 1–3 are the range in which experienced professionals can add durable value. Levels 4–5 are appropriate only for trainees. Levels 1–3 provide leverage and growth. Experienced professionals cannot work below these levels of freedom — if they are forced to, they stop adding value, and the organization pays the senior-level salary for junior-level output. Levels 4 and 5 are appropriate only for trainees. When a fast-moving heavyweight team is stuck at level 4 or 5 on any of its important decisions, that team is, by definition, not heavyweight. The freedom scale is not applied as a blanket label. It is applied decision category by decision category, in an empowerment matrix that the host and the team negotiate and publish together. A heavyweight team might sit at level 1 for day-to-day design decisions, level 2 for minor architectural changes, and level 3 for product-spec changes after the initial specification has been frozen. The matrix makes this envelope visible to everyone. How to deploy the empowerment matrix. (1) Assign one ERB member to own the matrix for each heavyweight team. (2) Tailor the decision categories to the team’s context — add or change categories as needed. (3) Where a single "X" in a cell is ambiguous, add a concrete example of a decision that falls into that category at that level of freedom. (4) Ask the team to self-assess its current level of freedom, per category. (5) Meet with the team to reconcile host expectations against the team’s understanding, and publish the reconciled matrix. (6) Use the matrix situationally, as a coaching tool, to train the behavior the host wants to see. The full empowerment matrix that lateralworks uses on new engagements is reproduced in Appendix B. It covers seven decision categories — staffing, resource allocation, performance appraisal, product definition, customer requirements, capital and expense spending, and design / technology — and specifies a default -- 23 of 48 -- › Host best practices › › › © 2026 lateralworks Page 24 freedom level for each. Teams and their hosts adapt the defaults to their specific context during the deployment conversation. Connection to the broader literature. The interrupt matrix has a direct analog in the andon cord of the Toyota Production System [1]: a standing mechanism for individual contributors to surface problems immediately, with a standing commitment from management to respond. Spear and Bowen’s description of Toyota’s "DNA" [13] emphasizes that the andon cord is not primarily about stopping the line — it is about forcing management to reveal problems it would otherwise prefer not to see. The empowerment matrix plays a similar role for decision rights: it forces an implicit, often unhealthy, delegation relationship to become an explicit, negotiable one. 8. Make decisions fast, default to action Speed of decision-making is not the same as quality of decision-making. A fast decision made with 80 percent of the information is almost always worth more than a slow decision made with 95 percent, because the 20 percent gap closes quickly once the team starts executing and the extra weeks spent gathering information are never recoverable. Fast organizations know this in their bones. They default to action. Figure 11. Three modes of decision-making, from slowest to fastest. Binary yes/no decisions are slow because they pretend each option exists in isolation. "Choose among alternatives" is faster. Full prioritization — ranking every option against weighted business objectives — is the fastest because it forces the trade-offs to be explicit and resolved at once, rather than being re-litigated on every decision. Fast organizations run a fast-decision forum with a standing commitment to respond to team escalations within 24 hours. They publish the company’s business direction and technology policy in a short, clear document that teams can consult to make their own tactical decisions without escalating. They use "strategic bypasses" — where a team needs guidance and the normal forum is not available, the product champion defaults to action after consulting the key decision-makers informally. The rule is: if you’re waiting more than a day for a decision, either the decision doesn’t really need to be made or the organization is broken. -- 24 of 48 -- › Host best practices › › › © 2026 lateralworks Page 25 Normal organization Critical decisions require approval from upper management and sit in queues for weeks. Teams lack an overall understanding of business direction and technology policy, so they cannot make defensible tactical decisions on their own. They default to either waiting or generating more data. "Default to delay" is the organizational norm. Best organization Decision-making is fast because business direction and technology policy are clear, documented, and widely understood. Teams can act inside that envelope without escalation. When escalation is needed, a fast-decision forum responds within 24 hours. The default is action; the exception is waiting, not the rule. Connection to the broader literature. A 2019 McKinsey survey of more than 1,200 managers and executives [19] found that only about 20 percent rated their organizations as good at decision-making — and the lost productivity from poor decision processes was estimated at more than 500,000 days of managers’ time per year in a typical Fortune 500 company. The framework that best distinguishes fast from slow organizations is Bezos’s Type 1 vs Type 2 decision taxonomy [20]: Type 1 decisions are irreversible and deserve deliberation; Type 2 decisions are reversible and should be made quickly, because the cost of a wrong Type 2 decision is low and the cost of waiting is high. Fast organizations recognize that most development decisions are Type 2 and treat them accordingly. Slow organizations treat every decision as Type 1. -- 25 of 48 -- Why hosts matter The ceiling The host is the ceiling on what any team can achieve. lateralworks FTTM methodology Practice 7 — Provision teams; remove interrupts © 2026 lateralworks Page 26 -- 26 of 48 -- › Host best practices › › › 04 Portfolio Pointing resources at the right work © 2026 lateralworks Page 27 A company with the right mindset and the right environment can still fail at speed if its portfolio is broken. Too many active projects for the available capacity; too few being killed when they stop making sense; starts that drift because no one owns the front end; teams tracked only to the handoff rather than all the way to the money. The portfolio practices close the loop: they make sure the resources that the environment frees up are pointed at the projects that matter most. -- 27 of 48 -- › Host best practices › › › © 2026 lateralworks Page 28 9. Manage the fuzzy front end The period between when a product idea is first discussed and when a full team is actually staffed is called the fuzzy front end. In normal organizations it is invisible and unmanaged. Ideas drift for months or years. Marketing champions some; engineering quietly prototypes others. Neither group has the resources to do serious feasibility work, so the real technical investigation is deferred to the eventual development team, which inherits product goals that were set without enough information and are treated as unchangeable. Figure 12. A typical product cycle has three phases. Gestation (idea to full team) and Overrun (target date to break-even) together often consume as much or more calendar time as the tracked design-develop-make phase. In most organizations, only the middle is measured. Fast organizations treat the fuzzy front end as a real phase, not a prelude. A small multidisciplinary team — typically two to four people from engineering and marketing — is assigned to study feasibility within a fixed time budget, often under two months. The output is a go/no-go decision with clear economics: the business case, customer requirements, market positioning, and macro schedule. Because the time budget is tight, the work is focused. Because it is real, the goals it produces are grounded in actual investigation rather than wishful thinking. Normal organization The front end is unowned and under-staffed. Ideas meander for long periods. Marketing and engineering rarely work on feasibility together. The real discovery happens later, on the development team, which was formed late and is under-resourced. Goals set in the front end are inherited by the development team and never revisited, including unrealistic expectations for performance and schedule. Best organization The front end is a formal phase with a time budget, a small dedicated feasibility team, and a clear go/no-go gate. It is managed with the same discipline as the rest of the development process. Because it is fast and focused, it shrinks total time-to-market substantially — gestation is often the largest single opportunity for cycle-time reduction. -- 28 of 48 -- › Host best practices › › › © 2026 lateralworks Page 29 Connection to the broader literature. Khurana and Rosenthal’s MIT Sloan research [21] studied the front end in 12 companies and found that successful front-end processes had three common features: an explicit product concept document, an identified product champion with executive sponsorship, and a formal go/no-go review before full development commitment. Companies that treated the front end as informal or implicit saw roughly twice the rate of late-stage requirements change. Koen and the PDMA’s follow-on New Concept Development Model [22] documented the same pattern across 23 companies. Both bodies of work support the lateralworks finding that the front end is usually the single largest cycle-time opportunity in the development pipeline. 10. Prioritize projects against business objectives Without an explicit prioritization system, project selection defaults to whoever has the most political influence. With an explicit system, project selection becomes a data-driven consensus. Fast organizations use formal methods — most commonly an Analytic Hierarchy Process (AHP) model — to score every candidate project against a set of weighted business objectives. The result is a ranked list, not a yes/no verdict. When something new enters the list, something else has to move down. Zero-sum ranking is the whole point. Figure 13. The two halves of portfolio discipline. On the left, every project is ranked against weighted business objectives to produce a prioritized list. On the right, the list is then checked against real functional capacity — the project that is second on the priority list may have to wait if the engineering group is already at 165 percent capacity on the first one. -- 29 of 48 -- › Host best practices › › › © 2026 lateralworks Page 30 Normal organization There is no formal prioritization system. Marketing drives project selection from revenue plans; engineering filters based on available capacity. The two planning systems never reconcile. The business unit with the most political influence wins the most projects. The pipeline expands without regard for capacity. Projects rarely get killed, even when they should. Best organization A formal AHP or equivalent model scores every project against weighted business objectives. Marketing and engineering are forced to reconcile what is wanted with what can be delivered. The portfolio is refreshed monthly or quarterly. New ideas are ranked against the current portfolio; a new start must displace an existing project of lower priority. Connection to the broader literature. The Analytic Hierarchy Process was developed by Thomas Saaty in the 1970s [14] and is now a standard technique in decision science. The Project Management Institute has published detailed guidance on using AHP for portfolio prioritization [15]. The method is widely used in defense procurement, infrastructure investment, and technology development precisely because it forces explicit trade-offs where political negotiation would otherwise dominate. 11. Align projects continuously with real capacity Priority is half of the portfolio discipline. The other half is capacity. A prioritized list of projects that collectively require 150 percent of the available engineering hours is not a portfolio — it is a queue of future disappointments. Fast organizations model the resource constraint explicitly, and they refresh the model regularly. When a new project is proposed, the model shows which existing projects would slow down if the new one were added. The conversation about whether to start the new project becomes a conversation about whether it is worth the slowdown on the existing ones. Slow organizations have no such model. When people point out that the pipeline exceeds capacity, they are told to be more productive. When projects slip, the explanation is always team execution, never resource overcommit. Executives who try to surface the capacity problem are career-limited; the safer path is to nod along with the "can-do" narrative until one is promoted out of the role. Normal organization No organized system for balancing resources. The tools that exist are ad hoc, consider only one functional view, and are updated infrequently. The pipeline expands because there is no shared picture of what the expansion costs. Executives who raise the issue are penalized. The "can-do" culture suppresses honest signals about capacity. Best organization A shared model tracks functional capacity against the active portfolio. New projects cannot be added without showing the impact on existing ones. The model is refreshed monthly; all stakeholders participate. When reality forces trade-offs, they are made explicitly, with data, rather than implicitly, by letting projects slip. -- 30 of 48 -- › Host best practices › › › © 2026 lateralworks Page 31 Connection to the broader literature. The cognitive research on task-switching — most notably Rubinstein, Meyer, and Evans [23] — consistently shows that shifting between tasks carries a 20–40 percent efficiency penalty per switch, and the penalty compounds with complexity. An engineer on eight concurrent projects is losing several hours per day to context switching alone, independent of any other inefficiency. DeMarco’s Slack [24] makes the organizational case: a system running at 100 percent utilization has zero capacity to respond to anything unexpected. Little’s Law from queuing theory [25] predicts mathematically that increasing the number of concurrent items in a fixed-throughput system proportionally increases cycle time. The multiplexing data in the case-study appendix is a field confirmation of this prediction. 12. Kill projects that miss objectives Projects started with good intentions do not always remain good projects. Markets shift, competitors move, technical feasibility changes, business objectives evolve. A project that was in the top quartile of the portfolio last quarter may be in the bottom quartile this quarter. In normal organizations, this rarely matters; projects, once started, tend to keep running. In the fastest organizations, the prioritization model is re-run every quarter, and projects that have dropped below a threshold are challenged. Some are rescoped. Some are deferred. Some are killed outright. The resources they release are redirected to higher-priority work. Normal organization Projects rarely get killed. When they are stopped, they often reappear under a new name. Business objectives are vague enough that no project can clearly fail against them. Projects pushed by senior management or politically powerful sponsors are especially hard to stop, even after they have missed their economic window. Best organization Projects are assessed at least quarterly against current business objectives. Projects that fall below a threshold or have missed their economic window are challenged. The decision-making process is data-based and agnostic to the sponsor’s position in the hierarchy. Killing a project is treated as good portfolio hygiene, not as failure. Connection to the broader literature. Cooper’s research on stage-gate product development [16] found that the single most predictive behavior of high-performing product organizations was willingness to kill projects at early gates. Low-performing organizations tended to pass projects through gates on faith, then discover late in development that the projects should have been killed at gate one. The correlation between kill rate and portfolio productivity held across industries. 13. Track new products all the way to break-even What an organization measures is what the organization optimizes. Most companies measure development projects by development cost and by time-to-first-shipment. Both metrics end at the engineering handoff to operations. The people who designed the product never see whether it made money, -- 31 of 48 -- › Host best practices › › › © 2026 lateralworks Page 32 yielded well, satisfied customers, or captured market share. They optimize for the metric they can see — the handoff — and make decisions accordingly. Figure 14. Break-even time (BET) tracks a product from the moment the opportunity is first perceived through to the moment cumulative cash flow crosses zero. Time-to-market is a subset of BET; it starts when the full team forms and ends at release. Teams that optimize for BET make different design choices from teams that optimize for time-to-market. Fast organizations measure new products by break-even time — a discipline pioneered at Hewlett-Packard in the 1980s [5]. BET starts when the opportunity is first perceived and ends when cumulative cash flow crosses zero. It includes the gestation phase, the design phase, the ramp phase, and the early market phase. Teams that know they will be held accountable to BET make different design choices from teams that are held accountable to time-to-market. They think harder about manufacturability, about yield, about cost at volume, about serviceability — because all of these show up in cash flow after launch. Normal organization Projects are tracked by function. Marketing tracks what it starts. Engineering tracks design-to-release. Operations tracks the ramp. Somebody in finance eventually notices whether the product made money. The engineers who designed it never see the economic consequence of their design choices. Best organization Products are tracked end-to-end by the core team from idea through to break-even. The team sees the economic consequence of its own decisions. This visibility changes design choices upstream: yield, manufacturability, and service cost are considered early, when they are cheap to influence, rather than late, when they are expensive. -- 32 of 48 -- › Host best practices › › › © 2026 lateralworks Page 33 Connection to the broader literature. Kaplan and Norton’s Balanced Scorecard [26] framed the general principle: what an organization measures drives what it optimizes. Goldratt’s theory of constraints [27] makes the stronger case for throughput accounting — measuring the rate at which the system makes money rather than the cost at which each function operates. BET is a throughput-accounting metric applied to product development: it measures when the investment turns positive, not how much was spent getting there. The HP executives who pioneered BET [5] understood that a development team held accountable to BET would make different design choices than a team held accountable to development cost, and their division-level results in the 1990s validated the prediction. -- 33 of 48 -- › Host best practices › › › 05 Implementation Putting it to work © 2026 lateralworks Page 34 The 13 practices are not a menu. They are a system. Attempting one of them in isolation — a new decision forum while the portfolio is still overcommitted, or a heavyweight team in an interrupting host — rarely produces more than a temporary improvement. The host behaviors that slowed the old system down will pull the new practice back into the old shape within a quarter or two. Real change requires moving on several fronts at once, in a deliberate sequence, with visible executive sponsorship throughout. -- 34 of 48 -- › Host best practices › › › © 2026 lateralworks Page 35 What follows is the six-step sequence that lateralworks uses on host transformation engagements. The sequencing is not rigid — companies with strong portfolio discipline but weak team structure would reorder the middle steps — but the sequence as written works for the majority of companies that come to lateralworks with a "we’re too slow" diagnosis. 1. Start with mindset Quantify the cost of delay on the top three current projects. Put the number in dollars per day in front of the executive staff. Make sure everyone understands, at a gut level, what a week of slip costs the company. Without this anchor, every other change is negotiable; with it, speed becomes the obvious default. 2. Install the interrupt and provisioning matrix Start with one heavyweight team. Have the team log its top three interrupts and top three provisioning needs, weekly. Have the executive review board commit to a seven-day resolution cycle. Protect the mechanism from being diluted. Within 30 days the pattern of interrupts will be clear enough that systemic fixes become obvious; within 90 days the team’s velocity will have measurably increased; within 180 days, other teams will be asking to be included. 3. Convert the most important teams to heavyweight Pick the top two or three projects on the current prioritized list. Staff them as heavyweight teams — dedicated, colocated, with a senior program manager who has real authority. Protect these teams from the old functional pull. This will be unpopular in the functions; do it anyway. 4. Redesign the development framework Assign one executive to own the end-to-end flow. Their job is to produce, within 60 days, a one-page framework that every project can use, and to begin retiring the accumulated review structures, phase gates, and sign-off chains that the framework is replacing. Expect resistance from whoever built the retired structures. 5. Install portfolio prioritization and capacity alignment Stand up an AHP-based prioritization model. Run it against the full project portfolio. Match the ranked list against real functional capacity. Kill or defer whatever is below the capacity line. This step tends to surface resistance from whoever championed the projects that end up below the line; hold the line anyway. The discipline is meaningless if exceptions are granted based on executive volume. 6. Switch the scorecard to BET Move the executive scorecard off development cost and time-to-market and onto break-even time. This is the longest-lead change because it requires agreement from finance, changes to performance management, and a culture shift away from functional measurement. It is also the change that most reliably sustains the other five: a scorecard built around BET rewards the right behaviors everywhere else in the system. Expect resistance. Every organization that has grown up with slow habits has built a set of internal structures that benefit from those habits — risk-averse mid-level managers whose role exists to gatekeep, finance functions whose control mechanisms depend on slow decision chains, functional leaders whose power derives from owning resources that heavyweight teams need. These people are not malicious. They are doing the job the organization asked them to do. Changing the job requires negotiating with them, not -- 35 of 48 -- › Host best practices › › › © 2026 lateralworks Page 36 overruling them. The engagements that work are the ones where the CEO or general manager makes the change a personal priority and stays with it for 12 to 18 months — long enough for the new structures to outlast the political half-life of the old ones. Key finding. Across lateralworks engagements, companies that complete all six steps of this sequence have consistently achieved 30–50 percent reductions in time-to-market on the projects run under the new system, within 12–18 months of the start of the engagement. Companies that attempt only one or two steps typically see a short-term improvement that fades within a year as the old structures reassert themselves. The system effect is real, and it is the system, not any individual practice, that produces the durable result. -- 36 of 48 -- › Host best practices › › › © 2026 lateralworks Page 37 Sources References [1] Ohno, T. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. [2] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [3] Christensen, C. M. The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business Review Press, 1997. [4] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd ed. Wiley, 1998. [5] House, C. H., and Price, R. L. "The Return Map: Tracking Product Teams." Harvard Business Review, January–February 1991. [6] Jacka, J. M., and Keller, P. J. Business Process Mapping: Improving Customer Satisfaction. Wiley, 2009. [7] Rogers, P., and Blenko, M. "Who Has the D? How Clear Decision Roles Enhance Organizational Performance." Harvard Business Review, January 2006. [8] Ries, E. The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011. [9] Edmondson, A. C. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley, 2018. [10] Womack, J. P., and Jones, D. T. Lean Thinking: Banish Waste and Create Wealth in Your Corporation. 2nd ed. Free Press, 2003. [11] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. Free Press, 1992. [12] Morgan, J. M., and Liker, J. K. The Toyota Product Development System: Integrating People, Process, and Technology. Productivity Press, 2006. [13] Spear, S., and Bowen, H. K. "Decoding the DNA of the Toyota Production System." Harvard Business Review, September–October 1999. [14] Saaty, T. L. The Analytic Hierarchy Process: Planning, Priority Setting, Resource Allocation. McGraw-Hill, 1980. [15] Vargas, R. V. "Using the Analytic Hierarchy Process (AHP) to Select and Prioritize Projects in a Portfolio." PMI Global Congress Proceedings, 2010. [16] Cooper, R. G. Winning at New Products: Creating Value Through Innovation. 5th ed. Basic Books, 2017. [17] Hamel, G., and Zanini, M. Humanocracy: Creating Organizations as Amazing as the People Inside Them. Harvard Business Review Press, 2020. [18] Graeber, D. The Utopia of Rules: On Technology, Stupidity, and the Secret Joys of Bureaucracy. Melville House, 2015. [19] De Smet, A., Jost, G., and Weiss, L. "Three Keys to Faster, Better Decisions." McKinsey Quarterly, May 2019. [20] Bezos, J. "1997 Letter to Shareholders" and subsequent annual letters. Amazon Investor Relations. [21] Khurana, A., and Rosenthal, S. R. "Integrating the Fuzzy Front End of New Product Development." MIT Sloan Management Review, Winter 1997. [22] Koen, P. et al. "Providing Clarity and a Common Language to the Fuzzy Front End." Research-Technology Management, March–April 2001. [23] Rubinstein, J. S., Meyer, D. E., and Evans, J. E. "Executive Control of Cognitive Processes in Task Switching." Journal of Experimental Psychology: Human Perception and Performance, Vol. 27, No. 4, 2001, pp. 763–797. [24] DeMarco, T. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Broadway Books, 2002. [25] Little, J. D. C. "A Proof for the Queuing Formula: L = λW." Operations Research, Vol. 9, No. 3, 1961. -- 37 of 48 -- › Host best practices › › › © 2026 lateralworks Page 38 [26] Kaplan, R. S., and Norton, D. P. The Balanced Scorecard: Translating Strategy into Action. Harvard Business School Press, 1996. [27] Goldratt, E. M. The Goal: A Process of Ongoing Improvement. North River Press, 1984. [28] Argyris, C. "Teaching Smart People How to Learn." Harvard Business Review, May–June 1991. [29] Detert, J. R., and Edmondson, A. C. "Implicit Voice Theories: Taken-for-Granted Rules of Self-Censorship at Work." Academy of Management Journal, Vol. 54, No. 3, 2011. [30] Oncken, W., Jr., and Wass, D. L. "Management Time: Who Has the Monkey?" Harvard Business Review, November–December 1974 (reprinted 1999). [31] Parker, G. M. Cross-Functional Teams: Working with Allies, Enemies, and Other Strangers. 2nd ed. Jossey-Bass, 2002. [32] lateralworks internal methodology documentation. "The FTTM Methodology." 2024–2026. [33] lateralworks internal assessment database. Host best practice maturity assessments across semiconductor, storage, networking, and industrial automation engagements, 1992–2025. [34] lateralworks. Team Best Practices: Right-Product, Right-Team, Right-Time — the team side of the FTTM framework. Companion paper to this document, covering co-development with tier-one customers, requirements translation, cross-functional core team roles, macro-micro scheduling, and continuous schedule pull-in. lateralworks methodology series, 2026. -- 38 of 48 -- › Host best practices › › › A Appendix A Case study: a large storage technology company © 2026 lateralworks Page 39 Context. This appendix reports anonymized results from a lateralworks engagement with a multi-billion-dollar storage technology company. The company had missed several major product launches, was losing share to a faster competitor, and asked lateralworks to assess why. The assessment covered the 13 host practices, used both structured interviews (50+ practitioners across engineering, marketing, and operations) and quantitative analysis of project-staffing data (65 engineers across 11 active projects). What follows is what the assessment found and what the company did about it. -- 39 of 48 -- › Host best practices › › › © 2026 lateralworks Page 40 A.1 Methodology — the 5-level maturity scale Each of the 13 practices is scored on a 5-level maturity scale standard in lateralworks host assessments. The scale is designed to force honest conversation: level 1 is explicit absence, and level 5 requires evidence of continuous improvement, not just presence of the practice. Level Label Meaning 1 Does not occur The practice is absent. Behavior actively contradicts it. 2 Occurs at random The practice appears occasionally, driven by individual initiative, not institutional design. 3 Occurs consistently The practice is in place and reasonably reliable, but not systematically managed. 4 Defined and managed The practice is documented, measured, and owned by someone accountable. 5 Continually improved The practice is periodically reviewed, tuned, and strengthened as the organization learns. A.2 Assessment results — perception vs reality Two parallel assessments were run. The project teams scored themselves on each of the 13 practices, using the same 5-level scale. In parallel, the lateralworks consultants scored the organization based on structured interviews with more than 50 practitioners. The results are shown below. The most instructive finding is not any individual score — it is the systematic gap between the two assessments. Figure A1. Maturity of the 13 host practices — team self-assessment (green) vs external lateralworks assessment (blue). The green line describes how the teams believed the company was operating; the blue line describes what the lateralworks interviews actually found. Red arrows mark the two largest perception gaps. What the chart tells us Four observations matter more than the individual scores. First, the gap itself is the finding. -- 40 of 48 -- › Host best practices › › › © 2026 lateralworks Page 41 In a healthy organization, the external and internal assessments converge within a level. When the external assessment is systematically lower than the internal one, the organization has lost contact with what it is actually doing. That is a leading indicator of trouble — the kind of disconnect that shows up later as missed launches and lost market share. The remedy is not to argue about the scores; the remedy is to close the perception gap so that executives and teams are seeing the same system. Second, the gap is selective. Teams and lateralworks agreed, roughly, on financial-impact awareness, roadmap ownership, early-warning behavior, and the fast development framework. Where they disagreed was on the practices most directly tied to how projects are staffed and run — cross-functional core teams, capacity alignment, killing projects, and tracking to break-even. This is telling. Teams overestimated the maturity of the operational practices because those practices touch their daily work, and no one likes to describe their own environment as broken. Third, the cluster of weaknesses is diagnostic. The practices that scored lowest — provisioning teams, making decisions fast, managing the fuzzy front end, prioritizing projects, aligning to capacity, tracking to break-even — are exactly the practices that define a fast host. They are not random. Together they describe an organization whose mindset is oriented toward speed in the abstract but whose operational structures are oriented toward functional control, overcommitment, and lagging measurement. Fourth, the near-zero scores are not effort problems. Several practices score at or below "occurs at random" on the external assessment. These are not problems that can be fixed by working harder. No amount of team-level effort will make the fuzzy front end well-managed if the host has not staffed it. No amount of team discipline will align projects to capacity if the portfolio itself is overcommitted. These are structural problems that require executive-level structural intervention. What the chart rules out. The chart rules out "the team is the problem" as an explanation for the missed launches. On every practice where the team has primary agency (mindset, early warning, development framework) the scores are reasonable. On every practice where the host has primary agency (provisioning, portfolio, BET tracking) the scores are low. A team problem produces the opposite pattern. Connection to the broader literature. The systematic gap between self-assessment and external assessment is a well-documented phenomenon. Argyris [28] called it "Model I behavior" — the organizational tendency to protect self-image at the cost of accurate self-understanding. Detert and Edmondson [29] documented the specific mechanism: mid-level managers learn early in their careers that delivering bad news to executives is career-limiting, so the news that reaches the top is systematically better than the news at the bottom. In this company, the pattern was not pathological — it was ordinary and predictable. The value of an external assessment is that it bypasses the filter. -- 41 of 48 -- › Host best practices › › › © 2026 lateralworks Page 42 A.3 Themes from the interviews The following themes emerged consistently across the more than 50 structured interviews with practitioners. Comments are anonymized and, where reproduced, paraphrased to remove identifying detail. Each theme maps to one or more of the 13 practices. On roadmap churn (practice 2) "The roadmap changes every time the VP of product attends a customer dinner." This was said by several engineers, independently, in different divisions. The pattern the interviews described was whiplash re-prioritization driven by the most recent customer complaint, without a structural process for deciding which complaints actually justified a roadmap change. On slow structures (practice 3) "I spend more time preparing review materials than doing the work that will be reviewed." The approval and review structures had accumulated over a decade without anyone being responsible for pruning them. Engineers estimated that 20–30 percent of their time went to reporting rather than producing. The reporting did not catch problems earlier; it merely made problems visible later. On cross-functional teams (practice 6) "I’m on eight projects. I have no idea which one is my priority." Several engineers reported being formally assigned to eight or more concurrent projects, with no single team leader empowered to set their priority. The functional manager nominally set priority but in practice deferred to whichever project had the most recent executive attention. On provisioning (practice 7) "The characterization bench is the critical path for my project and it’s booked by three other teams." Shared test equipment, shared software-development tools, and shared customer-access channels were all being rationed across too many concurrent projects. The cost of an additional bench or license was a small fraction of the cost of the slips caused by sharing. On capacity alignment (practice 11) "Every quarter we start two more projects than we finish. It’s been this way for five years." Capacity was never explicitly modeled. The pipeline expanded continuously because there was no mechanism to force the trade-off between a new start and the existing work. The multiplexing data in the next section quantifies what that expansion had produced. On killing projects (practice 12) "Projects here don’t die. They get renamed." Several interviewees described projects that had been stopped and then restarted under a new code name, with the same sponsor and the same team. The renaming preserved political face at the cost of portfolio discipline. On tracking to break-even (practice 13) "I designed three products in a row. I have no idea whether any of them made money." The measurement system ended at the handoff from engineering to operations. Engineers who wanted to know whether their products had been commercially successful had to ask a friend in finance as a personal favor; the data was not routinely shared. A.4 Quantitative finding: multiplexing In parallel with the interviews, lateralworks collected the project-staffing data for 65 engineers across the 11 active projects in the division. Each engineer’s count of concurrent active projects was calculated from the -- 42 of 48 -- › Host best practices › › › © 2026 lateralworks Page 43 formal staffing records. The distribution is shown below. Figure A2. Concurrent project load per engineer (n = 65, anonymized and ranked by load). Green dashed line: best-practice ideal of 1 project per engineer. Amber dashed line: best-practice maximum of 2.5 projects per engineer. Most of the population is above the maximum; a significant tail is well above it. Figure A3. The same data as a bucketed distribution. Only 19 of 65 engineers (29 percent) are working on a single project. 32 percent are at or above five concurrent projects — a load at which task-switching alone accounts for 30–50 percent efficiency loss before any other factor is considered. Multiplexing at this level has three compounding effects. First, direct task-switching cost: each time an engineer shifts projects, roughly 20–40 percent of the next productive hour is spent getting re-oriented to the problem. An engineer on eight projects may spend 2–3 hours per day context-switching, independent of any other inefficiency. Second, decision latency: when an engineer is needed for a decision on project A, they are often mid-task on project B, and the decision waits for the context-switch. Cumulative decision latency on a heavily multiplexed team can add 30–40 percent to schedule. Third, commitment softening: engineers on many projects cannot make reliable commitments on any one of them, because they cannot predict which project will demand attention next. Commitments drift, plans become fiction, and the team loses the ability to forecast its own work. -- 43 of 48 -- › Host best practices › › › © 2026 lateralworks Page 44 A.5 Analysis — what the data added up to Three findings emerged from reconciling the qualitative interview themes with the quantitative multiplexing data and the assessment chart. Finding 1: The host is the ceiling — and the host cannot see itself The perception gap between the team self-assessment and the external assessment (Figure A1) is not a scoring disagreement. It is evidence that the organization has lost accurate sight of how it operates. The executive staff believed the company was running a heavyweight-team model, prioritizing against business objectives, and killing underperforming projects. The data said otherwise. Until the executive picture aligned with the operational reality, no amount of team-level improvement would produce a sustained change in outcomes. Finding 2: Provisioning is a capacity problem first The interview themes and the multiplexing data point to the same root cause: the company had chronically overcommitted itself across too many projects for too long. The pipeline expansion reported by engineers ("two more starts than finishes every quarter, for five years") is exactly what produces the Figure A2 distribution. Every provisioning problem the teams identified — shared test equipment, shared engineers, filtered customer access — is downstream of the capacity overcommitment. Fixing any one of them without fixing the portfolio would produce a temporary improvement that reversed when the pipeline re-expanded. Finding 3: The core teams are heavyweight in name only Formally, the company had "core teams." The staff structure listed team leaders, team members, and charters. Operationally, the core teams had no authority the functions did not concur with; team members reported to functional managers, had their performance reviewed by functional managers, and took direction from functional managers whenever there was a conflict with team priorities. In every case where the interviews described a core team breaking down, the breakdown came from a functional pull that the team leader had no authority to resist. The structure was lightweight dressed as heavyweight. A.6 The improvement plan The company and lateralworks jointly proposed a seven-point improvement plan. The plan was phased over 12 months and sequenced deliberately: mindset-level changes first, then structural changes, then measurement changes. (1) Install the interrupt and provisioning matrix on the top three projects. Commit to a 7-day resolution cycle, owned by the executive review board. Publish weekly. (2) Rebuild the top three core teams as true cross-functional heavyweight teams. Assign senior program managers with real authority. Move performance review of team members from the functional managers to the team leaders. (3) Publish an empowerment matrix for each of the three teams, following the Appendix B template. Reconcile host expectations with team understanding and publish the agreed matrix. (4) Enforce a ceiling of 2.5 concurrent projects per engineer across the division. Kill, defer, or deprioritize whatever work does not fit under the ceiling. (5) Install an AHP-based portfolio prioritization model. Run it against the current project list. Match the prioritized list against real functional capacity. Share the model with all executives and publish monthly refreshes. -- 44 of 48 -- › Host best practices › › › © 2026 lateralworks Page 45 (6) Stand up a 24-hour fast-decision forum for cross-functional decisions that would otherwise escalate. Publish the envelope of decisions the forum is empowered to make. (7) Add break-even time (BET) to the executive scorecard. Begin tracking BET for every new project alongside the existing development-cost and time-to-market metrics, and phase out the development-cost metric over 18 months. A.7 Early results Twelve months into the engagement, the company reported the following results on the three pilot projects that had been rebuilt as true heavyweight teams inside a provisioning host: • Time-to-first-prototype on the pilot projects reduced by 35–45 percent compared to the baseline of the previous three products the division had shipped. • Schedule predictability, measured as the gap between committed and actual milestone dates, improved by roughly 3x. Milestone slippage fell from an average of 4–6 weeks per milestone to 1–2 weeks. • Engineer multiplexing on the pilot projects fell from an average of 5.2 concurrent projects per engineer to 1.8. Division-wide multiplexing fell more slowly (to 3.1) because the portfolio-kill-or-defer step (#4) took longer than expected. • Interrupt resolution reached steady-state at about 85 percent of logged interrupts resolved within the 7-day window, up from an effectively unmeasured baseline. The BET metric (#7) had not yet produced results; the first product launched under the new system was still in its early ramp at the 12-month report point. The company committed to continuing the engagement for another 12 months to see the BET signal and to extend the model across the remaining divisions. Lesson. The pattern at this storage company is the pattern lateralworks sees again and again: a team that appears to be the problem turns out to be an ordinary team performing to the ceiling of an interrupting host, and the executives who commissioned the assessment turn out to be the primary people with the authority to raise that ceiling. The teams could not fix this. The assessment did not make the executives more talented. It made the structural problem visible enough that it could be addressed at the level where the leverage actually existed. -- 45 of 48 -- › Host best practices › › › B Appendix B Empowerment matrix © 2026 lateralworks Page 46 The empowerment matrix is the document that makes the delegation relationship between a heavyweight team and its host explicit. Each row is a category of decision the team will face; each column is a level on the Oncken freedom scale introduced in practice 7. The cells show, for each decision, the level of freedom the team has by default. The matrix is not a rigid rulebook — it is a starting point for the conversation the team and the host need to have before the project begins. The matrix below is the lateralworks default for heavyweight teams in technology companies. It is offered as a template. Companies with different risk profiles — heavily regulated industries, safety-critical products, early-stage startups — will adjust the defaults. -- 46 of 48 -- › Host best practices › › › © 2026 lateralworks Page 47 Decision category Sub-decision L1 Act, report L2 Act, advise L3 Recommend Staffing Retain contractors / consultants 4 Relocate team members within the team 4 Resource allocation Assign members to tasks 4 Determine member availability 4 Re-assign members out of the team 4 Performance appraisal Team lead reviews of members 4 Member reviews of each other 4 Product definition Close initial specs 4 Change specs post-freeze 4 Customer requirements Obtain requirements from customer 4 Capital / expense Set project budget 4 Manage spending within budget 4 Spending under $5K 4 Spending over $5K 4 Design / technology Product architecture — minor 4 Product architecture — major 4 Day-to-day design decisions 4 Technology trade-offs 4 B.1 How to read the matrix The three freedom levels map to the Oncken scale described in practice 7: • L1 — Act, report: The team acts on its own judgment and reports the decision after the fact. Appropriate for decisions where speed is critical, reversibility is high, and the team has enough context to decide well. Most day-to-day design and spending-under-limit decisions live here. • L2 — Act, advise: The team acts but notifies the host immediately. Used for decisions that are reversible but where the host needs the information to coordinate with other teams or external parties. Minor architecture changes and contractor retention typically live here. • L3 — Recommend: The team frames the decision, presents options, and recommends. The host decides. Used for decisions that are hard to reverse, carry material financial impact, or commit the company beyond the team’s scope. Budget setting, major architecture changes, and external customer requirements live here. -- 47 of 48 -- › Host best practices › › › © 2026 lateralworks Page 48 Levels 4 and 5 ("wait until told" and "ask what to do") do not appear in a heavyweight-team matrix. A team operating at those levels on any substantive decision is, by definition, not heavyweight; it is a coordination body reporting to the functional hierarchy, which is a different kind of organism and should be labeled accordingly. B.2 Adaptation notes Adaptation notes. The defaults in this matrix work for most heavyweight product development teams in unregulated or lightly regulated industries. Adapt them as follows. (1) Regulated industries (medical devices, aerospace, financial services): move product-definition and spec-change rows to L3 across the board. (2) Early-stage startup inside a larger company: move most rows to L1 or L2; the point of an intrapreneurial team is speed, and L3 defaults defeat the purpose. (3) Platform teams serving multiple product teams: move resource-allocation and availability rows to L3, because the trade-offs span multiple stakeholders. (4) Safety-critical products: move design-decision rows to L2 or L3 and require a named safety authority. The matrix is a starting point, not a universal answer — use it to force the conversation, then write down what the conversation produced. A filled-in empowerment matrix should be published — on a team wiki, a shared drive, or printed and pinned to the team space — and referenced when decisions arise. The point is not the document itself; the point is to make the delegation relationship so explicit that both the team and the host know what the team is allowed to do, and neither has to guess. -- 48 of 48 --

FTTM Methodology·Revised edition

Host best practices

How executives create the conditions for fast product development

Core thesis. Teams deliver products; the host creates the conditions under which they deliver fast. Fix the host and speed becomes the default. Leave the host alone and team-level improvement fades within a year.

April 27, 2026·48 pages

View PDF →Download

© 2026 lateralworks Page 1 › › Whitepaper Team best practices How fast teams get the right product to market at the right time FTTM methodology series. A lateralworks Fast Time To Market (FTTM) methodology paper — the 15 practices that turn an empowered team into a fast team. Companion to Host best practices. Prepared by lateralworks FTTM methodology Date April 2026 Companion edition Online lateralworks.com FTTM series -- 1 of 31 -- › Team best practices › › › © 2026 lateralworks Page 2 Table of contents Team best practices Abstract 03 01 — The team: companion to the host 04 The framework: 15 practices, three groups 06 02 — Right-product 07 03 — Right-team 14 04 — Right-time 18 05 — Putting it to work 27 References 30 Core thesis. A fast team organizes itself around the customer (right-product), assembles the smallest competent group of role-owners (right-team), and uses its schedule as the primary tool for driving decisions and exposing gaps (right-time). Inside a provisioning host, these 15 practices cut time-to-market by 30 to 50 percent. Inside an interrupting host, they recover only a fraction of that, which is why this paper has a companion. -- 2 of 31 -- › Team best practices › › › © 2026 lateralworks Page 3 Overview Abstract Companies invest heavily in product development teams. They hire experienced engineers, recruit program managers, buy collaboration tools, and run training programs. Most of those investments produce little change in time-to-market. The team itself is only half the picture. The other half is the host: the executive staff and functional organization that surrounds the team and decides what it can do. The companion paper, Host best practices, describes 13 host practices. This paper describes the 15 team practices that operate inside a healthy host. The 15 practices fall into three groups from the lateralworks Fast Time To Market (FTTM) framework. Right-product covers six practices for getting the team to a product customers actually want and will pay for. Right-team covers two practices for turning a roster of names into a team that can deliver. Right-time covers seven practices for turning a schedule from a reporting artifact into a tool the team uses every day. The practices come from three decades of direct observation of fast-to-market teams, starting with a 15-company study of more than 500 practitioners in the early 1990s. They connect to a broader body of research: Wheelwright and Clark on heavyweight team structure [11], Reinertsen on product development flow [2], Smith and Reinertsen on developing products in half the time [4], Khurana and Rosenthal on the fuzzy front end [7], and the lean and agile traditions descended from Toyota [1] and elaborated by Ries [8] and others. The paper is written for program managers, chief engineers, and team leads who want a concrete checklist for how a fast team operates day to day. Executives who have read the host paper can use it to see what team-side practices their hosts will need to enable. Each practice has a short summary, a Best vs Normal contrast, and a practical example drawn from a lateralworks engagement or the published literature. -- 3 of 31 -- › Team best practices › › › 01 Foundation The team: companion to the host © 2026 lateralworks Page 4 A product development team is the visible engine of new product creation. It writes the spec, builds the prototype, runs the qualifications, and answers for the outcome at the executive review. When a product ships late, leadership looks at the team first, and often nothing else. That is a mistake. The team's performance is bounded by the host that surrounds it: the executive staff, the functions, the development framework, the portfolio, the decision-making system. A world-class team inside an interrupting host runs only marginally faster than a mediocre one. A merely-good team inside a provisioning host can outperform an industry leader [1, 11]. The companion paper, Host best practices, describes the 13 practices that make a host fast. This paper describes the 15 practices that make a team fast inside that host. The two are designed to be read together. Read the host paper first if you are an executive deciding what the company will permit. Read this paper first if you are a program manager, chief engineer, or team lead deciding how the team will operate. Either order works. Both papers are required to accelerate time-to-market. -- 4 of 31 -- › Team best practices › › › © 2026 lateralworks Page 5 Figure 1. The team is the visible engine. The host is the structural envelope. Team practices operate inside the conditions the host creates. What this paper does not cover This paper does not cover the executive mindset around speed, the design of the development framework, the portfolio prioritization system, the interrupt-and-provisioning matrix, the empowerment matrix, or the break-even time scorecard. Those are host concerns, addressed in the companion paper. What this paper does cover is what the team itself does: the practices that distinguish a 5-person team that ships in 9 months from a 25-person team that ships in 24. Right-product, right-team, right-time The 15 practices group naturally into three diagnostic categories. A team that consistently ships products customers do not want has a Right-Product problem. A team with the right idea but broken execution has a Right-Team problem. A team that executes well but always misses the market window has a Right-Time problem. Most teams that come to lateralworks have problems in two or three categories at once, but the dominant pattern is usually clear within the first two days of assessment. The framework on the next page makes the grouping concrete; the rest of the paper walks each practice in turn. -- 5 of 31 -- › Team best practices › › › © 2026 lateralworks Page 6 The framework 15 practices, three groups The 15 team practices fall into three groups, summarized at a glance below. Right-product covers what the team builds; right-team covers who builds it; right-time covers when it gets built and how the team manages the schedule that drives all three. Figure 2. The 15 team practices at a glance, organized by Right-product, Right-team, and Right-time. Each group answers a different question; together they describe how a fast team behaves day to day. -- 6 of 31 -- › Team best practices › › › 02 Right-product Build the product the customer wants © 2026 lateralworks Page 7 Six practices that get the team to a product the customer actually wants. The common thread is the customer's voice. In normal organizations, the customer is heard twice: at the start and at beta. In fast organizations, the customer is in the room throughout, in different ways at different phases. The product the team ships is the one the customer asked for, in their own words, validated against their actual workflow. -- 7 of 31 -- › Team best practices › › › © 2026 lateralworks Page 8 1. Co-develop with tier-1 customers Summary. Fast teams treat one or two leading customers as development partners. Engineers talk to engineers. Schedules and unfinished designs move in both directions. The customer's roadmap and the team's schedule pull on each other. The result is a product that fits the customer's system before it ships, and a relationship that converts directly to first-design-win revenue. Normal organization Best organization The customer is treated as a vendor-supplier relationship. Contact runs through the sales account team or marketing, who summarize, filter, and occasionally reinterpret what the customer actually said. Engineers are kept away from customers because someone might say the wrong thing. The team builds against a documented MRD and discovers at beta that the real customer wanted something different. One or two tier-1 customers are engaged as co-developers. Engineer-to-engineer channels are open and used. The team understands the customer's customer and the system the product slots into, not just the spec. Schedules are shared in both directions. Joint problem-solving builds trust that survives the inevitable bumps and converts the customer into a first-design-win at launch. From a lateralworks engagement A networking-equipment client was losing socket decisions to a faster competitor. By the time the client's product shipped, the customer had already qualified the competitor. The team set up partner-lab arrangements with two key carriers, stationed two engineers at customer sites for a week per quarter, and shared its working schedule weekly. Within 12 months the team had locked in first-design-win on the next two carrier deployments. The product was not technically superior. It had been co-developed against the carrier's actual rack, software stack, and operational procedures while the competitor was still translating an MRD. Connection to the literature. Toyota's keiretsu supplier system, studied extensively by Liker [12], formalizes co-development between OEMs and tier-1 suppliers in the same pattern lateralworks observes among fast technology teams: engineers embedded across organizational lines, shared roadmaps, joint problem-solving as the default rather than the escalation path. Toyota consistently develops vehicles in roughly half the calendar time of comparable Western OEMs [13], and tier-1 co-development is one of the structural reasons. -- 8 of 31 -- › Team best practices › › › © 2026 lateralworks Page 9 2. Translate requirements; reconfirm throughout Summary. Voice of the customer (VOC) is a thread through the whole TTM cycle, from gestation to field support, not a front-end phase. Fast teams build a VOC schedule alongside the development schedule and design specific customer involvement into every phase. Assumptions are reconfirmed continuously instead of frozen at the front end and re-discovered at beta. Normal organization Best organization Customer input is gathered at the front end and then again at beta, with very little in between. The quality of what reaches the team depends on the relationship between marketing and engineering: if it is good, specs are reasonable; if it is bad, specs are wrong and only get discovered in late testing. Beta produces a list of surprises that force a re-design under deadline pressure. VOC is engineered into every TTM phase: planning (counsel on strategy), gestation (skunk-works with leading customers), requirements (user groups and QFD), design (partner labs and direct contact with designers), development (use-ability testing), beta (early production install), field (root-cause analysis with customer), overrun (mutual problem-solving). Beta produces almost no surprises because the surprises were caught at the phase that could absorb them. From a lateralworks engagement A storage company was averaging 30 to 40 "beta surprises" per major release: customer-reported issues engineering had no idea existed until beta hardware reached the site. The team installed a VOC schedule with seven phase-specific touchpoints, ran every touchpoint with the same three lead customers, and converted them into engineering-owned commitments rather than marketing-owned briefings. The next major release went to beta with three reported issues, two of which were already in the team's known-issue tracker. The rework savings alone covered three years of the customer-engagement program. 3. Know what customers value, when they want it, and what they will pay for Summary. Fast teams separate customer requirements (the problem) from product specifications (the solution). They run a Teach-Negotiate-Tell (TNT) discipline: the customer teaches the team how the product fits into a business workflow; the team negotiates with the customer on "how much is enough"; the team tells the customer what it will build and when. Skipping the teach phase produces a spec the team can build and the customer will not pay for. -- 9 of 31 -- › Team best practices › › › © 2026 lateralworks Page 10 Normal organization Best organization The team goes straight to specs without ever sorting out what the customer actually values. "Customers don't know what they want" is the operating belief. When customer feedback does arrive, it is usually a complaint from a large account about a feature that the team had no idea was important. Customer satisfaction data exists somewhere but is not connected to the requirements process. The team uses TNT (Teach, Negotiate, Tell) to pull requirements from the customer in their own language and then convert them to specs in engineering language. The team can describe, in customer terms, what the product does and why the customer would pay for it. Pricing assumptions are tested early. Satisfaction data feeds back into the next round of requirements. From a lateralworks engagement A semiconductor client was preparing a new low-power processor variant for an embedded market. Marketing had set lower power consumption as the headline requirement, based on competitive benchmarks. A TNT round with three lead customers revealed that two of them would pay a 40 percent ASP premium for half the wakeup latency, and that power consumption was already "good enough." The team re-targeted the design around latency. The product shipped on schedule and captured premium pricing the original spec would have left on the table. 4. Understand customer wants vs hows; prioritize the drivers Summary. Customers describe "hows": specific features they think they want. Fast teams translate those hows back into the underlying wants they represent, then prioritize the wants. Quality Function Deployment (QFD) or a lighter-weight equivalent does this systematically. The result is a spec that maximizes satisfaction per engineering hour, instead of a spec that adds every feature mentioned in every interview. Normal organization Best organization Customer requirements are skipped in favor of product specifications. The team responds to the loudest customer complaint of the week. QFD is rejected as too complex; lighter VOC tools are rejected as too soft. The spec accumulates features. Engineering builds them all. The product ships late, with everything the customer asked for and many things they do not value. The team uses QFD or a lighter-weight equivalent to map the customer's wants to the team's hows, then weights the wants by importance. The top three or four drivers get serious engineering investment; the rest get parity-or-less treatment. The team validates the mapping by asking six lead customers to sign off that the chosen specs would be competitively superior at launch. -- 10 of 31 -- › Team best practices › › › © 2026 lateralworks Page 11 From a lateralworks engagement A medical-device team had a 60-item feature backlog from 18 months of customer interviews. A QFD-style exercise compressed the backlog to 12 ranked customer wants. The top two ("easy to clean" and "works with existing chart software") accounted for two-thirds of the weighted importance. Both were near the bottom of the marketing priority list, which had been organized around novel features marketing thought it could promote. Re-cutting the spec around the top two wants reduced release scope by roughly 18 months of engineering work and left the team with a product that changed clinical workflows on the customer side. Connection to the literature. QFD originated at Mitsubishi's Kobe shipyard in 1972 and was popularized in the West by Hauser and Clausing in their 1988 HBR article "The House of Quality" [14]. Their data showed that companies using QFD reported 30 to 50 percent reductions in engineering changes, design cycle time, and start-up costs. The lateralworks observation across hundreds of engagements is consistent: the QFD discipline matters more than any specific QFD tool. 5. Start design while refining specs; never freeze Summary. Specifications and design are interdependent. Freezing specs at the front end and forbidding change is a large source of TTM overrun, because the world changes during development and the eventual re-plan costs more than the discipline saved. Fast teams use flexible containment: short-form 80-percent specs early, an active Change Control Board (CCB), and a deliberate strategy of front-loading changes when the rework penalty is lowest. Normal organization Best organization Either design does not start until specs are fully defined (slow), or design starts with no specs at all (chaotic). Change control is ad hoc. Specs are eventually "frozen" by mandate, the world changes, the freeze breaks, and a major re-plan resets a new "really frozen" set of specs. The cycle repeats, accounting for a substantial fraction of total TTM overrun. Specs are short-form (one page) and cover the 80 percent that engineering can act on; design starts immediately. A standing CCB governs incoming changes. Early changes are encouraged (low rework penalty); late changes are stopped or absorbed via contingency. Total change volume is minimized. Adaptation speed is maximized: the team responds quickly to customer or competitive moves. -- 11 of 31 -- › Team best practices › › › © 2026 lateralworks Page 12 From a lateralworks engagement A mobile-software team had a 14-week requirements lockdown phase before engineering could start. The team replaced it with a 3-week 80-percent spec and a standing CCB that met for 30 minutes every Tuesday. The first prototype was in user hands at week 4 instead of week 17. The CCB absorbed 41 change requests over the next 20 weeks; under the old process those would have either forced a re-plan or been deferred. The product shipped 11 weeks ahead of the original schedule with the same scope. 6. Fail fast; integrate early; many do-it-try-it-fix-it cycles Summary. Fast teams integrate early and often, even when individual components are not yet finished. The integration surfaces system-level problems that unit testing cannot find. Integration failures are treated as learning events, with many short cycles budgeted into the schedule instead of one big cycle at the end. Roughly right beats exactly wrong. Normal organization Best organization The phase-gate waterfall (EVT → DVT → PVT) drives behavior. Each function makes its part "perfect" and hands off to the next. Integration happens at the end. System problems surface there, with no schedule buffer left to absorb them. The team falls back through the gates, redoing earlier work. Failure is treated as blame; people protect their pieces and avoid early integration. Concurrent engineering. Unit work, integration, and system test run in parallel and overlap. The team integrates as early as possible, often with simulated parts where physical parts are not yet ready, and integrates frequently. Each integration cycle is short. Failures are treated as information about the system. Learning cycles are explicitly budgeted into the schedule. Figure 3. Waterfall integration loads all the system risk onto the end of the project. Concurrent integration spreads it across many short cycles, each of which surfaces problems while there is still time to respond. -- 12 of 31 -- › Team best practices › › › © 2026 lateralworks Page 13 From a lateralworks engagement An industrial-automation client ran a strict EVT → DVT → PVT process for a new motion-controller board. Each phase took 8 to 14 weeks, and roughly one in three boards looped back to EVT after PVT discovered an integration problem. The team moved to concurrent design-of-experiments, running four parallel DOEs that each tested a specific integration risk in the first 6 weeks of the project. Two of the four DOEs surfaced problems that would previously have been caught at PVT and triggered a loop-back. Catching them at week 6 avoided roughly 22 weeks of rework and shipped the controller 42 percent faster than the previous generation. Connection to the literature. Reinertsen [2] formalizes this as the economics of fast feedback loops: the cost of finding a problem rises by roughly an order of magnitude for each phase the discovery is delayed. Ries [8] and the lean-startup tradition extend the same logic to whole product concepts. The deeper root is Toyota's jidoka principle [1]: make problems visible immediately, stop the line until they are understood, and resume only when the system has learned. Fail fast is jidoka applied to engineering, rebranded for the software era. -- 13 of 31 -- › Team best practices › › › 03 Right-team Build the team that can deliver © 2026 lateralworks Page 14 Two practices that turn a roster of names into a team that can deliver. Right-team is the smallest of the three groups, but the highest-leverage: a team organized incorrectly will under-perform every other practice in this paper. Both practices are about composition and structure. A motivated team in the wrong structure will burn out compensating for its own design. -- 14 of 31 -- › Team best practices › › › © 2026 lateralworks Page 15 7. Core team organized by ROLES, not functions; lateralized Summary. A fast core team is 5 to 7 people, each carrying a program-level role (chief engineer, system architect, customer integrator, manufacturing lead) in addition to their functional title. The role bias is horizontal: each person owns a slice of the whole product. The functional bias is vertical: each person owns a piece of their discipline. Right-team structure makes the horizontal bias dominate. Without it, the team becomes a coordination meeting between functional silos. Normal organization Best organization The "core team" is whoever needed to be invited so they would not complain about being left out. It has 20 to 30 part-time members, each loyal to a function. Meetings degrade into rat-hole technical debates won by the loudest SME. There is no system architect, no customer integrator, no chief engineer; technical trade-offs default to the most senior person in whichever function is currently complaining. Nobody owns the product as a whole. Failures are blamed on the next function downstream. The core team is 5 to 7 dedicated people, each carrying a clearly named program role: chief engineer, system architect, system integrator, customer integrator, manufacturing lead, test lead, quality lead. Functional sub-teams report into the relevant role. The role bias subordinates the function bias. The system architect, in particular, owns the trade-offs nobody else has authority to make, and is accountable for product-level coherence. Figure 4. The shape of a function-organized team versus a role-organized team. The role-organized team has a center of gravity (the program manager) and a small ring of role-owners; sub-teams hang off the role-owners, not the core team. -- 15 of 31 -- › Team best practices › › › © 2026 lateralworks Page 16 From a lateralworks engagement A datacenter-hardware client ran its flagship platform through a 26-person "core team" that had grown over four releases. Meetings ran four hours. Decisions deferred to follow-up meetings. Two prior systems-level integration failures had each been blamed-and-forgotten with nobody holding the architectural baton. The team reorganized into a 7-person core (PM, chief engineer, system architect, customer integrator, hardware lead, software lead, manufacturing lead) with the rest moved into role-aligned sub-teams. The next platform shipped 5 months earlier. In the team's words: "finally felt like one product instead of seven." Connection to the literature. Wheelwright and Clark [11] introduced the four-quadrant team taxonomy (functional, lightweight, heavyweight, autonomous) and documented a factor-of-three time-to-market advantage for heavyweight teams over lightweight ones in their study of automotive and electronics OEMs. Toyota's shusa or chief engineer system, described by Morgan and Liker [12], is the canonical heavyweight role: a single individual owns vehicle-program integration end-to-end with authority that cuts across the functional hierarchy. The lateralworks role-not-function discipline generalizes the chief engineer model into a small ring of named program roles. 8. Get the best people; mix of inside and external SMEs Summary. Fast teams secure the best technical talent for the project, whether it sits inside the company or outside. Internal employees, contractors, consultants, and supplier engineers all work as one virtual team on one mission. Resource constraints inside the company are real, but they are not a reason to staff the project with the wrong people. Normal organization Best organization The team is staffed with whoever was free that month. Key skills are missing or borrowed at 8 hours per week from someone with another priority. External SMEs are rejected on principle ("IP leakage," "only we know our domain") even when the internal expertise does not exist. The best people are split across 5 to 10 projects and are most absent at the start of the new one, when their input matters most. "Lack of the right people" becomes the all-purpose explanation for slip. The team is composed deliberately, with the right skills on day one. External SMEs are recruited when needed; NDAs handle the IP concern. The boundary between employees and external resources is invisible from the team's perspective. Everyone is on the same virtual team, accountable to the same outcomes. The portfolio runs with enough discipline that the right internal people are actually available when the project needs them. -- 16 of 31 -- › Team best practices › › › © 2026 lateralworks Page 17 From a lateralworks engagement A semiconductor client preparing a high-speed memory interface needed deep signal-integrity expertise it did not have internally. The functional manager's instinct was to assign whoever was available and have them ramp. The PM instead brought in two specialist consultants for a 6-month engagement, gave them the same access, schedule visibility, and decision authority as internal team members, and put their reviews on the chief engineer's desk rather than the consultants' agency. The two consultants caught two eye-diagram problems in the first month that, by the team's own estimate, would have surfaced in qualification 6 months later and forced a respin. The fee for the engagement was less than 5 percent of one respin. Connection to the literature. Parker [31] documented the same pattern in cross-functional team research: external members, treated as full members rather than visiting consultants, consistently outperform pure-internal teams on novel-domain projects. Reinertsen [2] frames the economics: the cost of an external specialist is small relative to the cost of delay caused by absence of expertise. Organizations that optimize headcount budget over delivered product almost always pay the difference, with interest, in slip. -- 17 of 31 -- › Team best practices › › › 04 Right-time Plan and drive the schedule © 2026 lateralworks Page 18 Seven practices that turn a schedule from a reporting artifact into the primary tool the team uses every day. Fast teams treat their schedule the way a startup treats its cash runway: a real number that drives real decisions, refreshed continuously, owned by everyone, honest about the gap between what is wanted and what is achievable. Normal teams treat their schedule as a presentation deliverable for the next executive review. -- 18 of 31 -- › Team best practices › › › © 2026 lateralworks Page 19 9. Schedule as driver, not reporter Summary. Fast teams use the schedule to drive day-to-day decisions: what to work on, what to defer, what to escalate, what to pull in. Normal teams use the schedule to report what already happened. A driving schedule prevents slip; a reporting schedule documents it. Making the schedule king does not require sacrificing quality or cost. It requires using the schedule to find and remove the wasted time that exists in every project. Normal organization Best organization Schedules are produced for management consumption. Inside the team, they are out of date within weeks and are used neither to set daily priorities nor to decide trade-offs. Schedule slip is treated as inevitable; "we can't sacrifice quality for time" is the universal rationalization. Re-plans happen at major reviews, after the fact, and slide the date out by months at a time. The schedule is the team's primary planning tool. It is up to date, honest, and used every day. Top management can articulate the cost of delay in dollars, which makes "pay to save a day" the default trade-off. Slip is treated as a signal of waste to hunt down and remove, not as inevitability to accommodate. The team challenges itself to find and eliminate slack. From a lateralworks engagement A networking-equipment client's schedule was traditionally regenerated the Friday before each monthly executive review. Between reviews, engineers worked from email threads, ad-hoc spreadsheets, and the chief engineer's memory. The team adopted a weekly schedule scrub on Wednesday mornings (60 minutes, full core team) and made the resulting schedule the only authoritative source for what was on the critical path. Within two months the team was identifying and recovering one to two weeks of slip per month before it accumulated. The product shipped 9 weeks ahead of target, the first on-schedule release the division had produced in 4 years. 10. Aggressive planning Summary. Fast teams spend roughly 3x the planning time of normal teams at the start of a project, then refresh the plan every week throughout. The investment looks expensive in calendar days, but it pays back many times over in execution. Aggressive planning surfaces the schedule gap early, when it can be closed. Passive planning surfaces it late, when it can only be reported. -- 19 of 31 -- › Team best practices › › › © 2026 lateralworks Page 20 Normal organization Best organization Schedules are top-down, manufactured to fit the date the team was given, and never seriously challenged. Individuals who push back are labeled non-team-players. The schedule is high-level, mirrors the functional structure, and is rarely used to manage daily work. Heroics and eleventh-hour firefighting are rewarded; the planning that would have prevented the fire is not. Plans are built bottom-up by the team using critical-path methods, structured around customer-need dates rather than internal capacity, and reconciled to the target date with explicit gap analysis. If the gap is too large to close, the project is killed before it starts. If it goes ahead, the plan is refreshed weekly with actuals, and the team looks continuously for ways to pull in the critical path before it slips. From a lateralworks engagement An enterprise-software client adopted aggressive planning across three concurrent projects. Two passed gap analysis and went forward; one was killed at week 2 because the gap exceeded what any reasonable acceleration could close. Killing it freed the people for the two that survived. Both shipped on time, in roughly half the calendar duration of the previous comparable project. The killed project, in retrospect, would have consumed 9 to 12 months of effort and shipped 6 months past its market window. Aggressive planning saved the cost of building it. 11. Macro-micro planning; rolling window Summary. Fast teams plan the whole project at the macro level (around 50 tasks, end-to-end, with 4 to 6 cross-functional integration points) and break down only the next 6 weeks into micro detail (1- to 15-day tasks). The micro window rolls forward weekly. Detail is added where there is clarity; macro placeholders carry the rest. This avoids two opposite failure modes: too little detail to manage near-term work, and too much detail in the far term where it will all change anyway. Normal organization Best organization Either the schedule has no detail (just milestones), or the project manager spends weeks producing a fully decomposed plan that is out of date the day it is published. The detailed plan is too complex for anyone but the PM to read, so it functions as a paper deliverable rather than a tool for managing work. When the project changes scope, the plan either does not change or has to be rebuilt from scratch. A 1-to-2-day offsite produces a 50-task macro plan covering the entire project, with explicit cross-functional integration points. The next 6 weeks are broken down into 1-to-15-day micro tasks. The window rolls forward weekly: as time advances, additional micro tasks are pulled out of the macro placeholders. The team has detail where it has clarity, and a coherent end-to-end view in the abstract. -- 20 of 31 -- › Team best practices › › › © 2026 lateralworks Page 21 Figure 5. Macro-micro planning. The macro plan covers the full project; the micro window covers what the team can see clearly, and rolls forward as the project advances. From a lateralworks engagement A memory-controller qualification program had repeatedly tried to build a fully decomposed 18-month detailed schedule and abandoned it within a quarter each time, because the schedule was unmaintainable. The team adopted macro-micro: a 50-task macro plan covering the full 18 months, with 6-week rolling micro detail. The macro plan caught two front-loaded integration points the previous detailed plan had buried. The rolling micro window kept the team focused on what it could act on. The program completed in 13 months, and the planning effort fell from roughly 0.4 of a PM FTE to 0.15. 12. Team planning, simulation, scrubbing, ownership Summary. Fast teams build and maintain their own plan, with the project manager as facilitator. Continuous scrubbing (small groups reviewing detailed sections of the plan against actuals) keeps the schedule honest and generates ownership. The team can simulate alternative paths together and choose with full information. The PM never edits the schedule alone. -- 21 of 31 -- › Team best practices › › › © 2026 lateralworks Page 22 Normal organization Best organization The PM creates the plan in isolation, then "sells" it to the team in a review meeting. Members are disengaged because they did not create it. The schedule slips out of sync with reality within weeks. The PM spends increasing time on cosmetic updates for management while the team tracks its real work in spreadsheets, email, and meetings. Team members do not own the dates because they were never asked to commit to them. The full team builds the plan together, scrubs it in small groups, and treats it as their own document. The PM facilitates. The team uses the schedule daily to set priorities, predict events, and identify cross-team dependencies. Refresh meetings take 30 to 60 minutes weekly. Ownership is high. The schedule is honest because the people doing the work are the people maintaining it. From a lateralworks engagement An industrial-controls client had a heroic PM who personally maintained the full project schedule across three releases. When she went on leave, the schedule deteriorated within four weeks. The team adopted shared ownership: a 60-minute Tuesday refresh with the full core team, plus 30-minute scrubbing meetings with sub-teams as needed. The PM stopped editing the schedule alone. The schedule stayed accurate through the next two releases regardless of who was on vacation. Team confidence in the predicted dates rose noticeably. 13. Market-driven, not resource-constrained Summary. Fast teams plan first without resource constraints. They establish what the market or the lead customer needs (the target date), what work is required to get there, and how long that work takes. Then they evaluate the resource and budget gap and decide explicitly how to close it: add people, outsource, rescope, or kill. Normal teams plan from the resources they happen to have and force-fit the schedule, hiding the gap and pushing it into the future. Normal organization Best organization Planning starts inside the constraint: "You have 12 months, $5M, and 15 people; show me a plan that fits." The team produces a plan that appears to fit, knowing privately that it will not. The project finishes at $7M, 18 months, and 30 people. The gap was real on day one but was not surfaced because the planning method hid it. The schedule, the budget, and the resource plan are all systematically optimistic. Planning ignores constraints initially, except the target date set by the market or lead customer. The team determines the work needed, estimates duration honestly, and then computes the resource and cost implications. The gap (if any) is explicit and becomes the focus of an executive trade-off conversation: invest more, outsource, rescope, or kill. The decision is made with information, not against the wall. -- 22 of 31 -- › Team best practices › › › © 2026 lateralworks Page 23 From a lateralworks engagement A storage client planned its next-generation array assuming the existing engineering headcount. The unconstrained plan revealed a 40 percent gap on a 14-month target. The executive conversation that followed went somewhere the constrained plan would have prevented: the team outsourced two non-differentiating subsystems to a long-time supplier, freed 6 senior engineers to work the differentiated path, and shipped the array on the original 14-month target. The constrained plan would have showed apparent fit at 14 months, then missed by 8. Connection to the literature. The Lockheed Skunk Works under Kelly Johnson is the canonical example of market-driven planning: the SR-71 Blackbird program defined the performance and schedule first, then assembled the resources required, rather than asking what could be built with available staffing. Reinertsen [2] reaches the same conclusion analytically: starting from the resource constraint optimizes utilization at the cost of throughput, and throughput determines time-to-market. 14. Know the gap; drive before-the-fact urgency Summary. The schedule gap is the difference between when a project is wanted (target) and when it will actually finish (honest schedule). Fast teams compute this gap on day one and use it to drive urgency while there is still time to respond. Normal teams hide the gap with happy schedules and discover it late, when the only response is a major re-plan and a slip announcement. Normal organization Best organization Happy schedules are the cultural norm. Showing a schedule that finishes later than the target is career-limiting. The team produces a plan that fits the target, says so on every status update, and only acknowledges slip when a major deliverable visibly fails. The slip is rationalized as "unforeseeable." The cycle repeats project after project. Senior managers treat the chronic slip as a team performance problem rather than as evidence that the schedules they accept are fictional. Target and schedule are separated explicitly. The gap (if any) is calculated and shown to leadership on day one. Senior management treats exposure of a gap as good behavior. The team uses the gap to drive specific actions: reduce scope, run things in parallel, outsource, ship a minimum viable version first. The earlier the gap is known, the cheaper it is to close. -- 23 of 31 -- › Team best practices › › › © 2026 lateralworks Page 24 Figure 6. The honest schedule shows the gap on day one and gives the team time to respond. The happy schedule hides it until late, when the only available response is to slip further. From a lateralworks engagement A semiconductor client's team built its first macro plan on the second day of the project and found a 6-month gap on a 12-month target. Under the old culture this would have been suppressed. Under the new gap-aware culture it triggered an immediate conversation with the lead customer. The outcome was a two-step release: a minimum-viable variant on the original 12-month target (covering the customer's mandatory feature set) and a full-feature variant 4 months later. Both shipped on time. The customer preferred the staggered release. The team preferred the honest plan. The executive sponsor started asking other teams why they had not surfaced gaps as early. 15. Refresh planning; continuous schedule pull-in Summary. Fast teams refresh their schedule weekly, sometimes daily. They update with actual progress and actively look for ways to pull in the critical path. When the schedule is on time, they accelerate to bank time against future unknowns. The discipline tracks the longest path and the cluster of paths behind it, because tomorrow's critical path is hiding in today's second-longest. -- 24 of 31 -- › Team best practices › › › © 2026 lateralworks Page 25 Normal organization Best organization The schedule is built once, presented to the team as theirs, and drifts out of sync within weeks. The PM updates it cosmetically before executive reviews. The team uses spreadsheets and email to track real work. There is no systematic pull-in attempt, only damage control after slip. Secondary critical paths are ignored on the assumption they will stay shorter than the primary. The team refreshes the schedule weekly in a 30-to-60-minute core-team meeting, updating actuals and re-estimating remaining work. It models pull-in scenarios and acts on them. It tracks 10 to 20 paths behind the critical path on the assumption that any one of them can become the critical path tomorrow. Figure 7. The critical path is not alone. Fast teams pull in the cluster of paths behind it, because the next critical path is one of those paths. From a lateralworks engagement A memory-products client had a strong project manager who pulled the critical path aggressively but ignored the rest of the schedule. Six weeks before tape-out, a path that had been the eighth-longest at project start surged forward as a verification subsystem ran into a corner-case issue and became the new critical path. No acceleration plan was ready. The team slipped 4 weeks. Subsequent projects adopted the discipline of pulling the top 15 paths weekly. Two later projects survived comparable late-emerging paths without slip, because each had been actively scrubbed and accelerated all along. -- 25 of 31 -- › Team best practices › › › © 2026 lateralworks Page 26 Connection to the literature. Goldratt's Critical Chain Project Management [27] argues the same principle from a different angle: managing only the critical path leaves the rest of the network exposed, and a slip on any feeding path can instantly become the new critical path. The lateralworks pull-in discipline operationalizes this in a weekly cadence rather than as a separate methodology, which is why teams adopt it more readily. -- 26 of 31 -- › Team best practices › › › 05 Implementation Putting it to work © 2026 lateralworks Page 27 The 15 team practices are a system. Adopting one in isolation produces a temporary improvement at best; the surrounding practices pull the new behavior back to the prior norm within a quarter or two. The teams that lateralworks has seen sustain 30 to 50 percent reductions in time-to-market adopt the practices in a deliberate sequence, with executive sponsorship from a host willing to provision and protect them through the early months when the new behaviors are still fragile. -- 27 of 31 -- › Team best practices › › › © 2026 lateralworks Page 28 What follows is the typical adoption sequence on a team transformation engagement. The order is not rigid. A team with strong customer engagement but a broken schedule would reorder steps 1 and 4. The sequence as written works for most teams that come to lateralworks with a "we ship late" diagnosis. 1. Reorganize the core team by role Get the team structure right before anything else. Reduce the core team to 5 to 7 people. Assign program-level role names: chief engineer, system architect, customer integrator, manufacturing lead, and so on. Move performance review of core team members from the functional managers to the program manager. Without this step, the rest of the practices have no team to land on. 2. Build the macro plan as a team Run a 1-to-2-day off-site to produce the macro plan. Surface the schedule gap on day one. If the gap exceeds what reasonable acceleration can close, kill the project before it consumes resources. If the gap is closeable, agree on the acceleration strategy (concurrency, outsourcing, scope reduction) before any committed dates leave the room. 3. Install weekly refresh planning Schedule a 60-minute weekly refresh meeting with the full core team. Make it the only forum where the schedule is edited. Track the top 15 paths. Within four weeks the team will be identifying and recovering one to two weeks of slip per month before it accumulates. 4. Open direct customer channels Identify one or two tier-1 customers and establish engineer-to-engineer channels. Run a TNT-style requirements pull. Start a VOC schedule alongside the development schedule, with named touchpoints in every TTM phase. Within 90 days the team will know what the customer actually values, and the spec will reflect it. 5. Move to concurrent integration Replace the EVT → DVT → PVT waterfall with overlapped phases and early system integration. Budget explicit learning cycles into the schedule. Treat each integration failure as information about the system, not as a defect to assign blame for. Update the development framework with the new model so the next project inherits the practice instead of reinventing it. 6. Hand the schedule to the team Move the schedule from a PM-owned artifact to a team-owned tool. The PM stops editing it alone. Sub-teams scrub their own sections. The schedule becomes the team's primary planning instrument, not a management presentation. This is the longest-lead change because it is cultural; allow two to three quarters for it to settle. -- 28 of 31 -- › Team best practices › › › © 2026 lateralworks Page 29 Key finding. Across lateralworks engagements, teams that complete this six-step sequence inside a provisioning host achieve 30 to 50 percent reductions in time-to-market on the projects run under the new system, within 12 to 18 months. Teams that attempt the sequence inside an interrupting host see at best a 10 to 15 percent improvement that fades within a year. Fast team practices and fast host practices reinforce each other. Neither survives long without the other. -- 29 of 31 -- › Team best practices › › › © 2026 lateralworks Page 30 Sources References [1] Ohno, T. Toyota Production System: Beyond Large-Scale Production. Productivity Press, 1988. [2] Reinertsen, D. G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009. [3] Christensen, C. M. The Innovator's Dilemma: When New Technologies Cause Great Firms to Fail. Harvard Business Review Press, 1997. [4] Smith, P. G., and Reinertsen, D. G. Developing Products in Half the Time: New Rules, New Tools. 2nd ed. Wiley, 1998. [5] House, C. H., and Price, R. L. "The Return Map: Tracking Product Teams." Harvard Business Review, January–February 1991, pp. 92–101. [6] Cooper, R. G. Winning at New Products: Creating Value Through Innovation. 5th ed. Basic Books, 2017. [7] Khurana, A., and Rosenthal, S. R. "Integrating the Fuzzy Front End of New Product Development." MIT Sloan Management Review, Winter 1997. [8] Ries, E. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business, 2011. [9] Edmondson, A. C. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley, 2018. [10] Womack, J. P., and Jones, D. T. Lean Thinking: Banish Waste and Create Wealth in Your Corporation. 2nd ed. Free Press, 2003. [11] Wheelwright, S. C., and Clark, K. B. Revolutionizing Product Development: Quantum Leaps in Speed, Efficiency, and Quality. Free Press, 1992. [12] Morgan, J. M., and Liker, J. K. The Toyota Product Development System: Integrating People, Process, and Technology. Productivity Press, 2006. [13] Liker, J. K. The Toyota Way: 14 Management Principles from the World's Greatest Manufacturer. McGraw-Hill, 2004. [14] Hauser, J. R., and Clausing, D. "The House of Quality." Harvard Business Review, May–June 1988, pp. 63–73. [15] Akao, Y. Quality Function Deployment: Integrating Customer Requirements into Product Design. Productivity Press, 1990. [16] Cooper, R. G., and Edgett, S. J. Lean, Rapid, and Profitable New Product Development. Product Development Institute, 2005. [17] Hamel, G., and Zanini, M. Humanocracy: Creating Organizations as Amazing as the People Inside Them. Harvard Business Review Press, 2020. [18] Spear, S., and Bowen, H. K. "Decoding the DNA of the Toyota Production System." Harvard Business Review, September–October 1999. [19] De Smet, A., Jost, G., and Weiss, L. "Three Keys to Faster, Better Decisions." McKinsey Quarterly, May 2019. [20] Bezos, J. "1997 Letter to Shareholders" and subsequent annual letters. Amazon Investor Relations. [21] Koen, P. et al. "Providing Clarity and a Common Language to the Fuzzy Front End." Research-Technology Management, March–April 2001. [22] Cooper, R. G., Edgett, S. J., and Kleinschmidt, E. J. "Portfolio Management for New Product Development: Results of an Industry Practices Study." R&D Management, 31(4), 2001. [23] Rubinstein, J. S., Meyer, D. E., and Evans, J. E. "Executive Control of Cognitive Processes in Task Switching." Journal of Experimental Psychology: Human Perception and Performance, Vol. 27, No. 4, 2001, pp. 763–797. [24] DeMarco, T. Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Broadway Books, 2002. -- 30 of 31 -- › Team best practices › › › © 2026 lateralworks Page 31 [25] Little, J. D. C. "A Proof for the Queuing Formula: L = λW." Operations Research, 9(3), 1961, pp. 383–387. [26] Kaplan, R. S., and Norton, D. P. The Balanced Scorecard: Translating Strategy into Action. Harvard Business School Press, 1996. [27] Goldratt, E. M. Critical Chain. North River Press, 1997. [28] Beck, K. et al. "Manifesto for Agile Software Development." 2001. https://agilemanifesto.org [29] Sutherland, J., and Schwaber, K. The Scrum Guide. 2020. https://scrumguides.org [30] Oncken, W., Jr., and Wass, D. L. "Management Time: Who's Got the Monkey?" Harvard Business Review, November–December 1974 (reprinted 1999). [31] Parker, G. M. Cross-Functional Teams: Working with Allies, Enemies, and Other Strangers. 2nd ed. Jossey-Bass, 2002. [32] Adler, P. S., Mandelbaum, A., Nguyen, V., and Schwerer, E. "Getting the Most Out of Your Product Development Process." Harvard Business Review, March–April 1996. [33] Clark, K. B., and Fujimoto, T. Product Development Performance: Strategy, Organization, and Management in the World Auto Industry. Harvard Business School Press, 1991. [34] lateralworks. "FTTM New Product Development Best Practices." Internal methodology document, Revision 2018.002. [35] lateralworks. "Internal assessment database." Engagement data across client programs, 1992–2026. -- 31 of 31 --

FTTM Methodology·Companion edition

Team best practices

How fast teams get the right product to market at the right time

Core thesis. A fast team organizes itself around the customer (right-product), assembles the smallest competent group of role-owners (right-team), and uses its schedule as the primary tool for driving decisions and exposing gaps (right-time). Inside a provisioning host, these 15 practices cut time-to-market by 30 to 50 percent.

April 27, 2026·31 pages

View PDF →Download

› › › › © 2026 lateralworks Page 1 › › Whitepaper Managing up, managing down, and the innovation paradox Why senior-manager failure modes kill the innovation their organizations depend on. Innovation series. A synthesis of the innovation-environment framework and the senior-manager failure-mode framework, with a representative case study. Names and sector-identifying details have been removed. Prepared by lateralworks Innovation methodology Date April 2026 Synthesis paper Online lateralworks.com Innovation paradox series -- 1 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 2 Table of contents Managing up, managing down, and the innovation paradox How good ideas die 04 Five conditions innovation environments need 05 The manager in the middle 07 The manager who over-invests in managing up 08 The manager who over-invests in managing down 09 How this plays out in performance 10 What good looks like 11 The leader’s decision 11 Appendix A — A representative case study 13 References 22 -- 2 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 3 Overview Abstract Innovation needs two things that pull against each other. Ideas need room to develop before they are evaluated, and they need rigor to determine whether they are worth pursuing. The paradox, documented by Amy Edmondson and others, is that organizations tuned for execution are structurally hostile to the early, fragile state in which good ideas exist. When rigor arrives too early, promising work dies. Over time, people stop bringing ideas forward. The companies that solve this paradox across decades — Google, 3M, Amazon, Pixar, Toyota, Analog Devices — share a structural pattern. They sequence encouragement before scrutiny. They separate the creative act from the evaluative one. They make feedback predictable rather than an ambush. They protect the space for exploration from short-term pressure. They reward the act of contributing, not the outcome alone. These conditions are cultural, but they do not maintain themselves. Senior managers hold them up or tear them down every week. This paper examines the two ways senior managers fail the innovation environment their companies depend on. One over-invests in managing up: optimizing the upward narrative, absorbing direct reports’ work into first-person-plural framing that becomes singular at the executive layer, hoarding strategic context as personal currency. The other over-invests in managing down: deep in the operational weeds, protective of the team, absent from the rooms where direction gets shaped. Both failure modes break the condition the innovation-environment framework calls protection from above. They do it for opposite reasons, with consequences that unfold on different timelines. The paper closes with a detailed case study (Appendix A) from a well-known technology company. A director-level leader solved a three-year-old commercial problem through self-directed weekend learning in agentic AI, delivered two production-grade applications and a live community platform, and in the process resolved an OPEX problem the CEO had been complaining about for months. What followed is the failure mode in compressed form. Senior managers killed the original promotion. The CEO’s compromise was a workload doubling rather than a real role change. The CEO then killed the working community platform itself, mandating a year-long product engineering review for a system already deployed and in active internal use, and characterizing the director’s production-grade work as “vibe coding.” The case is a textbook instance of the innovation paradox failing at every senior layer of the organization. It also surfaces a second paradox specific to the AI moment: a company that publicly commits to AI-driven efficiency but applies pre-AI engineering controls to AI-built work, eliminating the speed advantage that was the reason for using AI in the first place. Core thesis. The innovation paradox is a problem of environment. Senior leadership is the environment. When the managing-up failure mode dominates the middle of an organization, and when the executive layer above declines to correct it or participates in the same evaluative reflexes itself, no innovation policy can outrun the signal it sends to the team: wait to be told. -- 3 of 22 -- › Managing up, managing down, and the innovation paradox › › › 01 Framework How innovation environments work © 2026 lateralworks Page 4 Innovation rarely fails because people lack good ideas. It fails because the organizational environment is hostile to ideas in their early state. When constraints, skepticism, or institutional inertia arrive too soon, two things happen. The specific idea gets killed before it can prove itself. And, over time, people stop bringing ideas forward at all. They learn to wait to be told rather than propose something new. The evidence for this pattern is no longer debated. Detert and Edmondson’s research on workplace silence found that roughly 85 percent of employees have withheld important information from their manager at least once because they feared the consequences of speaking up [1]. Edmondson’s broader work frames psychological safety as the single most decisive factor in whether teams surface problems early or late [2]. Morrison and Milliken characterize the systemic version of this behavior as organizational silence [3]. Google’s Project Aristotle, a two-year internal study of 180 teams, found psychological safety to be the strongest predictor of team performance, above team composition, individual expertise, or access to resources [4]. A manager cannot produce innovation from a team whose members have quietly decided that innovation is a career risk. The paradox sits in an uncomfortable spot. The same rigor that makes an organization effective at execution can make it lethal to innovation. Execution wants discipline and predictability. Innovation wants exploration and willingness to fund ideas before their value is clear. Most organizations optimize for the first and are accidentally hostile to the second. The leader’s job is to sequence them so that rigor arrives at the right moment, after an idea has room to develop, rather than as the first response to anything new. -- 4 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 5 Five conditions Innovation environments need Companies that sustain innovation across decades share a structural pattern. 3M’s 15 percent culture dates to the 1940s. Toyota’s kaizen suggestion system launched in 1951. Analog Devices’ EngineerZone community has been continuously operated since the late 2000s. The pattern separates these programs from the innovation initiatives that launch with fanfare and fade within a product cycle. It breaks into five conditions. Sequence: encouragement before scrutiny Google’s 20 percent time gave engineers permission to explore before asking them to justify [5]. Amazon’s Working Backwards process has teams write a press release describing the ideal customer experience before anyone asks about feasibility [6]. Pixar reviews films in their rough state rather than waiting for polish [7]. In each case the stress test follows idea development rather than preceding it. Separation: the idea is not the evaluation Amazon’s PR/FAQ document lets teams iterate on what could this be? separately from what would it take to build it? Pixar’s Braintrust has no authority. Feedback is advisory, not directive, which lets directors be candid about a film’s weaknesses without feeling they have agreed to a specific fix. Keeping the creative work structurally distinct from the evaluative work prevents the evaluator from killing the idea simply by being the evaluator. Ritual: feedback is predictable Pixar’s Braintrust meets on a regular schedule. Toyota’s suggestion review is continuous with same-week implementation. Amazon’s PR/FAQ reviews are a known step in the development cycle. Predictability builds psychological safety. Ambush does the opposite. The difference between a draft that receives honest feedback every other Tuesday and a draft that gets torn apart by a surprise review called yesterday by a skip-level is the difference between a team that keeps producing and a team that stops. Protection from above Every long-lived innovation environment has a senior leader who defends the space against short-term pressure. Google’s 20 percent time decayed as product pressure grew and leadership stopped actively defending it; by the mid-2010s, internal reports suggested only about 10 percent of engineers consistently used the program. Analog Devices kept EngineerZone free of marketing interference because senior leaders actively refused to let the community become a sales channel. Pixar’s Braintrust survived as a candid-feedback forum because Ed Catmull personally enforced its norms [7]. When the senior-leader protection goes away, the rest of the innovation environment collapses, even if the policy language remains on the intranet. Process reward: the act of contributing, not the outcome alone Toyota implements roughly 90 percent of employee suggestions [8] not because every idea is valuable, but because the company treats participation as the measured output. Most of the implemented suggestions are small. One widely cited example: a plant tour guide asked for a hook to hang her bag on during stops. The hook went in that week. The implementation was essentially free. The signal — your idea gets taken seriously — kept the system running for more than seven decades. Organizations that demand ROI justification on every suggestion cap themselves at the suggestions they can predict. -- 5 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 6 These five conditions are well documented. What the literature covers less carefully is that they do not maintain themselves. They depend on behavior by a specific layer of the organization. -- 6 of 22 -- › Managing up, managing down, and the innovation paradox › › › 02 Failure modes How senior managers break the conditions © 2026 lateralworks Page 7 Every one of the five conditions depends on what senior managers do routinely. Sequence requires a manager who does not respond to new work with premature critique. Separation requires a manager who can offer advisory feedback without resolving it into a mandate. Ritual requires a manager who meets with the team on a rhythm that makes hard conversations normal. Protection requires a manager willing to absorb short-term pressure rather than pass it downward. Process reward requires a manager who signals, through attention and resources, that the act of contributing is valued. When this layer behaves well, the innovation environment holds. When it fails, no organizational policy survives. A company can publish a 20-percent-time policy, install a Braintrust, adopt Working Backwards templates, and see every one of them converge to theater within a year if the senior managers immediately around the work are not maintaining the underlying conditions. Two failure modes dominate. They are not equally common in every organization, and they are not equally visible. They damage the innovation environment in different ways. -- 7 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 8 Failure mode one The manager who over-invests in managing up This manager treats the relationship with senior leadership as the primary product. Their calendar is dominated by time spent with people above them: exec meetings, skip-level one-on-ones, strategy offsites, peer coalitions. One-on-ones with direct reports get rescheduled or delegated. They answer executive email fast and their own team slowly. They invest heavily in how work is framed upward. Decks are polished, status reports optimistic, messaging in all-hands carefully managed. Problems get softened; wins get personally associated. Over time, the gap widens between what leadership believes about the team and what is actually happening. Strategic context flows up and stops at them. They hoard organizational intelligence as personal currency with executives, and the team operates with a partial view of direction, priorities, and politics. When context does reach the team, it arrives filtered through whatever framing makes the manager look prescient. Herminia Ibarra’s work on political skill treats upward-facing effort as a legitimate senior-leadership capability rather than an inherent defect [9]. The failure here is not political fluency. It is political fluency that has consumed everything else. Work done by direct reports is presented in executive settings in a first-person plural that quietly becomes singular. When a direct report drives an outcome, the manager frames it as their own strategic call that the contributor executed on. When things go wrong, the explanation finds its way to someone beneath them. They hire for narrative reinforcement. They tolerate weak performers who are loyal. They lose the people who want substantive leadership, often without understanding why, because the exit interviews get filtered too. For innovation specifically, this manager is structurally incompatible with the protection condition. A manager whose upward narrative depends on being the broker of their team’s work cannot protect a space that produces work they cannot broker. If a direct report develops an idea outside the manager’s framing, the manager has two options: absorb the work into the framing, and deny credit to the originator; or suppress the work, and preserve the framing. Neither serves the organization. Both serve the manager. -- 8 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 9 Failure mode two The manager who over-invests in managing down The opposite archetype is less politically visible and just as damaging. They are deep in the operational weeds: present in every design review, running the hard technical problem-solving themselves, protective of the team to the point of isolation. Their calendar is full of one-on-ones and team syncs and thin on executive exposure. They know their team’s work in detail but cannot describe, in a single paragraph, how that work connects to the company’s top three strategic priorities. The failure modes feel virtuous from the inside. The team drifts from company direction because the manager is not in the rooms where direction gets shaped. Their strong work is invisible to leadership, so budget and headcount decisions go against them by default. The manager becomes a single point of failure on hard problems because they solve personally rather than scaling problem-solving through the team, which caps growth at their own throughput. Their career stalls, and the team’s trajectory stalls with it. For innovation, this manager fails differently. The team may be psychologically safe — this manager protects it — but the team’s ideas never reach the rooms where resources flow. A good idea that stays inside a manager’s team is a good idea the company does not get. Over a long horizon, this manager produces teams whose best work is, functionally, invisible. How this plays out in performance The consequences split along two axes: which metrics are being measured, and how much time is allowed to pass. Short term, externally observed, the managing-up-heavy manager looks excellent. Executives rate them highly. Promotions come early. Visible projects flow to them. The managing-down-heavy manager looks adequate or underrated because their value shows up in team outcomes that are hard to attribute individually. Over a longer horizon, the picture inverts. The managing-up-heavy manager’s team decays: top-performer attrition, burnout among those who stay, missed commitments once the narrative can no longer outrun reality, a brittle knowledge base because no one invested in development. The managing-down-heavy manager’s team is operationally strong but strategically stranded. When the reorg comes, the team takes disproportionate damage despite doing good work. -- 9 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 10 Aggregate effect What the org actually loses The organizational damage sits with the managing-up pattern. It degrades the quality of information the executive layer uses to make decisions. When many managers optimize for narrative over honesty, the C-suite ends up flying on instruments it cannot trust. Real risks surface late as crises rather than early as warnings. Recent research by Hagen and Zhao on middle-manager psychological safety finds that this layer reports the lowest safety scores in most organizations, below the executives above or the front line below [10]. The cascade is not accidental. The managers most incentivized to perform upward are also the ones most accountable in both directions, and they are the first to learn that honest reporting carries a personal cost. For the manager personally, the reckoning arrives in one of three ways. They move before the narrative-reality gap collapses and carry their reputation to a new employer. They get caught by a visible failure and the executive trust that protected them evaporates. Or they plateau at a level where the next promotion requires demonstrable team-building, a capability they never developed, and their reputation turns out to be thinner than it looked, a pattern McCall and Lombardo documented as a leading cause of senior-executive derailment [11]. For the organization, the reckoning is slower and more expensive. The innovations that would have come from empowered teams never appear. The capable people who would have led those teams leave for organizations whose senior managers amplify their work rather than compete with it. Attrition rises. Executive leadership frames the attrition as compensation, or culture, or onboarding, when the actual cause is structural: the organization’s revealed policy on initiative, communicated through the promotion and retention decisions its senior managers have been making for years, is that initiative is a risk. What good looks like The senior managers who perform well over a long horizon do both, and they do them in service of each other. They manage up to secure cover, resources, strategic alignment, and honest air-time for the real state of the work. They manage down to develop people, produce outcomes, and surface the reality that makes their upward reporting trustworthy. Credibility upward is earned by delivering downward. The ability to deliver downward is enabled by the political cover secured upward. For innovation, these managers maintain the five conditions actively. They sequence encouragement before scrutiny in their own interactions with their teams. They separate the idea from the evaluation in their own feedback. They make feedback a rhythm. They protect the space for exploration even when it produces work that falls outside their framing. They reward the act of contributing, not just the outcome. The test question for any senior manager is uncomfortable. If my direct reports and my skip-level manager described my performance in the same room, would their accounts be recognizable as the same person? When the accounts diverge sharply, the manager is over-invested in one direction, and the direction of the divergence tells you which one. -- 10 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 11 Implication The leader’s decision Every senior manager is making this call every week, whether they name it or not. Every staffing decision, every decision about which idea gets resources and which gets “needed in your current role,” every decision about whose work to broker upward and whose to leave at the local layer, is a choice about which failure mode to tolerate. The organization’s innovation pipeline is the sum of these choices across the senior-management layer over time. The appendix that follows is a specific, recent instance of these choices going the wrong way. The case is representative, not anomalous, and it is what the failure mode looks like when you can see the person it happened to. Three signals make this case worth reading carefully. First, the work in question is not a marginal contribution — it is exactly the kind of AI-enabled, fast-cycle output the company has publicly committed to enabling. Second, the failure spans every senior layer that touched the work, from the immediate manager up to the CEO. Third, the failure is mechanical, not malicious: each individual decision is locally defensible, and the aggregate is the organization revealing what it actually values when initiative shows up unannounced. The case is what the aggregate attrition data in many companies looks like when you zoom in far enough to see a person. -- 11 of 22 -- Failure mode The revealed policy “Innovation and personal initiative are not rewarded here. Stay in your sandbox. Wait to be told.” Director-level leader, technology firm Quoted in Appendix A © 2026 lateralworks Page 12 -- 12 of 22 -- › Managing up, managing down, and the innovation paradox › › › A Appendix A A representative case study © 2026 lateralworks Page 13 Names, products, and sector-identifying details have been removed. The company is a well-known technology firm: successful, profitable, with a dominant share of its vertical market. During the period described below it was experiencing unusual attrition and executive leadership was cycling through explanations. First compensation. Then culture. Then onboarding. None of those framings changed the trajectory. The setup The company had spent roughly three years trying to solve a persistent commercial problem. Customers were buying the platform but were not adopting it at the rate the renewal and expansion model required. Hardware worked. Contracts were signed. The operational chain from purchased capability to routine daily use had a gap that internal teams had repeatedly failed to close. The conventional proposal, the one the organization had been circling for most of the three years, was a new engagement playbook executed by a substantially expanded customer-engagement organization. The headcount math assumed hiring a cohort of expensive senior engagement specialists distributed across the country’s major markets. The OPEX increase would be significant. This had become a recurring issue at the executive level: the CEO had been complaining for months about cost growth in the customer organization, which was already running heavy. No alternative had been produced. Into this, the company hired a director-level leader with a broad, loosely specified charter that amounted to fix adoption. He reported to a senior vice president running a major customer-facing function. That vice president reported, in turn, to the executive who ran the entire customer organization. Both were established, long-tenured operators. Neither had a background in the kind of work the new director was about to do. -- 13 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 14 Case study What the director did Within his first several weeks he performed the gap analysis the company had never performed in three years. The root cause was not training quality, product design, or account management discipline. The company was failing at a much earlier step: it did not reliably know which external parties should be receiving the platform’s outputs in the first place. The coordination chain had a hole at step one, and everything downstream was compensating for it badly. He then did something almost no one at a company of this profile does. On his own initiative, without asking and without being asked, he spent his weekends learning agentic AI development tools. No manager assigned the learning. No program funded it. He used the time to build two production-grade applications that replaced a manual research process, roughly ten hours of analyst time per customer location, with an automated system that returned the same answer in seconds, at national scale. The two applications together delivered, in weeks of nights-and-weekends effort, what the company’s own internal estimates had scoped as a team-of-ten project requiring several months and hundreds of thousands of dollars of engineering investment. He went further. Having studied a twenty-year-old online community built by a large public technology company for its own technical end-user base, a community still active today and widely cited as a model of community-driven customer engagement, he designed, built, and deployed a full-stack branded community platform for his own company’s end-user constituency. Role-based onboarding, moderated forums, a searchable knowledge base, gamification, staff dashboards. Working prototype. Live. Seeded with content. Same nights-and-weekends model. “No one told me to do this. I did it on my own, on weekends, because the problem needed to be solved.” The combined approach replaced the hiring-heavy plan the organization had been assuming. Instead of a distributed field team of senior engagement specialists spread across the country, the model required a handful of community managers running forums and generating platform content at the center. The cost structure was an order of magnitude lower. The capacity to scale nationally was higher. The director solved the adoption problem he had been hired to solve, and quietly solved the OPEX problem the CEO had been complaining about since the project began. The second problem had never been his to solve. He solved it anyway. -- 14 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 15 Case study The reaction from above The director’s immediate manager and that manager’s manager did not understand the technology he was using. Neither had asked for agentic AI. Neither had asked for a community platform. The work was visible, it was working, and it was not theirs to broker upward. It had outrun their narrative. They did not stop him. Stopping him was no longer safe: the CEO had seen the output, was enthusiastic, and was using it in her own conversations. The two managers did something more revealing. They tolerated the work while maintaining their organizational framing that the director’s real job was the narrower customer-adoption role they had scoped for him. They praised the innovation in the room with the CEO. They made clear, in rooms without her, that this was not what they needed him to focus on going forward. Re-read the first failure mode in this paper. The calendar dominated by upward time. The framing polished for executives. The work of direct reports absorbed into first-person-plural phrasing that resolves, at the executive layer, as the manager’s own strategic call. This is that failure mode in a concrete instance, acting on a specific innovative employee in real time. What the two managers did, mechanically The two intervening managers tolerated the work because they could not safely stop it. The CEO had seen the output and was using it. But the tolerance was strictly above the line. Below the line, in their own rooms, both managers continued to define the director’s job as the narrow customer-adoption role they had originally scoped, and continued to position his AI work as a personal interest rather than a strategic contribution. This is the textbook signal: the work is fine while the CEO is watching, and not what we need going forward when she is not. Employees calibrate to the second framing, not the first. The structural consequence is invisible until it shows up in the aggregate. The director’s individual case is a single data point. The company has many directors and senior managers. Each instance of this pattern — work tolerated upward, suppressed laterally — sends the same signal to the rest of the organization. Over a quarter or two it accumulates into a culture where bringing forward unsanctioned work is understood to be a personal cost the contributor absorbs alone, and not a path to recognition. -- 15 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 16 Compromise The promotion that was, and then was not, and then was something else The CEO made a decision. The company needed an AI-native leader to carry this work across the organization, and the director had just demonstrated that he could be that leader. She contacted him directly, without routing through the two intervening managers, to tell him he was being considered for a new senior role. A new function. Reporting outside the customer organization. A significant promotion. The director was, by his own account, genuinely excited. The conversation lasted roughly twenty-five minutes. He notified his immediate manager shortly afterward as a professional courtesy and received what seemed like cautious support. The next day, the head of the customer organization killed the promotion. His stated reason was that the director was “needed in his current role.” The CEO, whose original instinct had been correct, did not let the kill stand cleanly. She intervened a second time and proposed what she framed as a compromise. The director would take on the new AI work at twenty percent of his time while continuing his existing customer-organization role at the other eighty. A title adjustment for the twenty percent portion was floated: a director-of-product slot under the product VP, contingent on cross-functional negotiation. A backfill requisition would open for his existing role. The director would lead the search for his own replacement. Once a successor was hired and ramped, he could move to the new role full-time. In the abstract, this was a reasonable bridge. In practice, the structure of the offer, stripped of its language, was simpler than its presentation: do two jobs for the pay of one, and we will revisit whether you can have just one of them later. No salary adjustment. No formal title at the senior level that had originally been described. The compensation for taking on a corporate-wide AI portfolio was the implicit promise of a real role to come, contingent on a backfill process the director himself was being asked to drive. The original promotion had been a recognition. The compromise was a workload increase wrapped in transition language. The director accepted. Declining was not safer than accepting. The same senior managers who had just killed the original offer were the people he would have to face if he turned down the second one. The CEO had personally championed the path. The risk of being seen to refuse opportunity outweighed the visible cost of the workload, and the AI work was where the company actually needed leadership. He took the deal. -- 16 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 17 Platform The platform gets killed The director’s community platform — the second of his two AI builds, the one that had replaced the hiring-heavy plan and resolved the CEO’s standing OPEX concern as a byproduct — was at this point a working prototype. Live. Industry-compliant. SOC2-aware authentication. Already loaded with company content: training videos, customer case studies, white papers, written material from across the organization. Internal teams were using the platform’s gamification mechanics to compete on who could publish the most content. The platform was, by any operational definition, working. The CEO killed it. Her stated reason was that the company could not have a customer-facing product without first running it through the standard internal product engineering process. Specification, design, development, validation, decision gates. The full lifecycle, which inside this company was a year-and-then-some affair. The platform — already built, already deployed, already populated with content, already in active internal use — was to be paused, rewritten through the process, and reapproved at each gate. In nearly every organization, that is how a working product is killed. The replacement plan was for the company to procure a commercial learning management system and graft community functionality onto it later. There was a problem with the plan, which the director tried to surface. The platform he had built was not just an LMS. It was an LMS-and-community hybrid, customized to the specific customer constituency the company served, integrated with the agency identification system he had also built. No commercial product on the market combined the two functions. The off-the-shelf LMS the company was now expected to purchase did one of the two functions and did it generically. Replacing a working, customer-customized hybrid system with a generic single-function tool was not a process improvement. It was a downgrade, and a costly one, paid for in license fees that would persist annually. “Vibe coding” In the conversations leading up to the platform decision, the CEO characterized the director’s work as “vibe coding.” The term has emerged in the past year for casually-prompted, prototype-grade output from AI tools. It is the technical equivalent of calling a finished house a sketch. The director’s own response to that characterization, in a separate written exchange with a senior colleague, is worth quoting close to verbatim: “As juxtaposition to ‘vibe coding’: my builds are full-stack, SOC2-compliant, auth-hardened, production-ready systems. I incorporate elements like the relevant legal frameworks into my build rules and edge-case testing. Current degradation points are at over 50 concurrent user submissions per minute, but most of that is governed by the AWS hosting tier I’m running on and can be modified on expansion. I’d put my builds up against a vendor. I have E&O and Cyber liability insurance, and at this point, two thousand hours in the last twelve months in learning and build time alone.” -- 17 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 18 Second paradox The bureaucracy paradox There is a deeper failure underneath the platform decision. The standard product engineering process the CEO invoked — specification, design, development, validation, decision gates across a year-and-then-some timeline — was built for an era of product development that agentic AI coding is making obsolete. It is the control architecture of slow development. It assumes building the system will take months. It assumes the cost of a wrong commitment is high. It assumes that gates exist to catch errors before they propagate, and that the sequence of expert review at each gate is the company’s defense against expensive rework. Agentic AI coding inverts those assumptions. Building takes weeks. The cost of a wrong commitment is low because rebuilding is cheap. Errors propagate at the speed of iteration, which makes iteration itself the defense against them. The director’s two thousand hours of learning and build time across twelve months were not the production of a single artifact waiting for evaluation. They were the rapid iteration cycle, applied as a working method. Agile development, in its original framing twenty years ago, promised this kind of rapid iteration. In most organizations, including this one, the promise was never fully realized. Control systems were too entrenched. The gates were too consequential. The reviewing layers had too much accountability for outcomes they could not move quickly enough to influence. Agile became, in practice, a vocabulary applied to a slower process rather than a structurally different way of building. Agentic AI coding is the first development methodology that delivers what Agile described. Production-grade code, written quickly, by individual contributors with the right tools, validated continuously rather than at gates. The director was using this methodology and producing in weeks what his company’s traditional process would have produced in eighteen months at a hundredfold the cost. The platform was the proof of the method. It was working. The CEO’s response was to send the working proof of the new method through the gates of the old one. A company that wants AI-driven efficiency but applies pre-AI controls to AI-built work is asking the technology to deliver outcomes the company’s process is designed to prevent. The two cannot coexist. The control system was not designed to govern work of this kind. It was designed to govern multi-year engineering programs run by the company’s existing staff. Forcing AI-enabled output through it does not validate the work. It eliminates the speed advantage that was the entire reason for using AI to do the work. -- 18 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 19 Predicament What the director was actually asked to accept Stack the three decisions together. The director is now being asked to continue performing his existing customer-organization role at full intensity, simultaneously build out a new corporate-wide AI function with no compensation change and no senior-level title, and watch the first serious AI product he built — the one that solved the problem he was hired to solve and incidentally resolved the CEO’s standing OPEX concern — be paused, sent through a year-long review process likely to kill it, and replaced by a less capable commercial alternative. The implicit deal is: take on the additional responsibility, prove yourself in the AI domain, and you will eventually have a real role with real authority. The reality of the deal is: do two jobs for one salary, and watch your existing AI work be discarded by the same leadership chain that is now asking you to commit to more of it. The data the director has on whether the implicit promise will be honored is the organization’s actual treatment of the work he already finished. The message the director received The director’s own summary of the experience is worth quoting, because he stated it plainly and because it generalizes beyond his own case: “Innovation and personal initiative are not rewarded here. Stay in your sandbox. Wait to be told.” That sentence is the company’s actual policy on innovation. Not the policy written in the culture deck. The policy communicated through action at the moment it was tested. Employees calibrate to the revealed policy, not the stated one. The company’s attrition problem, previously characterized as compensation or onboarding or culture, is most accurately characterized as this: capable people are receiving a consistent message that initiative is a career risk, and they are acting on it. -- 19 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 20 Synthesis Why this case matters Three elements of this case map to specific claims in the body of this paper. A fourth surfaces a related but distinct paradox. Together they no longer implicate only the senior-manager layer. The case implicates the executive above it as well, and the broader engineering organization that supports her. The director was punished for doing what he was hired to do, twice. First by the suppression of recognition: two production AI systems, an OPEX resolution that was not in his scope, and the suppression came from the exact layer whose structural function is to enable people like him. Then again, more visibly, by the platform being sent through a lifecycle gate process designed for ideas at a much earlier stage of maturity than this one had reached. The “promotion” was not a promotion. It was a workload increase wrapped in transition language. The compensation for taking on a corporate-wide AI portfolio was the implicit promise of a real role to come, contingent on a backfill process the director was himself being asked to drive. The company secured the additional output without paying for it. Whether or not that was the intent, it is the structure. The executive layer’s failure was not retreat. It was active participation. The CEO did not just decline to override her senior managers on the original offer. She killed the director’s working platform herself, characterizing his production-grade work as “vibe coding” in a way that revealed she did not understand what had been built. The company is structurally unprepared for the technology it has committed to. The CEO has publicly committed to deploying AI across operations. The director showed what that looks like in concrete form: an AI-built system that produced a year-plus result in weeks. The leadership chain’s response was to send the result through the gate process designed for multi-year programs run by the existing engineering organization. The control system cannot govern the development methodology AI enables, because the control system was designed for the methodology AI replaces. The test question, applied If the director’s direct description of his performance and his manager’s description of his performance were read in the same room, would they be recognizable as the same person? They would not. The director would describe an employee who identified and solved a three-year-old commercial problem through self-directed learning and nights-and-weekends execution, resolved a standing executive cost concern as a byproduct, and shipped a production-grade hybrid platform that no commercial alternative replaces. His manager would describe a valuable individual contributor who is needed in his current role and whose side projects, while interesting, should not distract him from his primary responsibilities. Both accounts are internally coherent. Only one is honest about what actually happened. The direction of the divergence — from transformational downward to useful contributor upward — tells you which failure mode is operating here. The pattern is the policy. -- 20 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 21 Reader questions What the case raises This case is presented without a resolution. The director, at the time of writing, has not yet made his decision. The questions below are the ones the case raises for any leader, manager, or contributor who recognizes the pattern in their own organization. What should the director do? Accept the workload-doubling and bet on the implicit promise? Decline and accept the cost to his standing? Stay and continue building, knowing the next AI product he ships may meet the same fate as the last one? The honest answer depends on factors outside the scope of this paper: his financial position, his professional reputation, his appetite for risk, the strength of his outside options. What the case foregrounds is that none of those personal factors should be load-bearing here. A company that has just demonstrated it cannot reliably distinguish a working production system from a casual prototype is asking him to bet his next two years on the assumption that the next decision will go differently. What did this company do wrong? The failure is not at one layer. The senior managers killed the original offer. The CEO retreated, then negotiated a compromise that doubled the workload without changing the title or compensation. The CEO then killed the platform itself. Each decision is defensible in isolation. Each is consistent with how the company has historically managed risk. The pattern is what the company did wrong: the consistent signal, sent through actions taken at moments that mattered, that initiative will be tolerated but not enabled. Why is attrition a problem at this company? Executive leadership has framed it, in turn, as compensation, culture, and onboarding. None of those framings have changed the trajectory because none of them is the actual cause. The case suggests a different frame. The company is losing people because its revealed policy — the policy communicated through the promotion and platform decisions reviewed in this case — is that exceptional contribution is met with workload increase rather than compensation, and that exceptional work is met with process delay rather than deployment. People who can produce exceptional work are also people with options. They calibrate quickly, and they leave. What did the CEO miss? The opportunity in the director’s work was not the AI tools, and not even the OPEX resolution that came with them. The opportunity was the demonstration that the company already had, on its current payroll, a leader capable of moving faster on AI than anyone she could plausibly hire externally. The cost of the misunderstanding she signaled with “vibe coding” was not the platform, which can be rebuilt elsewhere by someone else with more patience. The cost was the message every other capable employee at the company received about what kind of work this company is actually willing to value when the work shows up. That message will continue to compound. The director’s case is one data point. The aggregate is the attrition number the company has been trying to explain. -- 21 of 22 -- › Managing up, managing down, and the innovation paradox › › › © 2026 lateralworks Page 22 Sources References [1] Detert, J. R., and Edmondson, A. C. "Implicit Voice Theories: Taken-for-Granted Rules of Self-Censorship at Work." Academy of Management Journal, Vol. 54, No. 3, June 2011, pp. 461–488. [2] Edmondson, A. C. The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth. Wiley, 2019. [3] Morrison, E. W., and Milliken, F. J. "Organizational Silence: A Barrier to Change and Development in a Pluralistic World." Academy of Management Review, Vol. 25, No. 4, 2000, pp. 706–725. [4] Google re:Work. "Guide: Understand Team Effectiveness" (Project Aristotle). rework.withgoogle.com. [5] Page, L., and Brin, S. "Letter from the Founders: An Owner’s Manual for Google’s Shareholders." Google IPO filing, 2004. [6] Bryar, C., and Carr, B. Working Backwards: Insights, Stories, and Secrets from Inside Amazon. St. Martin’s Press, 2021. [7] Catmull, E., and Wallace, A. Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration. Random House, 2014. [8] Liker, J. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer. McGraw-Hill, 2004. [9] Ibarra, H. Act Like a Leader, Think Like a Leader. Harvard Business Review Press, 2015. [10] Hagen, J. U., and Zhao, B. "Middle Managers Feel the Least Psychological Safety at Work." Harvard Business Review, October 2025. https://hbr.org/2025/10/middle-managers-feel-the-least-psychological-safety-at-work [11] McCall, M. W., Jr., and Lombardo, M. M. "Off the Track: Why and How Successful Executives Get Derailed." Center for Creative Leadership, Technical Report No. 21, 1983. -- 22 of 22 --

Innovation·Synthesis paper

Managing up, managing down, and the innovation paradox

Why senior-manager failure modes kill the innovation their organizations depend on

Core thesis. Innovation needs encouragement before scrutiny, but most organizations evaluate too early and kill fragile ideas. Senior managers either over-invest in managing up (optimizing the upward narrative) or over-invest in managing down (deep in operational weeds). Both break the protection-from-above the innovation environment depends on.

April 26, 2026·22 pages

View PDF →Download

FTTM Product Development Best Practices lateralworks > -- 1 of 101 -- Document Revision, 2018.002 Initiated in Silicon Valley in the early 1990’s, lateralworks Fast-Time-to-Market (FTTM) Practices are based on an ongoing worldwide study into the drivers of new product development success. © lateralworks. All rights reserved. This document is copyrighted and all rights are reserved. This document may not, in whole or in part, be copied, photocopied, reproduced, translated or reduced by electronic method or machine readable form without prior consent in writing from lateralworks. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 2 -- 2 of 101 -- Table of Contents Introduction 5 Framework 7 How to use this document 9 New Product Development Best Practices 10 1.0 Mindset 10 1.1 Grasp enormous financial impact late products have on profitability and growth 10 1.2 Create fast culture through close-in oversight of product roadmap 12 1.3 Systematically dismantle slow structures 16 1.4 Accelerate the threshold of pain; reward early warning behavior 19 1.5 Fast decision-making system 22 1.6 Cost-of-delay is understood at individual contributor level; used to drive urgency 25 2.0 Host 27 2.1 Fuzzy-front-end is managed 27 2.2 Projects are prioritized based on business objectives 29 2.3 Projects continuously aligned with resources and skills available 32 2.4 New products are tracked to break-even 34 2.5 Kill projects that fail to meet objectives; early 36 2.6 Fast development framework 38 2.7 Provision teams, eliminate interrupts 40 2.8 Cross-functional core teams (heavyweight & dedicated) 43 2.9 Project-based performance measurement 49 2.10 Freedom Level 1 empowerment 52 3.0 Team 55 3.1 Co-develop with tier 1 customers; continuously refine requirements 55 3.2 Schedule as a driver vs. reporter 56 3.3 Translate customer requirements to product definition, reconfirm throughout development 58 3.4 Know what they value, when they want it, how much they will pay for it 59 3.5 Understand customer wants vs hows; prioritize the drivers that maximize customer satisfaction 60 3.6 Start design while refining requirements; never freeze specs 61 3.7 Fail-Fast; integrate/proto early, frequent & many do-it-try-it-fix-it learning cycles 63 3.8 Cross Functional Core Team ROLES not FUNCTIONS; lateralized 67 3.9 Get best people; mix of inside & external SMEs; virtual teams 71 3.10 Aggressive planning 74 3.11 Macro-micro planning; micro near, macro far, short interval scheduling 77 3.12 Team planning, simulation, continuous scrubbing, breakdown, ownership 80 3.13 Market/customer driven versus resource constrained 82 3.14 Know the gap; drives before-the-fact urgency 85 3.15 Refresh Planning; continuous schedule pull-in 88 ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 3 -- 3 of 101 -- Appendix 91 Start of the best practice study project (background) 91 Methodology for initial FTTM Best of Practices Study 94 Glossary of Terms (unique terminology used by fast teams) 96 Practice Framework Matrix 99 ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 4 -- 4 of 101 -- Introduction This document outlines some of the FTTM Best Practices (Fast-Time-to-Market), first researched by lateralworks in the early 1990’s, through an extensive multi-company study of over 500 people involved in fast-to-market projects in Silicon Valley. lateralworks has engaged with hundreds of teams trying to accelerate the delivery of new technology products to market, and continues to study fast team practices through its international consulting practice. Each engagement builds on the research database in terms of both changing practices and deployment tactics. Host…the organization outside of the project team, that provides resources, support and guidance; the “functional management hierarchy.” The host can “provision” and “interrupt” teams; it can create the conditions for success or failure of development projects. Fast organizations focus on rapid provisioning and interrupt removal. FTTM outcomes are a function of two inputs; 1) the behavior of the team and 2) the environment within which the team operates. Individual project teams can achieve fast cycle time results, often at the detriment to other projects (by stealing resources). The portfolio of projects will therefore remain slow if the environment within which the teams operate is not oriented to help teams move faster. FTTM Best Practices Framework; the provisioning Host, a set of practices organized around Mindset, Environment, and Portfolio ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 5 -- 5 of 101 -- Senior management must create the right environment through specific behaviors and mindset, a fast development framework, lateral organization structures, and fast decision-making systems. It is easy to make one project go fast at the expense of others, so the challenge is to balance the portfolio so the highest value projects get the resources they need in order to get to market quickly. The “FTTM System” is designed to deliver the right products (what customers want and value) at the right time. We call this environment the “Host” environment. In fast corporate cultures, the Host empowers heavyweight teams, removes interrupts, and provisions teams so they can be successful. In normal/slow corporate environments the Host tends to interrupt teams by not providing the resources when needed, filling the pipeline with more projects than there are resources to get them done in a timely manner, not developing “bench strength” of skills needed to create the technology, and controlling cost (at all costs) without understanding its economic impact on speed (i.e. arriving to market late). In short… provision teams for success, eliminate the interrupts. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 6 -- 6 of 101 -- Framework Best Practices based on lateralworks ongoing research project into the best practices of fast teams. The study was initiated in 1990 and continues today, with new ideas and insights being added through client consulting engagements around the world. Both the practices and the deployment tactics have evolved through continuous improvement, cultural adaptation, and changing collaboration technology. Best Practices broadly fall into three categories: Mindset, Host, and Team (horizontal axis). Down the vertical columns is a second classification; Portfolio, Environment, and Execution. For example; “2.1 Fuzzy-front-end is managed” is a practice performed by the Host that relates to the portfolio planning and management process. Most of the Portfolio practices are owned by the Host, with the exception of “3.1 Co-develop with tier 1 customers; continuously refine requirements” which belongs to the Team, but it relates to how the Portfolio is managed. One could argue for a different classification of some of the practices, as they could fall in multiple locations on the matrix. We chose this configuration (above), but what is more important is that there are mindset, host and team practices we observed that enabled the right products to get to market at the right time. Overriding these practices was a corporate “mindset” that speed was the most critical asset of the company, and this mindset was understood by the leadership team and practiced consistently. They didn’t just say it, they did it. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 7 -- 7 of 101 -- In the following pages, we will generally describe the practices that make up each category using a contrasting technique to accentuate the differences in terms of “normal” (or the typical team/corporate environment) and “best” in class. Although it may seem as though we are exaggerating at times, all of the “normal” conditions we write about are observed in real world situations. Each new project generates more live examples. Few companies follow all the “best” practices, but a lot of them follow many of the practices described as “normal,” and they also considered it normal to behave this way. The difference between “normal” and “best” separated the fast from the slow teams/companies. When we speak about speed, we always mean “right product delivered at the right time.” FTTM is not just being fast, but also delivering what customers want and value at a given point in time. Balancing this equation is very hard; on time with the right product, not a de-featured or technically compromised (in order to get it out the door on time) product. Going fast is relatively easy when product functionality or quality is compromised (i.e. traded-off), but what the best in class teams do is to deliver what customers want, when they want it. This requires knowing what they want (listening to them), being flexible enough to adapt as their requirements change (when they find out they are not sure about what they want), and then being able to execute on aggressive timelines through continuously pulling-in (accelerating) the schedule. They did this by continuously changing the product and continuously changing the schedule. This is counterintuitive as one would expect that the way to solve the problem would be to fix as many of the variables as possible. When teams fixed the spec and fixed the date, they almost always failed - missing both by wide margins. Why? Because nothing is fixed and everything is always changing, especially when it comes to technology development. On the contrary, fast teams kept the product definition fluid and the schedule fluid, always adapting them to the dynamic conditions of ever changing cutting edge technology development. The practices outlined in this document describe how they did/do it - how they execute using counterintuitive thinking. To understand why this is counterintuitive thinking is to really understand the best practices. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 8 -- 8 of 101 -- How to use this document This document was designed as a reference guide for teams and organizations implementing new product development improvement programs. Typically, organizations select a few of the practices to implement with multiple project teams. They select the practices that they feel they need to improve. The first step is to identify what the practice is (in your context) and secondly to determine how it might be adapted to fit the culture and the specific project conditions. These are not plug-n- play practices. They need to be adapted and modified for each environment. Rather, these are more guidelines than how-to instructions. This document does not have to be read front to back. Rather, the reader can select specific practices based on interest. Each best practice requires a chapter in a book to fully describe. We have simply summarized them in this document. It turns out that after 25+ years of implementing these best practices the deployment technique tends to be the key factor in determining success. To know and understand a practice versus to actually apply it are two very different actions. The later being much harder. Further, how it is deployed is as important as understanding the practice itself, because each practice must be adapted to the local culture, team skill levels, and readiness of people and organizations to try new ways of working. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 9 -- 9 of 101 -- New Product Development Best Practices 1.0 Mindset 1.1 Grasp enormous financial impact late products have on profitability and growth Summary Best product organizations recognize the cost of being late to market, and for every day saved, there is an enormous leverage on profit. Maintaining or pulling in the new product development schedule is therefore the highest priority and has a high profile within the company. Normally, to "make schedule king" and to get to market on time would require a significant, perhaps unacceptable, trade-off to quality and/or costs. Normal In order to be faster, something has to be sacrificed. "You don't get something for nothing.” Five development objectives are involved in possible trade-off decisions: feature quality, defect quality, development cost, product cost and TTM. To go faster, quality or cost must be sacrificed. Making schedule king means building a product with less performance or fewer features, or it means "blowing" the development budget. Management accepts the inevitability of schedule re-plans, and is complicit in permitting the schedule to slip. Management demands schedule reductions to hit target as if they can be achieved by mandate. Best Top management articulates the need for speed. They know that reducing time-to-market (TTM) has a huge impact on profitability over the lifetime of the product. They know that for every day ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 10 -- 10 of 101 -- saved, there is an enormous leverage on profit because the revenue to recover the additional development cost is earned sooner. The leverage is so high that you can "pay to save a day" and you will “more than earn it back.” Top management can communicate the economics of delay to the teams, and they know that saving TTM exerts more leverage on ROI than reducing development cost or product cost. Top management leads with "speed"; it makes schedule king. They use schedule compliance (managing the project using the schedule) to lead product teams to find and eliminate “wasted” time. Making the schedule king means never slipping the schedule, of if they do, they find easy to recover in order to stay “on time”. Since there is so much wasted time in the total TTM cycle, the best organizations continually challenge the product development teams to find and remove “slack". Top management supports their actions, and together they prevent or recover slippage. Making “schedule king” works because gestation (the period of time between first product concept and full team formation) and overruns (the period of time after the target market entry date for the product is missed) alone involve about 80% of the wasted time in new product development cycles, most of which is waiting. A high proportion of the development schedule is also waiting. Making the schedule king means permitting no "macro" schedule slippage; however the "micro" schedule may move in and out. If there is a trend of macro slips, the project is assessed and killed if a recovery plan cannot be put in place to pull in the schedule, thereby freeing resources for projects with a greater success potential. These decisions are made quickly and before the “point of no return” on the troubled projects. Mistakes are quickly converted to opportunities when discovered in time. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 11 -- 11 of 101 -- 1.2 Create fast culture through close-in oversight of product roadmap Summary Best product organizations have a single point of ownership and responsibility for all product planning decisions. They dedicate a cross-discipline team to develop rapid feasibility studies, and use fast prototyping when needed to validate paper assumptions. The process is simple and everyone knows who owns each step of the process, including those who are “Recommenders,” those that must “Agree,” the “Input” providers, the “Decision-Maker,” and who is “Responsible” for performing/executing decisions. The planning cycle is refreshed every month, it is fluid, and it is designed to make quick adjustments based on external conditions. It is driven by customer input and not internal “experts.” There is a constant feedback mechanism to understand failure, perform failure analysis, and to make upstream corrections based on this learning. Normal product organizations have no single person or entity who owns or is responsible for product planning. The responsibility is diffused throughout the organization between marketing and engineering functions, and across levels of business units and management hierarchy. The process (if defined) is complex and time consuming, requiring lots of man-hours to gather the data that few understand or even use in the decision-making process. In the end, no one is responsible, leaving final decisions up to the CEO who becomes the tie breaker. They usually lack sufficient information to make informed decisions and defaults to quick “gut” or intuitive decisions. The people that make the most noise or have the most political influence get their projects approved. People complain that the process is broken, but they secretly like the broken system because when things go bad, it is impossible to isolate blame or the causes of the failures since no single person or group is responsible. Normal The new product roadmap (or product portfolio) is shared between various functions in the organization. Marketing “owns” the product planning activity, but tends to operate unilaterally. Engineering’s role is to vet the ideas generated by marketing, but rarely are conflicts resolved. For the most part, both organizations operate on their own and in an adversarial environment of negotiation and bargaining. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 12 -- 12 of 101 -- Marketing has learned to ask for more than they need, while Engineering tends to under-commit in order to preserve a buffer to account for the technically unknown. Operations and Finance are not involved in product planning decisions. Marketing tends to drive roadmap planning with little contact or input from key customers, because they understand customer needs, technology trends, and the competitive landscape better than their customers or competitors. Further, it is believed that customers are not a good source of future innovation ideas, since they don’t know what they don’t know, which is another reason they’re input is somewhat discounted. When Engineering is involved in planning, they do not push back on the product requirements produced by Marketing because they know that any resistance is a waste of time and in the end, they know that they (Engineering) control what features and functions that eventually make it into the product. Marketing defines best-case requirements and they increase them to be safe to make the product easier to sell. All features, functions, and use-cases across all segments are expected to be developed (just to be safe), and little if any product functionality is prioritized to determine what is above and below the line of what is really needed. The cost-benefit value of each feature is rarely studied (yet alone understood), so all features are considered critical to the product’s success. The conflict and misalignment between Engineering and Marketing is rarely resolved. Both operate with a “different set of books.” Rarely does Marketing perform Voice-of-the- Customer (VOC) with the customer to understand what the customer’s driving requirements are and why. Product Planning is done on an annual basis through long drawn out data-gathering efforts by many people with few refreshes or changes between cycles, because the effort to get the data is so difficult and time consuming. The data tends to be dated/inaccurate due to the long gathering and analysis cycle. Decision-making defaults to “exactly wrong” instead of “roughly right” in an effort to get the “right data,” which everyone knows is based on assumptions and imprecise predictions of the future. If changes in market, customer, and/or competitive forces occur between cycles, little can be done to change the roadmap which is set in stone. Any changes have to wait. Product planning decisions are eventually rolled up through the hierarchy to the executive staff level of the corporation. These are presented as “the plan” and then “signed-off” by senior management with little (if any) input due to the complexity of the presentations and mounds of supporting data. Executive management assumes that the people below them know what they are doing, the people below assume the CEO knows what they are doing. Products are added, few are removed, no one checks to see if the Engineering organization has the skills and resources to complete the concurrent projects. This bottoms-up process is ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 13 -- 13 of 101 -- complex and full of data steps in terms of MRDs, complex business cases, intricate technology roadmaps and competitive analysis. Hundreds of slides in PowerPoint are created consuming many hours of work. Top management is not able to dig into the details of the planning since the layers of management are not really connected. Rarely is the product roadmap presented as an aggregate plan, but instead is discussed as individual products or technologies, specific market segments, or by business unit where nobody can see the macro-level implication of the decisions. It is expected that senior management understands the confusing and complex data presented, but most of the time they don’t and don’t say anything. The sign-off process is complicated and it is hard to identify a single source/focus for decision- making, and therefore ownership for the product planning decisions are diffused throughout the organization. People complain that the process is complex and lacks lateral synchronization between the functions, yet no one can change it because there is no one person to go to, and they all know that the lack of a single point responsibility makes it easier to avoid criticism if/ when product planning decisions result in failed products coming to market, e.g. late to market, low/no margin, not what customers wanted, etc. The organization lacks a cross-functional product planning body and a single executive who is responsible for product planning across the company. At the end of the day, that responsibility rolls up to the CEO, but is quickly pushed back to the operating business unit executives, and they push it back down into the functions below them. The “hot potato” ownership game continues to cycle up and down the hierarchy. Best There is a single executive who owns the product planning decisions. Decision-making is lateral, not hierarchical. Data for making product planning decisions is developed iteratively by a cross- functional body comprised of senior people from Marketing, Engineering, Finance, and Operations. Plans are refreshed monthly and includes new competitive and technology trending information in real time. Plans are fluid and subject to change if the cost-benefit can prove that changes will add value. Input for planning is primarily generated from customers and strategic partners, while internal subject matter experts carry less weight. The voice-of-the-customer (VOC) process is streamlined so it is easy to get continuous input from the market place. The decision-making process is simplified. It uses a business planning discipline similar to a new venture start-up model, where the business case, marketing plan, cost-of-delay analysis, prioritized product requirements based on weighted customer requirements, and macro ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 14 -- 14 of 101 -- schedules are developed by dedicated new product concept teams, primarily staffed by Engineering and Marketing leads. Projects are funded in a manner similar to VC funding of start-ups. Teams compete for funding like start-ups compete in capital markets for equity capital. The winners get funded, the rest don’t. The decision-making process is not complex so all people in the organization understand it. The steps fit on one page and everyone understands who is responsible for making the final product planning decisions, who “Recommends” (gathers input, analyzes and makes proposals), who: • Must “Agree” - individuals with veto power and yes-no control of recommendations — exercising the veto triggers a debate between those that must agree, and when this does not work, decisions are escalated to the Decision-Maker “D” • Provides “Input” - the implementation people consulted on a decision • “Decides” - the person with the “D” is the formal decision-maker who is ultimately accountable for the decisions and who has the authority to resolve any impasse in the decision-making process, and commit the organization to action • Should “Perform” once the decisions are made - these are the people that are responsible for execution There is a clear feedback loop to assess failures, so the causes are understood and preventative actions put in place on products earlier in the development life cycle. Failure is seen as a learning opportunity rather than a way to find blame. Differences between what is wanted (customer driven needs) and what can be delivered in the desired time frame are reconciled before the project is funded. If these differences cannot be reconciled, the project is not funded. The resulting product requirements are prioritized based on customer’s needs, and their value is clearly understood. Product planning is continually refreshed and the dynamic roadmap considers both technology trends and product evolution/maturity. Understanding technology directions and product planning are not bifurcated between a Research group and a Development group, but integrated into one iterative system. They understand that one affects the other and they carefully study these interactions to help them predict future product possibilities. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 15 -- 15 of 101 -- 1.3 Systematically dismantle slow structures Summary Best product organizations default to speed over control. They know that the cost of delay of a product far exceeds any additional OPEX costs associated with acceleration. Management systems are designed with this in mind; they identify all the interrupts (lack of resources, lack of timely resources, lack of skills, lack of funding, lack of information, constant strategy changes, etc.) that a development team might experience during the project, and they systematically eliminate them. Normal product organization’s dominant behavior is cost control. Decision-making, authority to spend and project flow is closely governed by heavy phase/gate life cycles. Much time and effort is expended to feed these systems, yet they provide little direct value to the team who is forced to use them. In an effort to control costs, most projects are slowed down, but when it is realized they are late, more money than was budgeted is thrown at them to recover, at which point it is generally too late because there was no early warning system in place. No effort is made to identify the source of systemic interrupts to the teams since these are seen as prudent management practices and “value-added” controls which minimize excessive spending. Further, removing the interrupts would eliminate a perfect source of excuses that people use when they are late. Normal The default behavior is to control the teams, especially their costs. Onerous Phase/Gate development methodologies are institutionalized to control spending. They are primarily designed to flow information vertically up and down the hierarchy and rarely do these control structures help with the lateral flow of information between functions. The logic is that development projects will be stopped at each gate and funding will not be authorized for the next phase of development until certain criteria is fulfilled. The criteria and requirements are published in lengthy documents that only a few people read and even fewer pay any attention to. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 16 -- 16 of 101 -- Elaborate PMOs (Program Management Organizations) are formed to be the gate keepers of the gate check lists. Thousands of man-hours are spent feeding information into the system. The more sophisticated companies implement multi-million dollar PLM (Product Line Management) systems to document and control every aspect of product development. Most of the time, the smart engineers find ways to fake out the system or find ways to work-around it to get through the phase gate and to avoid accountability. Top management feels better because on the surface, product development appear more organized and “automated.” For the most part, the phases are not followed rigorously, nor are gates really gates since teams can easily get wavers (“exceptions”) to pass around or get through the gates. The wavers are rarely reconciled and there is no follow-up system to check that these waved requirements are ever met. Instead of limiting the number of active projects in the pipeline, these control systems end up pushing more and more projects into the system without considering the impact of already overloaded resources. When there are time-to-market problems, executives add more layers of sign-off and approval to further “control” the “out-of-control” spending caused by delayed projects, and accelerating their burn rate during the slipped phase of projects where resources are thrown at the project to get it back on schedule. No one at the top sees the cumulative impact of these slow structures except each of the development teams that run into them every day while they try to get their work done. Best There is a conscious effort to minimize control structures. Fast organizations default to speed over control. They know the cost of delay (lost profit caused by missing market windows) far exceeds any additional OPEX costs associated with acceleration or relaxed controls. Management systems are designed with this in mind. An effort is made to identify all the interrupts that a development might experience during the project (lack of timely resources, lack of skills, lack of funding, lack of information, constant strategy changes, etc.). These interrupts are then eliminated, both systemic recurring interrupts as well as situational interrupts that are specific to a given project. They put in place a process to identify these interrupts and continually eliminate them. The emphasis is on speed and not on control, so approval processes are streamlined and levels of sign off approvals are raised. This permits lower level managers to provision their projects. They have learned that faster sign off and higher levels of spending approval result in faster decisions and end up being more cost effective in the end, since the authority to spend is pushed further down in the organization. People are more accountable and actually spend less. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 17 -- 17 of 101 -- Reporting is by exception. Projects that are within 25% of the target time and budget goals are left alone. The focus is on those exceptions that have deviated significantly from the norm. Business Process Management (BPM) is used to map business processes within and across functions. Once mapped, inefficient steps are eliminated. BPM is horizontally focused to consider end-to-end processes such as product development life cycles. Gates are removed and phases are layered to enable the projects to go faster. They know that gates are never followed anyway, so they use the old gates as check points to assess maturity of the technology being developed, but not as a yes/no or a start/stop constraint. Most controls are pushed down to teams to own rather than pushed up to top management to control. By pushing down the control systems to the teams (e.g. spending), they become more responsible and empowered. They spend less and go faster. Since control systems are designed to make sure people spend less and go faster, the counterintuitive logic of fast organizations is to use lightweight structures to drive decision- making down to the project teams and then hold them accountable for their actions. It is counterintuitive because more freedom implies less control which, in fact, results if faster development because the teams control themselves. Why are start-ups with fewer resources faster than established companies? Because they lack structure designed to control and govern speed. Large fast organizations achieve the best of both worlds; they have the economy of size and the efficiency of being small because they treat each team like an internally funded start-up with fast management structures, low overhead control systems, and authority to decide and act. In addition, like a start-up, these teams are accountable to the shareholders to produce something on time that meets customer/market requirements. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 18 -- 18 of 101 -- 1.4 Accelerate the threshold of pain; reward early warning behavior Summary Best product organizations force the “threshold of pain” to the front-end of development projects. They build management systems that encourage people to identify potential future failures early. They reward them for spotting problems and fixing them before they blow up. The culture is based on failure analysis and learning through this understanding. Teams live by the mantra “The sooner problems are found, the more time we have to fix them.” Transparency is designed into the way teams are managed. Transparency means honesty, honesty and early warning is encouraged and rewarded. Normal product organizations, push the pain later, because pushing pain forward is seen as a career limiting exercise reserved for non-team players. Identifying problems that have yet to happen is negative and can become self-fulfilling. Positive energy and aggressive predictions are the key to future success. Set the bar high and people will rise to the challenge. Failure is to to be avoided at all costs, but when things eventually go “off the rails”, it is easy to hide from accountability in the details of the organizational machination and complex technology churning. Learning from failure is discouraged because failure means someone “screwed up” and will get “beaten up.” Normal Development projects are initiated with great hope and optimism. All failures in the past are put aside because this time it will be different because “we have learned from our mistakes.” Since the atmosphere is positive and buoyant, any dissenting voices are quietly silenced by peer pressure to conform to the prevailing upbeat attitude of top management. People that bring up potential future problems are encouraged to be better “team players” and adopt a “can-do” ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 19 -- 19 of 101 -- sprit. They are told that negative ideas become self-fulfilling, so it is best to see the glass half full and get on with the difficult job at hand. When potential future problems are spotted well in advance, these are ignored because it is viewed as a planning failure to have not seen these at the beginning. Recognizing the potential problem could force the management team to make difficult trade-off decisions sooner than they really want to. It is explained to people that these potential problems may not happen and that if everyone was more positive, perhaps they could cause them not to happen, so there is no need to be forced into difficult choices now. Nothing is done. Eventually, the problems that were identified surface late in the development program when there is little or no time to recover. These have now grown into bigger problems, requiring more time and more money to solve, and the schedule slips. No one is held accountable for the failures because they were “unseen” and “unanticipated”, and if people had performed as planned they would not have happened in the first place. People start pointing fingers as to who’s “fault” it was, trying to locate the blame. Usually the technical problems are sufficiently complex they are easy to hide behind. Everyone blames the difficulties of trying to developed advanced bleeding edge technology because it hasn’t been done before, etc. The culture does not encourage learning, because this means finding the root causes of failure, so that actions can be taken to mitigate future failures. Failure is seen as an unforeseen event that is out of anyone’s individual control. “We are all victims of aggressive schedules and have to accept the problems associated with being on the cutting edge of technology.” In addition, learning means learning cycles, and each learning cycle costs money. To save money, the team crosses their fingers and hopes to get it right first time. Best The “threshold of pain” is forced forward to the front-end of development. There are systems built in to the development methodology that encourage people to identify potential future failures. When these future problems are identified in advance, they are rewarded. The rewards encourage people to look for more potential problems. Learning through failure analysis is part of the culture. Like in any engineering innovation, failure is seen as the fastest way to learn. People are encouraged to “fail faster.” Accelerated failure/ learning is how new technology gets to market faster. Identifying potential future failures and taking actions to mitigate this failure is encouraged by top management. The R&D budget supports the cost of multiple learning cycles. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 20 -- 20 of 101 -- The culture and management metrics are set up to push the pain forward so it can be dealt with early, while there is still time to fix the problems or take mitigative steps to reduce the failure’s impact on the schedule. This positive attitude towards finding future problems sooner than later causes a greater level of transparency and openness in the culture. People are not punished for failure, but rather rewarded for finding and fixing it before it causes too much damage. The learning cycles required are built in to the schedule so it is clear This mindset creates an open and honest product development environment in which realistic information is shared. This realism and early-warning behavior improves decision-making because teams and top management have much better information with which to make those decisions sooner. This ”learning culture” extends to each level of management, so people are more willing to take risks because the fear of failure is minimized if they are able to identify problems sooner and correct them. In the end, higher risk usually means faster development results. Risk, failure/learn cycles, and early warning are designed into the management system in fast companies. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 21 -- 21 of 101 -- 1.5 Fast decision-making system Summary Best product organizations promote and work in an environment where decisions are made quickly. They have an overall understanding of the business direction and technology policy. Fast decision-making procedures or forums are available that will provide fast guidance when issues surface that may impact the team's schedule. The concept of "defaulting to action" is the norm. Normal product organizations - critical decisions affecting the product team's schedule need approval by upper management. Teams lack an overall understanding of the business direction and technology policy. They don't proactively seek a "default to action" operating mode and assume it would be risky, so the default behavior is to wait for decisions or generate more data, or do both. Normal Project gestation (the period between idea and team full core team formation) often takes as long as the development itself. Lack of clarity in business direction and technology policy slows down product positioning. Senior management or staff respond slowly to product team requests for direction or approval. The development budget is over committed by a factor of two or three times, but this is not visible. The lack of limited resources become a reason for delay and slow action. Best The product team accepts responsibility for controlling its own destiny. The product team members consider it their task to be responsible for business development ("that's the way the market looks at it and so do they"); product positioning means positioning a complete business relative to the competition and relative to the company's portfolio of product businesses; the team emphasizes overall business success from the start (e.g. Break-Even-Time and/or Return- on-Investment). ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 22 -- 22 of 101 -- Development acts like a start-up and takes the initiative to get a coherent and compelling business concept; gets executive commitment; doesn't wait; actively keeps senior management support alive to keep the strategy consensus together and avoid re-plans. Executives recognize that TTM delays are primarily caused by product specification changes and slow decision-making by the host organization. Top management contributes most to FTTM by minimizing specification changes while giving fast guidance on business direction, technology and budget approval. The product team is released from the time constraints of all the host organization's periodic schedules. Business objectives should guide, but never delay products. The team gets the 80-20-business guidance it needs, when it needs it. Fast decision-making procedures are implemented that authorize fast starts and provide fast guidance. Best teams/organizations know the gestation period offers an inexpensive opportunity to cut TTM by as much as 30-50%. One or more product champions are assigned at product conception. A fast forum for fast decision-making process is implemented early. They make sure it's always on-line with a short turnaround time (typically <24 hours). If the decision-making process remains informal, product champions default to action after consulting the key players. Getting the product team the necessary guidance or issue resolution via strategic by-passes (even if imperfect) decisions are expedited. As a rule, best teams know that if a product will be affected by changes in business objectives, then TTM should be accelerated rather than changing its specifications. A percentage of development budget funds are allocated to the pursuit of unplanned opportunities arising during the year. Best teams/organizations make short but sufficiently clear versions of the business plan (values, vision, mission, strategy, goals, key success factors and key processes) and technology policy available to all. It should provide the quick 80-20 answers to the following questions about business direction: • What are the market segments for current and future business? • Who are the driving customers for each market segment? • Who is our competition in each market segment? • Will we compete in them by first-to-market, second to market or niche product positioning? • How aggressively should low cost products be pursued? • Which portion of the follow-on system makes up the business? ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 23 -- 23 of 101 -- Provide quick 80-20 answers to the following questions about technology policy: Target product parameters • What is the relative emphasis on product parameters (features, quality, cost, reliability, etc.) to achieve first-to-market, second-to-market or niche positioning? Support technologies • Is investment in related product and process technologies required to support the main product? Technology leverage • Is the product family structured to achieve technology leverage (number of lines, system threads, reusability, customer migration path, cannibalization intent)? Advancement steps • Will technology advancement be "many small steps" or “a few big steps?" Exclusivity • What competitive barriers are intended based on mix of proprietary and open standards? Sourcing • Which subsystems, process technologies or tools will be out-sourced? Facilities • What facilities will be used to develop product? ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 24 -- 24 of 101 -- 1.6 Cost-of-delay is understood at individual contributor level; used to drive urgency Summary Best product teams/organizations have calculated the "economics of delay" and have adopted the "pay to save a day" modus operandi. They use this to create a sense of urgency and to accelerate decision-making. Normally, the true costs of delay have not been calculated or seriously pursued. No one owns this “cost” in the organizational hierarchy. Example of a cost of delay model. Note that schedule is the most sensitive factor in this project’s profit projection. It was $1.6M in lost profit for every day this high volume consumer product was late. Normal The impact to delay in terms of “cost” to the company is not known by the development team. Since no one owns the “delay cost” in the functional organization, it is not identified and tracked. Time and money are not connected and are managed by two separate functional organizations. Financial decisions are made based on annualized functional department budgets without regard to the impact these decisions might have on product development cycle time (i.e. One additional person added to a project might accelerate the schedule by 90 days, but they are not hired because the function did not budget for the additional person at the beginning of the year: the lacking resource results in a $100k/day cost-of-delay to the project team, yet no one is accountable for this lost opportunity to save time). The annual new product development budget is set and "that's it." If the company does spend money for speed, they prefer to spend it on expensive productivity tools. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 25 -- 25 of 101 -- Best Offer to "pay for a day" is the best way to make management support for the economics of delay visible. Although some money will be spent (to save a day), the offer to pay has more than an offsetting value in changing the mindset. The best organizations calculate the cost of a "day of delay." They consider these variables: • Lost margin • Lost revenue • Declining average selling price • Extended run rate of development costs • Lost market share • Late entry into sales life • Lost customers and markets • For enabling technologies: loss of access to customer product cycles They use the cost-of-delay number to drive rapid decision-making and provisioning of their team with the resources they need to achieve their TTM target. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 26 -- 26 of 101 -- 2.0 Host 2.1 Fuzzy-front-end is managed Summary Best product organizations manage the front end of development, from concept to team formation by assigning small multidisciplinary teams of engineers and marketing people to quickly determine the feasibility of new product ideas. They significantly reduce overall development time by managing the front end activity within a fixed time-frame. It is treated as a formal development phase and managed like the rest of the product development process with specific target dates to be met. Normal product organizations let new ideas drift for long periods of time. Sometimes they are championed by marketing, sometimes by engineering, but rarely by both together. They lack the resources to do in-depth technical and business feasibility analysis, so the new ideas get cursory attention. The real work is left to the development team when it eventually gets formed (usually late and usually without enough of the right people) to do the discovery and investigation work that should have been done earlier. Problems arise later when the goals established in the fuzzy front-end are inherited by the formal core team. These goals were set without enough information, yet they never seem to change, including unrealistic expectations for product performance and project schedule. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 27 -- 27 of 101 -- Normal The period of time between from when a new product concept is first discussed to when a formal and fully staffed team is assigned is called the fuzzy front-end of the product development process. It is called “fuzzy” because in most organizations it is an unmanaged/ unowned process and there is little control. It happens when it happens. In the normal environment, this is done exclusively by one or two marketing people and/or it is done by a skunkworks of engineers working in the back room on the “secret” project that is yet unfunded, but draws resources from other projects to conduct the feasibility studies. The period of time between idea and team formation can be as long as the actual design, development, and manufacturing ramp phases. The reason is because it is unmanaged and usually under-staffed and/or under-funded. It is under-staffed because the resources requited are stuck on other projects that are late, hence they can’t roll-off. In some cases they are rolled- off, leaving the existing projects under-staffed. The fuzzy front-end meanders along because it is under-funded and often under the radar. Management focus is on those projects that are well into their development life cycles and are experiencing problems. They lack a fully staffed and funded multidisciplinary team to rapidly study feasibility, both from a technical and business perspectives. Best Senior management recognizes that up to 100% of the total development time can be lost in the un-managed time from idea to team formation, so they assign a small multidisciplinary team to study feasibility of the idea in order to quickly understand what is required to productize the new idea. They understand that the work necessary to turn a product concept into a product/project requires a cross-functional team of marketing and engineering to understand the customer requirements, market positioning, competitive/benchmark factors, determine technical feasibility and maybe even develop preliminary prototypes to validate the ideas/concept. If it involves new building block technology, then advanced research need to get involved. They set narrow windows of time for making these go-no/go decisions (e.g. <2 months). When this “gestation” period is factored into the overall development cycle time, a large acceleration can be achieved in total time to market when gestation time is reduced. Instead of it being under the radar, these feasibility assessments get immediate attention and focus because they represent one of the major sources of new product projects. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 28 -- 28 of 101 -- 2.2 Projects are prioritized based on business objectives Summary Best product organizations have a formal process for prioritizing new product development projects that are linked to the business planning and strategy development. The formal process quantifies the value of each project relative to the weighted business objectives. It is a managed consensus process where all stakeholders from engineering to marketing are involved, and are forced to reconcile what is wanted with what can be delivered given the constraints (resources, budget, risk, etc.) Normal product organizations have few (if any) formal systems to prioritize new product development. The funding process is driven by business units with the most influence. Projects starts are informal, so funding is erratic in the early stages when stability is most needed. Projects never get killed, and new ones keep getting being added without regard to the impact they have on the current resource allocation. Normal There is no formal system for prioritizing new product development projects. The project ideas are generated by customers, marketing, and engineering. Marketing and engineering have different systems for selecting which projects they will fund/initiate. Marketing’s is based on business planning; revenue and margin plans that must be achieved. Engineering’s is based on what they can do with the available limited resources/skills. The high profile the customer, the more likely that project starts. OPEX and CAPEX budget is derived from the business planning done by Marketing. The business planning and budgeting process encourages inflation of expectations and forecasts; ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 29 -- 29 of 101 -- one group wants to show more revenue and higher margins, and the other uses those to justify increasing development budgets. Failure occurs because the two planning systems are not balanced and aligned around the available resources (skills and quantity). The result is a pipeline that continues to expand to meet the business planning expectations, and the continued over-usage of the budget constrained resource pool. The two perspectives rarely get resolved until there is a crisis where people and budgets get cut across the board. There is no way for anyone to see which projects are more valuable than others, so they all get cut equally (but few ever get killed). Best A formal process is in place to model project priorities based on strategic business objectives and economic objectives. Strategy and economic metrics are clearly defined by the business units and weighted based on the objectives which contribute most to fulfilling the business strategy. Each project is assessed against each business objective to determine which projects contribute most to each objective, which results in a prioritization of projects. It is a zero-sum ranking, so when one project increases in importance, others are decreased in importance. This forces real prioritization, and is used later to assess the impact of constraints (limited budgets, resources and risk) on project priorities. The process is owned and managed by the product planning function, which is not part of either engineering or marketing. Engineering and Marketing are forced to reconcile what is wanted versus what can be delivered. They don’t move forward until both sides reach agreement. They do this in a regular cadence; from once a month to once a quarter, depending on the market and company. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 30 -- 30 of 101 -- New ideas are pushed through the process to see how they rank against the approved project portfolio. This creates a formal “starts control” process that funds, reduces funds, or kills projects that fail to score high enough against the objectives. This regular portfolio “refresh” also considers changes in business strategy/direction, and how the existing portfolio is impacted. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 31 -- 31 of 101 -- 2.3 Projects continuously aligned with resources and skills available Summary Best product organizations have a system to model resource constraints on current development projects, and the impact new projects might have on those projects. All stakeholders participate in the “forced” resource and skills alignment process on a regular refresh cadence. Normal product organizations have no organized system for balancing resources. Systems that are in place are ad-hoc and are used to show the misalignment, but they don’t offer solutions because they only consider one functional perspective. Such systems are cumbersome to use, unpadded infrequently and inaccurate. Meanwhile, more projects get added to the development pipeline because there is no way to see their impact on current projects. Attempts to highlight the problem are career limiting for the up and coming executives, so most are silent, toe the “can do” party line and hope they get promoted before they get caught. Normal In addition to no formal project prioritization system (see “Projects are prioritized based on business objectives”), these companies don’t have any way to assess the impact new projects have on existing resources already deployed and committed to projects in the pipeline. New projects are added without regard to the impact they have on the existing approved projects. Functions are expected to “get creative” and become more efficient to handle the new projects. The problems are compound every planning cycle as the existing projects in the pipeline get slower as new projects are added. The efficiencies of scale don’t apply when it comes to thinking about people working on difficult technical innovations. When executives complain they don’t have enough resources, they are told they are less efficient than their competitors who are able to generate more new products with fewer people. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 32 -- 32 of 101 -- Best The formal prioritization system (see “Projects are prioritized based on business objectives”), is used as the basis for modeling the impact of constraints (such as budget and resources) on existing the existing project portfolio. When the constraints are applied to the prioritization model, they quickly learn that some of the lower ranked projects should not get funded. They do a simple cost-benefit analysis to determine which projects get funded and which projects don’t, get killed or are delayed. They know that about 20% of the projects generate 80% of the benefit (based on the prioritized business objectives), so the process is designed to locate the high value 20% of the portfolio that must get maximum resources. The process is refreshed from once a month to once a quarter. The results are based on the multidisciplinary input by the key stakeholders. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 33 -- 33 of 101 -- 2.4 New products are tracked to break-even Summary Best product organizations track new products from idea through to break-even. Development teams understand the impact of their work on the company’s success/failure. Because they see a product through to break-even, they tend to make different decisions early on in the development cycle than they would if they were just taking the project to the manufacturing handoff point. Being able to make a yielding product cost effectively can change design decisions early when designers are conscious of future market success and product profitability. Normal product organizations track project cycle-time to the end of development to where the engineering organization hands the product off to operations for them to manufacture it cost- effectively. The clock starts when the full team is formed (not even when a partial team is formed). No one tracks the pre-team feasibility phase. Engineers rarely see/correlate the economic impact of their work with the company’s success/failure. Normal New product development projects are tracked by function, so marketing tracks the projects they start, engineering tracks the design and development activity, and over the wall it goes to operations (manufacturing) to track the manufacturing ramp up to reach the yield and cost targets. At some point sales starts to track the market performance of the new product and somewhere, way out into the future, a finance person might run an analysis to determine if the project made or lost money. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 34 -- 34 of 101 -- The engineering team that does the design hardly ever knows if their work makes or loses money for the company, since this is not their concern, as it is someone else's job to worry about much later in time. Once they have finished their job, they move on. Since each function/ silo is partitioned from seeing the complete life cycle, none of them ever see the end result of their work. They don’t identify with the project/product success, rather their focus is exclusively on their function’s achievement of their objectives, usually based on cost control metrics. Best The fastest teams/environments turn on the clock when the new product idea is first discussed. They measure cycle time (from idea to team formation), they measure design and development time and they measure the transition through the manufacturing ramp. This follows with a measurement of the time it takes to get from high volume through to market distribution and eventually to the time when the project breaks even. This is not tracked by the functions, but the core team that owns the development project through to the beak-even point. They follow the product all the way to the point that it starts to make money for the company. This creates a sense of ownership, purpose and a business, since they can experience the impact their work has on the company. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 35 -- 35 of 101 -- 2.5 Kill projects that fail to meet objectives; early Summary Best product organizations kill projects that fail to meet the business objectives. The decision- making process is agnostic towards position or expert power, since it is based on agreed data and decision modeling techniques. Normal product organizations rarely kill projects. Normal Projects rarely/never get killed. When they do, they reemerge as new projects with a different name. The business objectives are vague or they change, and there is no way to assess how well each project contributes to those objectives. Most projects that get approved and never killed are those projects put forth by senior management or people inside the organization with expert power. Since that have missed their economic value are kept on life support, since no one wants to admit that they should never have been started or should have been killed a while back before sucking up valuable resources. Best Projects are assessed (at least) on a quarterly basis to determine how they score against the business objectives, especially if those objectives have changed. Projects that don’t meet a certain level (score) are challenged. Projects that have missed their viable economic window are also challenged, with the aim to clean out the deadwood projects and free up resources for ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 36 -- 36 of 101 -- projects that can most contribute to meeting the business goals. It is a data-based decision, not an emotional-based decision. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 37 -- 37 of 101 -- 2.6 Fast development framework Summary Best product organizations - the development life cycle is owned by a single person/entity. Their job is to continually redesign it so it makes development projects move faster. The framework considers the problem from end-to-end, i.e. as one integrated system, starting from product concept through to the product end of life, rather than as a series of organizational deliverables. Systemic interrupts are continually identified and removed so teams get what they need when they need it. These frameworks are simple, one page explanations of the process. Because they are macro and simple, people understand it, which means they use it. Details are left up to the core team to fill in on their specific project. All projects look the same at the macro level, but at the micro level they are unique., i.e. there is flexibility within the framework so the team can adapt as necessary vs. giving the team a rigid of working that never works for all types of project. Normal product organizations - development frameworks (product life cycles) are slow, complex, and cumbersome processes that are designed to control development spending and to ensure decision-making is concentrated in the top levels of the functional hierarchy. The concept of design for reuse and platforms, spinning rapid derivative products are discussed but not implemented, because it implies an overall orchestration of the creation process which does not exist. Prior attempts to improve the development framework have failed, since the people that really need to do it are the people that are consumed by the daily grind of development problems. Product life cycles are rarely redesigned, but when they are, they are done by people on the sidelines, and they are therefore discounted and never get implemented. Normal Product development is structured functionally. There are many owners of the pieces of the development process, and there is no single overall owner of the product from end-to-end as it flows through the various functions that touch it during the development life cycle. The process is complex and few understand it, defaulting to just trying understand their contribution to the process. The development steps are rarely challenged and are hardly ever re-engineered to be more efficient. They tend to be additive systems that become bloated and overbearing, which is why few take the time to understand them. Few people follow the steps because they add no value and just slow down the development work, or they assign NPI people (overhead) to feed information into the tracking systems that few use. The concept of “design for speed” is not understood, and rather than developing reusable platforms, companies default to reinvent the wheel on every project, because they know it is impossible to reach a consensus. They will either tilt towards platforms that have everything or have no platform/derivatives at all, with each project becoming a new invention each time. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 38 -- 38 of 101 -- Since no single person/entity owns the overall product development life cycle (since it cuts across all the functions) it becomes impossible to optimize the product design process for speed. The process was designed to control spending and decision-making, and was never conceived as a way to make product development go faster. To fix it means “blowing it up.” No one wants to do this, so only incremental changes are made, resulting in little impact. Best The team emphasizes overall business success from the start, i.e. through to Break-Even and/or Return-on-Investment. The development life cycle has been optimized for speed. It is owned and managed by a product management function which cuts across the functions, reporting to the executive staff level. The product development framework owner’s job is to find ways to reduce friction (i.e. interrupts) and continually improve the process to remove waste and inefficient steps. It considers the complete life cycle, from first concept to end of life. The team knows that up to 100% of the overrun time can be lost during the “fuzzy-front-end” of development, i.e. the time from idea generation to full core team formation/project funding approved, so they carefully manage the front-end feasibility analysis in order to make faster go- no/go decisions about the project. They design speed into the product through the use of reusable parts and common platform architecture where up to 80% of the parts are reused and only 20% is changed for derivative platform spinoffs. Design and speed are seen as one thing, not two separate things. Every effort is made to design so the development effort is accelerated, i.e. “design for speed” rather than design for the most elegant technical solution. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 39 -- 39 of 101 -- 2.7 Provision teams, eliminate interrupts Summary Best product teams/organizations promote and create mechanisms to provision the product teams quickly with resources, information and fast guidance where required. The host organization works with the product teams to minimize the schedule impediments (interrupts). Normal product teams/organizations “default to delay" much of the time because they are waiting for the hierarchy to decide/act. Normal The design of the development organization structure by the host organization is ad hoc, slow and considers few alternatives beyond what has been done before. New product development work is divided between the functions responsible for the work. The project is coordinated by the functional hierarchy within and between functional groups. Breakdowns occur at the "hand off" points between functions because walls have been built up between the functions. The functions default to “throw it over the wall” method of working with little communication or interaction between functions. Uncertainty of the cross-functional tasks associated with development work forces those doing the work to coordinate the work while they are doing it. This inevitably overloads the vertical information capacity of the hierarchy and delay is inevitable. The entire development organization defaults to delay much of the time because it is waiting for the hierarchy to decide/act. Consequently, the host is slow to provision the development organization but quick to interrupt it. The development organization is deeply "embedded" into the host and each individual is deeply "embedded" into several projects. The over-head of context shifting and frequent interrupts are high and resources are provided to the team when they are available. They are typically not sufficient, with the wrong skills, and provided late due to the need to have a limited number of ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 40 -- 40 of 101 -- skilled people continue working on the other projects that have higher priority because they are closer to finishing and are late. In these “slow” environments, team members are typically more allied with their functional position within the host than the new product development team(s), of which they are a part of. They view team work as secondary to the work they are directed to do within the function. There are adversarial relationships between New Product Development (NPD) teams and the host: The Team… “They’ve never killed a project.” The Host… “We’ve never had a product delivered on time yet.” The Team… “Host has to understand that resources aren’t infinite.” Teams takes pride in being able to work around the host and view the host as the major impediment to speed. The underlying assumption is the Host views the team as a “means for between-function hand-offs” (versus the cross-functional owner). The Host controls/limits the team’s ability to decide/act on issues central to the team’s functioning and/or ability to stay on or beat schedule. The Host owns and controls the budget, it stretches people resources too thin between projects and/or sustaining work and limits or provides untimely information, decisions, resources, customer information, etc. The Host also limits equipment, tools, facilities (unavailable/shared/ dated). Examples of typical host interrupts that we have seen in our work includes: • 14 signatures required and 4 months to approve 2 critical engineering requisitions • Critical project resources redirected away from the team (unknowingly) • Periodic audits (as a result of low confidence) and frequent requests for information (need to know) virtually shut down productive project work • Artificial gates (checkpoints) and organizational reviews imposed to maintain overall control of daily decision-making (systematic interrupt) • Slow to respond on critical project/product decisions • Team was limited in it’s decision-making scope • Frequent changes to the product strategy and re-prioritization of the organization’s “key” projects • Failure to provide access to test software and the training to use it effectively • Failure to provide enough test equipment (2 shared between multiple projects) • Marketing and Sales (the Host) limited the team’s direct contact with customer • Throughout the project, requirements were vague and unclear ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 41 -- 41 of 101 -- Best It is recognized that delay caused by the host is a primary cause of TTM delay. Cross-functional core teams are formed on time, dedicated, virtually collocated, autonomous and empowered, and lead by heavyweight (vs. lightweight) program managers. Resources are provided on time and with the right skills based on what the team needs, not what is available. If this can’t be done, then the program is not started. Unless the development organization is designed to be a fast organization, the usual results will occur: engineers can be found to spend less than 25% of their time doing engineering work and 75% is spent on interrupts of various kinds. Likewise, the product team itself spends a huge portion of its time being interrupted or delayed by the host organization. In relation to the host organization, the overall design criterion for the fast organization is to optimize provisioning and minimize interrupts between the team and the host organization. Provisioning includes providing the team resources and information (direction, resolution, etc.) in a timely manner. There are two ways to design around the problem of overloading the hierarchy. The best organizations use a combination of all three: use self-contained teams and establish lateral relations (in other words they make the development team as autonomous as possible), design faster communication systems to the top management, and co-locate the team members for direct contact (or virtually collocate). To get such an organization in place, top management holds the teams accountable to the schedule, and reviews it in a rapid decision-making forum. The Host gives true “ownership” of the product (like a start-up) to the core team. They provide sufficient & timely information (market, financial, supplier, inter-company, etc.) to the teams. They provide sufficient budget for the team for the duration of the project (based on what is needed to do the job right vs. what is available or negotiated). They ensure the right skills and number of people are allocated to the project as they become needed on the project. They identify and provide sufficient tools & technologies to teams such that these are not bottlenecks to development and finally, they really do this and not just say they will do it. The Host insures that appropriate facilities for the team (co-located facility, “war room”, etc.) are made available when team needs them. This does not require “begging” on the part of the team, but rather the facilitization of the project is built into the fast design and development flow. Finally, they delegate sufficient authority to decide and act in order to stay ahead of schedule. Systemic interrupts are identified and eliminated. This is a continuous improvement process to find every thing the company does to generate friction, i.e. felt by teams when trying to move fast, then fixes them, from increasing sign-off levels to expanding the scope of decision-making. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 42 -- 42 of 101 -- 2.8 Cross-functional core teams (heavyweight & dedicated) Summary Best product organizations form heavy-weight teams early, i.e. during the project feasibility phase, on critical projects. They are truly cross functional, composed of members from engineering, marketing, operations, and finance. They are dedicated 100% to a project and rarely multiplexed between other projects. They are lead by heavy-weight Engineering Project Managers (EPMs) who have general subject matter expertise and also knowledge of the customer and the market. The core teams are run like start-ups and have all the necessary skills to run like an independent business. The host structure within which they operate is designed to provision the team with what they need to be successful. The power is shifted from the functions to the team. Both are critical to the success of the project, but the team is empowered with making a new product which means that they share in the rewards of the product success, but are also responsible for a product’s failure. Normal product organizations teams are “cross-functional” in name only. They are comprised of many part-time, over committed and under resourced functional representatives that take direction and are loyal to their functional hierarchy, not to the team/product. Because there are many functions on the team, the core team becomes bloated with sometimes >20 representatives. They politely attend project meetings, however the actual work on the project is done back in their functions (not in core team meetings). Since core team members are on ~10 teams at the same time, they miss a lot of meetings and rely on electronic communications, which is rarely up to date, often inaccurate or never read because of the hundreds of e-mails that get delivered every day. The teams are lightweight and used for coordinating between the ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 43 -- 43 of 101 -- functions rather than driving laterally through the organization. Nobody is responsible for the integration of functional deliverables that come together to make a product deliverable. Today’s cross-functional teams are really just new forms of old hierarchical departmental organization, and as such tend to be good at moving information vertically, and bad at managing horizontally. Normal There are many cross-functional teams. One engineer could be on 10-15 at one time. They participate on a part-time volunteer basis, and because they are on so many projects at one time and spend little time in team meetings, they have little if any connection with the team’s mission. Most of the engineering team’s time is consumed with technical meetings within their function. They receive performance reviews through their functional hierarchy and naturally focus on satisfying those requirements first. If there it anything left over at the end of the day, sometimes the teams get it. Team members complain of motivational problems caused by not being able to spend sufficient time on any one thing to do it right. Work product quality and motivation suffers. When asked, “What do you work on?” the response is usually, “I work in X Group and do Y activity.” Hardly ever do these core team members identify or associate themselves with a specific product by name. Their focus is exclusively functional. The core team is formed late in the development cycle. Members join the team at different points in time, making it difficult to develop any team culture or focus. Core team members join the team late due to the delay of a previous project and/or members being assigned to too many teams at one time. Leadership of the core team is unclear. There is a program manager, but their role is to coordinate meetings, document submittals and to give the “status” presentations when asked by top management. For the most part, it is an unmanaged team coming together regularly for meetings. However, all the members know that the “real work” is done back in their functional sub-teams. The core team is supposed to be a forum to share information and coordinate the hand-offs, but eventually it becomes more of a formality because it is required by the development process procedures. Teams resort to large multi-day all hands meetings to try and get information moving around the team when the core team fails to do this job during its weekly sessions. Even more time is sucked away from developers with these big meetings. Since there is no strong/authorized leader, the engineering elements of the project are broken down into independent work efforts with little coordination between the pieces. Core teams are bloated with 15-30 people because every engineering element of the product needs to be ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 44 -- 44 of 101 -- represented, and because they lack a technical hierarchy that leads back to a single person responsible for each major product deliverable. Who is the “Chief Engineer” in charge of making the difficult technical tradeoff decisions that are essential for timely systems development? These people are hard if not impossible to find. The decisions are spread over multiple people so no decisions ever get made. The lack of technical hierarchy on the team leads to sub-optimization, expanded task durations and downstream handoff problems. The core team members are not dedicated to a single project; most of the time they are on >10 at the same time. It gets worse with individual contributors who are multiplexed across >15 projects at one time. No one has enough time to do a good job on any of the projects because they are overloaded. This is why the focus is inside the functions and why team members expect the program manager to manage the “white space,” which everyone knows is impossible on complex technology projects today. The core team and extended teams are not co-located, even when on the same site. They rarely see each other and rely on automated systems to share data or communicate online. During online working sessions, those on the call are doing other things (replying to other e-mails related to the other projects they are on in order to keep up), while they are trying to pay attention to the speaker. The lack of face-time results in poor communication within and outside of the team. This is even true with people that work on projects at the same site, but don’t sit near each other. Sixty (60) meters within a site is about the distance when physical contact drops off. People default to electronic tools, even when they sit next to each other. They are often used to insulate people from outside contact, which is the opposite of what they were designed to do. If you want a decision to stall, put it into an email and copy 30 people. Finally, the core and extended teams take direction from their functional hierarchy. They pay lip service to project managers and are polite in team meetings, but they know that the real work is done back in the functions. The functions are protective of information and of making commitments. They add buffer to take into account the organizational inefficiencies. They know the incoming work will be late, so they add buffer to account for the delay and to protect themselves from blame when the project is late. When these duration buffers are accumulated, the schedule becomes bloated and inflated. The team are then forced to reduce durations. Few really care about the overall program schedule anyway, since they are only being measured on the performance of their function and their own ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 45 -- 45 of 101 -- technical metrics which they are held accountable for by the more powerful, functional hierarchy above them. Career advancement happens when this power structure is satisfied. The notion of an “autonomous” team structure is seen as wishful thinking and impossible, given the current limited resources and large number of committed projects in the pipeline. The teams are lightweight at best and only serve a minor coordinating role. Top management knows this and defaults to getting status reports from their technical subordinates through normal staff meetings and periodic project meetings that only involve the people inside a given function on a specific project. Everyone is doing this at the same time in their functions resulting in very little flows laterally across the functions. Development is slowed and the schedule slips. Best Executives recognize that the success of the business is based on timely release of new products (since these generate the highest margin) and in the technology. They also generate the fastest growth. They know that they must invest in strong teams and team leaders. This includes sufficient numbers of people to staff multiple teams with the right skills needed to develop the technology and the product. They know that to limit both of these means development timing will be impacted. To this end, they form Heavy-weight teams on their most important projects early in the development life cycle, as early as the feasibility study phase. They know that the fuzzy-front- end of projects is where up to 100% of the time is wasted/lost. They staff these dedicated teams with senior managers. Many use rotation through “project managing” as a path to executive leadership, because they feel that leading a cross functional team is the best preparation for general management of multiple functions in the future. The leader is a senior engineer with sufficient technical and managerial experience to make difficult technical and business trade-off decisions quickly, and they are empowered to do this. They have the respect of the team members, and the team members take direction from them. Anywhere from 50-100% of team member’s performance reviews are done by these heavy- weight team leaders. The project has a single engineering leader that all technical issues and decisions roll-up to. They can also take on the role of the system’s architect and technical visionary. They are are not experts in every field, but rather an expert generalist in all subjects. They see the complete system being developed end-to-end and can make the trade-offs necessary for the complete system to be successful, i.e. they are able to “connect the dots.” ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 46 -- 46 of 101 -- The teams are more autonomous and are collocated, at least the core team sits within a few Steven C. Wheelwright’s 4 forms of development team organization, Harvard Business School (adapted by lateralworks). meters of one another in a common “team space.” This common space is where all the meetings about the project take place and where information about the project is posted on walls. When projects have remote teams, a similar physical team room configuration is set up at the remote location. They rotate meetings in each location to maximize face time between members. The team is the focal point for all decision making about the project/product. The Host functions supporting the project provide teams with what they need to be successful, as provisioners of the right people, the right information, the best quality work, at the right time. The center of gravity is moved into the team from the host functions. The path to executive leadership/power is through these important team structures. They invest in their teams like they invest in researching new technology, because they understand that a strong team is the best delivery mechanism to rapidly get new products to market. The four team structures above illustrate how speed and structure are interconnected. The first form is called “functional.” This is the slowest way of managing projects; there is virtually no lateral flow of information, and all coordination is done through the functional hierarchy. The second form is called “lightweight.” This is the most common organizing form in technology companies, since it requires no change in the functions where the power resides. Everyone likes it because each function controls their part of the project, yet there is an illusion of lateral control through the project management organization (PMO). These PMO people tend to be note-takers and checklist fulfillment specialists, and always ready with the corporate side pitch outlining the status of the project. In reality, they don’t really know what’s going on. The third form is called “heavyweight.” This is a difficult structure to implement because it means shifting some of the power from the functions to the team. Since power is a zero-sum game, someone has to give it up to enable a heavyweight team. It also requires certain management skills to be present on the core team, which is not always the case. Companies usually have only a few good people for this role, but rarely enough good people to staff all the dedicated project core teams. In this heavyweight model, the functions are positioned to provision teams with the right people, with the right skills, and the technology so that the development schedule is accelerated. Decision-making is 80-20 inside the team, with the functions retaining 20% veto power, but the majority of the responsibility falls on the core team to make the right decisions. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 47 -- 47 of 101 -- Heavyweight is what most aspire to and it represents the second fastest organizing form. They are faster than lightweight teams, but it is clear that all projects should not be set to level 3 - just those strategically critical projects that have the greatest impact on achieving the business plan objectives. The fourth form is called “autonomous.” Teams are dedicated and collocated in a separate space. They are set up like a company inside a company and have all the advantages of a well funded start-up in terms of focus and rapid decision-making. This form is used to develop breakthrough products or in products where time-to-market success is directly connected with the life and death of a company. Some companies have seen this form of organizing as a way to build new businesses very quickly, and then use it periodically on special projects. Autonomous teams are the fastest and most effective forms of FTTM development. The autonomous team is analogous to the Navy model. In the Navy model, the Captain (project manager) of a ship leads his/her team to battle. All personnel on the ship report to the Captain while on the ship. The role of the base commander (functional manager) is to provide the training, skills , tools and equipment in preparation for battle. They also support their personnel while at battle, but understand that the Captain ultimately has authority while under the Captain’s command. The Navy model has worked for more than a hundred years. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 48 -- 48 of 101 -- 2.9 Project-based performance measurement Summary Best product organizations measure and reward an individual’s performance based on the success of a new product in terms of timeliness to market, customer satisfaction, and overall profitability of the product over time in the marketplace. It is an externally looking product focus versus an internally facing functional emphasis. Effectiveness over efficiency. Normal product organizations measure and reward an individual’s performance based functional departmental achievement (i.e. annual departmental goals). Efficiency over effectiveness. Normal It is very hard to associate an individual’s daily activity with the success or failure of new products. The emphasis is on functional or hierarchical achievement vs. new product success. Managers own functions, but no single person owns the new product. The logic here is that if each function is successful, then therefore new products flowing through these functions will be successful, except it rarely works this way. The function always trumps the product. People behave as they are measured (per W. Edwards Deming). Efficiency wins. The emphasis is on the function and the hierarchy within the function, because movement up the hierarchy is controlled by the hierarchy. Save money, stay within your budget, achieve specific technical goals, and so on and you move up and make more money in the company. There is really no emphasis on “product” success, because no one owns the product; it just flows through the functions who work on it, like the car that flows through stationary workers on the assembly line. The thinking is that all I need to do is make sure the door I hang on the car is done right while “someone” else is making sure the complete car is going together correctly at the end of the line. My interest is not in the finished car, but rather than my door is installed correctly. It is manufacturing thinking applied to new product development, except it is with people not parts or machines. This early 20th century manufacturing thinking dominates how people are measured in development of new products. It is much easier to manage and make people accountable for functional goal achievement, while it is much harder to reward a cross-functional team of hundreds of people for the successful creation of a new technology. So the default in the normal environment is to measure people they way it has been done since Alfred Sloan developed the modern manufacturing company in the 1920’s/30’s. The same practices are applied to cross-functional team work that are required to develop a new ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 49 -- 49 of 101 -- technology product. Measure/reward vertically, not horizontally because it is easier to manage and it is a known method. Teams fade to the background, while functions jump to the foreground. This encourages people to pay more attention to the functional manager’s demands than the cross-functional project manager’s leadership. Best Leadership recognizes that new product success determines the rate of growth of the tech- based product company. Profitability and growth comes from releasing new products, on time. To this end they also understand that cross-functional teams must be measured and rewarded based on the collective success of the team - everyone that touched the product as it flowed through the company from concept and on to high volume production. If the team fails, then the individuals on the project fail, and if the team succeeds then the team shares in the reward. Traditional functional goals are still in place in these environments, because they know that efficiency of a function is also critical to success. For example, reuse is one way to make a function more efficient. Develop it once and reuse it many times on multiple projects. A project team working on a new product may not take the time to design for reuse on other products, because this may delay their schedule, so they “hard wire” it for their specific application, not thinking of others that might need it in the future. So it is important for the functions to maintain efficiency standards, but these subordinate to the project development goals at the end of the day. There is a 60:40 or 70:30 ratio of functional measurement to project/product measurement and reward. The majority of the measurement system is loaded towards how well a new product meets its goals in terms of its target date for release, its functionality, and how well it performs financially when it is sold (margins, returns, revenue, etc). ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 50 -- 50 of 101 -- The lateral/horizontal emphasis on the product drives teams to more efficient cross-functional behavior. It is not sufficient for my function to succeed if at the end of the day the product is late or missing functionality, so my focus is on how I interact with the inputs and outputs from my function and I always consider how my actions will affect the overall success of the product when it is released. I am worried about “my car door,” but more worried about how the finished car looks when it roles off the assembly line. This lateral focus is executed through the degree of “performance review” authority that is given to the functional manager versus the new product development manager (i.e. project manager). Using the same 70:30 measurement ratio, best teams give a majority of the performance input to a team member’s lateral manager (the project manager of the new product effort). Both evaluate performance; one from the functional perspective and the other in terms of how well the person is doing to further the project’s goals. This gives the “project manager” a significantly greater role in managing team members, because their future career is based on how well the new product meets its goals when released. Organizations that have embraced this lateral performance measurement system place their best people in those lateral management jobs. Further, they have identified career paths to the top through project experience, not just through the more traditional functional hierarchical route. The function’s role in these “project-centric” companies is one of rapid provisioning of the best trained and skilled resources to the project teams and to deliver optimized/reused technology across projects in order to reduce aggregate development time. They, in fact, also get rewarded for project success by making sure teams get everything they need and when they need it. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 51 -- 51 of 101 -- 2.10 Freedom Level 1 empowerment Summary Best product organizations empower high performers at Freedom Level 1; act, routine reporting only. This provides managers with only “after the fact” control, so they must trust subordinates. This trust enables subordinates to grow faster, take more risks, and get things done faster. They act, then report - which is much faster. Normal product organizations limit the power and control they assign to project teams/ individuals, believing that people need to be micro-managed in order to optimize their performance. They require individuals, due to a lack of trust in many cases, to permit “before the fact” control over their actions. These teams are slower due to the time required to “check first” before acting. Description of Freedom Levels There are five levels of Freedom. The lower the value, the faster decisions are made, actions taken, and the more people feel ownership in the outcome — it's a way to quantify empowerment. Lets start at the lowest level, in this case it’s five (5) “Wait until told.” This is a completely passive state, only reserved for Trainee’s, yet we’ve seen executive vice presidents “waiting to be told.” The more you wait, the less empowered you’ll be and the more you will stay at Level 5. Level 4 is marginally better than Level 5. In this case the person is a little more proactive and “Asks what to do.” The more you ask, the more people will tell you what to do, you will find ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 52 -- 52 of 101 -- yourself quickly back to Level 5. Most of the time people disempower themselves because they continually “ask.” You also find this behavior when people are not trusted due to performance problems. The boss does not trust the subordinate, the subordinate does not feel trusted. Its a viscous cycle. Level 3 moves one out of the “trainee” mode. In this case, you would “Recommend, and then take resulting action.” This does provide the manager with some degree of “before the fact control,” yet it encourages people to take action and not wait. Perhaps the best example of this from our best practice study was the concept of “UNIDIR.” On a very fast development project, people would sometimes start emails with the acronym “UNIDIR,” which stands for “Unless otherwise directed, I intend on…” We also called this behavior “default to action,” versus “default to delay and discuss.” Level 2, “Act, but advise at once” provides leverage and growth to the individual being empowered/trusted to take actions. This provides the “boss” with “during the fact control” and is a more collaborative form of management. This is also much faster than Level 3, since there is no time waiting for the recommendation to be assessed and a decision made. Level 2 is “real- time” management. Often, we see different decisions/situations getting different levels of empowerment; for example a major strategic business decision such as an acquisition or the termination of a business unit might be Level 3, while technical product roadmap decisions may be granted a Level 1 or 2. Level 1, “Act, routine reporting only” provides the Boss with after-the-fact control only; maximum level of empowerment/most growth for subordinate; most leverage for boss; this freedom level reserved for those who are "self starters", have demonstrated an ability to consistently produce excellent work, on time within or under budget. Freedom Level #1 may not apply to all elements of subordinates work - depending upon their experience/competence or the relative impact some of the subordinates work may reflect directly on the bosses overall performance. Normal Using the Freedom Scale (above) as a reference, development teams/individual contributors operate at Freedom Levels 3-5. This provides functional managers with the ability to “catch” bad decisions before they happen. This is a control-based management system. The control is with the hierarchy above the team. Teams are not trusted with too much authority. Typically, this behavior is driven by a need from the Host to control financial expenditures. The logic is that if teams are permitted to make spending decisions on their own then they would spend so much money that the company would go bankrupt. This financial control extends to other decision-making topics over time, to include; management decisions, people decisions, and most importantly technical decisions. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 53 -- 53 of 101 -- In the development of technology, the best engineers and scientists tend to move up the hierarchy. They typically don’t have formal management training, they are just good engineers, so the logic goes that an engineer can do anything and especially something as simple as managing people. They default to doing what they know best, solving technical problems and making technical decisions. This means that they jump down into the details, and in doing so, the team is disempowered. At this point the manager owns the project outcomes, the team does not. Freedom Levels 4-5 are reserved for trainees, not professionals, yet we see many professionals being disempowered by this management behavior. The more concern you have for a subordinate, the more that person is micro managed (Levels 4-5). The problem with this type of management is that people don’t learn, they are not permitted to fail, and they have no ownership over the outcomes, because actions are decided by someone else. As a manager you have zero leverage over people at Levels 4-5. It is slow and the bottleneck is the information flow through the functional managers, yet this is the norm in many development organizations. In normal situations, the best teams and individual contributors can hope for is Level 3. They are permitted to make recommendations and then act on their own. This provides management with the before-the-fact control they feel they need in order to control spending and to make sure bad technical decisions are not made by development teams. It is a slow and cumbersome process due to the hierarchical reporting requirements. Best Development teams operate with total freedom at levels 1-2. Management trusts the teams and is satisfied with during or after-the-fact control. The more trust the team gets, the more empowered they feel. They tend to own the project outcomes more in this environment and are better at controlling costs and making sound technical decisions, because they own the outcomes and can be made accountable for their actions/decisions (since they make them). Levels 1-2 offer the highest level of leverage for management. This is also the fastest mode of working on new product development projects, because people are allowed to make real-time decisions without the need to check first or analyze alternatives for presentation at a later date in which someone outside the team will make the decision. Best teams are permitted to operate at Levels 1-2 on most activities. The freedom can be granted situationally based on the activity. For example, a team may get Level 1 on technical decisions, but may be asked to work at Level 3 on hiring decisions. These teams are faster and more empowered. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 54 -- 54 of 101 -- 3.0 Team 3.1 Co-develop with tier 1 customers; continuously refine requirements Summary Best product teams organizations engage with customers directly to define and then to develop the product. They integrate development organizations so that engineer-to-engineer communication can occur. They use this close-in contact to accelerate decision-making and improve overall system integration. Normally, product teams determine product requirements from generic market requirements, standards information, competitive data, and/or by increasing technology by a factor of (X) over the previous generation. Customers are not a part of the development process. Normal Communication with customers is more like a vendor supplier relationship. Team does not perceive itself to be credible with the customer, so they attempt to guess/align their schedules and product features with a future perceived need of the customer’s – but are always late because the customer’s schedule/needs changed in the interim period of time. No contact with customer’s development teams, only contact is through low-level product managers and/or marketing/sales. Perception is that engaging closely with a customer limits your flexibility do create a standard product. Fear that sharing actual schedule and product performance information with customers may cause the customer to look elsewhere. Best The team knows that they need to not only understand their customer, but also their customer’s customer requirements. Co-development enables teams to understand the overall system requirements, not only their individual piece. This knowledge causes better systems integration, higher quality, and faster time-to-revenue. Partnering with a customer development team creates customer “pull-through” and a mindset for speed. Co-development enables incremental releases of partial deliverables and early feedback. Best teams share all schedule and technical information with their customer because they know that trust and credibility can be built on joint problem solving. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 55 -- 55 of 101 -- 3.2 Schedule as a driver vs. reporter Summary Best product teams/organizations recognize the cost of being late to market, that for every day saved there is an enormous leverage on profit. Therefore, maintaining or pulling in the new product development schedule is of the highest priority and has a high profile within the company. Normally, to "make schedule king" would require significant, perhaps unacceptable, trade-offs to quality and/or costs. Normal To be faster, something has to be sacrificed. "You don't get something for nothing." Five development objectives are involved in possible "tradeoff decisions:" feature quality, defect quality, development cost, product cost and TTM. To go faster, quality or cost must be sacrificed. Making schedule king means building a product with less performance or fewer features; or it means "blowing" the development budget. Management accepts the inevitability of schedule re-plans and is complicit in permitting the schedule to move out. Management demands schedule reductions as if they can be achieved by mandate. The schedule is used to report progress to people outside the team in the hierarchy, but rarely used by the team to manage day-to-day activities or used to make decisions. When used for reporting, the schedule is “updated” to reflect the particular information needs and project outcomes of the intended audience. Best Top management can articulate the need for speed; they know that reducing TTM has a big impact on profitability. They know that for every day saved there is an enormous leverage on profit because revenue to cover the development cost is earned sooner; the leverage is so high that you can "pay to save a day" and "you'll more than earn it back." Top management can communicate the "economics of delay;" they know that saving TTM exerts more leverage on ROI than reducing development cost or product cost. Top management leads with "speed"; it makes schedule king. This means they use schedule compliance to lead product teams to find and eliminate wasted time. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 56 -- 56 of 101 -- Making the schedule king means never moving the schedule to the "right" (i.e., slipping the schedule out). Because there is so much wasted time in the total TTM cycle, the best organizations continually challenge the product teams to find and remove "slack;" top management supports their actions and together they prevent or recover slippage. Making schedule king (and used as the driver of project activities) works because gestation and overruns alone involve about 80% of the wasted time in new product development cycles, most of which is waiting. Also, a high proportion of the development schedule is also waiting. Making the schedule king means permitting no "macro" schedule slippage; however the "micro" schedule may move in and out. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 57 -- 57 of 101 -- 3.3 Translate customer requirements to product definition, reconfirm throughout development Summary Best product teams/organizations involve the customer during each phase of the TTM cycle (not just the development portion) to assure product superiority and a shorter TTM schedule. Normally, customer information is gathered at the front end of the development cycle with after- the-fact feedback at beta. Information typically comes through the sales account team or the marketing function. The quality of the information may be further eroded, depending upon the quality of the relationship between marketing and development or the project team. Normal Customer input is gathered at the front end of the development cycle with only spotty validation from the customer until beta. Customer contact is often limited to the sales account team or the marketing function. Effectiveness of product requirements/specifications is governed by the quality of the relationship and respect between marketing and development. If they listen to each other, specifications are pretty good; if they don't, specifications suffer accordingly. Best The best teams get and use the "right" customer information throughout the entire TTM cycle (gestation, development, overrun); this enables the product to be superior and TTM cycle time to be shorter. The best teams plan and schedule voice-of-the-customer (VOC) involvement, run it in parallel and integrate it with the entire TTM schedule (not just the development portion). The best teams design VOC involvement to fit the TTM phase: • Planning (gain counsel on business strategy) • Gestation (run "skunk-works" with leading customers) • Requirements (create user groups; collaborate in Quality Function Deployment (QFD) modeling) • Design (develop partner labs and allow direct contact with designers) • Development (conduct partner or customer "use-ability" testing) • Beta (do early installation of product for customer business use) • Field Support (get feedback and assist with Root Cause Analysis) and • Overrun (create mutual problem-solving forum to keep the relationship) The best teams scrub the VOC schedule repeatedly, and review it for quality, timeliness and effectiveness in the rapid decision-making forum. The best teams use customer input to resolve major development decisions throughout the TTM cycle, not just the front end of the development phase. This can save weeks of management and team deliberation. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 58 -- 58 of 101 -- 3.4 Know what they value, when they want it, how much they will pay for it Summary Best product teams/organizations distinguish between customer requirements and product specifications. They work hard to get requirements right in terms of the solution the customer is really looking for. Normally, specifications are considered "right" regardless of customer need. "Customers typically don't know what they want. If they do it usually confirms what we already knew." Normal Get specifications "right" regardless of customer need. The attitude is "Customers don't know what they want; asking them confuses them and us." When talking to customers, it's difficult to hear anything new. Customers often talk about their business and not about the product, or they just confirm what we already knew about the specifications. Lots of customer information is available (customer satisfaction, root cause analysis, etc.), but it's not connected to the requirements process. Best The best teams distinguish between customer requirements and product specifications. They get requirements right in terms of customer solution and total customer satisfaction. The best teams evaluate the product's value in terms of a solution on actual customer path and consider the product's role in the entire experience the customer has with your firm. Executives articulate the business logic of customer satisfaction and communicate the message that customer satisfaction relates directly to market share and repeat business. The best teams link customer satisfaction directly to the requirements-setting process with a closed loop. Use the Teach-Negotiate-Tell (TNT) approach to customer involvement: • T (Teach): Let customers teach the core team how the product is used to achieve a business solution on the customer path. • N (Negotiate): Agree on "how much is enough" for key requirement trade-offs. • T (Tell): Tell them what you are planning to do (what the specs will be and the delivery date). Find out if they will regard this as a superior product or a "me, too" solution at time of introduction. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 59 -- 59 of 101 -- 3.5 Understand customer wants vs hows; prioritize the drivers that maximize customer satisfaction Summary Best product teams/organizations develop product specifications by: • Systematically studying the customer's priority requirements • Learning and responding to the total customer satisfaction "formula" Normally, customer requirements are skipped in favor of going directly to product specifications. Customer input is acknowledged only when large customers complain. Normal Skip customer requirements and go right to product specifications. Use complaints of large customers for primary guidance. Quality Function Deployment (QFD) considered too complex; other VOC tools too soft. Best Customer requirements and product specifications address two different but related worlds; the best teams always distinguish between the two. Since the customers ultimately determine whether the specifications are right, "you might as well find out up front and fast." The best organizations converge the information from several VOC tools (focus groups, surveys, customer satisfaction database, etc.). They use QFD or something like it; it's the best way to get high quality and low-cost products. Specification changes is one of the primary causes of TTM delay because it emphasizes do-it- right-the-first-time (DRFT), the best teams use the QFD process as it reduces the total number of specification changes over the life of the project. If QFD is not used formally, the best teams use an informal tool that accomplishes the same and is mandatory. Otherwise, the product will ship with inferior specifications or there will be delay from rework to correct the specifications later. Even if QFD is not used to establish specifications, the best organizations establish a small team to run a modified QFD as a fast validity check on the effectiveness of converting the customer's requirements into specifications. The best teams run the following validity check on specifications: take the six specifications derived from the customer's top half dozen requirements; get six customers to "sign off" that; each specification reflects a valuable interpretation of the customer's underlying requirement. Based on their knowledge of likely competitive trends, delivery on the specification would be superior in the marketplace at the anticipated time of the product's introduction. If other relevant specifications are delivered at competitive parity, they would buy the product. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 60 -- 60 of 101 -- 3.6 Start design while refining requirements; never freeze specs Summary Best product teams/organizations develop short form ("abbreviated") specifications in order to start design while they are concurrently refining customer requirements and product specifications. They recognize that freezing specifications does not take into account the changing needs of the customer over the development cycle. Instead they: • Work consciously to minimize the "change volume." • Attempt to incorporate as many changes as possible early in the development cycle (when the rework penalty is less). Normally, work on product design does not start until specifications are fully defined. Or, design begins with few, if any, specifications. Normally, a change control strategy does not exist or is ad hoc resulting in an arbitrary freezing of specifications or a large volume of specifications that tend to rise throughout the development cycle. Normal Designers start with few if any specifications Designers are forced to follow the phase review steps and not start their work until specifications are fully defined. Best The phase review concept is a convenient simplification used by management to control projects and empower the team. Specification setting and design are by nature interdependent. Feasibility and desirability are inseparable. One without the other makes no business sense. In innovative development projects, both are evolving. The best teams run them concurrently from the start. The best teams get the design started ASAP with fast 80-20 initial specifications. With a few leading customers they use a fast but informal QFD to develop a short package (one page) of specifications expected to meet 80% of the customer's most important requirements and expectations. The best teams coordinate the progress of the design process with the QFD process; they install version control on external and internal specifications. Ad hoc or no-change control strategies results in divergent or chaotic paths to converge specifications. Normal organizations follow a strategy of Fixed Containment of specifications. They freeze specifications at the front end and insist on no further changes. Because the world changes (e.g., customer needs change, competitive offerings improve or technical difficulties arise). ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 61 -- 61 of 101 -- These almost inevitable events force a major re-plan to another set of "really" frozen specifications. This cycle (freeze specifications, the world changes, and cause major re-plan, re-set specifications) is one of the primary causes of TTM overrun. In normal operations there is a large volume of specification changes (especially around major re-plans); the rate of change rises as development proceeds. When customers are involved normal organizations have systematic procedures for convergence (i.e., the more customers you ask, the more specification changes and rework you get). However in the best organizations make the minimum number of changes to achieve convergence and adaptation of specifications. Even if the total number of changes remains the same, it's faster when they are front loaded (when the rework penalty is less) and then taper off as development proceeds. They follow a strategy of Flexible containment of specifications: They get a short form set of "fast specifications" early. They minimize the "change volume", but maximize the speed of adaptation to customer or competitive changes through continuous use of VOC and QFD. They minimize the change volume but maximize the responsiveness to technical feasibility or difficulty through delineating a path of early commits proceeding to late commits and contingency planning for high risk modules. The best teams establish change control guidelines and a Change Control Board (CCB) to implement flexible containment. They expect development teams to govern themselves to the "spirit and letter" of the guidelines; whenever the CCB was needed, they convened it instantly. The best teams review the change process in the rapid decision-making forum and use the following guidelines: • Stop the unnecessary changes. • Sort the early from the late commits. • Implement all changes quickly. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 62 -- 62 of 101 -- 3.7 Fail-Fast; integrate/proto early, frequent & many do-it-try-it-fix-it learning cycles Summary Best product teams/organizations push for early systems integration in order to prototype their design so that they “fail” as fast as possible. They know that with failure comes learning and the faster they learn, the faster they innovate. They accelerate learning cycles (do-it, try-it, and fix- it). Normally, failure is avoided because it represents poor design thinking. It should be right the first time, so teams take a long time to get to the prototype stage (systems integration). They integrate later in the design cycle, so problems surface close to final design verification milestones, then push past target dates when more time is required because it was not right the first time. The learning cycles are elongated because people want to make sure each step is perfect, causing slower overall learning. Projects take longer. Normal The phase-gate waterfall product development life cycle determines behavior. Each function passes the baton to the next in a sequential and methodical manner. The integration phase of the design process is at the end of the life cycle. Each function focuses on making their part perfect. The theory is that if each function does their job (i.e. Unit Testing) then when the final system is integrated it will all work flawlessly - since all the subsystems have been verified, the integrated system should work as designed. In practice it does not work this way, since problems caused by systems integration can’t be predicted or tested at the unit level of the design process. This is even more true for extremely complex systems. In fact, it is the integration process that usually surfaces design failures. The reason for the late integration is typically caused by functional development practices. The engineering is validated (EVT), then passed to a different group of people to validate the design (DVT) where systems are integrated and prototyped, and then the new product is production validated (PVT) to confirm it can be manufactured within cost targets and conforms to technical specifications. Each phase is linear. Failure at any stage causes the design to cycle back through each step sequentially (EVT->DVT->PVT->EVT….). Design failures are usually found later in the process using this waterfall method as the product gets thrown over each silo wall to the next group of specialists. This process is slow and can result in integration problems and/or manufacturability issues later in the life cycle. The higher the silo walls, the greater the integration problems later on. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 63 -- 63 of 101 -- Failure is avoided. The “right the first time” mindset causes people to spend a lot of time making sure their design works. The time accumulates with each design step. Some teams say, “It is not as important for us to succeed, we just can’t fail.” Fear of failure and being blamed for it causes engineers to hold on to each step as long as they can to make sure everything works prior to system integration. When the product is finally integrated, either as a simulated design or a physical product, they find problems that no one anticipated. However, much time was lost in the early stages making sure everything was right, so the team has lost any buffer to iterate the design and prototype builds. Ultimately more design iterations are required and the project slips. It is forced back to the start of the design process for the long journey back through the linear phases and gates. Best The product life cycle development process is agile and iterative. Teams are encouraged to fail as fast as possible because they know that failure is the fastest way to learn. Learning is the fastest way to finding technical solutions. With solutions comes innovations. When teams accelerate their learning, they can accelerate the product’s development. They try to “break it” early in their design thinking through early prototyping and/or simulated systems integration depending on the product. They use this failure analysis knowledge to improve the design. It is understood that unit testing will not catch all the problems. They unit test rigorously, but push for early integration to evaluate how the design behaves as a system. The behavior of the system informs future design decision-making at the unit level. Cross functional teams are involved in developing the product. The functional silos that gate each development milestone are not present in FTTM Teams. FTTM Teams still go through the EVT, DVT, and PVT phases, but they are performed concurrently (i.e. overlapped). There are no gates, but rather checkpoints. The fastest teams have the greatest degree of parallelism in their development process. In the 1970’s-80’s this was called Concurrent Engineering, now it is referred to as Agile Development. It is the same thing, doing steps in parallel and iteratively, but now with a new name. They strive for rapid design-test-fail cycles as the path to quicker learning. This means that there are many system integration tests (both simulated and physical depending on the product). Each team member works with the assumption that “It is better to be roughly right, than exactly wrong.” This means that roughly right is faster and good enough at the unit level, because they know that the more complex problems will result during systems integration testing or the prototype phase. Spending more time in the diminishing point of return part of the curve is a waste of time. The push to get the design to the point it where it can be integrated into some form of a ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 64 -- 64 of 101 -- prototype (physical or simulated), because they know that this will result in identification of design problems earlier that will need to be solved. Learning is accelerated by getting to the prototype stage faster, then trying to iterate faster by accelerating the time each step takes (design-test-fail-redesign). The high performance teams accelerate learning even faster by running concurrent design-test-fail cycles (i.e. well managed Design of Experiments - DOE). ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 65 -- 65 of 101 -- For example (above), they start DOE1 followed in time later by DOE2, when DOE1 is ready they evaluate the results while still processing DOE2, they start DOE3 to verify what they learned from DOE1 while DOE2 is processing, when DOE2 is finished they start DOE4 with learnings from DOE2… and so on. This concurrent design cycle is key to faster development cycle time. They know that the additional costs associated with concurrent agile development are a fraction of what they return with on-time or early delivery of the finished product to the market. Most importantly, the “fail fast” mindset is the key to unlocking or freeing-up creative thinking about problem solving. Fear of failure usually stifles creativity. Early integration and design validation is the key. It provides a validation of the design thinking early enabling vector changes based on failure analysis. They know that there will be many design validation iterations, not just one big one at the end. This causes more experimentation earlier in the design process and more understanding of the problems that need to be solved. This provides before-the-fact knowledge much earlier in the creation process that can be used to refine design thinking. Short intervals of iterative learning and incremental vector changes lead to faster solutions. Long intervals, few iterations, and big vector changes usually result in big project delays and/or compromised product design. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 66 -- 66 of 101 -- 3.8 Cross Functional Core Team ROLES not FUNCTIONS; lateralized Summary Best product teams/organizations organize their core teams around roles, such as Architect and Chief Engineer. Each team member has a functional responsibility, such as Hardware or Software, but the dominant behavior/bias is towards their program role. These program roles cause a lateral focus from beginning to end of the development project. Example of a core team’s roles, using a Steering Arm to help them remove organizational interrupts. Normally, teams are organized around functional responsibility, such as Hardware or Software. These functional roles cause a vertical bias within each person’s functional specialty. Effectively repeating the functional silos at the core team level, creating more emphasis on the parts rather than the whole. Definition A “core team” are typically 5-10 key people that are responsible for developing a new product or executing a project. They represent each of the functions that touch the product from the initial concept through design and engineering, and on into manufacturing and out to distribution of the new product to the customer. FTTM teams include all functions on the core team on day one, from marketing to manufacturing and even finance, procurement, and HR on larger projects. They also give members project “roles.” ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 67 -- 67 of 101 -- Normal teams focus on engineering core teams (i.e. the disciplines represented within the engineering function) and only tangentially involve marketing at the start of the project, then hand over the design to another “core team” in manufacturing that is charged with making the product manufacturable or meeting production cost targets. More typical are multiple functional core teams moving the ball up the field from one function to the next. Normal The core team, if there is one, is really an engineering team because it is understood that the engineering phase of the new product creation process is the most critical one. Marketing develops the MRD (marketing requirements document) and hands it off to engineering, so there is no need for them to be on the project core team (of engineers, which is the main focus of development anyway). The requirements conflicts are rarely resolved at this stage, because each side maintains “plausible deniability” - marketing can blame engineering for not developing what the customer wanted and engineering can blame marketing for not clearly describing that the customer wanted. What is eventually developed is usually what engineering can create, rather than what a customer expected (if anyone really knows what the customer expected). The conflicts in requirements is rarely reconciled due to the “siloed” organizational/teaming structure used to manage the project. The manufacturing function also does not need to be on the core team because their role is later in the process and there is no need to waste their time on early development issues, because they are focused on downstream problems associated with manufacturability and production of the current products being manufactured. They are not involved up front in the gestation phase of the project where they may have been able to inject “design for manufacturability” (DFM) thinking into the design team. The core team is a cross functional engineering team made up from each of the engineering disciplines. There is for example a hardware team member, a software team member, maybe a test and verification team member, and various design leads who can also be on the team. The team also includes technical subject matter experts (individual contributors). These “teams” can be quite large, sometimes 20-30 people, because no one wants to get left out of the technical decision-making process. So in effect, these are not really core teams, but can contain almost all the people working on a project. The bigger and more complex the project, the greater the number on the “core team.” Meetings tend to be frequent, long, and poorly structured, often degrading into “rat hole” technical debates and discussions with the strongest SME’s winning hard fought arguments. The team meetings are one of the few sources of information about the project, which is why they attract more people than are typically on the standing invitation list. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 68 -- 68 of 101 -- There are usually a few subject technical matter experts and position-power people that tend to drive these teams. The emphasis is on the function and the particular issues/problems in that function at that time. There is less of an emphasis on the product and the overall schedule, unless there is also a project manager on the core team. The project manager on these teams is more of a record keeper and occasionally raises red flags about delays, but few pay too much attention because the emphasis is on technical problem solving and “the schedule was unrealistic anyway.” Since the core team is dominated by functional thinking, discussions tend to drill down into specific areas of the project often losing sight of of the product perspective. Much time is spent on SMEs defending positions or establishing the ground rules for the integration points between functions - “I deliver X to you and you deliver Y to her….” Really, engineering core teams are just a new term for what used to be called engineering department heads that would meet regularly to try to synchronize the development efforts moving through their functions. Then the term “team” became the way to describe any group of more than two people. Every gathering of people became a “team.” Then “cross-functional” teams became the rage. When applied to “engineering” core teams they meant that that you invite all the department heads or technical leads from engineering to be on a “cross-functional” project team. Of course the same people site on every cross- functional team in the company, making this group the information bottleneck in many cases. Best The core team is a dedicated (100% to a project if possible) group of 5-7 people who represent each of the functions that the product flows through from concept to volume production. They assume project roles, subordinating their functional roles (which they still maintain). These project roles include; chief engineer, system architect, system integrator, customer integrator (marketing) and so on. They have another outer layer of core teams (sub-core-teams) that tend to be more focused on each function, such as an engineering core team comprised of each of the various engineering disciplines. This engineering project core team would report into the Chief Engineer on the program core team or the System Architect, for example. The second layer of core teams can also represent integrated project milestones deliverables. So for example, one of the first milestones is to define the product. This could be a team lead by the marketing person (customer integrator role) on the program core team and include representatives of the engineering and manufacturing sub-teams. The milestone team is formed ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 69 -- 69 of 101 -- for the sole purpose of completing the integrated project milestone and then disbanded to form new “milestone teams” associated with subsequent milestones. These milestone teams report into the program core team of 5-7 people. There can be hundreds of people working in this flat configuration, with a small group of people in the center and multiple sub-core teams revolving around it, like the moons revolving in concentric circles around a planet. The emphasis for the program core team is “role” responsibility. Take for example the Systems Architect role. The Architect is responsible for the total product or system and how each element of the system interacts/interfaces. They focus on the interface points and make the trade-offs necessary to optimize the total system (rather than sub-optimizing its components). There are always cost, technical, and resource trade-offs that need to be made to deliver on time. The system architect owns this job. The Architect is responsible for making these calls so that the end product is not compromised. The Architect may also wear a functional hat on the core team. They may also be, for example, the person who is responsible for the software development function. But their functional role subordinates to the program role. One of the missing “roles” on many failed technical development projects is the systems architect who oversees and makes trade-offs for the betterment of the end product. When products fail technically, it is often due to sub-optimized decision-making which is driven by functional role bias. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 70 -- 70 of 101 -- 3.9 Get best people; mix of inside & external SMEs; virtual teams Summary Best product teams/organizations secure the highest technical and skill level people for their development projects combining internal employee resources with external contract resources who function as the virtual project team. No distinction is made between internal and external resources. It is one virtual team focused on a single mission. Normally, development teams are put together with who is available at the time. Little to no effort is made to secure external resources due to the fear of IP leakage or a belief that the only people that have subject mater expertise are already within the company. Key people are usually oversubscribed due to there being too many projects and not enough people. Resource conflicts go unresolved and the best people are always oversubscribed. Normal New projects are initiated with the people that are available at that moment in time. Teams are resource starved as a management technique designed to “optimize” the headcount. Teams are usually understaffed and lack specific skills due to the “What is available” method of project staffing. The key people on the project are also working on manny other projects at a time that are further into their development life cycles, so their contribution at the start of the new project (where their time is most critical) is minimal. Firefighting current problems take precedence over preventing future problems from occurring. The best people are stretched thin firefighting. This is a cycle teams find impossible to escape. The general feeling is that what the team is creating is so special that there can’t be anyone outside the company that can help them. This bias has secondary “job security” benefits for the inside people, making them more valuable to the company. Further, the fear that intellectual property (IP) will leak is the other reason external resources are not investigated as possible project contributors. “We can’t get consultants on our project because then everyone will know what we are doing,” becomes the main reason for doing it all inside the company. An inability to use external resources exacerbates the resource problem making internal specialized people even more overloaded/overworked. Further, lack of external thinking tends to focus the technical problem solving on what the people inside know and down’t know, making it take long to solve difficult problems. Teams make due with what they have been given. At the end of the day, lack of the right people, with the right amount of time and skills becomes the perfect fallback excuse for non- performance on the project. Management knows this too, so they don’t push it. This behavior ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 71 -- 71 of 101 -- often leads to general cross-team morale problems and a defeatist attitude when the best people are not able to be secured for difficult development projects. Best The project team is seen as the most critical thing to get right. The wrong team means certain future failure, so every effort is made to secure the right resources on day-one of the project’s formation. This includes not just the needed quantity of people, but also to put in place a group of people with the necessary technical skills to achieve the project goals. Tremendous effort is made to secure the most technically competent people in their respective fields, regardless of them being inside or outside of the company. Careful balancing of the project portfolio enables proper resource planning so that resources from Project A can transition in time to start Project B, when Project B is getting started. The fastest teams have fully dedicated resources to a single project. Medium-fast teams have resources spilt between 1-2 projects. Slow teams are accessing resources that are multiplexed across <2 teams (the typical allocation is 5-10 simultaneous projects in shared functions like “central engineering”). Project teams are resourced, fully, on day one of the project or a careful effort is made to bring key people onboard prior to the time they will be needed on the project with some consideration made for the start-up learning phase required to become productive. The right people delivered to the project at the right time is a major focus for management, HR functions and external recruiters, because they know that the right-team can have the greatest impact on a project’s outcomes. No distinction is made between internal employee resources or external contract resources (contractors, consultants, suppliers, vendors). If the team lacks a skill, then that skill is quickly retained from the outside if that person or resource is not available inside the company. IP protection is secured through NDAs and everyone recognizes that TTM is the best form of protection, in that if the project is late then the value of that technical knowledge is lower if it were communicated to a competitor (it is now out of date). Who wants “old” or outdated IP? This is a conscious trade-off made to get the right people who can enable the project to get to market faster. Obviously, the most sensitive differentiating IP is worked on by inside people, because it is recognized that this IP has the core value the company provides its customers. These teams have inside and outside people working such that it is hard to tell who is an employee. They are all focused on the successful project outcome. Further, using external resources is a way to deal with the periodic resource shortfalls experienced in a multi-product development environment when resources from Project A are not available to roll-off onto ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 72 -- 72 of 101 -- Project B. The external resources bring new thinking to teams and help to accelerate problem solving, because they tend to have broader experiences to leverage. The Host knows that if they provision the team with the best people at the right times during the project, they can eliminate this as a possible excuse for poor performance later on. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 73 -- 73 of 101 -- 3.10 Aggressive planning Summary Best product teams/organizations use critical path scheduling systems and involve the whole team in interactively planning the program. These teams spend 3x the time in planning their work than normal teams. They reconcile the schedule to the targets and if the gap is too great, kill it before it starts. When started they aggressively refresh their plans every week and are constantly looking for ways to pull-in the schedule – before it slips. Normally, when schedules exist they are not reflective of what is actually happening on the program and therefore not used by teams to manage the work effort. Schedules don’t represent the “real” time necessary to accomplish the goals, but rather reflect the “not bought-in to” program targets of senior managers. Large slips are typical and unforeseen. Normal Schedules, if the exist at all; tend to be conveniently “manufactured” to meet the top-down driven dates that have been “given” to the team. Somehow these schedules always show the project finishing “on time” at the beginning of the project. These top-down schedules never change, until the day of a milestone review meeting when it is announced that they have slipped the project 6 months. “Group-think” sets in and schedules are not challenged for their accuracy or completeness. Individuals who challenge the schedule are perceived as not being “team players.” Schedules rarely reflect the reality of under-resourcing or over optimistic estimates of what can be done… and are rarely believed by the "workers” who have to complete the tasks. And as a result, are seldom used as a tool for managing daily workflow – only for presenting status to top management. Since schedules are rarely changed during a project, they quickly go out of date and only get modified prior to major status review meetings. Most team members never see the schedule and work on the things they either; a) want to/have interest in at the time, b) have been told to work on by their functional manager, or c) guess they should be working on based on information they have gleaned from attending many, many project meetings. Schedules are high-level and don’t reflect what the team is actually doing. Schedules mimic the functional structure and further reinforce the walls between the silos. Schedules for gestation, customer involvement and process improvement activities rarely exist. Development schedule content and design are not improved or reviewed after they are first ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 74 -- 74 of 101 -- built. The prevailing attitudes regarding scheduling are, "Don't tell me my job. -- I'm a competent professional. -- I can schedule my work better than an outsider. Just make sure I get the inputs from others that I need - when I need them." Lots of time and creativity is spent on the "design of the product.” Almost no time is spent on the "design of the work" required to accomplish the new product development schedule. There are design reviews of the product. There are no "design reviews" of the work content. They resist short interval detail; they fear opening the door to micro management and control by senior managers. They fear over planning. They do not have sufficient grasp to define activities in short duration detail. Focus is on damage control and after-the-fact recover efforts to deal with major slips in the schedule. Fire fighting and heroics are rewarded when a project is saved in the “eleventh- hour” through overworking (i.e. motivating) people and compromising the product functionality in the interest of time. Best They use a rigorous critical path based planning and tracking system, in order to: • Develop customer focused mission statements and milestones: structured on customer needs rather than on internal functional deliverables. Create work-breakdown-structures with near-term detail. • Generate market driven schedules based on customer need dates (rather than when they can get it done based on their available resources). • Get top-down and bottom-up commitment to the schedule. • Know the difference between a TARGET and a real SCHEDULE. They understand the gap and take before the fact action to accelerate the schedule. Create realistic schedules that are developed by the team, for the team as DRIVERS rather than REPORTERS of status to senior management. If the gap is too great and can’t be closed, they kill the project. REFRESH the schedule every week (sometimes more frequently) with more detailed activity breakdown, actual work completed/in-progress reports, and try and pull-in their critical path in the near-term. Pull-in the schedule before it slips. They scrub every aspect of the TTM cycle. They pay attention to schedules for the gestation period, the voice-of-the-customer involvement, improvement of processes, as well as the development schedule. They know that scrubbing expands grasp. It increases the cycles of learning about what it takes to produce the desired outcome and it promotes migration of practices throughout and across teams. They recognize that scrubbing replaces the "mistake, fail, punish" cycle with a "try it, fix it, recycle learn" cycle. They know that grasp of the whole ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 75 -- 75 of 101 -- plan in sufficient detail is necessary to control the work and pull in the schedule. They treat scrubbing like a "design review" of how the work is to be done. Most of the opportunities to improve the way work is done involve the dependencies between work activities. They understand that all team members need not grasp the entire plan. Scrubbing should not be done with the whole team; rather triads of knowledgeable and capable individuals get together to scrub small chunks of the schedule. They move up the planning continuum: • No planning • Planning but no refreshing • Planning with continual refreshing During the development of the baseline plan they scrub for completeness, accuracy of activities, activity duration's, resource allocations, precedence relationships, potential for concurrence, and preventive and contingent actions. During the execution of the project they scrub for short interval schedule pull in opportunities. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 76 -- 76 of 101 -- 3.11 Macro-micro planning; micro near, macro far, short interval scheduling Summary Best product teams/organizations start planning their projects from the macro perspective to include all aspects of the product realization process from concept to release. They breakdown the near-term schedule (<6 weeks out) into smaller micro increments that are used to pull-in/ accelerate. They roll the planning window forward every few weeks, breaking down into shorter interval as they go and when more is known about the project. Normally, detailed plans are generated for the complete project. It is time consuming, so few people work on it so there is little team buy-in. If the project changes scope, then the planning has to be redone or is not done at all due to time limitations. There is a belief that detail equals accuracy, so more micro detail means a more accurate schedule. Normal The planning process is a painstaking and laborious process involving just a few people and usually just the project manager compiles detail functional plans from the various functional teams working on the project, such as software, hardware, mechanical, test, and manufacturing schedules. They do their planning on their own, without the project manager being present. They are all separate and detailed schedules that describe each function’s work flow. They are usually in different formats and follow different standards which make it difficult to integrate. The project manager is left to somehow stitch them all together into a cohesive integrated plan. Since they were done separately, the interface points between functions don’t match up. This starts the “communications” problems between functions that the project manager is supposed to sort out (“manage”). ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 77 -- 77 of 101 -- The detailed schedule is too complex for anyone to understand, so few people ask questions about it or refer to it in their daily activities on the project. It is really just the “project manager’s schedule” and quickly goes out of date as things change on the project. Detail is seen by everyone as providing a more accurate estimation of project completion and project status. So more detail planning is always encouraged, which further consumes people’s time making them hate the planning process even more. Detailed schedules are usually complex. The complexity renders them unusable, but they make impressive documents to scare senior management away and give them confidence that the team knows what they are doing. As a management tool for the team, these detailed schedules tend to be of little value. Rarely does the detailed plan provide a reasonable estimate of completion compared to when the project is expected to be completed, due to its complexity, poor structure, and functional bias. Best The core team (5-10 people) meet for 1-2 days in a focused offsite workshop to develop their macro plan. They are able to look at the project in the abstract; from a “macro perspective.” The macro plan is no more than 50 tasks that represent the total project from concept to some future defined end point (usually some sort of product introduction or manufacturing ramp phase). The macro plan is constructed using 4-6 major integration points by which the team will measure progress. The outcomes of each integration point are agreed to and differences are reconciled between team members. Expectations are mutually set and confirmed at this point. These are cross-functional milestones. Cross-functional integration is forced top-down through this process. This avoids the interface problems described earlier as “normal” and the separate planning associated with the functional bias. The macro plan is a strategic statement from the team about where it is going and how it will get there. It is designed to raise and respond to the strategic decisions that must be made about the project in the early stages in order to finish on time. The macro plan provides the first gap analysis to the core team. This is a measure of time from when the project is needed to be finished to when it really will be finished, based on the critical path macro schedule. Most projects are late by 30-50% of the overall project duration, but rarely do teams know it in the first 1-2 days of starting their projects. The macro planning workshop generates this critical gap information and causes the full team to participate in the planning process, which is the first step in getting cross-team buy-in to the schedule. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 78 -- 78 of 101 -- The macro plan also permits the core team to do simulation studies together to explore alternate paths to faster project outcomes. These simulations generate the strategic discussion needed at the start of a project in terms of how the project should be structured, what technical decisions need to be made, what resources are required, and so on. The macro plan does not cause the team to get lost in the forest they way detail micro planning does, but rather it provides a birds- eye view of the complete landscape from start to finish. The gap that emerges from macro planning usually stimulates urgency much sooner for project teams and the supporting management hierarchy. When, for instance, you know that your project is 6 months late on a 12 month project completion window, you know that strategic decisions must be made to close this considerable gap (your 12 month project is taking 18 months). When this information is not known, teams tend to accept the project requirements that they where given and only find out much later into the project that they are missing the target date by a wide margin. By then it is too late to recover. The macro planning process exposes the gap sooner, with very little information, when there is still enough time to take corrective action. As time moves forward, teams breakdown the macro plan into incremental detail. This involves the next level of team member participation, either team leads and/or individual contributors do the task breakdown. The macro plan provides the framework to decompose long duration macro tasks into smaller 1-15 day tasks. The focus of the breakdown is <6 weeks out, because any further out into the future usually means less clarity. The more cutting edge the technology, the less clarity teams have on future details. So they only breakdown what they know today. The planning window roles forward every few weeks with more tasks being decomposed as more is known. This process avoids major schedule redo’s when things change significantly. The point of breaking down into detail is to find ways to do the work faster by either doing it differently or doing things in parallel or even eliminating things all together. The near-term detail is used to accelerate the near term schedule or recover time that was lost due to slippage. This is called short-interval scheduling. There is no sense breaking down future tasks if the details are not known to the team at the time, so future tasks are left as macro placeholders that can be decomposed when more is known in the future and as you get closer to them. Eventually, the project is fully broken-down into detail, about the same time the project is finishing. So planning never ends on FTTM Projects. It is continuous, iterative, and constantly changing as the project changes. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 79 -- 79 of 101 -- 3.12 Team planning, simulation, continuous scrubbing, breakdown, ownership Summary Best product teams/organizations involve the complete team in planning and tracking their project through an engagement process involving ongoing schedule scrubbing to gain individual ownership over the project outcomes. Normally, a single person (project manager) creates the plan. The plan is then shown to the rest of the team who are expected to buy-in and accept it. There is very little group participation in the ongoing maintenance of the schedule as the project changes, normally the solo project manager is driving all changes to the schedule and reselling the new dates to the team. Normal The project plan is created by one person, usually the project manager or technical lead for the project. They use their own individual experience or may involve 1-2 others if needed at times, but the basic organization, work-break-down structure, duration estimates, and network logic are made by the project manager. If things don’t fit, the project manager reduces durations until they do. These aggressive duration estimates become “challenges” and “opportunities” to think creatively by the people who have to do the work. They tend not to be very enthusiastic about these opportunities. When finished with his/her detailed plan, the project manager needs to “sell” the schedule to the rest of the team. Because they were not really involved in creating it, they are somewhat confused by the schedule and don’t say much for fear of looking ignorant or getting too involved. They know it is not their plan, so have little interest in the details of it in terms of the logic and time estimates that where made for them. Oddly, the schedule fits inside the time specified for the project’s completion. This further disengages team members, because they know that the durations are underestimated and certain risks have not been factored into the planning. It is a best-case, 100% goes right schedule they are seeing for the first time. After the schedule review meeting with the team, the schedule quickly becomes out of synch with what the team is actually working on. The effort to maintain the schedule (so it reflects what people on the project are actually doing) is so great that the project manager spends less and less time keeping her/his schedule up to date. They default to their management tasks of driving daily activities and communicating project status to higher level management. The schedule slips into the background. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 80 -- 80 of 101 -- Periodically, the project manager tries to bring the schedule up to date for major milestone reviews or to check off a item at a gate review (i.e. “Up to date schedule presented, check… it is done, move on to the next gate review line item”). The schedule and the work on the project tend to drift away from each another. The team rarely sees the schedule and uses their own detail methods for tracking their own work (spreadsheets, cloud team collaboration, email, lots of meetings, and so on). The project manager uses these different information sources to try to estimate current status and when each group will finish. There is ongoing of discussions about why the team does not buy into the committed dates and why they don’t spend more time planning their work, but little changes in the way they plan. Best The full team is engaged by the project manager in planning and tracking the project, so that the project initially reflects their committed dates and on an ongoing basis, so that it keeps pace with the changes occurring in real time on the project. This is done using low-time-overhead practices enabling engineers to focus on their work. The team spends the necessary time to plan and simulate different critical paths to specific end points. They know the planning time invested will pay off over time with better coordination and communication across the team. They understand the schedule gaps and explore, together using the schedule, how to close those gaps. The exploration process brings the team closer and exposes all of them to future challenges, in advanced - like having a project simulator. Periodically, team members scrub the schedule in smaller groups. Scrubbing means to review detailed sections of the schedule for accuracy and completeness, based on the changes on the project. Constant schedule scrubbing generates ownership in the data and the schedule outcomes across team members. This is their schedule and the project manager is their planning facilitator, but it is clear the team members own it. The project manager does not touch the schedule without team members present. They use it for daily management of tasks, because it is up to date and reflective of what they are working on. They use it to predict future events and to evaluate project trends, again because it accurately reflects what they are working on. They use it to identify the interface points they have with other groups and what inputs they need to get from them and when they are needed to stay on schedule. In general, they spend far more time planning than normal teams. They accept the investment of time because they know what kind of return they get from their time investment. Visibility, transparency, early warning, low overhead reporting are all the benefits they get from putting in the time with the project manager to accurately build the plan and then to scrub it continuously, so it remains accurate. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 81 -- 81 of 101 -- 3.13 Market/customer driven versus resource constrained Summary Best product teams/organizations plan new product development projects without initially using constraints (time, cost and resources). They focus on the market window or a driving customer’s timing. They work out the optimal schedule and then evaluate the gap, then use techniques to close the gap. Then they apply constraints to the optimized schedule. This provides more gap data in terms of resources and cost. Similar techniques are used to close these gaps. Normally, plans are developed from the inside-out. The plan is a function of the available resources and money. This results in schedules that push past target dates, so the schedule is arbitrarily cut to fit the time available. The resource constraint is never exposed nor resolved. Later in the project it will return. Normal The plan is a function of the available resources. Duration is derived using resource driven estimates. If 1 person would take 10 days to complete a task, then 0.5 of a person would take 20 days. This kind of bottom up thinking is used to generate the schedule. It is called “resource driven” scheduling. Working within the limitation of a constraint is a corporate mindset, “I only have X therefore I can only do Y.” No one ever challenges the assumptions, they just accept them as is and as fact. This acceptance of constraints translates to other aspects of development. Space, power, cost are all typical design constraints. Engineers wonder why they can’t solve problems when they accept what they have as a given and then try to solve within them. They know it can’t be done, but have no way of communicating it without sounding like they are complaining, so they just accept it knowing that problems will always resurface later. To challenge the constraint assumptions is to not be a “team player.” All planning is done inside the constraints given to the team. “You have 12 months and $5M dollars and 15 people to do this project, now show me a schedule that gets me there in 12 months for less than your budget…” The team comes back with a 12 month schedule, at less than $5M, and all 15 people are fully utilized. In the end, the project takes $7M, 18 months to complete, and consumes 30 people. Why the disconnect? Because they worked backward from the constraints. Plans naturally follow this pattern in normal environments. Work expands or also contracts to fill the time available for its completion. The problem started when planning from the constraint. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 82 -- 82 of 101 -- Teams talk themselves into believing it can be done, because it has to be done. The gap is never exposed. The people on the team know there is a gap so they remain skeptical of the planning and the commitments if forces them to make. In order to address the market and customer timing demands, the team force fits the schedule using available resources. If they show their original resource-driven schedule, they get shot down by management. They are forced to live with their situation even though they know it has a high probability of failure. Best Ignore constraints, with one exception they recognize the market or customer timing requirement and call it the “target date.” The target date and the schedule dates are two different things. One is when it is wanted, the other is when you are going to get it. Want and Get are not automatically the same. The targets are then turned off and used later as a reference point during schedule gap analysis. They not only ignore the time constraint, but also the resource and financial constraints. They plan assuming they have the resources and skills they need. Most projects just get worse when you add in constraints. Even with no constraints, projects are usually late, so why start planning from them? Resource driven schedules simply show that the project can’t be done in time, but this does not resolve the conflict. Why waste time making them? This is not to say they don’t factor in risk, complexity, resource efficiencies, and some degree of resource availability (no one is ever 100% available). These are constraints that make their way into estimating logic. These are factored into duration estimates and the number of contingency tasks they add to their schedules to account for risks and unknowns. They don’t use the number of resources they have to plan, they define what work is needed to achieve an end state, determine how long it will take to get there, and then determine how many resources are needed to get the tasks done in that time frame. So it is a “what is needed?” versus a “what do I have?” estimating process. What results from this is a plan that more realistically estimates the resources needed to get to market at a given point in time. If there is a gap, they model the schedule acceleration needed to close the gap. What usually happens is that more tasks are done concurrently, more risks are taken, and more things have to happen on time in order to stay on schedule. The additional resources required are modeled in the accelerated scenario. At this point it becomes a business decision; should we add more resources to accelerate the schedule? What is the ROI? or is there another way to do the project, such as outsourcing part of it that would reduce our resource/financial exposure and still achieve the project goals? This process is a logical decision-making activity based on realistic information about How long it ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 83 -- 83 of 101 -- would take without constraints?, How long would it take with constraints? and What are ways that it could be done differently if constraints were considered? It is a scientific management process, rather than arbitrarily cutting and then closing ones eyes to reality. If at the end of the day the gaps in schedule, cost, and resources can’t be reconciled, then the project is killed before it starts, thereby freeing up resources to work on projects with a greater likelihood of success. Resources are not wasted on a project that will fail. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 84 -- 84 of 101 -- 3.14 Know the gap; drives before-the-fact urgency Summary Best product teams/organizations identify the schedule gap at the start of the project. This is the gap between when a project is expected to be completed and when the schedule tells them it really will be finished. They use the gap to generate urgency today, while there is time to affect change. This drives changes in scope, outcomes, and methods in advance of a failure to improve the project’s chances of success. Normally, schedules are manufactured to meet the demands of the audience. They show the audience what they want to see. These are “happy” schedules, since everyone is happy that the project will finish on time. The sense of urgency is low. This only delays the inevitable when the project naturally slips later on. Normal Happy schedules are the norm and can be career enhancing. The corporate culture demands that they be produced, communicated, and religiously bought into by the executing project team. Everyone knows to “get on board” and be team players. It they think positively then good this are bound to happen. There is no schedule gap in these environments, because if a gap was to be recognized and acknowledged by management, then the slip would be come self fulfilling, so the thinking goes. To avoid having self fulling prophecies becoming reality, teams generate schedule that fit nicely inside the time window they are given. This is the no-stress form of project management. At least no stress today. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 85 -- 85 of 101 -- It is less stressful to take the position to not argue that you may be late. It is seen as negative energy, you that you are a can’t-do team player, and someone who can only find faults and not solutions. With enough pressure from above even the most resilient manager will buckle under the pressure to conform to this obfuscating behavior. Managers are encouraged to make aggressive schedules and then drive their teams harder to accomplish them. When they fail, they are replaced in the harsher cultures. People see examples of this and this reinforces the culture of happy schedule creation. The schedule does not change in these places. Every week the team is on schedule. A fluctuating end date is cause for concern and could bring a load of scrutiny to the team. So the best way to avoid this attention is to report that everything is fine. It is fine at the start and it is fine most of the way through. The problem with this game is that eventually the truth catches up and reality can’t be ignored when a major deliverable is to be demonstrated. When it fails to materialize, the project reviews start and the team is inundated with “help” and lots of questions about how this could have happened and who is at fault for the mistake? A new committed date is published that is slightly later than the original date, because the team knows that if they really tell the truth, the new much later date would not be acceptable (same problem when they tried to tell management what the real date was at the start of the project). This ridiculous schedule game continues over and over again. It is painful and career limited for most involved. These organizations experience a lot of turnover and don’t know why. They assume it is caused by “communication problems,” so institute more team building off-sites and training classes. Best Fast teams and environments know the difference between a target and a schedule. The target is the constraint or goal, while the schedule is what is needed to get there. If there is a gap (usually is) they recognize it and embrace it as a tool for generating urgency at the start of the project, rather than at the end when there is no time to recover. This is a before-the-fact management system that rewards people/teams who honestly plan by factoring in risks and unknowns. “Let the truth set you free” one manager exclaimed to his teams. The gap is encouraged by senior management as a tool to be used to explore alternative strategies to do the project on time and per customer or market expectations. It forces people to think differently and to make the tradeoffs, they must, in order to fit the schedule inside the time window available. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 86 -- 86 of 101 -- Could an initial minimum viable version be released in the time available, then quickly followed by a product refresh a few quarters later with full functionality? These are the types of questions people start asking when they are presented with the reality of a schedule gap. The bigger the gap, the more open they are to challenging the base assumptions about the project. When there is no gap and the schedule is a happy one, people are not forced to think about the project differently. They figure they can get everything they want within the time frame they want to get it. Ten pounds of flour will not fit in a 5 pound sack, so why pretend that it will in order to make people feel good at the start of a project? In the end, those 5 extra pounds are going to come spilling out onto the floor. Why not use the planning process to expose this problem early, while there is still time to approach the problem differently? This is the culture of best teams who get to market on time. It is critical that this thinking be in place at all levels of management, because the honesty and transparency it creates can quickly be killed by the top manager who slams the team for showing him/her a schedule that does not finish on time. The team will quickly revert back to presenting “fake” schedules to avoid the pain. They also start to separate themselves from the project’s outcomes, which over time become the senior manager’s outcomes, not theirs. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 87 -- 87 of 101 -- 3.15 Refresh Planning; continuous schedule pull-in Summary Best product teams/organizations refresh their schedules every week, sometimes multiple times in a week. They update it with actual task progress, they add changes to the workflow, and they try to pull-in the schedule when it slips to recover lost time and when it is on time, they try to accelerate it even further to bank time for when the unknowns pushes the schedule back out again. This process is relentless and continuous throughout the project. It is the key to being on time. Normally, schedules are not updated with what is really happening on the project. The schedule falls out of synch with what is happening on the project and can no longer be used to predict deliverables and timing. It is somewhat maintained, but not relevant as a real management tool. Normal The schedule is created at the start of the project by the project manager. Very little team input is solicited, because the team members don’t have time to plan - they are already late and need to get on with the design effort - when design competes with planning, design always wins. The project manager makes her/his best attempt to to map out the workflow and estimate the time it will take to do each work package. The good ones with technical subject matter expertise can come close to approximating the project plan on their own, but then it lacks team input. When done, the plan is presented to the team as “their schedule.” The team quickly sees the deficiencies in the schedule, but does not have the time to sit down with the project manager to fix the problems to make the schedule reflect what they are really going to do. Some emails are shared and comments made to the project manager. It is up to her/him to make the corrections. All this takes too much time and besides, the project just changed direction again and the schedule that was made earlier is now even more out of date. No one has time to bring the ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 88 -- 88 of 101 -- schedule up to where project has moved. There is now only a distant relationship between the plan-of-record and the actual project direction. The schedule is rarely used by the team because it is not up to date. It does not reflect what they are doing so it is of little use to them. Rather, its value is as a management reporting tool to distract management into believing that the project is really complex and that they should not ask too many questions - they are continually told, “It is on schedule, don’t worry.” They do worry, which is why they continue to micro manage the team, but few actually look at the schedule. Best The schedule is created by the team, scrubbed, and the gap analyzed. Alternative paths to completion are modeled and decisions made about how to position the project to improve the team’s chances of success. It is an open, transparent, and honest scientific process. The baseline schedule is refreshed weekly, sometimes daily by the core team. They tell the schedule what actually happened and re-estimate tasks that are not complete, based on new information generated by working on the tasks. They bring all tasks up to date to the current status of the project. They always know where they are because every update causes the schedule to match what is happening on the project. This is a low overhead effort, taking 30-60 minutes for each weekly team refresh meeting. Once the schedule is updated so it reflects the current state of the project, a new critical path is calculated to the end date. This usually reflects a slip in the schedule, because most projects will always move to the right if not pulled-back. The core team models different pull-in scenarios and determines the best actions to recover some of the lost time or even accelerate the project ahead of schedule in order to bank time for the future, knowing they will withdraw from the time-bank when the unexpected happens. More sophisticated teams will peel back the critical paths to determine the longest path and the paths immediately behind the longest paths. This focuses team attention on reducing multiple paths, not just the longest. They know that any one of these shorter paths just behind the main path could bite them if they don’t try to accelerate it. They focus on 10-20 of the paths behind the critical path, attempting to accelerate all of them. Unlike normal teams that assumed and hope that the 10-20 secondary critical paths get longer (they assume the people on the critical path will have problems and their schedule will get longer, thereby giving them more time), fast teams expect the critical paths ahead of them to get shorter which means that the full team is pulling-in. They assume acceleration versus slip. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 89 -- 89 of 101 -- They call this process Refresh Planning. It generates smaller sub-group meetings of 60 minutes or less during the week to further refine the schedule, breakdown macro tasks to micro tasks, and further pull-in at the micro level. The Refresh Planning Process connects the team to the plan. It is a living document that at any time can tell an accurate story of the project’s history, where it is now, and somewhat predict its future. The more they do it, the more they own it and are familiar with not just their own work, but with the work of other team members and how they all interface with one another. The schedule is alive, real, and accurate in forecasting future events (of course the degree of accuracy is a function of the risks and unknowns that are factored into the plan). ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 90 -- 90 of 101 -- Appendix Start of the best practice study project (background) Current: Since initiating the study, lateralworks has continued studying fast teams around the world. The best practice database is continually being updated with new findings and insights. lateralworks consulting teams have worked on hundreds of projects since the initial study and have applied many of these practices with many clients in a variety of cultures. Each time learning about how best to adapt and deploy the practice with teams and organizations. From the initial published study Our study of the best practices of highly successful new product development teams began in the early 1990’s. LateralWorks conducted numerous interviews with executives, mid-level managers, and new product development team members representing virtually every line and staff function. The majority of those interviewed were in positions that directly or indirectly affected new product development initiatives.The companies in the study operate in highly competitive niches of the high technology market, where time-to-market (TTM) is perhaps the most essential variable to manage. The research for this project continues to be ongoing. 15 original study participants: Amdahl Corporation LSI Logic Cadence Design Systems Compression Labs Quantum Corporation Sun Microsystems Cypress Semiconductor Tektronix Philips Semiconductors Tandem Computers 3Com Corporation Philips Electronics Network Equipment Technologies IBM Corporation Conner Peripherals (Seagate) The practices that were distilled from the interviews are specific and implementable. The intent was to isolate the specific practices of the most successful organizations and teams, practices ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 91 -- 91 of 101 -- that were believed to have both a direct and indirect impact on the ability to deliver the right product at the right time to maximize profit. The 15 companies that participated in this first phase of the study all designed, developed and manufactured high-technology products. There was a wide range of project types, from low- volume (one-of-a-kind manufactured products) with long sales lives to high-volume commodity products with very short sales cycles. Systems companies that participated in the study developed products that required forward and backward integration into their current systems, while other companies made stand-alone component products. The practices reflected in this study are common to all. Framework within which the study findings are organized In the process of analyzing the information collected during the interviews, it became clear that development speed, while essential, must be "woven" with the continuously changing needs of the customer throughout the development cycle to be successful. The product must not only arrive on time but must also be the "right" product when it arrives. Recognizing that the customer's product requirements will evolve during development, and responding quickly to those changing needs, is a practice of those teams/organizations that highly successful. Those teams that "froze" specifications early and were not in regular contact with the customer’s changing requirements were clearly less successful. We also found that the most successful development teams chose to seek product requirements from the most suitable dominant Tier 1 customer in a particular segment of the market. As a result, LateralWorks has organized this best practice study according to three concepts: Right Customer, Right Product, and Right Time. New products succeed most when they successfully address all three. In today’s competitive market, two out of three isn’t enough. Giving our clients the tools to hit the “sweet spot” where all three intersect is the prime goal of LateralWorks. Right Customer Highly successful companies base their business plans on the market. They study market segments and carefully choose which ones to compete in, looking for the most suitable dominant Tier 1 customer in a particular segment—the Right Customer. The Right Customer’s product requirements are the ones to zero in on. If the dominant customer buys the product/solution, the Tier II customers are more likely to jump on the bandwagon and buy it too. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 92 -- 92 of 101 -- Derive product requirements from a Tier II customer, and the product will likely appeal only to the Tier II customer, and end up capturing a small share of the market—if any. LateralWorks has developed methodologies that help companies focus on the Right Customer: • Engage with customers directly to define and develop the product • Analyze market segments in-depth to position products precisely • Put the emphasis on finding and meeting customer requirements, rather than letting the product’s potential capabilities drive the process Right Product Simply stated, the Right Product is the one that precisely meets the Right Customer’s product requirements. But determining those requirements and translating them into product specifications is a complex process, and businesses don’t always put in enough effort. The problem: it’s possible to wind up spending money and time developing a product that has a fabulous array of features—which the customer doesn’t turn out to need. Designing unnecessary features can also lengthen the development cycle, causing the product to miss its window of opportunity. LateralWorks has a proven process for taking the guesswork out of determining the Right Customer’s real product requirements: • Identify the right people in the customer organization to ask • Develop questions that get to the heart of what they need • Find out what the customer’s own customers actually want • Obtain the customer’s involvement throughout the entire development cycle, to keep up with their changing requirements • Quickly translate the customer’s priority requirements into product specifications • Convince engineers to buy in to those product specifications Right Time Product lifecycles are short and steep, and there's a great deal of competition from Asian and now third world countries--especially in the high technology sector. Therefore, entering the market at the Right Time is critical to a company's survival. This almost always involves being first to market, at the time when demand is just beginning to accelerate. By entering the market at the Right Time, companies can sometimes contract to sell at the highest average selling price for an extended period of time, avoiding the price degradation that inevitably occurs over time. LateralWorks provides tools that turn the schedule from wishful thinking into a dynamic tool for managing the process, reducing time-to-market without compromising other requirements: • Ensure that the organizational structure supports fast teams • Know the cost of being late to market, and use that cost-of-delay as the primary driver for speed. • Implement fast decision-making procedures that authorize fast starts • Make schedule KING • Create fast schedules and rigorous tracking systems ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 93 -- 93 of 101 -- Methodology for initial FTTM Best of Practices Study The study sought actionable factors which discriminate between low performance fast-time-to- market (FTTM) versus high performance. Several analytic techniques are available to identify factors which could potentially improve performance in a given endeavor. These include task analysis, expert judgment, and more recently, competency analysis. Task analysis involves describing all the tasks associated in doing the work. Expert judgment involves invoking the experts opinion on what factors theoretically should have most impact on job performance. Competency analysis seeks the factors by analyzing critical incident interviews from high performance cases versus lower performance cases. To make the contrast more graphic the extreme ends of the performance curve are preferred. The interview does not inquire about what a performer would do in general or would recommend, but rather inquires about what the performer actually did in a recent incident. The strength of competency analysis to identify factors for improving performance in the work place has been shown to be about five times that available through task analysis and expert opinion (R2=.49 versus .09) Recognizing the strength of this tool, many companies and the American Management Association have used competency analysis to find the discriminating factors to improve many aspects of work and management. We believe we have built a first version of a competency model for fast-time-to-market and expect to refine the model in each future data gathering phase. FTTM was operationally defined as Right Product - Quick. Effectiveness measures were: • Right product was measured by meeting targeted R.O.I.; and • Quick was measured by reductions in start versus finish time consisting of two components; gestation time prior to team formation and overruns compared to initial project schedule. • The data in this study consisted of competency based interviews of about 95 Executives, Managers and key independent contributors involved in new product development projects. The conclusions about factors were based on separating 13 high performance cases from the other 82 using the evaluation criteria of the companies and participants themselves to classify the cases. We have not attempted to define any external or independent criteria to evaluate FTTM performance. To identify the factors which distinguish the 13 high performance cases from the 82 others, we carried out the conventional non-quantitative ("brute force") discriminate analysis. This resulted in six factors and 30 sub-factors which we call Best Practices. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 94 -- 94 of 101 -- In addition, quantitative data were gathered from all 95 participants This descriptive data provides supporting information, but it was not used as the basis for factor identification. No quantitative factor analysis nor discriminate analysis was performed with this data. The factors found in this study are based on professional judgment and experience in developing competency factors. No statistical significance is being asserted in the findings. We believe, however, that competency based analysis is by far the most powerful methodology available for identifying actionable factors and best practices to improve FTTM because it is based on what higher performers are actually doing. This lets us all learn from their best practices which is the value of bench marking. Each set of discriminating factors is formatted as follows: • Three factor clusters; • Six discriminating FTTM factors; and • Multiple best practices associated with the factors. Note: Many observers find competency factors and practices "obvious". When readers find them obvious, this is an advantage because it means the factors will be more actionable. Obviousness does not detract from the fact that many equally obvious ideas do not discriminate better FTTM performance from lesser performance. So, the discriminating power plus their obviousness gives the FTTM competency factors and best practices their strength for improving FTTM performance. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 95 -- 95 of 101 -- Glossary of Terms (unique terminology used by fast teams) "Right" customer information throughout the entire TTM cycle (gestation, development, overrun): Continuous and systematic give and take with the customer throughout the TTM cycle insures access to the "right" information. Voice-of-the-customer (VOC): The essence of customer input. Understanding that the customer has become so critical to business success that specific technologies and tools have been developed to assess this information. The voice-of-the-customer implies that a new product team understands the degree of value the customer places on specific features and functionality of the product "to be." It also implies that the team can translate these values into specific requirements that delimit the boundaries of acceptability. VOC schedule: A specific schedule of customer input throughout all TTM phases including planning, requirements, design, development, beta, and qualification. The best teams integrate specific customer involvement steps into their project schedules. The customer's involvement throughout the TTM cycle insures access to the "right" information. Customer path: The "exact" experiences the customer undergoes in the defined segment/niche at a given moment in time. This also takes into account the customer's environmental context at the time it is being assessed. Do-it-right-the-first-time (DRFT): The emphasis on Total Quality Management and Zero Defects has caused organizations to re-evaluate old paradigms that assumed first pass perfection was not a realistic expectation, that rework was the norm and DRFT was largely accidental. DRFT requires that many more micro cycles of learning (do-it, try-it, fix-it) occur in an increasingly compressed period of time. DRFT also requires extensive use of benchmark or historical data to assist in predicting outcomes. Where data does not exist, it must be captured during the design-verify-test cycle and fed back to the process. Install version control on external and internal specifications: A mechanism that delimits changes on existing specifications that are imposed within and outside of the organization. Typically this mechanism takes the form of an automated specification change-order-control system, in which all changes are recorded and are accessible by all members of the product team. Specific version control is required to manage the change authorization process. Strategy of fixed containment of specifications: Sets absolute limits on the number of changes allowed. Specifications are "frozen" in order to minimize schedule delay caused by changing specifications. Rarely do development efforts that employ specification "freezes" meet eventual customer requirements, because customer requirements evolve during the life ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 96 -- 96 of 101 -- cycle of the development project. The longer the development project, the more chances there are for the customer requirements to be something other than that which was originally "frozen." Flexible containment of specifications: The flexible containment envelope delimits the extent to which the product team will make changes to the product design and/or process. Unlike the fixed containment process, which seeks to freeze all changes, a flexible containment envelope provides for versatility in dealing with the changing requirements from the customer during the design/development cycle. However, the envelope does have limits, which insures "change" has some boundary. Delineating a path of early commits proceeding to late commits and contingency planning for high risk modules: Identifying on a time continuum when changes must take effect for a given portion of the product development. Contingency planning for high risk modules means identifying the back-up actions needed for those modules or interfaces that are identified as high risk. For example, during the development of an application software system, there are "early commitments" that must be made such as architectural, language, and database decisions if the project is to proceed to later phases of development. There are also "late commitments" decisions such as user interface and output requirements that can be delayed until later stages of the development effort. Commit ratio: The relationship between those resources that are committed to approved projects versus those resources that are available for new product development projects. A stream of incremental derivative products based on a given platform: A series of succeeding product concepts/designs that are derived from the previous design -- all based on a common "platform" or base product architecture. Rapid incrementalism in technology advancement: Requires that only short intervals of time elapse between the release of succeeding product increments, so as to limit the profit problems associated with cannibalizing your own products (i.e., replacing your own products with a competitive offering). Project gestation: The period of time from the origination of a new product concept to the time when a core product team is formed to start working development. This time frame offers a major opportunity for reducing the TTM cycle. Default to action: When faced with a problem or decisions, key players and/or product teams assume responsibilities and take action rather than waiting for top management to make a go/no go decision. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 97 -- 97 of 101 -- Strategic by pass: An effort to resolve a product-related issue in which the existing hierarchy or information flow was by passed in order to obtain a quick answer and/or decision. Macro schedule: A broad, high-level schedule that summarized the specific action plan of the project. Cost and resource allocates are also summarized in this plan. Micro schedule: Detailed schedule. Typically "micro schedules" are derivations of and roll up to a "macro schedule." Micro schedules are defined as having individual activity durations of less than ten days. The micro schedule is constructed using precedence relationships to explain inputs and outputs between given activities. Additionally, each activity contains cost and resource allocation information. ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 98 -- 98 of 101 -- Practice Framework Matrix ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 99 -- 99 of 101 -- Practices (list form) 1.0 Mindset 1.1 Grasp enormous financial impact late products have on profitability and growth 1.2 Create fast culture through close-in oversight of product roadmap 1.3 Systematically dismantle slow structures 1.4 Accelerate the threshold of pain; reward early warning behavior 1.5 Fast decision-making system 1.6 Cost-of-delay is understood at individual contributor level; used to drive urgency 2.0 Host 2.1 Fuzzy-front-end is managed 2.2 Projects are prioritized based on business objectives 2.3 Projects continuously aligned with resources and skills available 2.4 New products are tracked to break-even 2.5 Kill projects that fail to meet objectives; early 2.6 Fast development framework 2.7 Provision teams, eliminate interrupts 2.8 Cross-functional core teams (heavyweight & dedicated) 2.9 Project-based performance measurement 2.10 Freedom Level 1 empowerment 3.0 Team 3.1 Co-develop with tier 1 customers; continuously refine requirements 3.2 Schedule as driver vs. reporter 3.3 Translate customer requirements to product definition, reconfirm throughout development 3.4 Know what they value, when they want it, how much they will pay for it 3.5 Understand customer wants vs hows; prioritize the drivers that maximize customer satisfaction 3.6 Start design while refining requirements; never freeze specs 3.7 Fail-Fast; integrate/proto early, frequent & many do-it-try-it-fix-it learning cycles 3.8 Cross Functional Core Team ROLES not FUNCTIONS; lateralized 3.9 Get best people; mix of inside & external SMEs; virtual teams 3.10 Aggressive planning 3.11 Macro-micro planning; micro near, macro far, short interval scheduling 3.12 Team planning, simulation, continuous scrubbing, breakdown, ownership 3.13 Market/customer driven versus resource constrained 3.14 Know the gap; drives before-the-fact urgency 3.15 Refresh Planning; continuous schedule pull-in ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 100 -- 100 of 101 -- Notes: ! . FTTM New Product Development Best Practices - lateralworks - Revision 2018.002 101 -- 101 of 101 --

FTTM Methodology·Methodology paper

FTTM Product Development Best Practices

Three decades of fast-team research, 2018 revision

Core thesis. FTTM outcomes are a function of two inputs — the behavior of the team and the environment within which the team operates. Best practices observed across hundreds of programs are codified into a Mindset / Host / Team framework that delivers the right product at the right time.

July 18, 2018·101 pages

View PDF →Download

9 papers. More papers added regularly.