Operational excellence is not a single methodology or a set of best practices; it’s a discipline of coherence: the ongoing ability of an endeavor to align intent, capability, and execution so that work flows smoothly from concept to completion. At its core, operational excellence depends on three things:

• Clarity of purpose (what the system is trying to achieve)

• Visibility of work (how value is actually produced)

• Coherence of behaviors (how agents act within the system)

When these elements reinforce each other, endeavors develop a kind of operational gravity: work moves in the right direction with less friction, fewer surprises, and more resilience. But this gravity only emerges when the underlying orientations of the people doing the work are recognized and integrated rather than left to operate in isolation.

The Role of Agent Orientations

Every agent in a system operates from a viewpoint. Some are Process‑oriented, optimizing flow and reducing variation. Others are Insight‑oriented, probing for meaning, patterns, and strategic leverage. Still others are Action‑oriented, driving momentum and execution. These orientations are inherent to how agents approach complex work.

Operational excellence emerges when these orientations are deliberately orchestrated. A system that overweighs process becomes rigid. One that overweighs insight becomes paralyzed by analysis. One that overweighs action becomes chaotic. The craft of operational leadership lies in creating a work operating system where each orientation plays its role without dominating the others.

The Pitfalls That Undermine Operational Excellence

Most endeavors don’t fail because they lack intelligence or effort. They fail because they fall into predictable traps. Some of the most common include:

1. The Illusion of Alignment

Teams often believe they share a common understanding of goals, constraints, and priorities. In reality, each orientation interprets the mission differently. Without explicit alignment rituals, these differences compound into drift, rework, and conflict.

2. Process Overreach

In the name of efficiency, organizations often add layers of process that obscure rather than illuminate the work. This creates a brittle system where compliance replaces judgment and where deviations (often the source of innovation) are treated as defects.

3. Invisible Work and Hidden Queues

When work is not made visible, bottlenecks form silently. People optimize locally, unaware of the system‑level consequences. Operational excellence requires exposing the true shape of work, even when that visibility is uncomfortable.

4. Over‑reliance on Heroics

High performers can temporarily mask systemic flaws, but heroics are not scalable. Systems that depend on exceptional individuals inevitably collapse under load. Excellence comes from designing systems where ordinary performance reliably produces extraordinary outcomes.

5. Fragmented Feedback Loops

When insights from the front lines don’t reach decision‑makers—or when decisions don’t translate into operational behavior—the system loses its ability to learn. Excellence requires tight, bidirectional feedback loops that connect strategy to execution.

6. External perturbations

Changes are inevitable, and the dynamics they generate amplify the effort required to resolve known problems and obfuscate the clarity of purpose essential for coherence.

The Real Work: Integrating Perspectives Into a Coherent System

Operational excellence is ultimately a systems integration problem. It requires building a work operating system where:

• Strategy is translated into actionable constraints

• Processes are designed to support - not constrain - human judgment

• Insights flow freely across boundaries

• Execution is measured in terms of outcomes, not activity

• Agents understand not just their role, but how their orientation contributes to the whole

This is why operational excellence is so difficult: it demands continuous negotiation between competing goods; efficiency vs. adaptability; standardization vs. autonomy; speed vs. quality. The organizations that excel are those that treat these tensions not as problems to eliminate but as dynamics to manage.

The PIANOS model exposes these viewpoints and operates within a macro-level flow depicted in Figure 2:

A narrative of these viewpoints in action

Here lies the Territory occupied by endeavors pursuing excellence. Its aspirations are charted as requirements, the sacred pact made among team members and the endeavor’s stakeholders. The endeavor’s Audience - the sum of all our stakeholders, vests a Navigator role with fiduciary trust, expecting that these captured requirements will stand as the blueprint for endeavors as they unfold. The interactions with this Audience often shape risk profiles, priorities, and cultural dynamics.

Yet in every endeavor, risks lurk - wily shadows that threaten our course and anticipate unforeseen detours. Opposite them, opportunities wait in latent promise, ready to be elaborated by those daring enough to shoulder the inevitable responsibilities. Navigation allocates resources to fuel learning and knowledge capture which provide a foundation for improvements that will stick. Despite this knowledge, the impacts of changes continue to emerge, perturbations that nudge our venture from stillness into motion.

In parallel, Adaptation lays down Structure, carving channels for Alignment. It’s the architect of our resilience. It beckons Orchestration, that deft hand which conveys vision and assures cohesion, ensuring each resource finds its place.

Actions take form, as each team member uses their competency and capabilities to execute their Jobs to Do. These tasks are fed by ceaseless feedback loops. With each iteration, outputs materialize, as system updates are deployed, releases are delivered, and customers are served.

Between each node, flawed intentions and slips also flow contaminating our aspirations and our gaps. Defects emerge where intentions falter, and power pulses to correct our course. The crucible of alignment serves to confirm that business objectives are being effectively translated into operational targets and trigger adjustments when warranted.

Within this Territory of intentions therefore lies both our greatest potential and our most familiar pitfalls. Only by tracing these threads, and by orchestrating Adaptation and Navigation, can we shift from planning to effective action which will transform intentions into impacts.

I open my scuttle at night and see the far-sprinkled systems,
And all I see multiplied as high as I can cipher edge but the rim of the farther systems. 
Wider and wider they spread, expanding, always expanding, 
Outward and outward and forever outward. —Walt Whitman, Song of Myself

“Planning” is a concept with baggage. For many, it calls to mind a passive activity: sitting, thinking, staring into space, abstracting what you’re going to do. In its more institutional form, planning is a bureaucratic exercise in which the planner writes reports, colors maps and charts, programs activities, and fills in boxes on flowcharts. Such plans often look like train schedules, but they’re even less interesting. Much planning does fit that bill.

And that’s a problem because it’s a serious mistake to treat planning as an exercise in abstract, bureaucratic thought and calculation. What sets good planning apart from the rest is something completely different. It is captured by a Latin verb, experiri. Experiri means “to try,” “to test,” or “to prove.” It is the origin of two wonderful words in English: experiment and experience.

Plan-driven methods

Professional societies offer plenty of guidance about this experiential experimentation. Since 1969, the Project Management Institute has championed plan-driven methods that promise to produce a robust project plan. Unfortunately, the robustness often drags along an accompanying bureaucratic overhead with it. Many other disciplines, like systems engineering and software engineering, echo significant elements from PMI’s framework.

Figure 2 captures the major processes in the Project Management Body of Knowledge Guide (PMBOK), with planning processes getting most attention, and plans being the primary output.

There are ten core elements of the planning process: scope planning, scope definition, activity definition, resource planning, activity sequencing, activity duration estimating, cost estimating, schedule development, cost budgeting, and project plan development. In comparison, there is only one executing process and two controlling processes, so the primary output of project management is the project plan, which itself risks becoming bureaucratic. Quoting the PMBOK:

The definition and management of processes is key to plan-driven methods. For that reason, plan-driven methods are almost always associated with process improvement. The processes need to be defined, standardized, and incrementally improved to provide the data needed to control and manage their operation. Such processes generally include detailed plans, activities, workflow, roles and responsibilities, and work product descriptions.

Thus, learning and improvement are expected to be a fundamental feature built into project plans, though these attributes often rely on activities outside the scope of the resulting plan.

In its most recent incarnation, the PMBOK has placed an increased emphasis on principles, which are worthwhile, unsurprising, and easier said than done. This is a positive step away from a strict control orientation (note, for example, the guidance on the project manager chief role responsible for coordinating project activities). Several concerns about the PMBOK remain:

1. Structural rigidity and lack of flexibility

   1. Prescriptive nature: PMBOK has traditionally emphasized rigid processes and documentation, which can hinder adaptability in dynamic or innovative projects.

   2. Slow to adapt: Critics argue that PMBOK struggles to keep pace with rapidly changing business environments, especially in tech and creative sectors.

2. Documentation focus and administrative burden

   1. Heavy emphasis on documentation: While useful for compliance and audits, extensive paperwork can create unnecessary overhead, particularly for small endeavors.

   2. Process-centric bias: The focus on process groups and knowledge areas may lead to bureaucratic inefficiencies in fast-moving projects.

3. Insufficient emphasis on sustainability

   1. Sustainability gaps: While PMBOK mentions sustainability, it lacks actionable frameworks for integrating related concepts into project success criteria.

   2. Lifecycle sustainability: Critics call for sustainability to be embedded throughout all project phases, not just acknowledged in theory.

4. Underutilization of AI and Data-Driven Decision Making

   1. AI as an afterthought: PMBOK has been slow to embrace AI as a strategic partner in project planning, risk assessment, and communication.

   2. Missed opportunities: Tools like generative AI and machine learning could enhance forecasting, stakeholder engagement, and adaptive planning, but are not yet central to the PMBOK framework.

5. Challenges with Distributed Teams and Modern Collaboration

   1. Limited guidance for remote and distributed teams: PMBOK has traditionally focused on co-located teams and hierarchical structures, which may not reflect today’s collaborative, networked environments.

6. Disconnects between conceptual and practical elements

   1. Theory-heavy: Some practitioners find PMBOK too abstract or academic, lacking practical tools for real-world challenges.

   2. Principles vs. execution: The shift to principles-based guidance in newer editions aims to address this, but implementation clarity remains a concern

Plan-driven methods are themselves production processes which are expected to facilitate tradeoffs across alternative approaches for activities, confront tensions between autonomy and control, and transform inputs into outputs within whatever organizing framework has been adopted for activities. The Origins of Efficiency outlines the challenging circumstances of production:

Production processes are sociotechnical systems, embedded in human organizations and subject to the vagaries of human decisions, which are often guided by considerations other than cost. These decisions can and do influence the trajectory of production process development, by adding costs in service of achieving other goals like increasing safety or reducing environmental harms, or by limiting the sorts of improvements that can be made.

Information is an input needed, and an output produced, by most production processes. When we think of planning as itself a production process, the is often operating in the realm of ideas, narratives, and concepts, often (much of it unreliable), assumptions (when information is unavailable), and predictions of forward-looking behaviors (which are subject to biases), all under time pressure that often limits a necessary understanding of the presenting situations of the endeavor.

Agile

Agile software development emerged in 2001 and provides an iterative, incremental, and evolutionary framework which embraces values and principles appeal to small teams. Since then, many separate methods have emerged that share DNA with these ideas, while seeking differentiation across the competitive environment they operate within; an ocean liner of businesses (including many led by Agile Alliance members) emerged ready to offer their services and combat the common pitfalls encountered with these methods. Yet studies on failed transformations highlight preparation issues: - lack of leadership, inadequate sponsorship, unclear decision rights, misaligned incentives, rigid governance structures, ow psychological safety, and poor cross-functional collaboration.

Many Agile-focused methods have also been embraced in applications outside software development, with limited success. Scaling up agile to major development efforts (100+ developers working on a specific product) and in regulated, safety-focused endeavors has also proved challenging.

Steve McConnell’s book, More Effective Agile offers the following contrasts between plan-based, sequential methods like PMBOK and adaptive methods like Agile:

Comparisons of Agile and plan-driven methods often contrasted failed plan-driven projects with successful Agile projects, or vice versa. Since all successful projects rely upon effective organization and oversight, customer collaboration, and robust transformations, such comparisons are rarely useful.

One of my favorite books evaluating improvement frameworks is Balancing Agility and Discipline. It describes the tension between these two competing worldviews:

The agilists rail against the traditionalists and lament the dehumanization of software development by “Taylorian” reductionists who worship process. The establishment has responded with accusations of hacking, poor quality, and having way too much fun in a serious business. True believers on both sides have emerged to proclaim their convictions with near-messianic stridency, raising the perplexity level of software developers and managers trying to evolve their success strategies.

At the ten-year anniversary of Agile’s Manifesto, Philippe Kruchten captured the ‘elephant in the room’ nature of issues which the participants reflecting on. A sample of his thoughts deserve repeating:

While the community has been good at amplifying what works, it often has not been good at dampening what did not work, analyzing why it did not work, or under which conditions it did not work (context!)…

In most instances, when practices are described too little of the actual context is described, leaving an impression of very wide applicability; even if this wide applicability is not actually claimed. Sometimes this is just pure dogmatism, or bigotry…

Unlike other disciplines, like medicine for instance, there is very little reporting of failures or limitations in software, and no clear venue or even templates or exemplars of such reporting. And again the fear that this would reflect badly on the person reporting, or the “victim” or “culprit” organization. A good template for such report would include a detailed description of the context…

There are still too few people gathering objective, significant, scientific evidence on our practices, except for a very few that are easy to instrument (pair programming, for example)…

The agile movement is in some ways a bit like a teenager: very self-conscious, checking constantly its appearance in a mirror, accepting few criticisms, only interested in being with its peers, rejecting en bloc all wisdom from the past, just because it is from the past, adopting fads and new jargon, at times cocky and arrogant.

Continuous flow

The book The Origins of Efficiency highlights one of the primary constraints limiting both plan-driven methods and Agile: they simply do not scale:

When we take a 30,000-foot view at where and how efficiency has improved, one recurring theme is the importance of scale. Economies of scale are not only a major driver of efficiency improvements in and of themselves, but they are also a gating mechanism that unlocks other efficiency improvements by making it possible to amortize the large fixed costs that such improvements often require over a sufficiently large output…

When we can’t repeat a process, or when there’s significant variation in the production environment or in the product itself, many paths toward increased efficiency are blocked. Without repetition, we can’t take advantage of economies of scale. A constantly changing process or a highly variable environment is harder to predict and control, making it more difficult to increase yield and decrease waste. It’s also harder to automate or mechanize in such circumstances, which limits our ability to reduce labor costs. This is one reason why services like medical care, car repair, and construction, which rely on skilled labor that can flexibly adapt to highly variable conditions, remain expensive. Finding ways to make these things cheap will require escaping the constraints of scale to get the benefits of a continuous process—that is, a constant transformation of inputs into a finished product without waiting, buffering, failures, or wasted actions—without needing to repeat that process over and over again…

The development of continuous processes has historically been most easily achieved with a carefully orchestrated arrangement of workers and special-purpose equipment, which is costly to build and operate and, therefore, requires the cost to be spread over a very large output. It takes time, effort, and expense to make the steps in a process work together in sync, a result that can often only be achieved with dedicated equipment and justified with large production volumes…

What if it was quick and easy to figure out the order of steps in a process and arrange them so that the transformation is swift and steady? And what if this process didn’t require special equipment but could use flexible, adaptable machinery able to produce a variety of different items? Then it would be possible to achieve a smooth continuous process that worked in a highly variable environment, bringing the benefits of efficiency improvement to domains that have traditionally resisted it…

For production technology to be able to flexibly adapt to a highly variable environment, there are two broad requirements. First, it requires [methods and] equipment that is physically capable of responding flexibly—that can take a broad range of possible actions, or a small number of actions that can be combined to produce a wide variety of outputs…

The second requirement for flexible, automated production is that the equipment has some method of determining the sequence of the proper actions to take—an information-processing component that can, based on data from the environment, break a desired output into a series of achievable production steps.

The capabilities available from satisficing these requirements will be considerably enhanced as artificial intelligence technologies are incorporated into activities and allow dynamic reallocation of efforts to maximize achievable outcomes.

Operations focus

Neither Agile nor plan-driven methods provide the universal flow-oriented viewpoint for production that is offered by Lean (an extension of the Toyota Production System). Lean and JIT (Just-In-Time) methods emerged from industrial engineering with a queueing-theory backbone, pushing teams toward dynamic flow while retaining and customer focus.

However, Lean lacks the disciplines of plan-oriented methods, since it is designed for improving operations; further, its focus on elimination of waste can shortcut strategic efforts. As a result, Lean-Agile hybrids have been effective in industries that require both operational excellence and rapid innovation. These hybrids typically feature adaptive planning with feedback loops, pull-based scheduling, visual management techniques, and continuous improvement concepts with a customer-value focus across cross-functional teams.

Analysis

Well-established professions typically build their concepts around theoretical foundations. In The underlying theory of project management is obsolete, the authors recognize that production has many manifestations:

… competing theories of production (projects are just special instances of production) have existed even before the emergence of project management. Another concept of production was presented already in the framework of early industrial engineering. The flow view of production … is embodied in JIT and lean production. In a breakthrough book, Hopp and Spearman (1996) show that by means of the queueing theory, various insights, which have been used as heuristics in the framework of JIT, can be mathematically proven.

While Lean concepts rely on this theoretical foundation, and have recently gained traction among startups, they have had their greatest success fighting ‘big company disease’, through a focus on customer concerns and a systems approach across collaborative teams. Their biggest contribution has been helping to change thinking from a static plan-oriented focus to a dynamic flow-oriented model.

Let’s break down the features of each of these frameworks, drawing from this analysis:

If the reader studies this table, they may conclude no single option provides what they need.

Hybrid approaches

Hybrid approaches, while appealing, aren’t a panacea; common pitfalls include overhead and complexity, fragmented communications, dilution of core principles, tooling challenges, inconsistent metrics, and the ever-present resistance to change. Examples cited in the literature include:

• Teams using sprints but still following rigid upfront planning, losing Agile’s adaptability

• Isolated Agile adoption in which Agile is adopted locally but is not supported or compatible with other departments frameworks, creating delivery misalignment

• Organizations cherry-picking practices and adopting Agile rituals (like stand-ups) without embracing its principles, often resulting in limited adaptability

• Lean’s reliance on accurate forecasting clashes with Agile’s responsiveness, especially in volatile markets.

This is made worse when one realizes that few endeavors fully implement all the features in their situation, so relying on a hybrid puts the user in the difficult role of integrating parts designed for separate purposes on their own.

The bottom line:

The idea of a fixed method, or a fixed theory of rationality, rests on too naive a view of man and his social surroundings - Paul Feyerabend, in Against Method

In the next post in this series, we will confront the inevitable tensions between desires for autonomy and control.

In Federalist paper #51, James Madison writes:

In framing a government which is to be administered by men over men, the great difficulty lies in this: you must first enable the government to control the governed; and in the next place oblige it to control itself. A dependence on the people is, no doubt, the primary control on the government; but experience has taught mankind the necessity of auxiliary precautions.

In The Square and the Tower, Niall Ferguson highlights further the weaknesses of people in these situations:

…the defect of autocracy is obvious, too. No individual, no matter how talented, has the capacity to contend with all the challenges of imperial governance, and almost none is able to resist the corrupting temptations of absolute power.

Sometimes failures arise as a result of defects injected by agents themselves. But too often, it is a failure to understand the weaknesses of the methods they use and the dynamics of the collective games that are being played while using them. Let’s consider how frequent these problems arise.

A sampling of failures

The author of the book How Big Things Get Done, Bent Flyvbjerg (a professor at Aalborg University in Denmark) has been tracking over 16000 projects across 20+ different fields, and across 136 countries for over twenty years. His findings:

Only 8.5 percent of projects hit the mark on both cost and time. And a minuscule 0.5 percent nail cost, time, and benefits. Or to put that another way, 91.5 percent of projects go over budget, over schedule, or both. And 99.5 percent of projects go over budget, over schedule, under benefits, or some combination of these. Doing what you said you would do should be routine, or at least common. But it almost never happens.

Steve McConnell’s book More Effective Agile records his consulting business’s experience in over one thousand company engagements with Agile endeavors. As you can see, the performing organizations - on average - failed to apply Agile key practices consistently and effectively across this landscape, even when blessed with the benefits of experience from experts. Unless there is a ‘closed loop’ approach to such practices, this is exactly what one might expect given the inevitable cultural resistance that accompanies introducing such practices into routine practice. And without buy-in and practice, everyone hunkers down until another batch of promising silver bullets attracts attention yet again.

Several large endeavors are particularly noteworthy across the landscape of my experience. Such endeavors tend to be ambitious projects that fear delivering reduced capabilities which can erode trust and accountability in their sponsors, providers, and methods. When ‘selling’ the endeavor, the underlying mindset is to offer optimistic projections drawn from limited surveys while downplaying risks and uncertainty. Their common maladies typically involve overreach and minimal learning:

1. Transportation

   1. Puget Sound’s mass transit project, Sound Transit - according to Bloomberg - was to be a showcase that would show that providing better service would attract more riders and generate a virtuous cycle of growth. The current endeavor was approved by 54 percent of voters in 2016 and was to include sixty-two miles of light rail throughout the region, to be completed by 2041; the delivery was phased, and construction was well underway when the Bloomberg article was written in 2018. It has not gone well.
      
      One of the key segments was across the I-90 bridge, which moves with wind, water, and traffic. In 2022, it was discovered much of the bridge installation required extensive demolition and rebuilding (much as other segments have encountered, suffering of all things rail gauge incompatibilities). These issues pushed the original 2023 opening of cross-bridge traffic to 2026. The original $55B budget, which voters (paying over $1700 per household per year in new taxes) were assured had more than adequate contingency for any uncertainty, is now looking at between a $30-40B overrun. Five other segments to suburbs have also suffered delays of up to seven years, while their taxes, and additional overruns, continue. Yet the current system carries less than 1% of all trips in the region, and has failed to offload overcrowded roads, as promised.
      
      Such problems are always viewed as financial, with the only solutions offered by advocates involving additional revenue and deferring implementation still further. Meanwhile, revenues from riders have tanked, as the adopted hub-and-spoke design reduces rider convenience and its required transfers lengthen end-to-end times. Luckily, self-driving cars are beginning to get approval for ride sharing in limited areas, and by the time the Sound Transit plans are completed, this more effective and less costly alternative will likely be ubiquitous.

   2. But it’s hardly the worst transportation endeavor currently in work. Consider California’s High-speed rail effort, authorized by a 2008 statewide initiative to deliver continuous service between San Francisco and Los Angeles with a nonstop travel time of one hundred sixty minutes. Phase 1 (five hundred miles long) was to be delivered by 2020, at a cost of $33B. Phase 1 is expected to share tracks with conventional trains, operating at a higher average rate than France’s fastest TGV trains. They were warned this was infeasible back in 2008. Costs to date have tripled and projected completion is thirteen years after original commitments. It’s no wonder that funding is questionable since the initial construction package will only connect Fresno and Bakersfield, over which little traffic is expected.

   3. How’s NASA doing in transporting astronauts to outer space? We are no longer hitching rides on Russia launch capability, but our astronauts still need a place to ride. The Orion Capsule is NASA’s crew spacecraft capable of supporting a crew of four beyond low earth orbit and has been under development since 2006. Its specifications call for twenty-one days of undocked service and six months of docked service, and are to be used by the Artemis program, NASA’s current lunar exploration endeavor. Orion has already spent $31B (2025 dollars) and struggles to recreate the mission first accomplished over sixty years ago (the total expenditures including the Space Launch System approach $100B). The maladies of the doomed effort are well chronicled here; suffice to say that if only cost and schedule were the problem, one could still kindle some hope, but it’s far, far worse than that. Meanwhile, SpaceX’s private space efforts continue to astound, with a vision pointing to establish a permanent Mars settlement, rather than completing another trip to the moon.

2. Government services

   1. Health care

      The U.S. health care system is innovative but fiscally unsustainable. It delivers cutting-edge treatments and short wait times for specialized care, but at the cost of uneven access and worse population health outcomes than other wealthy nations. For example, according to The Origins of Efficiency, the cost to develop a new drug has increased by a factor of 14 - in inflation adjusted terms - over the last 4 decades. These problems have worsened since the launch of the Affordable Care Act, which has relied on escalating infusions of subsidies, rather than effective cost control.

   2. Education

      Since the founding of the Department of Education

      1. $3 trillion spent

      2. Reading scores for 13-year-olds have not improved

      3. Only 27% of 8th graders proficient in math

      4. Only 31% of 8th graders are proficient in reading

      5. 47 cents of every federal education dollar spent on compliance

      
      If you’re defending the Department of Education, you’re defending a failure. For example, five years ago, according to a recent report from UC San Diego faculty, only about 30 students arrived with math skills below high-school level. Now, that number is now more than 900, with most failing to fully meet middle-school math standards. As a result, the students supported by these investments are expected to earn 8% less than graduates 12 years ago.

   3. Megaprojects

      Look no further than The Line and its collapse.

Traditional frameworks appear to have had inadequate influence on outcomes for many types of endeavors.

Reality always requires investments in understanding

Existing frameworks focus on prescriptive content definitions for expected artifacts (many of which are rarely read or maintained in practice). When an endeavor is large, complex, and ‘too big to fail’, political will inevitably contaminates prudent judgement, a recipe for failure rather than success. A library of excuses - environmental reviews, inflationary costs, adjustments in scope, externalities - is quickly designated the cause, without confronting the uncertainty inherent in snapshots of reality against plans. Plans have at their core imperfect forecasts of the future based upon limited knowledge and less understanding, so assumptions must be made. These assumptions can inevitably unravel in long-lived projects, those guilty of overreach may have moved on to their next adventures, and a new wave of leaders emerge to claim that a comprehensive reset (with new assumptions) will curtail further sins - if stakeholders will just wait a while longer and shell out a lot more. Until they won’t.

True understanding is achieved by through adequate preparation in the ways things can go wrong, as described in the next post in this series.

Economists’ thinking about production has evolved from simple input–output rules to today’s nuanced, multi-factor frameworks. These conceptual shifts include transitioning:

1. From an engineering metaphor to an economic optimization tool

2. From fixed technologies to technology itself as an endogenous, evolving factor

3. From two-factor simplicity to multi-factor, multi-output complexity

4. From static efficiency to dynamic productivity and innovation analysis

This evolution in thinking originally rested on the concept of production as a black box and examination of what powers it. Let’s open this box and see what’s inside.

Means of production

The concept of the means of production, depicted here in Figure 1, is widely used to signify the relationship between things used as inputs to a production system and the constituent mechanisms needed to provide those inputs - factories, tooling, systems, services, and methods - whether in a system of interest, or within an economy or society.

Karl Marx focused on these means of production to distinguish them from contributions by labor. Elon Musk sees them as levers for exponential innovation and automation. Two components of these means - resources and capabilities - deserve further detailing. For orientation for my intended use of the term power, see here.

Resources as power

Production for a system of interest consumes resources provided by upstream providers (who produce them) and produces resources for downstream consumers (who consume them). Energy is one of the most critical resources - the capacity to do work - since it fuels all actions, from powering a data center, lifting an object, or running a machine.

Energy comes in various forms - kinetic, potential, thermal, electrical, etc. Power is the rate at which these forces can be applied in accomplishing work or transferring resources. Think of it as the speed of doing work. It can tell us how effectively resources are being used to accomplish useful work. Energy is a stock, while power is a flow. If unfamiliar with this terminology, see this post.

The three primary resources, as shown in Figure 2, are time, talent, and treasure (capital), as those allow effort to be applied, capabilities to be matured, and objects to be transformed. While the selection of the other resources - forces, information, and raw materials - are important for efficiency, the primary forces enable better objects to be used in assembly, greater competency to be incorporated into capabilities, and better domain knowledge to be leveraged in performing the work.

Capabilities as power

Capabilities (Figure 3) provide the ability to execute specified courses of action, and guide and constrain agents in performing these activities.

The concepts underpinning capabilities have had the greatest reach in military applications today, reflecting how armed forces think about applying power in conflicts while keeping a mission focus. The applications of these concepts focus on preparation - to understand how well forces can reliably employ resources within anticipated situations. This focus goes beyond traditional planning, which focuses on raw numbers of resources and equipment, to consider the capacity to successfully achieve desired courses of action. When considered in this context, capabilities are sources of power, but unlike resources, are not consumed in usage (though they can be degraded with time).

Maladies in production

Many things inevitably go wrong in accomplishing this work, especially when affected by complexity, external influences, resource shortages, quality breakdowns, and garbled communications. In this post we are focusing on the implicit structure for each production operation when encountering these situations. These are only apparent when observing patterns of operations across the requisite variety of contexts. When they arise, they lead to internal pivots in straightforward processing, or off-ramps from further processing. Such maladies are chronic, problematic conditions that introduce disruptions in production equilibrium, whether biological, psychological, or systemic. They often signal:

• A misalignment between internal states and external demands

• Flaws in communications and exchanges

• Breakdowns in incorporating information from feedback loops

• An inability to effectively adjust resource allocations as adverse conditions arise

Let’s examine the many types of pitfalls that are at the root of these production maladies:

1. Shortfalls or incorrect resources (time, talent, treasure, information) provided for the work

2. Breakdowns in preparation (orientation, architecture, stakeholder engagement) or orchestration of required actions

3. Inadequate attention to risks or change management

4. Slips and lapses in performing the work (resulting in defects that require rework)

   1. Mistakes in analyzing what is needed for the work to be performed effectively

   2. Performing work out of sequence

   3. Mistakes in performing the work itself

   4. Failure to properly document the work

5. Externalities adversely injecting change into endeavor

6. Improper use of tools - including automation - to situation

7. Incomplete testing of functions, performance, structures, or failure modes

8. Procedural disconnects (mismatches between situations and domain knowledge)

Each of these maladies threatens the orderly flow of work and thus adversely impacts throughput across each step of production.

The Minimum Viable Production Flow

If we are going to orchestrate production adequately, we must account for all these steps and transformations that occur, track the frequency, pace, and rework of each step, and use that information to learn to apply and mature capabilities and means of production to minimize non-value-added detours through this flow. The underlying steps and feedback loops are depicted in a stock and flow model, in which flows are represented by valve symbols representing transfer functions and stocks are represented as boxes depicting reservoirs. The processing steps are described generically here but are mappable to most situations. Note that inputs and outputs required by each step are not shown here but are implied in separate writings about portfolio management.

Once jobs are committed, the work is distributed across performing agents, depicted in Figure 6 as multiple parallel efforts for each step (when steps indicate depth):

We want our model of these dynamics to be viable for representing as many situations as possible, while being as simple as possible. Performance of production systems is non-linear and classically follows what is described as an S-curve - the sigmoid function whose graph is shown in Figure 7. This pattern is consistent with the elements described in figure 3 of this post.

In Brian Potter’s book The Origins of Efficiency, these dynamics are described as follows:

When we talk about production methods, we’re really talking about technologies… a production process can be thought of as a large collection of different technologies strung together to accomplish a particular goal… For individual technologies, progress tends to follow an S-shaped curve, with time or effort on the horizontal axis and technological performance on the vertical axis.

Early on, the technology performs extremely poorly, if it works at all. The phenomenon at play in the technology may have only recently been discovered and as a result is poorly understood. It might not yet be clear how it behaves under different conditions, or what arrangement of components can best take advantage of it, or even for what purposes it might be harnessed. Fixing one problem with a nascent technology tends to simply reveal more problems, so significant time and effort might be invested without any noticeable increase in performance.

But over time, as scientists, engineers, and tinkerers explore different ways of implementing it, the technology’s characteristics become better understood. As people begin to figure out what works and what doesn’t, the search space of the technology is narrowed, and it attracts more talent and funding. As attention converges on the most promising avenues for advancement, performance improves more quickly… This gradual refinement that leaves the basic nature of the technology unchanged is often called incremental or evolutionary improvement. During this period, the technology might converge on a dominant design: a specific way of implementing the technology that can be easily adapted to serve the needs of many potential users.

Eventually, a technology’s performance approaches some natural limit: the maximum level of performance that the given effect or principle at work or the structure of the dominant design can achieve. As the technology approaches this limit, gains in performance are harder and harder to achieve, and the rate of improvement slows.

As the legend in Figure 6 indicates, the steps in our production process manifest performance through four phases (estimates below are approximations for a typical small to medium-sized endeavor):

1. Inception: the scope, goals, expected benefits, risks, and feasibility of the endeavor is assessed. The effort (~5%) and schedule (~10%) at this point are small but establish the baseline for future acceleration.

2. Elaboration: The requirements, strategy, and structure of the work are explored, and the necessary details are captured, organized into jobs ready for assignment, and baselined. The curve begins to steepen as more resources are engaged, and the definition of jobs and methods stabilizes. This phase involves ~20% of the overall effort and ~30% of the schedule.

3. Construction: As jobs are committed and prepared, actionable elements of the work elements are initiated, work in process is generated, results of that work are stabilized, and solution elements are aligned, with a focus on functionality and performance. This represents the bulk of cost (~65%) and schedule (~50%) consumption, powered by peak learning and velocity.

4. Transition: The solution is validated and made available for delivery, with training, validation, and final adjustments. Effort (~10%) flattens and schedule (~10%) reflects wrap-up activities.

The pathway through this landscape is challenging. Each step’s performance has a probability distribution reflecting the natural variation of processing. This variation is amplified as this variation, and its corresponding limits of capacity, inject uncertainty, incorporate feedback from downstream steps, as these functions interact, and adjust to maladies encountered along the way, rinsing, and repeating with each time increment.

Transfer functions

Transfer functions characterize each action’s output for each input. There will be many complex inputs in addition to what is shown in Figure 6; those collectively influence decisions that are abstracted into the Power value that feeds the rates of each step in the flow. Such functions can be implemented by human agents or agentic transformers.

The steps depicted in Figure 6 are outlined below, with flows (the transfer functions) stylized in bold, stocks in italics, and the transition indicated by an arrow character in the following lists. The normal flow (aka “happy path”) is described in the outermost, numbered outline level. These steps typically have one or more feedback loops that are captured underneath each step as indented, exception processing pathways which inject rework into its upstream steps, resulting in delays.

Step sequences

1. Observation: Signals → Opportunities

   Observation is the act of noticing, watching, or measuring something to gather information. These observations can be passive or active; each involves:

   • Perception: Detecting the signals through sensing and communications

   • Attention: Focusing on specific signals while filtering out noise

   • Interpretation: Deriving meaning from perception free of influence from prior knowledge or bias

   Signals come in many flavors - orders, resource shifts, support obligations, and expedite requests among them - but each requires ingredients in amounts appropriate to each situation. Noise can obfuscate these signals; indeed, when the level of noise exceeds the signal, chaos dominates the search for worthwhile opportunities, and can increase the likelihood of subsequent pivots, or influence decisions about needing to ignore opportunities. Incentives must be sufficient to amplify effort sufficiently to effectively capture the opportunities despite the noise.

2. Orientation: Opportunities → Goals

   Goals are a bridge between intentions and execution. Orientation must validate the feasibility of each opportunity (considering timing, constraints, and achievable throughput), confirm relevance with priorities and values, and translate visions into outcomes that realize the intended successes. Goals should follow best practices and describe what success looks like in unambiguous terms, anchoring opportunities with timing to reinforce urgency, provide room for course corrections, and enable evolution as feedback reveals new insights or conditions.

   1. Ignoring Opportunities

      Not all opportunities are deemed worthwhile to pursue, so some number will out of necessity be ignored. Delays in processing are an indicator that such disposition should be considered.

3. Analysis: Goals → Requirements

   Goals are analyzed and translated into requirements through the capture, refinement, and elaboration of context, intentions, and constraints into specific, testable conditions that must be satisfied.

   1. Pivoting towards different Opportunities

      Some goals are worthwhile in pursuing an opportunity but require revision prior to analysis.

   2. Discarding Goals

      Other goals are not critical to pursuing the opportunity and can be discarded.

4. Organization: Requirements → Jobs

   In his book Competing against Luck, Clayton Christensen describes jobs from a customer’s perspective; progress involves understanding what that customer is trying to do in particular circumstances, and what decisions they must make. This step elaborates statements of work, allocates responsibilities, and distributes requirements across jobs for responsible agents.

   1. Revisiting Requirements with respect to Goals

      As requirements are fully considered, the need for clarification, conflict resolution, and addressing missing elements arises, forcing further work on the related requirements.

5. Commitment: Jobs → Preparation

   Commitments require a psychological and relational progression through

   three phases:

   • Understanding: Gaining clarity about the context and expectations for the jobs

   • Acceptance: Acknowledging and embracing the reality of these inputs and their relationship to the jobs being assigned (including responsibilities, relationships, limitations, and challenges)

   • Support: Agreeing to accept these responsibilities and collaborate upstream and downstream to ensure adequate progress is achieved

   Preparation ensures actions connect to broader goals or narratives and empowers responsible agents to navigate this progression so that work can proceed in a straightforward fashion. This preparation is the traditional role that planning performs and enables parallel action in subsequent steps if sufficient agents and resources are available.

   1. Refactoring Jobs given new Requirements

      Requirements changes can necessitate adjustments to job structure considering those changes.

6. Provisioning: Preparation → Actionable work

   Once the parties responsible have committed to perform the necessary work, preparation is performed to define the steps necessary, required interdependencies, and secure the resources necessary for implementing these steps. Work becomes actionable by provisioning the inputs necessary for execution.

   1. Enhancing Preparation given new Jobs

7. Initiation: Actionable work → Work in process

   Although work may be actionable, many factors can delay launching the effort:

   • Cognitive friction: Complexity can overwhelm; goals and requirements can lack clear definition; and uncertainty around prioritization and sequencing can paralyze action.

   • Emotional and relational factors: Anxiety, low motivation or energy, and insufficient alignment on values can burden progress with negotiation or avoidance.

   • Structural barriers: Poor integration of tools, unclear feedback mechanisms, multitasking, and resource shortages (promised but unfulfilled) can erode progress.

   To optimize flow, these constraints should be addressed rather than passed downstream. Initiating action converts potential into momentum, shifting from planning to doing.

   1. Augmenting Requirements after consideration of Actionable work

      Revisions to requirements are typically triggered by new insights into stakeholder needs, technical feasibility, risk exposure, or strategic alignment. These insights often emerge from real-world feedback, evolving conditions, or deeper understanding gained in implementing these requirements.

8. Generation: Work in Process → Results

   Each action is primed by clear intentions and requirements which set the direction and define what success looks like. Interactions with other actions and related systems feed checkout, incorporate feedback, and enable progress to be accumulated.

   1. Discovering new Requirements while performing Work in Process

      See 7.a

9. Inspection: Work in Process → Reviews

   Reviews are a mechanism to generate signals that inform whether to continue, refine, or pivot work in process and candidate solutions. The entry conditions for such reviews are an important consideration in organizing the work.

   1. Abandoning Work in Process

      Effort invested in preparing for and performing work accumulates; when work is abandoned, those efforts are wasted and contribute to the opportunity costs of the endeavor.

10. Incorporation: Review results into Work in Process

    Typical dispositions of review findings include acceptance, conditional acceptance, revision requests, rejection, and escalation for further action. These outcomes vary depending on the context - legal, academic, regulatory, or organizational - but they reflect the reviewer’s judgment on the adequacy, accuracy, and implications of the material reviewed. Additional actions required to achieve this disposition are added to the work in process.

11. Stabilization: Results → Solution elements

    Elaboration, trial, and error powers the maturation of results into candidate solution elements.

    1. Correcting Results

       When results require correction relative to

12. Alignment: Solution elements → Candidate solutions

    Holistic solutions require that the pieces interact properly and collectively satisfy requirements.

    1. Diagnosing problems with Solution elements

13. Validation: Candidate solutions → Progress

    Each proposed solution must be evaluated against real-world conditions before being released into service.

    1. Isolating problems with Candidate Solutions through Reviews

The gears driving production rates

As Figure 6’s legend indicates, each step can be characterized into one of three categories, using the metaphor of a funnel:

1. Exploration: High Variability, Low Throughput

   In exploration, we are in the wide part of the funnel - the scope of searches is wide, and the entropy is high.

   1. Characteristics

      1. Purpose: Discover options, surface unknowns, generate hypotheses

      2. Inputs: Often ambiguous or incomplete

      3. Outputs: Possibilities, insights, candidate pathways

   2. Throughput Implications

      1. Rate: Low and uneven; progress is nonlinear and often recursive

      2. Variation: High given the low quality of information available; cognitive load, novelty, and branching paths reinforce this unpredictability

      3. Constraints: Bottlenecks often stem from lack of clarity, insufficient framing, or premature convergence.

2. Evaluation: Moderate variability and throughput

   Evaluations narrow the funnel through the incorporation of structured filtering.

   1. Characteristics

      1. Purpose: Compare, prioritize, validate, and assess trade-offs

      2. Inputs: Structured options or hypotheses

      3. Outputs: Ranked choices, decisions, or filtered paths

   2. Throughput Implications

      1. Rate: Moderate. Can accelerate with clear criteria and decision matrices.

      2. Variation: Medium; depends on complexity of criteria and stakeholder alignment

      3. Constraints: Bottlenecks arise from unclear metrics, cognitive bias, or decision fatigue

3. Transformation: Low Variability, High Throughput

   These steps exploit upstream processing by operating as the nozzle of a funnel does, allowing agents to ‘turn the crank’ and deliver at high rates.

   1. Characteristics

      1. Purpose: Execute, build, incorporate, implement, or convert

      2. Inputs: Validated decisions or designs

      3. Outputs: Tangible results suitable for follow-on steps

   2. Throughput Implications

      1. Rate: High. Execution benefits from repeatability and automation

      2. Variation: Low; standardized inputs yield predictable outputs

      3. Constraints: Bottlenecks shift to resource availability, tooling, or integration points

Each exception processing step in the step sequences above are explorations for context by searching for the relevant details of the presenting conditions so the underlying problem can be accurately diagnosed. Transformations and evaluations have their own puzzles to be solved, but the context in both those cases is known - to produce a useful result within the attack surface of the territory and goal in question.

Wrap-up

Now that you understand this DNA of production generically, it should become apparent that even straightforward pathways can quickly become quite complicated. Such complications can be difficult to unwind, especially for the inexperienced. Practice and learning are the best medicine for such dilemmas. Such learning requires understanding each of the writings in this series, animating the above dynamics under alternative initial conditions and injections by externalities, and rehearsing the actions expected by each of the

Figure 1 is a depiction of a real machine which was used around 60 A.D. for removing standing water from underground mines. These machines are known as reverse overshot water-wheels, and one of them was recovered from a copper mine at Rio Tinto in Spain and is now at the British Museum.

We know about these devices from the writings of Vitruvius, the Roman architect. He described a specific installation consisting of thirty-two water wheels, mounted and stacked above one another within the vertical shaft of a Roman mine. Each wheel was turned by one or more individuals who walked along the top of the water wheel to spin them.

A batch of water was raised up a specified distance as each worker turned their assigned wheel. This water then became a queue of work for the next higher wheel and worker to process. Each worker could only consume the output of the prior worker after enough water had accumulated at their assigned stage.

The pace of the slowest worker in the chain would thus constrain the end-to-end throughput potential across the entire device. Despite this limitation, their efforts were collectively able to lift the underground water about 200 vertical feet from the mines where they were installed, which was an impressive accomplishment for that time, and which gave the endeavors who used this technology advantage over other competing approaches, such as a bucket brigade.

This device can be considered from two distinctive perspectives. The first viewpoint consists of its capability to raise a column of water by a particular distance; we'll call this a water elevation system. The second perspective uses such a capability in the context of a larger ore extraction system; its primary goal is to economically produce ore which can then be provided as a resource for many other purposes that are not relevant to our example. The extraction of ore was financed by investors who saw this potential. Not all mines had water draining into the tunnels being mined, but when it did, the water represented a constraint which blocked the potential realization of value that could be achieved.

The economics of such ore extraction is determined by the value that ore has in the marketplace, the number of resources necessary to produce that ore, and how long it takes to produce it. Each mine would have unique characteristics, such as the volume of water flowing into the mine, and the height to which the water needed to be raised. The operation of an ore extraction system is only economically viable within a performance envelope and operating context which each device was designed to serve. The throughput of the water extraction system had to be sufficient to consume inflows from all sources of water and any accumulated pool of water present at startup.

The ore extraction system and the water elevation system are interdependent since each requires the other to provide value. The costs to develop and operate the water elevation system will be bounded by the economics of the ore and its transport to a location where the ore is used as an input to another system that would consume the ore, such as a smelter.

The water elevation system would require water to be drained sufficiently so that ore could be extracted from the mine. One can envision water seeping into these underground mines from many sources, such as from rainfall, springs, or underground streams. Each of these inflows may have a varying rate over time, such as when a sudden rainstorm occurred. It might not take many people to extract water during a dry period, and it might take a long time after a rainy period to remove sufficient water for the ore extraction to be resumed. Delays in developing or operating the water elevation system could lead to delays in the time it takes to perform ore extraction, and thus significantly reduce the time-adjusted value of that ore. The actions and skills required to produce operational outputs are fundamentally different from those necessary to develop new capabilities that could extract water more efficiently and effectively.

In this example, the ore is an output of the mining value chain. The water wheels which were used to raise water required personnel, equipment, information, and tools to realize the needed capability. The capability of a water wheel to remove this water would be determined by many factors, including the volume of water which each wheel could consume, the pace at which workers could operate the system, and the leakage which occurs across the elements of the system itself. During operation, pools of water formed at the boundaries between each processing stage performed by each wheel. The size of these pools can provide a visual indicator of the backlog of the work cells that are accomplishing that work. Such queues are inevitable in any development or production process, due to variation in the quality of requirements, the capacity of team members, and the information available to the team.

Development environments share most of the features of the water elevation system described above. In development settings, a cascading process is typically used, as depicted in Stuart Pugh's core design activity model of the interactions of technologies and technique shown in figure 3; note that in this case, the vertical flow is depicted top to bottom, unlike in the water wheels, which are subject to gravity. Each stage requires horizontal integration of the elements relevant to the structure of activities and material relevant to that stage, though the translation into wedges of activity depicted may vary by stage. The flow among team members involved in such designs can be thought of as like those of our cascading water elevation system.

The overall throughput of a team is a function of the interactions between the team members. Feedback can be used to manage the rates of injecting work (be it new or rework) into the system. The queues of work in process between team members can be used to provide visual indicators of the flow of this work as it moves through the system. The size of these queues will be dependent upon whether a batch production, job production, or continuous production technique is being used. A description of managing such flow is here.

Production decisions regarding the allocation of resources across work stages are often driven by the robustness of the forecasting information available, the cycle time variation inherent in each operation, and the quantity necessary for efficient economic operations.

The size of each batch to be processed across each stage of such an operation is critical for many reasons:

• Communications costs grow as connections are n**n for n units, and many interactions are often necessary to coordinate the work across these channels

• Large batch sizes limit efficiencies that may be achieved by performing similar and routine operations together

• Large batch sizes also reduce the usefulness and effectiveness of feedback to improve the system, which complicates connecting cause and effect when something goes wrong.

The value of a batch of work can only be evaluated within the context of the environment within which that work is being performed. A tool (like the water wheels used to provide the capability to elevate the water in question) is only a means to an end; in the case of mining, the immediate mission is to extract marketable ore from geological deposits. Far too often, we are inclined to measure value by quantifying the resources which are visible, or which are easy to measure, rather than by the flow of this work in the context in which value is realized. This can cause us to measure work by the number of people who descend into the mines each day, rather than considering the efficiencies being realized in the various stages of the flow. As Donald Reinertsen indicates:

Product developers create a large number of proxy objectives: increase innovation, improve quality, conform to plan, shorten development cycles, eliminate waste, etc. Unfortunately, they rarely understand how these proxy objectives quantitatively influence profits. Without this quantitative mapping, they cannot evaluate decisions that affect multiple interacting objectives...

Life would be quite simple if only one thing changed at a time. We could ask easy questions like, "Who wants to eliminate waste?" and everyone would answer, "Me!" However, real-world decisions almost never affect only a single proxy variable. In reality, we must assess how much time and effort we are willing to trade for eliminating a specific amount of waste.

A modern, kid-powered version of one stage of this water wheel is in use today for pumping water in underdeveloped countries. In field use, such devices have often failed to meet expectations, and have proved to be more costly, less reliable, and harder to use than the child's play they were marketed to be.

Regardless of the outcomes expected from such production systems - be they technological maturity, new product development, or service excellence - value can only be realized once solutions have been completed and have been placed into service. This can only occur at the rate of acceptance of the methods by users and the throughput of the system overall.

Until then, investments are just holding costs for an uncertain future. They merely represent an inventory of work which has begun but which has not yet been completed. This inventory can be particularly large for software-intensive efforts since the inventory is less tangible than it is for physical assets. This means that investments in labor may exceed the costs of materials, especially when the costs of paying for this labor pool over time are made visible. The size of this inventory is equally critical, since the value they offer may become stale over time, as opportunities for usage and customer enthusiasm for requested work tend to evaporate during dry seasons.

A learning organization can incorporate these performance insights into behavioral changes quickly, efficiently, and effectively. For this learning to gain traction, an organization must design affordable interventions, mitigate constraints arising in different situations, and channel information to where it is needed. These practices are more likely to get traction when they emerge from the collective insights of team members rather than appearing as mandated interventions from above.

The first operational goal of any endeavor should be to lay out the steps required for the realization of end-to-end flow, emphasizing the cyclical nature of these operations. The total elapsed time between the beginning of the first processing step and the end of the last processing step of these iterations is the cycle time. Within development processes, productivity improvements are always a function of achieving cycle time improvements in some form.

Waterfall-based development processes provide recipes for large-batch processing. They share the same wastefulness, inefficiency, and risk as bureaucracies. Therefore, they tend to accumulate large inventories of work-in-process at each step in production and suffer from decreasing throughput over time. A strategy of small-batch, continuous flow can instead identify opportunities to improve efficiency by eliminating the wasteful burdens of delay, work in process inventory, and communications breakdowns between process steps.

We can highlight these principles by performing a thought experiment within the context of transportation planning. The purpose of highway systems is to enable the efficient transport of people and goods from one place to another. The total resource consumption and cycle time of such systems are a function of traffic congestion since pathways are susceptible to the tragedy of the commons. Traffic flow over these pathways is a function of the speed and density of the vehicles and is. As traffic density approaches the capacity of any segment, average traffic speed at that location will begin to decrease.

It is easy for bottlenecks to arise in such systems. When traffic density begins to exceed a particular loading factor, local perturbations (such as a driver touching their brakes) can cause a cascading effect over a large distance, and this delay can propagate for a long period of time. While one delay is playing out over time, the probability of a second issue arising is increased and may have an even greater impact.

Predicting the time it takes for a particular vehicle from one location to another is highly dependent upon many factors. Average flow is impacted by many factors - the average capacity of the channels over which it travels, the patterns of demand at different points along those pathways, environmental factors, bottlenecks, characteristics and interactions of the vehicles, etc.

The nature and quality of information available to manage such flow changes with time, Further, delays often impact other parts of the endeavor, resulting in further waste and inefficiency. Yet this flow cannot be increased just by encouraging each vehicle's driver to maintain their speed. Because of the frequency and impacts of these constraints, infrastructure improvements should be deliberately designed to enhance flow. For example:

• Incoming lanes are designed to allow entering vehicles to merge at the same speed as the rest of the traffic.

• Metered ramps throttle vehicles on entrance ramps carefully to maintain spacing between traffic.

• Emergency vehicles are pre-positioned to respond quickly to problems.

Individual drivers desire minimal transit times, yet lack traction to do something about it themselves; the system they are in just pushes back, in ways that can frustrate everyone.

When resources like gasoline consumption are considered for this transportation system overall, the impacts of relatively minor issues can thus have major systemic effects and result in far greater impacts than would be immediately apparent. Yet the root cause that caused such effects are often not easily seen from ground level, as the volume of traffic, and the passage of time introduces significant noise into making these associations. Since new designs for roadways take a long time to change, by the time they are actually implemented, they are often no longer relevant to the new traffic patterns which have emerged since these designs were introduced.

This traffic flow analogy helps to explain situations in which processing time is largely predictable, and there is little variability from item to item. This is the case in most manufacturing environments, and organizations usually strive to drive out all waste that arises during production operations within such settings. To return to our traffic analogy, in such environments, each vehicle would only put as much gasoline in their car as they think will be necessary to get to their destination on average, with a small contingency. When there is little variation item to item, this might be an acceptable strategy. Unfortunately, these conditions rarely exist in other kinds of projects and would lead to disabled vehicles clogging up the roadway (and additional vehicles servicing those vehicles). In environments where work differs widely in form, context, and structure, the time it takes to process this work will be highly variable.

For technical debt to be retired, and solutions to be produced more cost effectively, systematic, repeatable methods must be adopted that will produce more reliable outcomes for larger and more complex efforts.

Structured processes were initially introduced into such environments to mitigate the painful lessons associated with more ad-hoc methods. Yet an emphasis on process is frequently cited as a burden by developers that constrains them from pursuing their passion, and getting that which needs to get done, done.

Many have the perception that in-process quality doesn't matter, and that it is the ends, rather than the means, which matters. This is like saying that if water is clean, it doesn't matter where it has come from or what has been done with it. Today, countless development and manufacturing standards have been refurbished to attempt to address contaminants discovered after all processing is complete. Too often, organizations have adopted such standards as protectionist legislation intended to keep new competition out, rather than to guarantee higher quality outcomes.

Some quality definitions

To think through how to do this, some basic definitions are in order. A defect is anything that must be changed in a design or implementation because it detracts from the system's ability to meet stakeholder's needs completely and effectively. Defects can be identified, described, and counted; they are discoverable. The interrelationship between a defect, and the impacts from that defect (which may manifest through failure, as described below), is complex. Even simple defects can cause large problems, and not every defect can result in a failure (since it can be masked by the architecture, or latent until the required combination of events excites that flaw).

When agents make mistakes that result in defects, these lapses are typically described as injecting defects. The rate at which they do this is measurable and has been found to be between 50 and 120 defects per thousand lines of code. Half of these defects can be detected by modern tools during coding and unit checkout; an acceptable proportion of the remainder must be removed through down-stream evaluation activities. If those prove inadequate, they risk escaping into service and affecting operations for customers.

A bug is an observable anomaly which results from a defect and is discovered because an inconsistency with expected behavior is noticed by someone (who hopefully then records this observation so that it can be analyzed and traced to root causes).

Bugs typically manifest themselves through the following pattern:

1. A defect is introduced into a component, or into a related artifact (requirements, design, construction, or test) that is being produced during development. Note that the agents responsible for the component, the artifact, and this verification are often different individuals.

2. When a path through software logic (either within or across modular units) triggers this defect, one of two possibilities arises

   1. the execution state of the code will no longer valid relative to the intentions of the design

   2. the artifact will mislead those responsible for implementation or verification

3. In the case of defects, this invalid state can itself propagate throughout the system in other ways (as other execution sequences are traversed) to produce other invalid states

4. One or more of these invalid states may then eventually result in a bug - the externally visible condition - though this is dependent upon the combination of the execution sequences that are traversed.

5. A failure may further occur when one or more errors in the system occur, are propagated, and cause the system itself to enter an unsafe, incorrect, or unacceptable operational state.

The relationship between defects and failures is thus quite complex and is highly dependent upon the architecture of the system and the robustness of its implementation. Frequently, it isn't just one defect or error that leads to a failure, but a combination of several.

What it takes

Development processes require diligence, effort, and appropriate tools to shortcut routine operations and help us avoid making slips; unfortunately, both people and tools are fallible. Would you drink water from a glass that was dirty, or drink from a catch basin that had a visible scum coating the inside of it? Probably not unless you had no other choice. Yet this insight can clarify the importance of having a well-designed process to produce a high-quality product. Believing that dirty pipes can produce pure water amounts to accepting the position that flawed tools or oblique human efforts will produce satisfactory results without accountability. Still, this myth lives on in the minds of both novices, some experts, and particularly bureaucrats.

Quality is difficult to measure directly. The operations necessary to transform inputs into acceptable outputs require multiple steps to be performed, across diverse environments, regardless of whether a business’s products are suitable for human consumption (like drinking water and software) or not.

If we stick with this plumbing analogy a bit, we can consider requirements to be like a supply of drinking water. The value stream that turns these requirements into useful progress is analogous to the links of pipe that fit together to carry water from its source to where it will be used. Each link is like the steps in the processes of a value stream. These processes may require defining what kind of product is needed, developing artifacts - designs, tests, and verification activities -which assure that the product complies with its requirements and does not introduce hazards to customers. If the links don’t interface properly, or there are missing links, value will be difficult to realize.

If the interconnections between these activities are like catch basins, buckets, and funnels, then someone must make sure the aggregated flow accumulating in these reservoirs is not stagnant or contaminated. Eventually something will exit from the pipeline, and with perseverance, it will be a quality product. The integrity of the pipeline will impact the quality of the output. There is no guarantee that even the most superb development processes will produce correct products and services.

Software quality has become a catch-all buzzword for a huge family of various methods geared either toward achieving better software or toward assessing how good software is. Each of these methods represents a different pipe link, and there are numerous ways of integrating these links that make sense; other combinations are nonsense. For example, putting the system level testing link in front of the processes for checking the requirements for ambiguity is foolish. Not all problems with water (or other products) are self-evident. Management of water quality is like other types of quality management activities and requires risks and opportunities to be managed across the entire water supply network.

Today’s quality practices can be categorized as either process-oriented or product-oriented methods. Process-oriented standards and methods focus on the effectiveness of implementing best practices; CMMI, DO=178, and ISO-9003 all expect a focus on quality across all critical activities, including assurance that this focus is sustained. In contrast, product-oriented verification approaches often presume that you can test quality into a system, rather than assuring that the people, methods, and information involved are all up to the task.

If we return to our analogy of a water system, flow-oriented methods function like connections that are distributed at separate locations along the pipe that allow software representations - whether in a design language or specification format - to be sampled to assess its correctness. The methods that perform assessments would be clustered towards the latter half of the pipeline, since in the earlier phases, code will not be available. These process-oriented methods would attempt to ensure that the original requirements were clean, and that every transformation through the development cycle was not contaminated. Clearly if the water quality is compromised at point A, then at a later point B, it will remain so, unless some filter is employed between A and B. Water doesn’t clean itself any more than incorrect software fixes itself, and water treatment has its limits.

People are prone to making mistakes

You might believe that to assess software quality, all you need are adequately predictive reliability estimation techniques. Most reliability models employ error history information from other situations and use them to forecast future error rates. The problem is that different models can make widely varying reliability projections for the same data, making it impossible to determine which model is the best predictor for a situation. Reliability will be a function of how many errors are injected and detected. Even direct measurement of software quality is less than practical.

Even ignoring all the potential sources of errors in generating test cases, defining test oracles, administrating test execution, and the fidelity differences between development, test, and execution environments, this is unlikely to change anytime soon; the people in the loop are usually the greatest source of defects.

Many of the remaining software assessment approaches focus on metrics. Over one hundred software metrics are in use today, typically focusing on measuring the structural or static properties of the system. The key problem with such metrics is that they do not capture the essence of software. Software is implemented by iterative refinement of mechanisms for transforming inputs into outputs, through a series of prescribed operations. This transformation is the essential characteristic of software development.

Each execution of a program involves a series of state transitions, where each machine state shapes the output. Exactly what effect a particular instruction has on the mapping between program inputs and program outputs is determined by the program’s input space distribution and the program’s control logic and instructions. Structural metrics cannot capture this dynamic aspect of software behavior. This lack of connection with the behavior of the software makes structural metrics especially poor as a predictor of in-service quality performance.

Methods

Research has suggested using fault-injection methods to assess software quality by determining the rate of discovery of these defects. Such techniques purposely inject faults into your software and checks to see whether such injections are detected by other verification methods. However, the types of defects that affect most systems are broad, and the interactions that such defects produce simulates some of these events, and by doing so, it predicts how the software will behave in the future if these anomalous events were to occur.

This entire process of fault-injection relies upon statistics and pseudo-random fault-injection methods. Also, the actual process of instrumenting for the anomalies is quite complex. But the results can be most informative, particularly when you learn that your code doesn’t handle problems quite as well as you thought it would. This information provides an immediate quality improvement opportunity. Interestingly, software fault-injection methods, while they directly assess the behavior (i.e., goodness) of your code, also indirectly assess the goodness of your pipes.

By this, we mean that if software fault-injection methods determine that software is intolerant to either faults within itself or anomalies that can attack the software from external sources (such as human factor errors, failed external hardware, or failed external software), then we learn that the other software development processes failed to build in the necessary water filtering mechanisms. Code must be designed with the proper water filtering systems to ensure that the result from the pipe is clear of defects. If software is incapable of producing the outputs we want under even anomalous circumstances, then we cannot claim that the pipes are clean. And if over time it can be demonstrated (via the results of fault-injection) that the set of pipes you have used repeatedly do result in clean water, then you at least have anecdotal evidence that correlates your processes with the quality of your software.

The quality of your pipes is only one part of what determines the purity of potable water. It is myth to believe differently. Sadly enough, people at the highest levels in governments and corporations have all swallowed this lure, hook, line, and sinker. Quality software does not fail often and never fails in hazardous ways. Software development processes do not define software quality; software behavior does. Behavior is an intrinsic characteristic of software, and it can be viewed without regard to the software’s developmental history.

Before we can have faith in software standards and process models, it must be demonstrated that they have quantifiable effects on the quality of the software produced. Parnas once said: "It seems clear to me that not only is a ‘mature’ process not sufficient, but it may also not even be necessary."

The current popularity of process-oriented assessment techniques is, in part, a reaction to the intractability of performing adequate assessments of software projects. Unfortunately, the relationship between development processes and the attainment of some desired degree of product quality has never been adequately established. This problem is particularly acute for formal methods: forming the required processes does not give quantifiable confidence that the software, when released, will have the required reliability.

In short, testing measures the right thing - product reliability - but it often cannot measure it to the desired precision. Process measurements are more tractable, but they are more effective at managing the flow of work than they are at answering questions like 'how many problems remain'. Some basis must be established to build a data repository from which predictions of uncertain futures can converge with time. And with even more data from such projections (given some underlying framework for the underlying activities and characterization from which several factors such as effort, process yield, and product stability can be analyzed and improved.

Yet few are willing to accept a charge of incompetence. Consider BP, the third-largest energy company in the world. Hydrocarbon exploration is a high-risk business; should a less than perfect record be considered incompetent? Throughout its history, BP's leadership consistently represented that financially, it was not only competent but was one of the premier companies in the world. Many of BP's workers criticized the company's repeated emphasis on cost-cutting. But such cost pressures are present in competitive businesses. Yet after the Deepwater Horizon Oil Spill, the company's environmental and human rights records were widely regarded as abysmal. As the results of investigations into the accident unfold, multiple factors contributed to the disaster.

The accident could have been avoided with the most basic of procedures - if the battery in one of the wellhead's dead man switches had been replaced in a timely fashion (a routine maintenance operation) the catastrophe could have been avoided. In the court of public opinion, BP (and its employees) may never recover, all for the lack of a simple battery replacement, which a competent organization should expect their competent workers to perform routinely.

Each of these perspectives of competency - corporate, legal, and personal - may appear to draw from similar concepts for different situations. Yet upon closer examination, the specific meaning for competency is highly dependent upon the context in which it is used, the criteria of the competency evaluation, the qualifications of the evaluator, and the implications of the determination.

The real reason the word 'competency' is used so much in today's businesses is that we all want to be competent when it counts. A bias known as the Dunning-Kruger effect by itself can explain why the results of most self-assessment competency evaluations are so often determined to be unreliable. Further, since the criteria for conducting competency evaluations may not be well defined in advance, the evaluation itself can be subject to evaluator biases, political considerations, and other factors. These, in turn, may cause determinations to be quite different than real performance, and produce outcomes quite different from expectations.

Strategic decisions are considered competent when they shape the nature of an organization through decisions which have long-lasting effects. As a result, these decisions are critically important to get right. In this context, the keys to achieving competency include:

• self-awareness, to confirm the ability to perform

• confidence, to enable a willingness for action

• judgement, especially around boundaries that make a difference

• trustworthiness, to provide

• mastery, reliability built from repetition

The classic work on shaping human performance is Human Competence: Engineering Worthy Performance. It seeks to 'engineer' competency through deliberate action. The choice of the word "engineering' is a deliberate one, which Gilbert describes as follows:

Scientists approach their fields of study with humility, seeing themselves as small spots of intelligence "surrounded by a vast sea of ignorance", to quote Issac Newton... The scientist approaches nature as a little child does, to discover what it is like. The engineer approaches nature with a swagger, determined to change it into something it never has been and never would be, if left to itself. The scientist has a well-developed methodology and follows it wherever it may lead; the engineer knows precisely where to go, and will use any available methodology to get there...

Gilbert's heuristics about competence incorporate the following ideas:

• Human competence is proportional to hard work, motivation, and knowledge

• Incompetency does not necessarily mean inefficiency

• The less competent people are, the easier it is to improve their performance.

Individuals seeking to improve their competency should begin by making sure they have a well-formed and consistent understanding of the meaning of the term. This understanding will be further enriched in other articles in this series.

The book The Origins of Efficiency describes production as follows:

Outside of the small number of things we can obtain directly from nature, all products of civilization are the result of some sort of production process—some series of transformations that take in raw materials, energy, labor, and information and produce goods and services. At first glance, services might seem far removed from the production of physical goods like cars or shoes, but the same basic model applies. A house cleaner, for example, goes through a specific series of steps—cleaning the bedrooms, then the bathrooms, then the kitchen—using various inputs—labor, electricity, cleaning products—to transform an input—a dirty house—into an output—a clean one.

It is an abstract concept that must achieve fitness from a variety of contexts:

Several factors are at work to make moving production technology from one place to another so difficult. For one thing, there will often be substantial differences between production facilities, even if they’re in the same industry and producing the same goods. Different facilities may have different production volumes, target different markets, or have different product designs. (Aston Martin and Toyota both make cars, but their markets, production volumes, and designs vary dramatically.) They may have chosen other options from the palette of available production technologies, or they may utilize separate standards, such as imperial versus metric units or 120-volt versus 220-volt electricity. They may be operated by organizations with different strategic goals, organizational structures, or work cultures. They may be subject to individual regulatory requirements or have different resources available to them, such as what skills can be found in the local labor pool. In short, a production process, like any technology, doesn’t stand on its own but is always embedded in a particular context—a surrounding environment of resources, knowledge, assumptions, and relationships.

Let’s explore a conceptual presentation of production as a black box, from several perspectives:

• the holistic production process that is comprised of lower-level, separate interacting processes of a system of interest

• the means of production for that system as separate production systems which provide inputs for the production system of interest

• the outputs of the system of interest which serve as inputs to downstream processes (distribution, installation, support, …) and which are also production systems in their own right

Figure 1 provides a stylistic representation of this structure:

The figure depicts a sprawling, industrial production line reminiscent of Ford’s River Rouge complex. It’s rendered in a gritty, mechanical blueprint style with heavy textures and large machinery evoking the grand scale of an early 20th-century factory. This depiction reinforces the recursive and reentrant aspects of any production system of interest:

• Primary System of interest: At the heart of the image sits a large, complex machine labeled “Production System” and acts as the central node for a network of capabilities. It is robust and intricate, with branches and interfaces suggesting dynamic interactivity.

• Upstream Systems: Across the top of the primary system of interest, there are several interconnected feeder lines, each themselves production systems. These stations are labeled respectively as Resources, Models, Infrastructure, and Information, and are connected to the system of interest by transportation elements that supply necessary inputs. depicting the flow of elements necessary to drive and fuel the system. The supply of the primary system of interest depends upon the adequacy of supply from these upstream systems. These collectively are often described as the Means of Production, and correspond to Elon Musk’s conceptualization of a factory as a machine:

  • The true difficulty, and where the greatest potential is, is building the machine that makes the machine. In other words, it’s building the factory. I’m really thinking of the factory like a product.

• Downstream Systems: Extending from the system of interest across the bottom of the figure, the primary system of interest interfaces with other production systems - Distribution, Installation, Training, Operations, and Support - that are instrumental in delivering value to customers. These downstream systems are shown as extension bays where the finished output is processed, refined, and prepared for usage in service.

• Coupling: Bright lines symbolize the active, continued flow of energy, information, and materials across these elements.

For examples of this hierarchy, consider the architecture of living systems.

Production functions

In economics, the utilized amounts of production inputs determine the quantity of output through a relationship called the production function. It is a key concept in mainstream neoclassical theories, where it is used to consider marginal products and to evaluate allocative efficiency. These uses involve applying the input factors of production and observing their resulting effects on output, while abstracting them from the technological problems of efficiency as an engineer might understand it. These concepts consider production as a black box with a ‘happy path’ mindset.

Powering the means of production

In a production process, factors of production, resources, or inputs are used to produce outputs, i.e. goods and services. There are four basic resources or factors of production: land, labor, capital, and the capability to apply these efficiently. Materials and energy are considered secondary factors in classical economics because they are derived from land, labor, and capital. These primary factors facilitate production but neither become part of the product (as with raw materials) nor become significantly transformed by the production process (as with fuel used to power machinery). In my rendering, I use a different term - power - to delineate differences from classical economics and connect to engineering concepts. In the context of production, power looks like this:

Production and capabilities

Capabilities are like means of production but supplement them by providing expertise for agents to implement the transformations of production efficiently and effectively.

These capabilities become the ‘levers’ by which production optimization can be performed.

Transducers and conduction

In physics and electrical engineering, a conductor is a type of material that enables the flow of current in one or more directions. A flow of negatively charged electrons transfers this current from the current source to those consuming it (the loads). Each charged particle nudges its neighbor a finite amount, causing a chain reaction that powers the consumer loads. Many factors influence these transfers - including the material’s properties, cross-section, length, temperature, and ampacity. They also determine its resistivity, or ability to oppose the current, which leads to energy dissipation.

Production and conduction share similar roots. Each term carries a nuance of guiding, channeling, or bringing forth something new. Production’s Latin roots - pro- (“forth”) + ducere (“to lead”) - imply bringing something into being through agency and transformation. Its semantic twin, conduction, has similar roots: con - (“with, together”) - and injects the idea of collaboratively working together to channel or transmit the outputs of producers to the inputs of consumers. This systemic flow exploits the structure, medium, and policy of production to enhance behavior.

Within this context, transducers encode outbound messages from producers into a ‘language’ downstream consumers can interpret and decode into suitable form for their own internal processing.

The medium of conduction brings another idea into play. The payload being transmitted is subject to noise, and is also often amplified, filtered, lost, or itself transformed as it is exchanged. These characteristics play heavily in the effectiveness of connections across elements, and how they perform as a unified whole. They also connect each production system with its means of production; when the channel capacity of these connections is not adequate for demand, delays are injected into processing. The reason may be conduction sludge.

Characterizing flow over time

Economics, manufacturing, and accounting fields often distinguish between quantities that are called stocks and those that are flows. These differ in their units of measurement. A stock is measured at a specific point in time and represents a quantity existing at that time, but which may have accumulated from prior flow. A flow is a ‘valve’ which defines the quantity passed through a particular point within an interval and is thus measured in quantity per units of time, analogous to rate or speed.

Flow concepts are important to gain operational insights on performing work once authorized, as shown in Figure 3:

This structure represents the aspects of operational costs from a lifecycle viewpoint and highlights the impacts on these costs from delays and quality escapes. To thrive within this structure, the drivers of cost from each element in Figure 3 must be actively orchestrated. This requires understanding the rate at which various kinds of work can be performed, how that evolves with time, and the longer-term consequences of short-term thinking. Planning, designing, and managing these rates are critical skills to facilitate learning and optimization. Let’s explore some examples in which stocks and flows are critical factors for production in economics.

Flows are used to represent income, spending, saving, fixed investment, inventory investment, and labor utilization. Capital is a stock concept which can be invested to produce a periodic income which is a flow concept. A person or country might have stocks of money, assets, liabilities, wealth, means of production, and inventories. It can be invested in human capital (or labor power). A simple view of these concepts is provided in Figure 4.

The gross domestic product refers to the total number of dollars spent within a period. Therefore, it is a flow variable with units of dollars/year. In contrast, the U.S. nominal capital stock is the total value, in dollars, of equipment, buildings, and other real productive assets in the U.S. economy, and has units of dollars.

A black box flow model

These concepts are also particularly helpful in thinking through a development process flow. Figure 5 shows how work is processed through a typical value chain. In this figure, there are two systems of interest depicted, one behind the other. They must collaborate to deliver service-ready products and services. As Figure 1 indicated, there are many production functions that require orchestration, but they all share the same conceptual structure:

Let’s break down these components and their responsibilities:

1. Orchestration (top left)

   1. Sets direction, pace, and structure

   2. Feeds Needs and balances supply of what must be provisioned across the production systems of interest

2. Production enablers (upper right)

   1. Translates needs of system of interest into actual Means of Production (resources, infrastructure, capabilities)

   2. Includes a provisioning delay, depicting the real-world lead time to hire/train, procure hardware, and deploy processes

3. Execution & Flow (center)

   1. Jobs to be Done → Actionable Work → Work in Process → Service-Ready Products & Services

      1. Stocks (rectangles) accumulate WIP, service-ready inventory, raw materials.

      2. Flows (valves) show conversion rates, capacity constraints, and rework loops.

      3. Constraints to be mitigated fall into two classes: material needs and decisions needed. The rate at which these constraints can be mitigated determines the delays in flow from their discovery.

4. Demand & Delivery (left and right edges)

   1. Target Customers define business/technical requirements.

   2. Customers receive deliveries and generate support requests (which brings another delay).

5. Key Dynamics & Feedback

   1. Capacity ↔ Demand Balancing

      1. Capacity (a dynamic property of the Means of Production) must scale to match the demand, or the rate work enters the system

      2. Undershooting demand with capacity creates queues which delay delivery, while overshooting it ties up investment in idle capacity

   2. Rework Loops

      1. Known Rework and Undiscovered Rework both send items back from WIP or even service-ready stock into earlier stages, incurring additional costs of quality.

      2. Support requests → Jobs may delay responsiveness to customer needs unless provisions for expedited service are provided.

6. Decision Points

   • Trigger where and when to invest (scale infrastructure, hiring, …) or mitigate constraints (bottlenecks, material shortages).

   • Provide opportunities for adjusting allocational efficiencies.

7. Delays & Latencies

   • Provisioning, supplier lead times, and support-response delays all introduce oscillations if not smoothed by buffers or governing policies.

   • Conduction issues can inject undesirable effects into transfers.

By modeling production as a black box, we gain a powerful vantage point for diagnosing inefficiencies, identify opportunities to learn to enhance throughput, and align capacity with demand. This black-box abstraction doesn’t ignore complexity, it channels it. Whether we’re scaling infrastructure, mitigating rework, or navigating provisioning delays, this viewpoint helps us see the system as a whole and think through strategies to act with precision. In a world where costs are not merely calculated but must be reduced, this orientation offers both strategic clarity and operational leverage.

The next step in this series involves understanding how to optimize such situations is to dive into a post about how production breaks down.