• drives or shapes your subsequent actions over a planning horizon (typically multi-year)

• are not easily changed once made, and

• will have the greatest impact at this point in time on your long-term success

This handful of decisions includes:

• selecting your strategic posture with respect to your customers for the products and services which you intend to offer them

• identifying the value propositions which you will pursue with those customers through a coherent concept of operations

• developing approaches to create or align projects with these sources of value

• constructing tailored delivery systems to realize benefits from these projects as soon and broadly as possible

In synthesizing these strategies over time, customer-driven value should be pursued by extending:

1. Speed: the ability to deliver results faster than before, and respond rapidly to the emerging needs of the business

   • Approaches to quickly and successfully launch activities for the most frequently occurring customer engagement scenarios

   • The ability to rapidly and reliably reallocate resources to new situations with the minimum of friction

   • Responsive and effective infrastructure for satisfying operational service requests

2. Capacity: assuring a supply of products and services that is sufficient to meet the needs of all customers

   • Capacity that is scalable to meet current and future requirements cost effectively (up and down)

   • Strategies to extend the reach of products and services so that unit costs can be driven down

3. Efficiency: More products for less resources across the life cycle of your products and services

   • Managing assets and execution resource consumption to extend the leverage of investments

   • Eliminating chronic patterns of waste

4. Delivery: Products and services that accelerate delivery of results to the customer

   • Architectures that enable responsive, cost-effective solutions for customer’s needs - now and in the future

   • Scalable solutions which offer value and choices to the customer for different levels of investment

   • Approaches which insulate customers from the underlying means of production (‘handle the details’)

5. Quality: Reliable realization and cost-effective satisfaction of quality expectations for the customer

   • Assuring that the quality of products and services is adequate to support customer needs

   • Coordinating infrastructure changes so they have with minimal impact to customers

   • Keeping systems operating at peak performance

   • Ensuring that infrastructure provides security controls and maintains the integrity of the organization’s information

   • Managing corrective action and restoring services when outages or problems occur

Opportunities to pursue such value will only be worthwhile if they are appealing to your customers, can be monetized, and if the resulting revenue or resource authorizations can be redistributed among the organizations to reimburse the costs of implementing the required changes, and sustain and support the changes over time. All of these require anticipating the customer’s needs based upon insights derived from working together over time and developing an understanding of their preferred patterns, chronic issues, and future direction.

Regardless of how they are communicated, key success criteria for evaluating and selecting them are as follows:

1. They must promote a consistent understanding of their intent, scope, and reach across multiple stakeholders

2. They must integrate and exploit the conceptual knowledge available within the organization

3. They must provide utility for the organization’s business and its evolving environment under multiple possible future scenarios

4. They must facilitate exploration and trade-offs of candidate approaches to implement the strategies as the environment evolves over time

1. All work must be clearly defined as to content, sequence, timing, and outcome.

2. Every customer-supplier connection must be direct, explicit, and transparent

3. An effective protocol must be used to communicate requests and information about deliveries and priorities.

4. The pathway for delivering every product and service must be simple, seamless, and well understood by the responsible agents.

5. Improvements must be guided through carefully controlled experiments, under the guidance of an experienced coach, at have ownership at the lowest possible levels in the responsible groups.

Lean means the elimination of waste. In manufacturing, this typically means reduction of material in inventory, since that material is expensive, and since such reductions cause efficiencies in other important aspects, such as cycle time. In knowledge-based industries, waste is not extra people, as you might expect, but rather a reduction in the information and decisions that are ‘in inventory’, or essentially, in processing. This waste reduction is usually further augmented with additional efficiency improvements, by balancing capacity against demand and prioritizing work queues.

Lean practices have not yet achieved the penetration within engineering groups that they have achieved in manufacturing. I believe this is for several reasons:

1. Engineers don’t always understand why cycle time is important to the business.

2. A lack of a clear and brief explanation of how lean principles can be applied to the engineering environment.

3. There haven’t yet been enough good examples and ‘how-to’ guidance available or shared on Engineering Lean practices that have been relevant to engineering fields.

As a result, many engineering groups think Lean practices are not relevant to what they do, believe that Lean is a way of thinking, rather than a collection of techniques, or do not know what steps they might take to employ these techniques.

In manufacturing environments, variation typically arises when recurring, mechanistic operations are implemented inconsistently. Within engineering, such routine operations do not exist, since each design problem is unique, requiring searches through unfamiliar territory for potential solution elements.

Identifying waste

What’s common to both environments is a mandate to improve, and Lean can help in that regard. To accelerate outcomes, waste is anything that stands in the way of that objective. Pursuing waste reduction unlocks access to the next goal - removing these obstacles from the pathway of future endeavors.

For example, if regular meetings don’t seem to be helping move towards these goals, then in the spirit of removing waste, the design of these meetings should be reconsidered. Streamline the communications path by separating those critical for decision-making from those who merely want to be kept informed.

Avoiding rework, upping quality, and root-cause analysis

If a feature has an unusually high defect density, it may contribute to wasted time and effort. This wasted time doesn’t help in getting software in the hands of the customers, therefore, an effort should be made to reclaim it. The only way to do that would be to - get it right the first time. To do that, one has to ensure that no (or as few as possible) bugs are found during the final testing, instead, everything ought to be caught and fixed earlier.

This means two things - one, that testing needs to be done early and often through all stages of the game. Two, each time a non-trivial issue is discovered, the root causes should be investigated to prevent the same kind of thing from happening again. This is the equivalent of the ‘pull the Andon cord’ philosophy of Lean manufacturing.

Getting better at the difficult stuff

One reason why certain teams to achieve frequent releases is because deployment is hard. It can be an arduous process with lots of moving parts. That is the kind of situation that is ripe for fresh eyes and new thinking. Thet technical debt that inevitably piles up when not doing this boldly, simply must be avoided at all costs - else it will kill even the possibility of speedy delivery.

Multi-skilled people

When tasks require unique skills, those skills can become single points of failure should those individuals be unavailable for any reason. Such bottlenecks must be resolved. Having redundancy of skills across a Lean team can help mitigate this risk.

A culture of excellence

A culture of excellence can contribute to reducing cycle-time further. These include limiting the size of queues, achieving single-piece flow, using pull scheduling systems, and proactively discovering the next opportunity that can improve throughput of the team.

Each team-member should have a caring attitude for the customer and a curious attitude. One set of questions can be directed towards the customers themselves, to gain a fuller understanding of what they’re trying to achieve, so that the best, most creative, and efficient solution can be found. Another set of questions can be directed to the team and its processes. By following these practices, things become better for the customer, for the company, and for the team as well.

This culture of excellence judges its results by one metric alone: throughput. It realizes that any step taken to improve things should be measuring its effects. This culture should focus on how to optimize the whole system, and not just a part of it. Cycle-time is one of the easiest and most effective measures for managing this throughput, and can be enhanced by following these practices.

Once offerings are placed into service, existing resources need to begin be allocated to improve the quality and functionality of the product which may have been viable, but is now on life support. These improvements become the focus of subsequent iterative cycles in order to refine, shape, and extend the value of the solution for a broader range of customers. As figure 1 shows, the size of the batches packaging this value has a direct relationship on the holding costs for the business, which are a function of the availability of the information, material, and resources necessary for future investments.

As an example, in Managing the Design Factory, Don Reinertsen highlights how such batch size tradeoffs can play out in protracted test cycles:

Let us define the batch size of our testing process to be the amount of design work that we complete before we start testing. The largest batch size would be waiting for the entire design to be complete before we start the test. This will minimize the number of tests, but we will discover our defects very late in the design process, when it is expensive to react to them. In contrast, if we test a partially complete design, we deliver the information associated with the test earlier. Our problem is to balance the cost of extra test cycles against the cost of making expensive changes late in the design cycle.

Faster iterations enable multiple efforts to search for value in parallel with the decision cycles framed by their circumstances. Timeboxing of these iterations facilitates the exploration of more alternatives within a given timeframe and provides opportunities for more effective evaluations to be performed earlier, to determine which ones are worth saving, so the rest can be pruned out without a lot of collateral damage. These adaptation tactics form an essential practice for businesses which enables convergence of fitness for use through incremental cycles of learning. This convergence is effective even when performed within a constantly changing environment, as long as the team’s agility is faster than the pace of environmental change.

In the initial iterative cycle, the initial conditions, transformations, and context may all be flawed, but it is necessary to be able to tell the difference. We would like to be able to reduce uncertainty and improve our projections of the work to go until our original commitments will be achieved; the earlier and more frequently we obtain information about that target and our path towards it, the better off we will be.

As products come and go, those that glitter may not subsequently be found to contain gold. The evaluation of opportunities must be adequately framed, so that evaluation and prioritization can be performed competently. Implementation then requires a series of transformations across multiple planning horizons, disciplines, organizations, product breakdown structures, and work breakdown structures. Control of batch sizes is critical to enable feedback to be incorporated with each cycle of these transformations, unlocking tremendous efficiencies:

Author Rose George explores the taken-for-granted environment of containerization around the world, and its often opaque ownership structures, regulations, and inhumane working conditions. The world of container ships has everything sized in terms of twenty-foot equivalent units. Ninety percent of our modern world's consumption travels by these means, and make it possible to send a can of beer around the world for about a penny. As the book describes, this creates odd incentives which make it cheaper catch fish in Scotland, freeze them and ship them to China, filleted them, re-freeze them, and shipped them back to Scotland, where they are sold in a Scottish grocery store at less than had the processing all have been done locally by Scottish workers.

Erhardt Reichlin, author of The Art of Systems Architecting, describes how to achieve this progressive elaboration - by reducing batches and increasing iterations - as follows:

Stepwise refinement is the progressive removal of abstraction in models, evaluation criteria, and goals. It is accompanied by an increase in the specificity and volume of information recorded about the system, and a flow of work from generalized to specialized design disciplines. Within the design disciplines the pattern repeats as disciplinary objectives and requirements are converted into the models of form of that discipline. In practice, the process is neither so smooth or continuous. It is better characterized as episodic, with episodes of abstraction reduction alternating with episodes of reflection and purpose expansion.

Since the value of information uncovered during this pursuit quickly decays, it must be acted on quickly. While more information seems preferable to less, in practice, information is only trusted in decision-making when it is accurate, meaningful, and relevant to the situation. The groups responsible for accomplishing this stepwise refinement need sufficient capacity to respond to latent demand while having effective channels to return work packages that are not sufficiently developed for realization.

• who are the customers?

• what do they need in order for business objectives to be realized?

• what functions must be provided by solutions to fulfill these needs?

• how well must solutions perform for these functions to meet expectations for cost, quality, and schedule?

• which requirements are necessary to characterize acceptable solutions in order to focus and manage development?

• how will the uncertainty of achieving these requirements within the negotiated resource bargain be managed?

Here is Stanford Beer on such resource bargains:

The Resource Bargain is the ‘deal’ by which some degree of autonomy is agreed between the Senior Management and its junior counterparts. The bargain declares: out of all the activities that System One elements might undertake, THESE will be tackled (and not THOSE), and the resources negotiated to those ends will be provided.

However autocratic or democratic (or even anarchic) your Resource Bargaining proves to be, the governing mode of management is Accountability. Please think about this responsibility for resources provided in terms (not of financial probity, not of emotional dependency, but) of variety engineering. Can you possibly itemize every single thing that the subsidiary does, demand a report on it, and expect a justification? Obviously not. Therefore accountability is an attenuation of high-variety happenings [and] investment is a variety attenuator.

EXAMINE precisely how accountability is exercised and especially what attenuators (totals, averages, key indicators) are used. If in the end, you are appalled to discover that the machinery is inadequate, that Senior Management just does not have Requisite Variety, then you had better own up.

The discipline of triage is essential to close any gaps discovered between the identified problem and solution spaces and establish situational awareness for aligning the viewpoints of design, production, and support systems. Gaps have different levels of importance for different stakeholders, and these stakeholders have different interests at different points in their system’s lifecycle.

OODA loops have proven to be effective constructs to shape a cyclic set of activities for organizing the pursuit of agility over these cycles, especially in high-pressure environments. Chet Richards positioned this framework as a strategic framework to progressively align actions to changing environments: “Strategy is a mental tapestry of changing intentions for harmonizing and focusing our efforts as a basis for realizing some aim or purpose in an unfolding and often unforeseen world of many bewildering events and many contending interests.”

Each cycle of iteration of these transformations conceptually can be divided into 4 phases:

• Orientation

  Orientation begins by performing a situational assessment which involves the exploration and framing of the perceptions of actors, the states of objects they are focused on, and the significance of events which shape those states, as each object interacts within a broader context. The goal should be to develop a neutral understanding of the collective intentions of stakeholders relative to the environment and conditions which present themselves. It is usually helpful to use a set of organizing questions to help shape the collection of this information in order to establish connections between actions and consequences, by projecting not only what is happening, but how the situation is likely to unfold over time under different scenarios.

• Observation

  Given this orientation, observations are collected by actively acquiring information from available sources. In philosophical terms, it is the process of filtering sensory information through a mental process. In science, observation additionally involves the recording of data via the use of instruments. Nearly all observations will be a mixture of objective and subjective assessments; these observations should include context, learnings, and an innate “feel” for situations, people, and events. It should be recognized that each of these is influenced by a mix of variables, some within the subject’s control, and others outside it. The underlying goal of both activities is to synthesize a mental operational definition that is grounded in facts and whose interpretation (or meaning) is consistent with observations. There is sometimes a question in data processing as to where “observing” ends and “drawing conclusions” begins, though the boundary typically involves recognizing intensions, and evaluating options for aligning behaviors and intentions. Casual analysis can also be helpful, if time permits.

• Decision-making

  Decisions require appropriate framing in order to make balanced trade-offs between target outcomes, time, resources, and risk. A major part of this decision-making involves identification and analysis of a finite set of alternatives that can be evaluated using a limited set of criteria The speed within which decisions must be made is likely to determine the decision process involved; decision methods such as that used by the military are thorough but time-consuming. When the observer is the decision-maker, this task might vary according to whether the decision must be made intuitively or intellectually. If the latter, one must rank these alternatives in terms of how they are perceived to impact target outcomes, both in isolation and as interactions between the criteria when all are considered simultaneously. When decisions instead are to be made by a group, adoption of a more formal decision process should be considered.

• Taking Action

  Actions are necessary to establish momentum and begin achieving progress towards objectives. In military operations, the objectives are sent as an operations order. The sooner one can begin getting started, the faster one can begin learning. Of course, one can’t initiate just any action; it must be purposeful, conscious, and focused on making progress. Tyler Cowen stresses the importance of taking action even in the face of limited data: “The more information that’s out there, the greater the returns from just being willing to sit down and apply yourself. Information isn’t what’s scarce; it’s the willingness to do something with it.”

As Kyle Eschenroeder says, “we need to rebalance our appreciation for the power of action with our tendency to overthink, over-plan, and otherwise waste our energies in abstraction.” The work of Fernando Flores has been instrumental in guiding how to transform an existing chain of transactions into a lean and efficient set of organizational capabilities through learning. The pace of this learning depends on how quickly and effectively provider and customer concerns about the necessity and sufficiency of provided capabilities can be fulfilled:

A process can be improved if it can be understood; it can be understood only if it has a consistent structure [Senge 1990]; and its structure can be consistent only after the first steps of process improvement have reduced process variability... Many processes exhibited such broad variation in behavior that it was difficult for process specifiers to agree on a process that represented the typical scenario. Many organizations informally built process specifications from anecdotal process experience instead of developing the baseline process model with empirical models and data. Many organizations... created an ideal specification instead of capturing empirical practices, and organizations used these specifications as a baseline for improvement despite the mismatch. Because many process specification models were divorced from empirical practice, they could not reliably drive real development practice.

Organizations can track the effectiveness of their decision-making by measuring the momentum at which benefits are being realized from investments, rather than by measuring the velocity of the teams who are doing the work. Preparation for this realization capture requires orientation of both the context of customer concerns and the utility of solutions being deployed by service providers.

In Stafford Beer’s Viable System Model, the multinode is the structural and cognitive configuration of the organization’s “identity function” when decision-making is not the result of a single person but a collective mind. It is Beer’s way of describing how multiple individuals can jointly enact the role of ultimate policy, coherence, and long‑term direction. His comments on this notion illuminate convergence:

We claim we know how the whole thing works. The problem is to make it work more quickly. That must surely mean the introduction of discipline and order, of some sort, into the situation. It also means, however, that no measures may be adopted which would at the same time put the remarkable freedom of action and the wonderful flexibility of the multinode in jeopardy. If people could see how to do this, without putting themselves and their organization into a strait-jacket, there is some chance that they would adopt new techniques. One method, we ought now to agree, must be excluded although it is the one method most usually attempted in practice, because no one can think of anything else. This is the method of rigorous protocol. Explicitly: it denatures the system itself - with all its in-built capacity to generate the right answers.

The first difficulty is to know what kind of problem the multinode actually solves. It does not devote itself, its seniority and power, to the determination of trivial outcomes or it ought not to do so. It is likely to be settling a policy of great importance and therefore considerable complexity. Thus it is that people think of thinking as a process of synthesizing an integral but elaborate conclusion from a large number of component parts. The decision is seen as a rococo edifice built up clause by legal clause. This is perhaps why there are endless drafting problems facing anyone trying to promulgate an agreed decision.

The cybernetician adopts the contrary position. The output of the thinking process, the decision, has the following form: do this (rather than anything else). When the process of thinking originally starts, the multinode is faced not indeed with a number of building bricks in an edifice but with a seemingly infinite number of possible outcomes between which it must choose. It is the existence of this plethora of possibilities that cries out for decision in the first place. Then, under this model, the process we seek to assist is one of chopping down ambiguities and uncertainties until we may say: do this. In short, we would like to measure the variety of the complex decision at the start, measure the reduction of variety brought about by each conclusion reached in the process of thinking things out, and in general monitor the entire operation of the multinode as the variety comes down to a value of the decision itself. To do this we shall need two tools: a paradigm of logical search, and an actual metric - a rule and a scale - for measuring uncertainty.

The speed of this search is the critical discriminator between groups that can deliver sustainable, exemplary performance and those who just get by. Those in the latter class are implicitly condemned to a death by a thousand cuts.

1. what outcomes are expected from this work?

2. why is this work required?

3. who is going to do and use the work?

4. when must this work be completed?

5. how will the work be performed?

6. where will this work be reviewed and reported on?

The ‘what’ question should be answered by writing down the accomplishments and completion criteria which must be satisfied when performing this work. These criteria should enable an evaluation of whether an event has been completed or not, with the determined result producing a binary choice. While activities may be represented in relative terms (like “50% complete), accomplishments are either achieved or they are not. A good plan needs a description of exactly how this doneness will be determined. A good way to do this is to document the tangible evidence that is expected to demonstrate satisfactory completion, such as the examination or evaluation of an artifact, rather than just tracking the passage of time, or the consumption of resources. Events described in this way provide the basis for assessing progress while the work is being performed.

Answers to the ‘why’ question reveal the underlying intentions for performing the work. If the team’s performance ever strays too far from the path of these intentions, a record of the underlying motives is helpful in providing a north star for reorienting the team as they consider whether to adjust their plan or their execution.

Answers to the ‘who’, ‘when’, and ‘where’ questions are typically required to divide up the work into executable chunks by performing units. For major endeavors, this partitioning is often done by defining distinct work packages that can be separately estimated and planned at lower levels. These work packages are natural subdivisions of lower-level activities that can be assigned to specific organizations for allocating responsibilities, lower-level planning, and monitoring progress during execution.

A work package is completed when all accomplishments assigned to that work package have been satisfied. To answer these three questions, the description of these work packages should record the work that is to be performed, the deadlines by which that work must be completed, and the skills and expertise required for performing that work. Once the work package is framed in this way, an estimate of resources required for this execution. and an assessment of the risks that may impede progress along the way should be developed. For example, work packages might be defined for performing a design task, developing tooling, making an initial manufacturing production run, performing a shop order, purchasing an off-the-shelf component, or any other definable collection of activities which can be assigned to another organization or a sub-unit of an internal organization.

The ‘how’ question is answered by describing the activities which will achieve these outcomes. These activities often require elaboration at different levels of detail over time, though it is unusual for all of the required details to be known before execution must begin. Since planning for complicated endeavors are required at many different levels, the associated plans and schedules are established and managed in a hierarchical fashion. When we use the adjective ’master’ with the noun ‘plan’, we are mean the top-level elements of this collection, which are the principal, driving forces, and controlling authority, for lower-level activities. In this context, the top and upper-level elements will likely be established using different methods, and will be negotiated by different parties, than lower-level plans. Detail is added, and accountability is provided, as the schedule, functional, and performance requirements are flowed down, and managed within a well-defined set of organizational interfaces. When we add the adjective ‘integrated’ to our ‘master plan’, we have an ‘integrated master plan’, which describes the details and information relationships across these multiple levels, and assures that they have been verified to be sufficiently consistent and complete for execution to begin, and refinement of planning to occur over progressively longer time horizons.

While planning can occur in people’s heads, and in conversations among team members, none of that has meaning unless it is written down and approved. An integrated master plan must be written down, reviewed, and approved. This suggests using an outline such as that provided below:

• Introduction

  • A short description of the endeavor

  • A definition of the scope for the work

  • An analysis of the progressive flow and maturity of work products. There should be a particular focus on adopting conventions and expectations for maturity definitions such as draft, preliminary, written, submitted, accepted, and approved.

• Assumptions and Ground Rules

• Events, Accomplishments, and Criteria Dictionary

  • Events, which are the logical points at which to assess progress

  • Accomplishments, which are the desired results to be achieved by a specific event

  • Criteria, which is the evidence required to demonstrate that each accomplishment has been complete

• Work packages

  • Organizational responsibilities for producing the work package

  • The primary organization responsible for negotiating additional details about the interactions between this work package and other work packages (often called the work package owner).

  • A narrative describing the work package activities, with a focus on the handoffs into or out of the work package:

    • what inputs are needed and by when

    • which work package those inputs are needed from

    • what outputs will be produced

    • when (relative the start of the work package) key decisions need to be made

  • The definition of done

The intent of this information is to lay the groundwork for producing a schedule which is tethered to a start date, i.e. weeks from launch, months from go-ahead, etc.

To avoid confusion about whether a particular named activity is located in the plan, or will instead be found in its accompanying schedule, an effective convention for naming is often adopted; this convention involves describing activities in an integrated plan using past tense verbs, since these activities describe assessment points that should have been completed when the event itself occurs. For example a key event might be described using accomplishment named ’Systems Requirements Review completed’. In contrast, present tense verbs should be used to describe activities when they are instead in the integrated master schedule (e.g., Develop Software Specification, Perform Requirements Analysis). This change in verb tense reinforces that there is a relationship between planned activities and scheduled activities and makes it easier to integrate activities and events across plans and schedules. Consistent use of such constructs helps to emphasizes these important distinctions and provides a very simple naming convention that signals where to find things.

If the definition or development of any portion of a work package has not yet been sufficiently defined to allow planning to be done, a mechanism should be adopted which captures the associated activities in a ‘parking lot’ construct. The need for this deliberate delay in detailed planning typically arises when the work is sufficiently far in the future that it is dominated by unknowns, being deliberately performed in a series of implementation phases, or if scouting explorations to discover which rainbow to follow in order to accomplish that work have not yet been accomplished. Ideally, a rough estimate of the time and resources required for accomplishing this future work can also be made, though this many not always be possible. One way of addressing uncertainty in this context is by producing an estimate with both an upper and lower bound combined with a confidence level associated with this prediction.

The collection of these ‘future planning packages’ should be time-phased in accordance with known need dates and historical rates of execution for similar endeavors. Refined planning of these future planning packages can then be accomplished once requirements and the environment become clearer, and the timeframe for performing the work draws nearer. The work required to refine the plans for these future planning packages should be incorporated as a part of the baseline integrated master plan itself, to avoid painting the team into a corner.

In small bites, a schedule depicts activities and their dependencies for an endeavor. But when endeavors are complicated and involve many pieces, it is likely that a particular kind of schedule is used - an integrated master schedule which links the information in an accompanying integrated master plan for an endeavor, instantiates that information through the network logic established by lower-level schedules, and optimizes the allocation of available resources and time. Through this means, the integrated schedule establishes dates when key events are expected to occur, and weaves together the work packages necessary to achieve the corresponding accomplishments.

An integrated master schedule is thus a time-based depiction of the information contained within the integrated master plan, with substantiation of this depiction through lower-level schedules which implement that plan, and depict how the work will be performed. The use of the adjectives ‘integrated’ and ‘master’ in this context have the same meaning as they do in the corresponding integrated master plan.

A good schedule requires elaboration of details and concurrent sizing of the work to be done. Each require collection of facts and data about that work, so that appropriate modeling of this work can be performed. The organization which charters the development of such an integrated master schedule must commit to proactively use the resulting information (instead of optimism, opinions, or ill-defined targets); it must also then manage the lower-level schedules, or the resulting top-level schedule will be meaningless. While many think schedules are a joke, that attitude is a self-fulfilling prophecy.

In reality, schedules are just a tool, and should not be confused with the challenges that may actually be encountered while performing the work. The process of developing a schedule can be as important as the schedule which results from that process, since this journey itself often serves as a catalyst for discussions which may not otherwise have happened. In the absence of sufficient attention to planning and scheduling, precious time and resources may be wasted on relatively unimportant activities as the work unfolds, and many options for mitigating risk will be missed until it is too late to exploit them.

Work packages owners (i.e. those primarily responsible for producing the results expected from the work packages) must work together to translate the activities, events, and accomplishments described in the integrated master plan into specific dates by:

• aligning with the equivalent planning & schedule models of the higher and lower level schedules for an effort

• connecting with upstream, concurrent, and downstream performing organizations

• working through the needs of customers, including those of downstream performing organizations

• negotiating interactions with other work packages owners

• taking account of estimates for the demand and the availability of critical resources

An integrated master schedule should be presented as a structured hierarchy which make the key activities, milestones, and interdependencies between the constituent work packages visible. An integrated master schedule models the logic of these interactions (i.e., their predecessors, successors, and associated lag or float time) in order to depict how accomplishments will be achieved with the passage of time, and through the expenditure of resources. This hierarchy should also align with realistic start dates and needed end dates to lower level planning efforts. When seen from this perspective, an integrated master schedule is really a network of commitments. The combination of these commitments for individual work packages, their predecessor and successor relationships, and their triggering conditions, are what enable a critical path analysis to be performed, and resources to be optimized across a portfolio.

The integrated master schedule should be a living document that is regularly updated to reflect the progress of the program or project. The information in the integrated schedule network should be logically consistent, and the collection of resources required should sum to the budget agreed to for the endeavor. This collection should also:

• Maintain consistency with the integrated master plan

• Illustrate the interrelationships among events, accomplishments, criteria, and tasks

• Maintain consistency with the work package definitions

• Indicate the start and completion dates and duration for each event, accomplishment, criterion and task;

• Provide the ability to sort schedules multiple ways (e.g., by event, by work package owner, by type of funding required,?etc.

• Provide for critical path analysis;

• Provide the means to perform ?what if? schedule exercises

• Provide for updates on a regular basis, and record completed actions, schedule slips, and rescheduled actions from the previous schedule for reference

This network should include all the elements necessary for achieving the accomplishments. For example, if the project in question is an engineering development project, it should include requirements elaboration and clarification, design and development, verification and validation, production or modification, and delivery of the total system. The work required for these activities should be described within a context which is meaningful to running the business. This network should provide the basis for critical path analysis, establish a framework for identification and assessment of disconnects, and allow alternative scenarios to be explored. The progressively increasing level of detail in these schedules across the schedule network or hierarchy should include:

• A summary schedule, typically depicted in a single view, which highlights the period of performance, key milestones and/or deliveries, and other significant events

• Intermediate schedules, which represent work package or project activities, milestones and phases at a level of detail which is below, but vertically traceable to, the summary schedule. Intermediate schedules are used within performing organizations to manage their commitments and communicate their progress

• Detailed schedules at the level that the work is being done within the formal network, and are the sources of the data that drives the summary and intermediate schedules. Detailed schedules elaborate authorized work into a logical sequence of time-phased tasks and interrelationships, and provide meaningful indicators of work being accomplished at levels below the formal reporting threshold. For example, such detailed schedules may not track individual change requests, but instead would the activities which must be implmemented to deliver a collection of these work requests over time.

As this elaboration is performed, the resources required to accomplish these work packages can begin to be rolled up and examined in aggregate. It is at this point that the total demand on available resources will become apparent. Generally, adding resources to meet the demand should be a last resort, because most resources are not interchangeable, and growing the team will increase the costs of coordination, communications, and decision-making. A preferred alternative is for the scheduling process to rearrange the order in which these work packages will be executed; however, this process should not try to change the underlying structure or approach to doing the work, unless the associated integrated plans are themselves updated.

Negotiations typically begin in earnest when such resource or time conflicts become apparent. A strategy will need to be developed so that tradeoffs among priorities and alternatives can be performed. Ideally, these tradeoffs should avoid erosion of contingency buffers which are necessary to absorb the inevitable risks that will arise. To the extent possible, this reconciliation should be performed so as to preserve the ability to accomplish events in the higher-level schedules, though often, the results of these discussions may also rippleinto requested changes to the integrated master plan itself.

For complex projects or portfolios of related projects, use of a work breakdown structure (WBS) will be helpful to organize the work packages and activities associated with an entire portfolio of projects associated with some endeavor. This work breakdown structure provides a framework and context for collecting costs, reporting progress, and providing oversight by different levels of management, and across different levels of this schedule hierarchy, with respect to the actual status of the individual elements contained in this structure. The work breakdown structure may also organize this work across major phases, such as pre-acquisition, acquisition, and sustainment, to emphasize the necessary lifecycle implications of an endeavor over some planning horizon.

Events and deadlines are typically represented on a schedule using a milestone notation. All such notational conventions should be established up front, for consistency across the schedule network. These standards should also describe how the planned start and finish dates of activities, and the relationships between these activities, should be depicted, as well as provide a means of communicating and managing schedule baselines. As work is performed, a similar convention should also be adopted to depict progress which has been achieved. This convention should also draw attention to the impact of prior delays on work in progress, as well as work planned in the future.

The basis of estimates for the durations of activities should be traceable to realistic projections of effort for the size and complexity of all products which must be produced. Whenever possible, the analysis behind these projections should be calibrated with data from prior experience. While an integrated master schedule should be an event-driven depiction which has been derived from the projected durations of the underlying activities, there may be specific constraints on when individual events must be accomplished by (i.e. no later than dates). A periodic schedule analysis should be performed to evaluate the realism of any sequence of activities relative to such constraints, as progress unfolds.

The path originally envisioned by the integrated master schedule may turn out to be unrealistic, once execution begins; those who are responsible for managing to changes to the schedule should keep in mind that the map is not the terrain. High-risk, concurrent activities may be attempted, and aggressive estimates may be prescribed to meet emerging conditions. For an integrated master schedule to be effective, it should not override what can realistically be done; instead, schedule risks should be identified, and timely mitigation efforts should be put in place to attempt to shorten time flows which don’t fit into overly ambitious targets. The integrated master schedule should then explicitly include these known risk reduction activities which are expected to mitigate these risks, and include the associated resources required for performing this mitigation.

Scheduling tools and the specialists who use them can steer projects into trouble if these tools are used to spread resources in artificial ways, such as by capping resource consumption at some level or forcing the spread of resources to match available funding. Handoffs between individuals are rarely clean unless there is a robust process in place which communicates the protocols of these exchanges. For example, while gantt charts can be useful representations, the activities which they depict can be misleading unless they are integrated, and their start and end dates match the criteria established in an integrated master plan. The resulting allocation may not actually be practical or realistic, but those reading the schedule will not be able to tell the difference. People can’t multitask from one task to another without reorientation and loss of efficiency. Another pattern often observed is for teams to locally authorize shifts to events for their own convenience, without requiring corresponding reviews and authorization of the direct and indirect impacts on other work packages.

There are many practical scheduling guides available that offer good advice about how to satisfy the above provisions. One of the better ones is the Planning and scheduling excellence guide, which is available from the NDIA. This guide provides eight over-arching tenets for building, maintaining, and using schedules using what is described as ‘Generally Accepted Scheduling Principles (GASP)’.

The tension

Miranda’s musical celebrates Hamilton’s ambition and legacy, framing him as a hero of order and national coherence by favoring centralized, expert-led authority to tackle national problems like infrastructure, regulation, and technocratic governance. This pursuit often occurs in an atmosphere of Jeffersonian skepticism which champions local autonomy and individual liberty and is wary of elite control and centralized power. It’s a romanticized origin story of American governance, emphasizing the creative tension that forged the Constitution and early institutions.

The musical is an entertaining story, but reality is, as usual, more complicated than that. Marc J. Dunkelman’s Why Nothing Works explores why America, once capable of building massive infrastructure and social programs, now struggles to “get things done.” Everyone needs power but would prefer someone else to shoulder the burden of making that happen (Figure 1).

A case study

Dunkelman argues that endeavors often try to embody both of these impulses, which can lead to incompatible goals and conflicts. These conflicts can produce a vetocracy, where too many actors can veto action, stall progress and erode public trust. It creates a dynamic in which no one has the power or motivation to say “yes”, while anyone can delay and block action. The inevitable outcomes of these forces lead to repeated delays that can accumulate and result in cancellations.

This dynamic is highlighted in Chapter 8 of Dunkelman’s book, which uses electrical power distribution as a metaphor for the broader dysfunction in American governance. It illustrates how the tension between centralized control and decentralized autonomy undermines systemic reliability and reform. It also highlights the challenge of big ideas - for example, demanding national action on climate change (a Hamiltonian tendency) while resisting higher-level mandates that impinge on personal rights (the Jeffersonian approach).

In order for alternative energy sources to be developed, the means to transport that power from source to destination is crucial. The U.S. power grid evolved from a patchwork of local systems into a vast, interconnected infrastructure. Initially, power was generated and distributed locally, reflecting Jeffersonian ideals of community autonomy and responsiveness. But as demand grew and industrialization accelerated, the need for centralized coordination became unavoidable. High-voltage transmission networks and regional interconnects were introduced - hallmarks of Hamiltonian planning - and enabled bulk power delivery across states, improving efficiency and reliability, and striving for balance between the benefits of competition and the stability of monopolies that are core characteristics of public utilities.

However, Dunkelman argues that this centralization of planning and control came at a cost, as local actors lost control of their property and resources, and the system became vulnerable to fragmentation and political gridlock. Regulatory agencies like FERC and NERC were created to oversee reliability and standards for these assets, but their authority is often undermined by state-level resistance, utility lobbying, environmental causes, and fragmented jurisdiction. The result is a paradox: while the grid requires Hamiltonian coordination to function, Jeffersonian impulses - manifested in local vetoes, fragmented oversight, and resistance to federal mandates -prevent necessary upgrades, especially in integration and resilience planning for renewables.

This tension is especially evident in ongoing efforts to modernize the grid. For example, building interstate transmission lines for wind and solar power requires federal coordination, but local communities often block projects due to land use concerns or political ideology. Since these sources of clean power require these transmission lines to transport power from producer to consumer, the dynamic erodes action on climate change while resisting the centralized authority needed to implement it. This contradiction mirrors the broader theme of the book: America’s inability to reconcile its founding impulses now paralyzes its capacity to solve big problems.

Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual. Those who cannot remember the past are condemned to repeat it. In the first stage of life the mind is frivolous and easily distracted, it misses progress by failing in consecutiveness and persistence. This is the condition of children and barbarians, in which instinct has learned nothing from experience. - George Santayana, The Life of Reason

Santayana highlights the importance of focus, experience, and learning over instinct. Just as Hamilton and Jefferson clashed over the role of government, modern America struggles to balance expert-led coordination with grassroots autonomy. Until this tension is acknowledged and addressed, Dunkelman warns, the nation will continue to suffer from systemic breakdowns—not just in electricity, but in governance itself.

A scorecard for traditional frameworks

There are plenty of competing frameworks that presume a control orientation, but all have limitations, and none provide explicit guidance for all the forces captured in the PIANOS model. It is worth stepping back and putting our system’s thinking hat on to understand why.

In their article Applying Systems Thinking to Engineering and Design, Monat and Gannon highlight the key principles of system thinking for production:

1. Holistic Perspective/Proper Definition of System Boundaries

2. Awareness that Events and Patterns are caused by Underlying Structures and Forces

3. Systemic Root Cause Analysis

4. Sensitivity to Emergent Properties

5. Sensitivity to Unintended Consequences

6. Dynamic Modeling

7. Focus on Relationships

8. Sensitivity to Feedback

Many endeavors employ these principles in practice, but none of the traditional frameworks explicitly seek to leverage these principles.

The dynamics

Let’s consider how dynamics of traditional frameworks unfold using the causal loop diagram shown in Figure 2. Such diagrams highlight the interactions of factors involved in achieving some result, in this case, the capacity of a production system. These interactions (labeled by the red arcs) have a polarity associated with each relationship, labeled with a plus or minus sign. This polarity indicates the influence one factor has on another - positive means ‘moves in the same direction’ and negative means ‘moves in the opposite direction. For example, the leftmost arc connects the cost of capital to the economy with a minus sign, meaning that in general (without considering other factors), when the cost of capital increases, the net effect will cause the economy to deteriorate. Alternatively, when the cost of capital decreases, the net effect will enhance the economy.

These factors also collectively form loops which accumulate the impacts of this polarity, and feed back to influence subsequent performance, leading to further growth or decline. These loops are labeled in the diagram with a prefix of R as reinforcing (creating growth) or B for balancing (leading to decline).

When building a simulation of these dynamics, the extent of each factor’s influence can be calibrated to match what is common knowledge, as long as the natural variation that accompanies each factor is taken account of.

The figure highlights the effects of resource contention - resources can be anything with enduring value, such as a home, a person’s health, and even their education. The ‘centralization of control’ factor in the lower left-hand corner is examined in more detail here. The running narrative for these interactions - applicable to any production system (whether governmental or industrial) - follows:

Loop R1: The Capability Investment Flywheel

At the heart of the diagram is a reinforcing feedback loop: production capacity increases → enabling more investments → which fund capability enhancements and learning opportunities → boosting labor productivity → which further expands production capacity. This loop reflects a virtuous cycle of growth, where reinvestment in human and technical capital drives compounding returns. It’s a Hamiltonian vision of centralized scaling through expertise and infrastructure.

However, when the economy takes a downturn - whether from a national crisis or demographic decline - this loop runs in reverse with limited options for recovery, all relying on the ability to attract buyers willing to finance additional investments with higher risk and lower returns.

Loop B2: Human Capital Foundations

This loop highlights how willing and able workers depend on upstream factors like:

• Effectiveness of education

• Effectiveness of public health

• Immigration (as a labor supply enhancer)

These elements feed into labor productivity and ultimately production capacity. But they’re also shaped by regulations, tax burden, and centralization of control, which can either enable or constrain public investment. This loop shows how social systems and governance deeply affect economic output, underscoring the Jeffersonian tension between local autonomy and centralized policy.

Loop B3: Resource Competition Dynamics

Here we see a more complex, potentially destabilizing loop:

• Rising production capacity boosts the economy, which increases resource demands → driving up prices.

• Higher prices may stimulate resource supply, but also increase debt and inflation, which can negatively impact cost of capital and reduce investment.

This loop introduces negative feedback which can increase systemic fragility. It shows how economic growth can trigger affordability crises and financial instability, especially if regulatory and monetary systems fail to adapt.

Loop B4: Resource Supply and Regulatory Friction

Demand on production increases pressure on the supply of resources, which can be constrained by regulations and tax burden.

• If these constraints are too tight, they reduce investment and slow the capability loop.

• If too loose, they risk environmental degradation or inequality.

This loop captures the dilemma this poses for governance: balancing growth with sustainability and equity. It’s where Hamiltonian efficiency meets Jeffersonian caution.

Loop B5: Popping economic bubbles

Once irrational exuberance begins fueling a speculative bubble, the threat of future price increases begins to spur investor enthusiasm, causing a contraction in the economy. There will be winners and losers around this transition.

The dynamic tensions in systems

The diagram doesn’t offer a single solution—it models a dynamic equilibrium shaped by competing feedback loops.

• Positive loops drive growth and innovation.

• Negative loops introduce checks, risks, and social costs.

• Governance levers (regulation, centralization, taxation) mediate these forces but are themselves contested and subject to dynamics.

The lower right factor Consensus on policies deserves elaboration. Consensus - the collective agreement or unified opinion reached by a group - doesn’t require unanimity, but it implies broad support or alignment. That only happens when leadership can orchestrate stakeholder negotiations and interests until a broadly acceptable solution emerges that everyone can live with. That relies upon a common understanding, acceptance, and support of the required tradeoffs which are necessary to realize the goal being pursued - all infused with patience for the dynamics to produce those results.

Achieving balance

In the Incremental Commitment Spiral Model, Barry Boehm emphasizes what he describes as The Fundamental System Success Theorem, which states: “A system will be successful if and only if it makes winners of its success-critical stakeholders.”:

One implication of the Fundamental System Success Theorem is that it is risky to use terms such as “optimize,” “minimize,” and “maximize” in project guidance. As Nobel Prize winner Herbert Simon showed in his book Models of Man, success in multiple-stakeholder situations is achieved not by optimizing, minimizing, or maximizing of individual criteria, but rather by satisficing with respect to the stakeholders’ multiple criteria.

To be accountable for a commitment, it is important to neither promise nor expect more than can be delivered. In a world of rapidly changing mission priorities, new technologies, competitive challenges, and organizational relationships, total commitment to the full details of a product to be delivered five years later is a very risky bet.

The term “satisficing” here means not everybody gets everything they want, but everybody gets an outcome that they can be satisfied with. Lacking such consensus, convergence on solutions may be fleeting, disappointing, and potentially overridden as power shifts with improved situational awareness, emerging political alliances, and new externalities drive dynamics. Adaptation is key to weathering this storm.

In the next post of this series, the scaffolding underneath these tensions is explored to lay the groundwork for understanding the common failure modes in endeavors. With these insights, you will be ready to practice how to avoid them.

When you are a Precisely Right person and are presenting a topic to an audience primarily composed of Roughly Right people, it is easy to spend most of your time covering a lot of details, since that is the way to naturally communicate ideas. Unfortunately, you are likely to lose the Roughly Right people in your audience as you go over these details or trigger an impatient demand from them to get to the point.

Yet the opposite situation is also true; when Roughly Right people are communicating with Precisely Right types, breakdowns can occur unless the Precisely Right people are provided with the details they crave, since otherwise they may not feel that they adequately understand high-level ideas or notional concepts. As these details emerge, the Roughly Right may then struggle in obtaining commitments from the Precisely Right, if these details require different pivots than expected.

To do great things, to really learn, you can’t shout suggestions from the rooftop then move on while someone else does the work. You have to get your hands dirty. You have to care about every step, lovingly craft every detail. You have to be there when it falls apart so you can put it back together. You have to actually do the job. You have to love the job. - Tony Fadell, Build

As John Sterman indicates in his book, Business Dynamics, the uncertainties and instability that results from ambiguous information sources must be reconciled for decision-making on projects to be effective:

Much of the information we receive is ambiguous. Ambiguity arises because changes in the state of the system resulting from our own decisions are confounded with simultaneous changes in a host of other variables. The number of variables that might affect the system vastly overwhelms the data available to rule out alternative theories and competing interpretations. This identification problem plagues both qualitative and quantitative approaches. In the qualitative realm, ambiguity arises form the ability of language to support multiple meanings… Rich, ambiguous texts, with multiple layers of meaning, often make for beautiful and profound art, along with employment for literary critics, but also make it hard to know the minds of others, rule out competing hypotheses, and evaluate the impact of our past actions so we can decide how to act in the future.

Successful projects must thus provide a reliable means of engaging with both Roughly Right and Precisely Right people. Leaders must achieve a collective buy-in from both types of people to resolve this ambiguity. Ideally, requirements provide an adequate foundation for shaping and evolving high-level concepts and incorporating necessary design details coherently and comprehensively. Translating and refining such information requires persistence, discipline, time, energy, resources, and sufficient attention for elaboration. Otherwise, the path to solutions may be dominated by change and rework as the project unfolds over time, resulting in projects which never seem to finish, and fail to meet expectations.

During the elaboration of these needed details, gaps of knowledge and interpretation will inevitably be discovered. Our ability to effectively engage subject matter experts to discover these details for each circumstance will be crucial to making sure these gaps are closed. This can challenge any team to achieve consistently. Until these details are revealed, the work necessary may not yet be actionable. One of the underlying causes for this lack of clarity is that it is easy for each of these types to assume that everyone shares the same cognitive framework, and that deriving an understanding and meaning from this framework should be straightforward and predictable. Too often, the work necessary to establish such a framework is often overlooked. As Fred Brooks describes it in The Design of Design:

As… complexity grows, the need for explicit use models increases. Even for a shovel, it is important to be explicit as to whether it is for coal, dirt, grain, snow, or some mix; whether for child, woman, or man; whether for the casual user or the manual laborer. How much greater is the need for explicit use models for a truck, a spreadsheet, an academic building! Moreover, the more complex the design, the less likely the designers are to be domain experts who could do the users’ jobs. Implicitly assumed models are then much more dangerous.

All designers in fact have user and use models consciously or subconsciously... as they work. Team design creates the all-new requirement that the entire team have the same user model, the same use model. This requires explicit models and assumptions. This exercise is rare because the members of the team usually believe, without anyone saying so, that they share a common set of assumptions. After all, each one heard the enterprise leader charge and challenge the team. Each one has read the goal-defining document. All are expert.

Matters are not so simple. Each of us has in fact had a different experience using similar systems; my experience informs my picture of the typical user. Each of us has been exposed to a different set of applications; my exposure helps me define this application. If the team does not draft a common set of explicit assumptions, each designer will work with a distinct set of implicit ones. Micro-decisions too minor ever to be discussed will be made differently, and conceptual integrity will be lost. 

Roughly Right people tend to be first movers and starters. From their frame of reference, they often lose interest in projects before the required details are defined. In contrast, Precisely Right people are often finishers, the unspoken heroes who must save projects that were built with good intentions but flawed assumptions. You can't expect Roughly Right people to be able to provide all the details that are needed by Precisely Right people. But until the individuals responsible that need this information have access to these details, you also can't expect teams of those people to have sufficient control over the factors critical to success. They will then fall back on satisfying what they had understood needs from one stakeholder's viewpoints, which may or may not satisfy things from the perspective of other stakeholders.

The way forward requires Roughly Right people to acknowledge there are such gaps, even though they rarely are the ones who will have the persistence or discipline to close them. Precisely Right people must learn to effectively communicate what kinds of gaps exist for a body of work to be actionable. Trust is built once everyone can agree that finding the way through such clouds of ambiguity is more like hacking through a jungle than like following a GPS-calibrated moving map to a destination. Environments are jungle-like when they require sifting through extensive information from many problem domains and elaborating work so that other individuals can take constructive courses of action, assure this work is being accomplished effectively, and validate that this work has sufficient value to be worthwhile.

Leaders (often roughly right people) must commit to projects before all these details are fully defined. Those responsible for deciphering and implementing their intentions (ideally, precisely right people) must assure that such commitments have access to sufficient contingent resources so these project commitments can be clearly defined and achieved, despite the uncertainties of direction from above. As a result, both types need each other, but must learn to work together effectively, given their shared destiny.

Next article in series

Like most qualities, the characteristics we seek in the pursuit of value are usually specific to the eyes and circumstances of each beholder. As Thomas Sowell describes it:

How well one thing substitutes for another cannot be determined by how similar they are in physical characteristics, or indeed, by any purely objective criteria. Economists define substitutability in terms of people's subjective preferences as revealed by their overt behavior. If a rise in the price of coffee causes people to buy more tea, then economically speaking, we can say that they are substitutes without having to investigate the chemical or physical characteristics of either...

Simple as all this is, it goes completely counter to rhetoric that is often heard, and sometimes heeded, about the urgent need to "establish priorities" either nationally or in a business or other organization. At the instant that such rhetoric is uttered, there may indeed be an urgent need for more of one thing at the expense of something else, but it is only a matter of time before the changing proportions of the two things change the relative urgency of adding more of each. Categorical priorities ignore this fact, unless they are very flexible and reversible-in which case they are not really "priorities." But because sober analysis seldom has the appeal of ringing rhetoric, priorities often do get established, and outlive the necessities that gave rise to them.

Value being ultimately subjective, it varies not only from person to person but from time to time with the same person, and varies also according to how much of the given good he already has. Obviously a man in the desert dying of thirst would sacrifice much more for a glass of water than he would in his home, with water available from his faucet. In short, even for the same individual, the value of water can vary from virtually everything he has down to zero-or even below zero, since he would pay to have water taken away if his basement were flooded...

While an individual or an economy may appear at first to be weighing the subjective value of a good against its objective cost, ultimately what is being weighed is the subjective value of one good against the subjective value of another good. Faced with identical technology and resources setting the limits of what is possible at a given time, different combinations of goods may be produced, according to the subjective preferences of the decision makers, whether those decision makers are consumers, central planners, or royalty...

Different stakeholders will evaluate the utility provided by a proposed solution from their own context, because of varying levels of accessibility to information, experience, or viewpoint from which their observations are made. Their valuation thus depends upon their assumptions, domain expertise, lifecycle insights, and basis of understanding of the environment in which the business operates.

Since these stakeholder perspectives will be constrained and biased, it can be quite difficult to synthesize all their perspectives into a clear direction which will guide decision-making and enable tradeoffs. Biases, delays, or hedges in selection of this sweet spot can waste precious resources on unsustainable paths, fatal dead ends, or paradoxes of choice.

The size of the intersection of all these factors may be quite small, presenting the creation of new things with a challenging target to attempt to hit. It is important to search for the target wisely. In their book Understanding Cognition, Terry Winograd and Fernando Flores suggests the search for value needs to be considered from many different dimensions:

We can illustrate the kind of questioning we have in mind by seriously asking "What is a word processor”. The first thing to recognize is that different answers grow from the concerns of different individuals. For the manager of a factory that builds word processors, they are assemblies of electronic and mechanical devices, to be constructed, tested, and shipped. For the person who programs the word processor, it is a particular collection of software, dealing with the input, storage, and output of bytes of information. It operates through some kind of interface to a user who generates and modifies that information.

These are both perfectly valid answers, arising in particular domains to which the theories of computation and electronics are relevant. If we want to understand a breakdown of the hardware or software, we operate in their terms and turn to them for predictions. But these answers do not deal with what a word processor does - with the fact that it is a medium for the creation and modification of linguistic structures that play a role in human communication. For the purchaser of a word processor, this is the relevant domain. The word processor exists as a collection of hardware or programs only when it breaks down. In its use, one is concerned with the actions of creating and modifying documents and producing physical presentations of them on a screen or printed page. The relevant domain is not a computational one, but one that emerged long ago with the first writing instruments. It brings with it concerns of visual presentation issues of layout, type fonts, and integration of text with illustrations. Many current computer products are designed with a primary concern for this domain. They deal at length with formats and typography, focussing on the document as the thing being produced.

But still with this, we have not reached a full understanding of the word processor. We cannot take the activity of writing as an independent phenomenon. Writing is an instrument - a tool we use in our interactions with other people. The computer, like any other medium, must be understood in the context of communication and the larger network of equipment and practices in which it is situated. A person who sits down at a word processor is not just creating a document, but is writing a letter or a book. There is a complex social network in which these activities make sense. It includes institutions (such as post offices and publishing companies), equipment (including word processors and computers, but also all older technologies with which they exist), practices (such as buying books and reading the daily mail), and conventions (such as the legal status of written documents).

The significance of a new invention lies in how it fits into and changes this network. Many innovations are minor they simply improve some aspect of the network without altering its structure. The automatic transmission made automobiles easier to use, but did not change their role. Other inventions, such as the computer, are radical innovations that can not be understood in terms of the previously existing network. The printing press, the automobile, and television are all examples of radical innovations that opened up whole new domains of possibilities for the network of human interactions. Just as the automobile had impacts on our society far beyond speeding up what had been done with horses, the use of computers will lead to changes far beyond those of fancy typewriter. The nature of publishing, the structure of communication within organizations, and the social organization of knowledge will all be altered, as they were with the emergence of other technologies for language, such as the printing press.

One might think that the questioning can stop at this point. It is clear (and has been widely recognized) that one cannot understand a technology without having a functional understanding of how it is used. Furthermore, that understanding must incorporate a holistic view of the network of technologies and activities into which it fits, rather than treating the technological devices in isolation. But this is still not enough. We can say that the word processor must be understood by virtue of the role it plays in communication, the distribution of information, and the accumulation knowledge. But in doing we take for granted the use of words like 'communications’, 'information’, and ‘knowledge’, which themselves require further examination. In this examination, we find ourselves being drawn into inquiries about basic human phenomena that have been called things like ‘intelligence’, 'language," and "rationality’.

As the use of a new technology changes human practices, our ways of speaking about that technology changes our language and understanding.

This enhanced understanding leads creators to embark on a voyage of discovery with confidence, fueled by cycles of concurrent experimentation, evaluation, learning, and positioning themselves to benefit from the favor of luck. In his book Adapt: Why Success Always Starts with Failure, author Tim Harford compares this search for value to a journey across unfamiliar solution landscape:

One way to think about the quest for solutions is to imagine a vast, flat landscape, divided into a grid of billions of squares. On each square is a document: a recipe describing a particular strategy. Evolutionary theorists call this a ‘fitness landscape’. If the fitness landscape is biological, each strategy is a different genetic recipe: some squares describe fish; some describe birds; some describe human beings; while the majority describe a genetic mush that represents nothing that could ever survive in reality. But the fitness landscape might equally represent recipes for dinner: some produce curries; others produce salads; many produce dishes that are nauseating or even poisonous. Or the fitness landscape might contain business strategies: different ways to run an airline or a fast-food chain.

For any problem, it’s possible to imagine a huge range of potential solutions, each one carefully written down and scattered on this vast landscape. Imagine, too, that each recipe is very similar to its neighbours: two adjacent dinner recipes might be identical save for one demanding a little more salt and the other a slightly longer cooking time. Two neighbouring business strategies might advocate doing everything the same, except that one prescribes slightly higher prices and a bit more marketing.

Now let’s change the picture and say that on our fitness landscape: the better the solution, the higher the altitude of the square that contains it. Now the fitness landscape is a jumble of cliffs and chasms, plateaus and jagged summits. Valleys represent bad solutions; mountain tops are good. Problem-solving on a contoured fitness landscape means trying to find the high peaks. In dinner-party space, that’s not so hard. But in a biological ecosystem, or an economy, the peaks keep moving – sometimes slowly, sometimes quickly... As one peak subsides, others may not be clearly visible. The biological process of evolution through natural selection is entirely blind; finding a corporate strategy may or may not be a more deliberate and far-sighted process

Yet, as Jordan Peterson says in his book, We Who Wrestle with God:

It is of course the most ancient idea that the treasure eternally sought by the hero is guarded by a terrible dragon. Sometimes, perhaps, the treasure is obvious, and the dragon lurking. The reverse should be equally true: when a dragon appears, there is treasure to be found somewhere, if enough care is taken to look, and enough faith manifested to make the search possible. This is a very good thing to understand in times of trouble.

While even the most treacherous terrain can often be eventually scaled with enough resources and time, those pursuing such ends will be at significant risk. The constraints which must be overcome may not yet be apparent, inviting daredevils, downplaying obstacles, and encouraging shortcuts. In new product development endeavors, as in attempts to climb difficult terrain, the conditions for success can be fleeting. Overcoming one constraint often just allows us to see an even more difficult one ahead. Returning to Harford:

Evolution explores this landscape with a serendipitous mixture of wild leaps and small steps. The wild leaps usually end up at the bottom of some chasm, but sometimes they land in the foothills of some totally new range of mountains. The small steps lead uphill rather than down, but perhaps only to the top of a molehill.

As developers conduct this search, the teams they are on must learn to orient themselves so they can efficiently consume inputs, apply technology, and produce outputs which will satisfy a customer's or market's needs. These needs may be spread across many customers or organizations. Their decisions may be embedded within many different business models or may only be accessible after a unique set of tailoring is performed that erodes the affordability of shared functions. Strategies like Marissa Mayer's development process offer several catalysts that may shorten this journey, but only if those on the journey believe in and are willing to incorporate such approaches.

In Balancing Agility and Discipline, Richard Turner and Barry Boehm describe an easy pitfall that solution providers can fall into within this environment:

Many software projects fail by succumbing to the "Field of Dreams" syndrome. This refers to the American movie in which a Midwestern farmer has a dream that if he builds a baseball field on his farm, the legendary plays of the past will appear and play on it ("If you build it, they will come")... [There is a] software analogy of the "Field of Dreams" syndrome: "Build the software and the benefits will come."

This syndrome is why Turner and Boehm caution against premature investment and instead argue for the importance of adopting an economic framework for decision-making. Such a framework should consider the impacts which would be realized across development, deployment, operations, and support. These considerations must take account of the assumptions and constraints which may affect the realization of goals and the uncertainty inherent in all such journeys.

Robert Rubin suggests exploring this inherent uncertainty with 3 challenges:

• What if we are wrong in our estimation of the situation today - how will the world look to us in the future compared to now?

• What if our assessment of today's situation is correct, but the situation changes - how might the world look from that future perspective?

• Under each of these scenarios, what should we have done today to prepare for dealing with that future situation?

As we try to absorb all this advice, we are challenged to try to understand which system and subsystem features will offer the greatest value under a range of alternative futures and critical business scenarios. These scenarios may realize this value across many targeted improvements, such as enhanced responsiveness, reliability, flexibility, or exploiting advantages offered by one solution over alternatives under consideration. Future solutions are likely to be a mix of different combinations of these advantages. As solution providers, we must discover which combination is the best fit for a set of anticipated scenarios, and do this sooner, rather than later. 

As a solution's chosen design stabilizes, its definition and understanding by the development team should be stitched together to form the project's value proposition that can be realized within the 'sweet spot' depicted in the figure above. As a result, the fidelity and clarity of the performance envelope within this sweet spot provides an important leading indicator of an endeavor's potential for success.

Just which jobs we consider complicated and which ones we consider elementary, even crude, is a judgment too often made not on the true nature of the work but on the things that attend it — the pay, the title, whether it’s performed in a factory or an office suite, in blue jeans or a gray suit. And while those are often reasonable yardsticks - a constitutional scholar may indeed move in a world of greater complexity than a factory worker - just as often, they’re misdirections, flawed cues that lead us to draw flawed conclusions about occupations we don’t truly understand. We continually ignore the true work people and companies do and are misled, again and again, by the rewards of that work and the nature of the place it is done.

It may not be much of a surprise that bosses and economic theorists don’t fully appreciate the complexity in many jobs. Both groups, after all, are interested mostly in performance, never mind how it’s achieved. More surprising is the fact that coworkers are often just as poorly informed about what the person one desk over or two spots down on the assembly line actually does all day. When they do give the matter any thought at all, they almost always conclude that the other person’s job is far less complicated than it is.

The longer it takes for this complexity to become apparent, the less useful this feedback will be in implementing changes that will have lasting effects on performance. People are motivated to change their behaviors when their own interests are connected to business needs. Causes must be connected to effects so they can make sense of information and how it relates to a particular context and framing of their work.

In The Principles of Product Development Flow, Don Reinertsen describes importance feedback plays in enabling teams to establish control over their environment:

Rapid feedback causes us to subconsciously associate our delivery of a work product and the beginning of the next process step. This attribution of causality gives us a sense of control, instead of making us feel we are the victim of a massive bureaucratic system.

In the book Improving Performance, Brache and Rummler describe the factors which affect the ability to perform work. Collectively, these factors determine the extent to which planned work can be successfully executed and determine the extent to which the means of performing such work can be improved over time. These factors include:

1. Job Preconditions

   1. Are the inputs accessible and suitable for processing?

   2. Can the task be performed without interference?

   3. Are the procedures and workflow logical?

   4. Is help available if required?

2. Performance specifications

   1. Do job standards exist?

   2. Are they attainable?

   3. Are they accepted by the people who must perform the work?

3. Ability to execute

   1. Are the roles that individuals are assigned to perform consistent with their experience and preparation?

   2. Are the responsibilities for that role understood and accepted?

   3. Do the performers have sufficient capacity available to implement these roles within the time allocated?

4. Feedback

   1. Will feedback information be relevant, accurate, specific, understandable, and timely?

   2. Will the feedback be provided in a way that is useful to the performer and so that adjustments can be incorporated within the required period of performance?

5. Motivation

   1. Have incentives and consequences been established to support desired performance?

   2. Are the criteria for reporting progress and estimates of remaining work well designed, agreed to, and appropriate to the situation?

Jobs are 'actionable' if and only if they satisfy all the above attributes. When some portion of a work package does not satisfy these attributes, the time it will take to perform that work will be more variable, since work products that will be produced will be more likely to have less utility than desired, and risks associated with achieving target outcomes will be increased.

Teams select the most actionable work from a work package to perform first, even though this work may not be the most important work from the perspective of the customer; while it may enhance the team's ability to demonstrate progress in the short term, this approach may not give the best long-term result. Simply put, the degree to which work is actionable determines the pace at which work can be acted on, and the extent to which rework can be avoided.

Now the Lord God had formed out of the ground all the wild animals and all the birds in the sky. He brought them to the man to see what he would name them; and whatever the man called each living creature, that was its name. So the man gave names to all the livestock, the birds in the sky and all the wild animals. - Genesis 2:19–20

This passage is often interpreted as humanity’s first act of classification and stewardship, a symbolic gesture of understanding, responsibility, and creativity. It also highlights the relational dynamic between humans and the rest of creation: naming implies attentiveness and authority within a broader context. These ideas will be a recurring theme in my posts.

Classical thinking on names

Classical philosophers - especially Plato and Aristotle - had rich and contrasting views on the nature and function of names. Their debates laid the groundwork for centuries of thought on language, meaning, and reality.

In Plato’s Dialogs, he explores whether names are arbitrary labels agreed upon by social custom or instead are somehow intrinsically connected to the essence of what they name. Through his character Socrates, he leans toward the idea that a “correct” name reflects the true nature of a thing, arguing that names can be crafted to mirror the essence of their referents. But he also acknowledges the limits of this view, admitting that names are imperfect shadows of Forms (the true realities beyond language).

Aristotle takes a more pragmatic and systematic approach. For him, names are spoken sounds that have significance by convention, not by nature, signifying concepts or essences. For him, names are ways to classify and describe the fundamental units of reality. He invites us to seek deeper truths behind words and gives us tools to reason clearly with them.

Together, they frame a tension between essence and convention that animates philosophy, linguistics, and AI. Over time, such ideas crystallized into ontology, the philosophical study of being.

Figure 1 presents key names and relationships of entities that I will be using in this blog, so that ideas I present herein can be evaluated from a firm philosophical foundation.

Ontologies organize elements (data, facts, entities, objects, and concepts) into a relational hierarchy, connecting how we observe, describe, interpret, and act upon the world. They facilitate precision in classification, which is especially useful in modeling real-world systems, AI reasoning, and philosophical analysis.

Figure 1 highlights the flow from perception (data) to understanding (concepts) to interactions (through relationships and agents). Naming a thing involves assigning it attributes, mapping it to categories, positioning it relative to other elements, and asserting authority, all central to the search for ground truth and meaning. A few examples will help amplify these ideas.

A modern case study

Clayton Christianson is widely recognized as one of our most influential thinkers on innovation theory and practice. While he is most famous for his classic book The Innovator’s Dilemma, his more recent book, Competing against Luck, is my favorite. It’s his answer to the dilemma he identified in his earlier work, which describes why most companies miss innovation opportunities: successful companies with established products focus on extending the features of those products rather than cannibalizing that business for more visionary frontiers. In this passage, he defines jobs in customer rather than product terms:

…customers don’t buy products or services; they pull them into their lives to make progress. We call this progress the “job” they are trying to get done, and in our metaphor we say that customers “hire” products or services to solve these jobs…

We define a “job” as the progress that a person is trying to make in a particular circumstance. This definition of a job is not simply a new way of categorizing customers or their problems. It’s key to understanding why they make the choices they make. The choice of the word “progress” is deliberate. It represents movement toward a goal or aspiration. A job is always a process to make progress, it’s rarely a discrete event. A job is not necessarily just a “problem” that arises, though one form the progress can take is the resolution of a specific problem and the struggle it entails…

Second, the idea of a “circumstance” is intrinsic to the definition of a job. A job can only be defined—and a successful solution created - relative to the specific context in which it arises.

Christensen’s redefinition of a “job” reflects how ontologies define functions, roles, and intentionality. From Christensen’s viewpoint, jobs aren’t static identifiers but instead are dynamic roles situated in circumstances. This aligns with the ontological modeling of events, agents, and goals shown in Figure 1. Defining a customer or agent’s role (their “job”) influences how their needs and strategies are framed, a prime example of how terminological precision influences system behavior.

Endeavor as an umbrella term

The word endeavor is an abstract concept that is often used as a broad umbrella term in the context of projects, programs, and processes, It serves as a kind of superclass that captures any purposeful, goal-oriented effort. It’s especially common in project management, where the PMBOK Guide defines a project as “a temporary endeavor undertaken to create a unique product, service, or result”. Figure 2 depicts this structure.

An endeavor in this context is thus a structured, intentional effort to achieve a specific outcome, often involving planning, coordination, and resource allocation. It’s a flexible term that can encompass:

• Projects – temporary, unique efforts with defined scope and timeline

• Programs – coordinated groups of related projects managed together

• Organizations - a group organized for a purpose that performs coordinated activity under shared rules and roles

• Processes – ongoing, repeatable sequences of activities that produce consistent results

• Capabilities - the methods, tools, and competencies (“How-to”) that enable resources to be used effectively in accomplishing a specified course of action

Why use the term endeavor at all? Because it’s neutral and inclusive. It doesn’t assume:

• Whether the effort is short-term (like a project) or ongoing (like a process)

• Whether it’s standalone or part of a larger system

• Whether it’s formalized or informal

That makes it useful when I want to talk about all kinds of purposeful work without getting bogged down in such details. It also enhances the reach of propositions associated with endeavors.

Why is this blog named SwiftSure.Pro?

When I began working at Boeing, my group had several sailing enthusiasts. Long-distance sailing challenges participants to demonstrate their preparation, navigation, and sailing skills, while competing against other boats, weather, and equipment problems. One of their favorites was the Swiftsure International Yacht Race, which since 1968 has been run regularly from Victoria, BC around Swiftsure Bank (at the entrance to the Juan de Fuca Strait) and is the pinnacle of ocean racing in the Pacific Northwest. It is also a warmup for the much longer 2300nm Vic-Maui race.

The name SwiftSure runs deep in oceangoing currents, from gunships to submarines and even lightships. Starting in 1909, Lightship #93 was a US Coastguard lightship that was stationed at the Swiftsure Bank - where the Swiftsure Cup Races turn.

The domain name swiftsure.pro itself is a blend word that combines appealing, powerful, and complementary concepts for system development and operation. The “.Pro” top-level domain is derived from professional, indicating its intended use by certified professionals. But its Latin root productio means “to bring forth” or “to lead forward.” Pro is thus a directional force, and its suffix determines what’s being led forward - a product, a person, a promise. Production thus aligns with operational emergence by bringing capabilities into form, whereas professional aligns with strategic representation by declaring mastery within a domain.

Speed is a desirable attribute in this pursuit since such strategic advantages can overwhelm competitors and increase opportunities for progress. The Agile methodology tries to blend this speed with adaptability, attempting more than just being “quick,” but “quick to change, pivot, rebound.” It suggests nimbleness under uncertainty: an agile dancer weaving through the crowd, or an agile team adapting to new requirements. There’s a flexibility baked into the term.

Yet speed in the wrong direction is wasteful, and demonstrations of progress can suffer when instability rears its head. Instead, the concept of swiftness speaks of the combination of speed and smoothness, delivering rapid action with precision and grace. It feels decisive and final: a swift stroke, a swift reply. It evokes confidence that whatever happens, it happens fast and cleanly. You’d call a falcon’s dive “swift,” or praise a customer service team for “swift resolution” of a ticket. The emphasis is on rapid execution.

The second of our blend words, “Sure”, brings a different dimension. As an adverb, it describes something or someone as guaranteed, certain, or self-possessed. It can signal an external guarantee (“delivery is assured”) or an internal composure (“an assured manner”). As a noun, it also means confidence, an internal sense of trust or belief in one’s abilities, in someone else, or in the reliability of a thing.

My goal in naming this site as indicated is to help bring these ideas into being for others - to provide information to build confidence in bringing forth results rapidly and smoothly. A novel structure to aid that pursuit is here.

How are taxonomies useful?

Clear definitions can help improve understanding, but only if they are used consistently. Here are several examples of the confusion that can arise when definitions are not consistently applied, taken from Barry Boehm’s book, Balancing Agility and Discipline:

Probably the easiest source of perplexity to identify, and perhaps the most difficult to resolve, is that of multiple definitions for the same word. For example, the term disciplined, whose dictionary definition includes both “common compliance with established processes” and “self-control,” is confined to process compliance by CMM bureaucrats, and confined to self-control by agile free spirits. Similarly, agility has been selectively interpreted positively as “dexterity” and negatively as “inconstancy of purpose.” A further example is quality. In the SW-CMM, “quality assurance” is defined as “specification and process compliance.” Agile methods see quality as essentially customer satisfaction.

Pursuing such consistency is the hallmark of taxonomies, which promote a consistent alignment of definitions for classifications, categorizations, and naming of the entities they represent.

Taxonomies are crucial in domains like project management, knowledge architecture, and systems design. At its core, a taxonomy is an organized classification system that arranges concepts, entities, or components into hierarchical relationships based on shared characteristics. It’s like a mental scaffolding that helps us navigate complexity by breaking it into digestible categories.

In systems thinking, taxonomies allow us to:

• Surface interdependencies, by seeing where elements sit in a larger structure

• Diagnose problems at the right level (don’t treat a process problem as a project failure)

• Design feedback loops by recognizing roles and relationships between layers

It’s also how we can avoid confusing symptoms for causes and make smarter interventions.

With that in mind, a taxonomy for this site is here, in which I will capture definitions such as in Figure 1 - and for ideas developed throughout my posts - which will be updated periodically.

Throughout my professional career, I have encountered the term “system”, usually with a functional descriptor preceding it. In college, it was database systems, operating systems, etc. When I began working for Boeing, a new set of functional descriptors associated with the top-level airplane system itself were revealed, including avionics systems, flight controls systems, propulsion systems, electrical systems, and many others. I also learned about Conway’s Law, which was coined by the computer programmer Melvin Conway in 1967, which states:

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

This idea has profound implications. In systems development, it explains why modular teams produce modular components. In product design, it suggests that organizational silos can lead to fragmented user experiences. In systems thinking, it highlights how internal dynamics shape external outputs.

A definition

But what is a system? There are many definitions, so here is mine: A system is a set of parts that interact, expose properties, and exhibit behaviors. This concept is recursive, operating at higher and lower levels (see Figure 1). For example, as humans, we operate on a platform of metabolic systems, that themmselves are made up of many cellular subsystems. We also operate within the context of an environmental system which itself exists within a planetary and solar system, and so forth.

When studying the relationships between the periphery of any system and the rest of the system - whether a human cell, a complex device, or a social system - one realizes that there is no “center”. The context depends upon an observer’s frame of reference in which it operates (Figure 2).

There are many of such viewpoints for any system of interest, among them:

• A strategic viewpoint, with the system as context, and the rules, constraints, and goals for how the system of interest, subsystems, and agents should work together

• A design viewpoint, describing the system as it will be constructed (see Figure 3 below)

• An operational viewpoint, with the system as mechanism, processing inputs and producing outputs. This view depicts how decisions, constraints, and interactions during operations shape outcomes.

• A reflective viewpoint, with the system as a construct indicating how observers perceive the system, through mental models, inevitable biases, and assumptions.

Each of these viewpoints is influenced by feedback, which tracks what the system produces and compares it with what was intended. This feedback may also activate latent capabilities, prompt new configurations, and energize correction, adaptation, and innovation power requirements.

Applying a systems approach to system development

Erhard Reichlin, author of the Art of System Architecting, describes the application of a systems approach as:

... one that focuses on the system as a whole, linking value judgments (what is desired) and design decisions (what is feasible). A true systems approach means that the design process includes the problem as well as the solution. If a system is to succeed, it must satisfy a useful purpose at an affordable cost for an acceptable period of time.

Now consider the meaning of each of the italicized words in Reichlin's description. Such abstractions are sometimes utilized by evangelists advocating investments with roughly-right people, sometimes things are deliberately opaque for political purposes or to provide maneuvering room. Yet until such abstractions are sufficiently elaborated into clear, specific, and actionable requirements, any efforts to pursue these goals are likely to be less focused and can fall short of meeting the needs of all (or even the most important) stakeholders.

These forces operate within a system architecture with many interdependencies which must be unpacked, as represented in Figure 4.

Unleashing the dynamics

Changes to a system of interest typically unfold in an iterative fashion under multiple forces exerted through the fields of the PIANOS model, summarized in Figure 5. Value can be created when changes to such systems through orchestrated production will address the needs of its stakeholders better than existing alternatives.

The call to action

When we treat systems as static, we miss the living, breathing interplay of innovation, adaptation, synthesis, and power. To wrestle with a system is to wrestle with ourselves. But to do so mindfully, by tracing the threads from intent to outcome and back again, is to craft better questions, clearer compasses, and braver choices.

If any of this resonates, the next step isn’t to add complexity. It’s to pause, reframe, and ask: what parts of your systems of interest are you affecting, how effective is that engagement, and what can be done to accelerate swift, confident, and sustainable production?

Throughput is the average rate of delivery of acceptable products through a production system. Architectures are often driven by throughput considerations, and the constraints which must be confronted drive the design of the system’s components. This throughput (and the reliability of assessments made of it) can be impacted by many factors, including the regularity of its inputs, the size and nature of queues which arise in processing throughout the system, the usable bandwidth and availability of channels for inputs, processing, and outputs, production losses due to coordination or quality issues, and impacts due to congestion.

Transforming bottlenecks

How can better prioritization, systemic insight, and a shift in mindset transform bottlenecks into breakthroughs and enhance throughput? Through workflows - repeatable pattern of activities that systematically organizes actors to transform information, materials, and energy into products. The Rational Unified Process illustrates this well as an example by breaking down work into sequential phases, each requiring time and effort to create intermediate work products necessary for shaping shippable features. It, and workflows like it, provide mechanisms which can enhance discipline in front-end activities - such as analysis, design, and construction - with expected payoffs in reducing rework in later phases. This makes sense as the isolation, management, and resolution of issues is easier while the issue can be isolated quickly within established contexts, rather than in later phases, when only symptoms are known and context is uncertain (see Figure 1).

But in practice, inputs often arrive according to business cycles, not customer demand. When the volume of incoming work outpaces the processing capacity of each work cell, bottlenecks form. Delays snowball, requiring more resources and rework downstream. These growing queues aren’t just nuisances; they signal a systemic imbalance between demand and throughput. What are these signals, and what can be done about it?

The Cost of Congestion

As queues expand, performance deteriorates. Teams divert resources reactively, which masks underlying inefficiencies rather than resolving them. Like rush-hour traffic, even a small dip in capacity can cascade into major slowdowns. The temptation to push incomplete work forward creates defects that emerge later, when they’re far more expensive to fix.

Why Prioritization Matters

Prioritizing before work enters the system may face resistance, but once customers experience shorter cycles and more predictable delivery, the value becomes clear. Smart prioritization isn’t about picking favorites - it’s about stabilizing flow so high-value work moves smoothly from start to finish.

Designing for Context

Unique products call for different development models. As Michael Cusumano notes, high-end custom systems require deep user engagement and expert tools, while mid-range offerings benefit from standardized processes that balance cost and customization. Mass-market products, by contrast, thrive on maximizing value for the average user.

Shining light on the invisible sources of variation

Manufacturing benefits from visual cues - inventory piles up where flow breaks down. Engineering lacks that visibility. Without tangible artifacts, inefficiencies go undetected, leading to unreliable throughput estimates. And traditional project plans often assume idealized, linear progress that’s rarely achieved.

Variation arises from two sources: assignable causes (clear execution failures) and random noise (systemic complexity). The former calls for better quality control; the latter demands systemic change.

Shaping Smarter Teams

Multi-skilled teams can adapt on the fly to balance queues and maintain cadence. Visual indicators - distinguishing customer-driven work from internal refactoring - support better decision-making. Over time, as teams learn their true pace and capabilities, they can make credible commitments to stakeholders.

But that only works if work enters the system in a ready state, with strict limits on in-progress inventory. Planning must begin with ideal assumptions - perfect timing, full capacity, zero defects - that are then adjusted for reality, making risks visible and prioritized accordingly.

Optimizing throughput

A depiction of the elements involved in enhancing system throughput is shown in the Figure 2.

In Systems Thinking: Managing Chaos and Complexity, Jamshid Gharajedaghi describes the key requirements for improving the throughput of a system:

... even a simple throughput consists of a chain of events and activities need to be integrated. Since these activities are usually carried out by different groups in different departments of an organization, strong interfaces and effective coupling among them are a must... To design a throughput system, we need to:

• Know the state of the art, as well as the availability and feasibility of alternative technologies and their relevance to the emerging competitive game.

• Understand the flow, the interfaces between active elements, and how the coupling function works

• Appreciate the dynamics of the system - the time cycle, buffers, delays, queues, bottlenecks, and feedback loops

• Handle the interdependencies among critical variables, plus deal with open and closed loops, structural imperatives, and system constraints.

• Have an operational knowledge of throughput accounting, target costing, and variable budgeting.

Given the constraints of technical risks and cultural adoption, and the inevitable uncertainties of implementation, I’d add four things to Gharajedaghi’s requirements:

• Perform a reliable assessment of the dynamic interactions of existing system components to identify known bottlenecks

• Determine what changes will provide the greatest performance returns for those roadblocks, considering investments in process capabilities, organizational maturity, and associated changes to subsystem components.

• Define the target reference architecture that will be employed to incorporate these changes over time

• Establish a roadmap for those changes

• Allocate the target performance objectives to components within this roadmap to realize optimal sustainable performance improvements over time

• Determine how much of this change can be successfully accomplished within the next iteration

• Manage the change process for these components

• In parallel, lean out the system, with particular focus on the system’s administrative functions, so that desired efficiencies are achieved over time.

While a theoretical peak throughput may be achievable for short bursts in a system, projections of change to sustainable throughput should be conservative, as such changes will only have impact as higher-rate throughput accumulates over time. Realizing such improvements will thus be a function of the sizing and resources available for servicing internal queues between and within components, and the ability of the system to adapt and reconfigure in response to changing demands.

Wrestling with needs

Defining the needs of a diverse stakeholder landscape feels less like a strategy session and more like wrestling pigs: exhausting, messy, and vaguely entertaining to those on the sidelines. Every stakeholder brings unique goals, constraints, and expectations, woven into a knot of competing demands. Untangling this tangle requires more than listening - it requires synthesis.

Crossing the Chasm - and then?

Geoffrey Moore’s “chasm” (figure 2) remains a harsh terrain between early adopters and the mainstream. Where early adopters chase novelty and technical credibility, the mainstream seeks stability and proven value. Bridging this divide demands more than marketing finesse—it requires frameworks like Ivar Jacobson’s Essence to map the hidden gaps in value perception. The irony: your solution must be credible to gain users but only gains credibility through use.

Agreement is not understanding

It’s tempting to think that group consensus means shared understanding. But the pressure of collaboration often creates premature convergence - where teams subtly collapse problem and solution spaces into one fuzzy middle. The result? An illusion of alignment that quietly erodes design integrity.

To truly define the problem, one-on-one conversations often reveal buried needs. In group dynamics, though, the process accelerates toward comfort rather than clarity. We declare victory too early. We move forward before we're ready.

The challenge of harmonizing the pursuits of local relationships with the broader interests of the collective - so that progress can emerge in the complex, adaptive behavior (see figure 4) - requires harvesting the feedback available from explorations, relevant evaluations, and experiences drawn from prior transformations. Exploration, evaluation, and iteration are not luxuries in these environments—they’re essential. The “answer” doesn’t live in a static blueprint. It emerges through disciplined cycles of feedback and reframing.

Patterns in the noise as opportunities for learning

John Sterman, in his book Business Dynamics: Systems Thinking and Modeling for a Complex World, further illuminates how these dynamics unfold:

Much of the information we receive is ambiguous. Ambiguity arises because changes in the state of the system resulting from our own decisions are confounded with simultaneous changes in a host of other variables. The number of variables that might affect the system vastly overwhelms the data available to rule out alternative theories and competing interpretations.

This identification problem plagues both qualitative and quantitative approaches. In the qualitative realm, ambiguity arises form the ability of language to support multiple meanings… Rich, ambiguous texts, with multiple layers of meaning, often make for beautiful and profound art, along with employment for literary critics, but also make it hard to know the minds of others, rule out competing hypotheses, and evaluate the impact of our past actions so we can decide how to act in the future.

Sterman goes on to describe other challenges in balancing between the needs of the few (but potentially powerful) and the many:

To influence the actors in our transactional environment we have to understand why they do what they do. Understanding is different from both information and knowledge. Information deals with the "what?" question, knowledge with the "how?" question, and understanding with the "why?" question... The why question is the matter of purpose, that of choice. And the choice is the product of the interactions among the three dimensions: rational, emotional, and cultural. Rational choice is the domain of self-interest, or the interest of the decision-maker, not the observer. A rational choice is not necessarily a wise choice. It reflects only the perceived interest of the decision-maker at the time. Meanwhile, wisdom has ethical implications and considers the consequences of an action in the context of a collectivite.

Progress in adaptive systems looks less like marching in formation and more like dancing with feedback. Sterman’s system dynamics remind us: decisions shape results which reshape understanding. Ambiguity isn’t an obstacle—it’s where learning happens.

The Wicked Webs We Weave

Horst Rittel first described the challenges of such chaotic environments on large projects in a paper on Dilemmas in a general theory of planning back in 1973. He made these observations about such situations:

• There is no definitive statement of the problem - it's an ill-structured, evolving set of interlocking issues and constraints (a tangled mess of problems)

• No one person understands the problem sufficiently

• Since the problem lacks definition, so does the solution. The implications are that the problem-solving process ends when resources - such as time, money, or energy - are exhausted, rather than when an intended solution emerges.

• Each fragment of a solution concept exposes new aspects of the problem, requiring further adjustments to other aspects of the solution.

• Without a full set of requirements to establish context, tradeoffs across solution contexts are not possible; one cannot first understand, then solve.

• Solutions are neither right nor wrong. They might be better or worse, but what's good enough for one party may not be good enough for another

• Analysis is considered procrastination by those in power, and one opinion is believed as good as another

Rittel named the combination of these factors in situations 'wicked problems' because they involve the interaction of many dynamic forces which amplify the effect that each factor would produce on their own:

• Solution abstractions, the fuzzy, shape-changing lingua franca by which participants attempt to communicate and justify tangible aspects of an unfolding environment over time

• Fragmentation, which emerges from the above tensions and forces, works against achieving solution cohesion, and erodes the primary motivation for achieving architectural integrity

• Social complexity, which arises from the diversity of stakeholders, who all expect to buy into each recommendation, and who want to avoid having to change themselves

As Rittel and Webber warned, wicked problems don’t have tidy definitions or fixed endpoints. Each attempted solution refracts the problem in new ways. There are no final victories—only more refined approximations.

And in the absence of certainty, power dynamics fill the gap. Data becomes secondary to opinion. Decisions feel like tradeoffs between competing partial truths.

Designing the Compass

So how do we lead through this? By building decision-making structures that aren’t stability-bound but instead enable strategic shifts. These pathways must translate messy feedback into structured decision-making, providing a consistent “North Star” even as the landscape keeps shifting. Such tools don’t eliminate chaos, but they help navigate it with intentions guiding the necessary refinement of ambiguity and thereby making it actionable.

Restructuring decision-making

A disciplined, opportunity-driven approach is essential to confronting such situations. Projects must learn to consistently evaluate solution concepts and connect them to the underlying values and needs of the business overall. Endeavors must then properly allocate precious resources across projects to maximize returns. Until they develop this competency, values and goals will remain mere abstractions, rather than foundations for strategic clarity. Clarity is earned—not given. Strategy isn’t just about choosing a path—it’s about choosing the right conversations to have. And that begins by asking better questions.

A well-designed decision-making framework is necessary to provide stability for decision agents in their actions and considerations. If your team keeps circling the same confusion, if your strategy feels more like camouflage than clarity—it may be time to upgrade the frame, not just the tactics.

Confronting ignorance

It is necessary to confront, rather than ignore, uncertainty. The unfortunate alternative, as George Bernard Shaw warns, relies on false hope:

Ignorance is a most wonderful thing. It facilitates magic. It allows the masses to be led. It provides answers when there are none. It allows happiness in the presence of danger. All this while, the pursuit of knowledge can only destroy the illusion. Is it any wonder mankind chooses ignorance?

Magic may feel comforting. But in the end, only understanding makes progress real.

Let’s move beyond the illusion of certainty—and into the opportunities available by choosing more wisely.

Such situations can tempt leaders to overlook chronic issues until a fire alarm finally forces their attention on some emerging crisis. They should instead ensure they understand and address risks, dependencies, planning gaps, and blocking issues, and provide assurance that their endeavors are utilizing their resources efficiently and effectively.

Since few endeavors have cash to burn, the aggregate resources available must be allocated within whatever resource bargains the business can afford. Within this context, they must make prudent investments across their full portfolio. Inevitably, the evolving constraints imposed internally and externally can lead to resource shortages on some efforts and surpluses on others, despite the best efforts of sponsors and teams.

The resources needed by endeavors can be squandered over many pathways - ineffective planning, poor oversight, and careless execution. These issues not only drain resources but also undermine efforts to prevent such waste. To conserve valuable resources, it's crucial to standardize priorities and status reporting across multiple endeavors, fostering trust and promoting positive practices throughout the initiative.

Instead, endeavors should be implemented through a series of phases that provide incremental delivery of functionality and quality over time. In such cases, these phases should begin with an unambiguous definition of the minimum viable product for the effort and follow with phases that draw from a balanced set of trade-offs between features, available resource allocations, and product quality over the available time horizon that is dictated by business needs.

Sponsors expect leaders to actively collaborate and steadily lessen the uncertainties tied to costs, improve the delivery of necessary outcomes, and ensure these outcomes meet the changing needs of stakeholders. If not effectively managed, these uncertainties can compromise an endeavor's success and indirectly affect others within the portfolio. To meet these expectations, these leaders must embrace a common framework for communicating and evaluating opportunities and risks.

Review gates can be a key element of such frameworks by providing mechanisms to assure that the decisions and actions associated with such collaboration are understood, accepted, and will be supported by those responsible or affected by such decisions. The primary purpose of these review gates should be to determine whether to authorize continued investments on each endeavor as previously planned or instead adjust priorities or resources with respect to others competing for these resources. This is particularly important at the fuzzy front end of new efforts when any business's investments rely upon the often-tenuous credibility of narratives and often-limited evidence available for decision-making.

Since many decision makers are often involved in these choices, reaching a consensus may require a lot of compromises, and inertia is the unfortunately common by-product of disagreements across these parties in how to move forward. The key for decision-makers is to get things right over time and be patient with results while holding leaders accountable for their commitments.

Gate reviews should be scheduled to support the incremental commitments of resources through each subsequent decision gate. In this way, funding for the endeavor's total lifecycle should depend upon the accomplishments achieved, and an extrapolation of this record of accomplishment going forward.  Each gate review should also confirm that quality criteria for that gate have been achieved. These reviews should also verify that prior accomplishments meet expectations, are available, and are consistent with defined decision criteria. Finally, the status of outstanding risks and issues must be reviewed to assure that risks are being adequately mitigated, and to assure that these issues will continue to be mitigated and resolved as the endeavor continues.

In Balancing Opportunities and Risks in Component-based Software Development, Barry Boehm and Jesal Bhuta describe the critical use of 'pass/fail feasibility evidence descriptions' which determine whether continued investments in the endeavor are warranted:

Evidence provided by the developer and validated by independent experts that if the system is built to the specified architecture, it will:

• satisfy the requirements: capability, interfaces, level of service, and evolution

• support the operational concept

• be buildable within the plan's budget and schedules

• generate a viable return on investment

• generate satisfactory outcomes for all the success-critical stakeholders

Shortfalls in evidence are sources of risk, and all major risks should be resolved or covered by risk management plans. Risk items and risk mitigation strategies are a basis for stakeholder's commitments to proceed.

Such evidence is a critical part of conducting effective gate reviews (see Figure 1).

These reviews should be conducted by a cross-functional mix of participants who examine this evidence to determine whether to:

1. authorize the next phase of the effort

2. cancel the endeavor

3. place further investments on hold until some well-defined condition is satisfied, or

4. provide clarifying directions to the endeavor. This frequently means clarifying leadership's intentions and addressing their concerns; in these situations, it typically will be expected that the current gate review which raised these concerns will need to be repeated within a brief period to assure that this feedback has been appropriately incorporated.

Through this focus, gates provide accountability on progress towards delivering on commitments while assuring that the associated risks and issues are being reduced over time. This focus is essential for stakeholders to trust that desired products will be delivered within cost, schedule, delivery, and quality targets. Review results should include a summary of the status of actions identified at prior reviews, a report of the progress being made in mitigating risk over time, and a description of changes from previously established baselines that could affect stakeholders.

An overview of processing

The detailed definitions of these gates will always be technology, business, and product dependent. The over-arching philosophy is that they should provide synchronization mechanisms that assure that all the necessary planning and coordination has been accomplished across all performing organizations. Too often, organizations instead chose to employ a 'dog and pony' shows whose primary intention is to assure management that they are making progress, rather than providing firm go/no go decisions for proceeding to the next gate

Figure 2 below is a conceptual depiction of how such a flow might be organized. The structure is consistent with the PIANOS model, though that alternate representation provides a full elaboration of feedback pathway and off-ramps.

On many endeavors, an iterative development process is used which produces an incremental delivery of functionality and performance. Early cycles typically focus on demonstrating feasibility, validating the accessibility of value, reducing risk, and maturing the concepts of operation. For major efforts, the iterative development cycles may receive special attention at more detailed review gates, ensuring that prior phases produced plans and requirements of sufficient fidelity so that subsequent development can proceed unimpeded. Additionally, the development cycles often involve teams working in parallel, as depicted in Figure 2.

Methods

To perform such reviews in a consistent fashion, the overall review approach should define:

• When gate reviews are expected to be performed

• Who has responsibility for organizing and implementing these gate reviews

• How the agenda, approach, and participants will be communicated

• Where results will be tracked over time

• What evaluation criteria must be satisfied to obtain authorization to proceed to the next gate

All performing organizations participating in these activities should align their separate development and planning efforts to these over-arching review milestones. Once solutions have been deployed and are being utilized in operations, products typically enter a sustainment phase. During this phase, an alternative means of oversight must be established, since the work is driven by operational, rather than development, events.

The continued commitments depicted by the green box in Figure 2 need to be negotiated and documented as service level agreements, ideally in ways that tie the funding stream for continuing work back to the organizations that are subscribing to ongoing service. Despite this shift to operations, the ongoing visibility of required resources and their associated asset utilization must continue to be monitored throughout the operational service life product or service. This transparency enhances accountability for the total cost of ownership and provides assurance that its associated resource allocations are provided and aligned with the business's overall objectives. If it is burdensome to demonstrate that these goals are being achieved, something needs adjustment - the methods, the goals, or the people!

Gates

27.9KB ∙ PDF file

Download

Download

As organizations grow, complexity increases, making it difficult to balance short- and long-term priorities. The pressures of immediate survival often sharpen focus, but expanding teams, diversifying locations, and evolving work processes introduce challenges in coordination. Leadership often provides broad directives, but these simplified abstractions may not align with the specific tasks employees must execute. This ambiguity - along with shifting environments and incomplete handoffs from upstream teams - can cause confusion, misinterpretation, and inefficiencies. Without a well-integrated collection of processes spanning multiple dimensions, employees may struggle to apply the guidance they are expected to follow effectively, making work more complicated rather than streamlined.

Startups are understandably motivated by the necessities and uncertainties of survival through the endeavor’s next fiscal quarter. This pressure provides a focus for the workforce that improves attention on the most immediate priorities. But as an organization increases its size and diversifies its locations and work groups, and as the artifacts its members produce increase in complexity, teams find it much more difficult to strike a balance between short- and long-term perspectives, especially as evolutionary changes accumulate over extended periods of time. This is when efforts to document processes first emerge for young businesses.

Process guru John Stearman highlights the limitations of this approach when an established organization attempts to create a new product or service:

It was argued that in the same way a complicated tractor is built by parts, each performing only a simple task of horizontal, vertical, and circular motions, an organization could be created in such a manner that each person performed only a simple task. The mechanistic mode of organization was born as a logical extension of this conception and became instrumental in converting the army of unskilled agricultural laborers to semiskilled industrial workers. The impact of this simple notion of an organization was so great that in one generation it created a capacity to produce goods and services that surpassed the previous cumulative capacity of mankind. The essence of this mechanistic viewpoint of an organization is simple and elegant: an organization is a mindless system- it has no purpose of its own.

A socio-cultural view considers the organization a voluntary association of purposeful members who themselves manifest a choice of both ends and means. The critical variable here is purpose. In contrast to machines, in which integrating of the parts into a cohesive whole is a one-time proposition, for social organizations the problem of integration is a constant struggle and a continuous process.

The elements of mechanical systems are energy-bonded, but those of socio-cultural systems are information-bonded. The members of a socio-cultural organization are held together by one or more common objectives and collectively acceptable ways of pursuing them. The members share values that are embedded in their culture. The performance of each variable can be improved independently until the slack among them is used up. Then the perceived set of independent variables changes to a formidable set of interdependent variables. Improvement in one variable would come only at the expense of the others.

Adapting to new entrants or emerging technologies can also be such a challenge for any business. The need to allocate across these competing demands becomes progressively more challenging, as the number of dimensions that must be coordinated and organized to accomplish work increases. Organizations of any size are naturally chaotic, and the guidance provided by leadership is unfortunately often delivered in the form of simplified abstractions. These directions may not be relevant or helpful with respect to performing the work by the members of the responsible units and individuals in the organization. Because of this ambiguity, changing environments, and incomplete processing pushed out prematurely from upstream organizations, jobs become increasingly difficult to implement, and assignments may even be interpreted in contradictory ways. As a result, unless a coherent collection of processes is introduced that are well integrated across the many dimensions in which work must be performed, the direction which employees are instructed to follow may not be applicable to their situation.

Rummler and Brache call managing and deciphering this ambiguity "the white space" in an organization:

The greatest opportunities for performance improvement often lie in the functional interfaces - those points at which the baton... is being passed from one department to another... All too often, it's the organization chart, not the business, that's being managed... A primary contribution of a manager (at the second level or above) is to manage interfaces. The [functional] boxes already have managers; the senior manager adds value by managing the white space between the boxes.

Agents control, shape, and connecting processes within this white space, so it makes sense that they will also be the primary failure mode for these exchanges. This means that unless communications channels between communicating roles are explicitly designed, those responsible for acting on these exchanges are likely to adopt ad-hoc behaviors that are convenient for the circumstances and parties involved, rather than for achieving broader business objectives.

Even well-designed processes suffer when connected through these unpredictable and noisy communications channels. Just as in computer networks, the performance of these human-based communications channels is most likely to degrade significantly when under intense load. This arises when it is least convenient, such as when the business expands, undergoes adaptive change, or must respond to a crisis.

The connective tissue which joins the organization's separate units (people and information) operate as other information networks do, with implications to latency, congestion, failures, and mangled messages that networks must deal with in their design. An organization's leadership must serve as the master switch for this information system. A lesson from the book Master Switch, about the impacts of human operators in the early telephone network, is relevant here:

When human operators were needed to physically connect one phone line to another, a larger network meant a slower switching system, prone to bottlenecks and breakdowns.

In the ideal case - when the agents that are filling these gaps are competent, available, and motivated - the types of interactions may still not be appropriate to the situation and overload their capacity, which often complicates situations even more. As Tom DeMarco describes, some slack time is essential to investing for long-term improvement, and finding such slack may not be easy:

When companies and divisions and departments get themselves totally stuck, when they can't learn their way out of a paper bag, they often look to change the lines and boxes on the org chart. They'd be better off to concentrate on the space between those lines and boxes. Since healthy organizations use this white space as their learning center, you can bet that the nonlearners have got trouble exactly in the white space. Instead of being vital and collaborative, their white space is isolating and dangerous to explore.

Appropriate protocols are thus necessary for exchanging data and control information, managing synchronous and asynchronous operations, multiplexing unidirectional and bidirectional communications, and escalation when initiating or responding to high priority events. More interventionist techniques may also be required (packetization, compression, conversion, etc.) to improve overall throughput. Turning again to Rummler and Brache, they observe:

All organization structures have white space. The mission is not to eliminate white space. The mission is to minimize the extent to which white space impedes processes and to manage the white space that must exist.

While a well-designed structure can significantly facilitate improved organizational behaviors, when given enough time, tuning, and useful feedback, prioritization and load shedding of target business outcomes may be necessary, if the underlying expected communications breakdowns are to be systematically addressed. Any organizational structure that cannot eventually converge on these target outcomes, and adjust their own behaviors as these outcomes evolve, is not likely to achieve the competitiveness necessary for survival.

Whitespace

490KB ∙ PDF file

Download

Download

To avoid oversubscribing to obsolete ideas, endeavors must evaluate the relative merit of alternative future approaches, investments, and product lines; integrate this information across many time horizons, environments, and operational scenarios; and mobilize the necessary resources to successfully place these changes into broad usage. To do this effectively, multiple factors must be considered:

• the benefits and risks achievable from investing in new or modified capabilities

• the period in which these enhanced capabilities could be made available

• the availability of situations to which such capabilities could be applied to

• the uncertainty implicit in pursuing these courses of action

• the level to which primary and affected parties understand, are willing to accept, and will personally support the changes required

• to whom the benefits are expected to accrue, and how the accounting of costs and benefits associated with transitions will be reconciled over time

A study of these factors and their interactions can illuminate consideration of all opportunities and their impact on strategic objectives. Without an adequate understanding of these dynamics, the strategic plans of a business can get lost in the daily grind of reviewing opportunities, reporting status, managing risks, and enforcing operational discipline. 

The focus on longer-term benefits may be sharpened by adopting an organizing framework such as that provided by program management, though such frameworks cannot achieve effective change by incentives, decree, or force of personality alone. In The Guide to Lean Enablers for Managing Engineering Programs, a Joint Community of Practice on Lean Program Management between MIT, PMI, and INCOSE, programs are defined as follows:

A program is a group of related projects, subprograms, and program activities managed in a coordinated way to obtain benefits not available from managing them individually... Programs deliver benefits to organizations by generating business value, enhancing current capabilities, or developing new capabilities for the organization, customers, or stakeholders. A benefit is an outcome of actions, behaviors, products, systems, or services that provide utility to the sponsoring organization as well as to the program’s intended beneficiaries or audience.​

Effective engineering depends upon focused exploration and probing of candidate solution elements, typically in time-boxed endeavors, while navigating within an unfamiliar territory. Progress may be accomplished by executing iterative, overlapping phases of Definition and Realization, as depicted in figure 1. Either explicitly or indirectly, the activities in each of these groupings set the context for those in the other grouping in an iterative and recursive fashion.

In a paper on Benefits Management for such endeavors, John Sopko highlights the differences in pursuing benefits for a program and outcomes for a project:

When one discusses the difference between projects and programs, the answer can be found simply by examining the expected results by which the success of each is measured. Projects are deemed successful if they produce the desired deliverables at the desired time and on budget. Programs have expectations beyond project deliverables and focus on how these deliverables are applied to realize benefits. In the end, a program’s success is measured against the effectiveness of which they deliver benefits. Programs are the mechanisms through which benefits are defined, planned and realized by organizations... a benefit is an outcome of actions or behaviors that provide utility, value, or a positive change to the intended recipient.

Figure 1 maps the high-level activities of program phases onto the V-model of systems engineering as rendered by the Project Management Institute. The ways and means necessary to accomplish these definition and realization activities must be incrementally matured, so they both can be performed consistently and concurrently. Unfortunately, the yield from available investments is often sufficiently far in the future that its results are uncertain, potentially disappointing investors, labor, and management alike. One of the primary reasons for such disappointments is that optimists tend to overestimate gains and underestimate loses, while pessimists suffer from the opposite bias. A dilemma thus can arise despite attempts to negotiate a middle course, since the promise of long-term benefits may need to be sacrificed at the altar of necessary short-term gains.

Like projects, programs require an early focus on eliciting stakeholder needs and synthesizing a shared vision worthy of both types of investments. Meanwhile, everyone goes forward with the hope that things will improve with time, and the belief that they share a consistent interpretation of this context. Aids like blueprints are essential for moving forward. Yet such ‘definitions’, as they are, typically abstract and unproven, are often based upon mental models with different underlying assumptions. This will only be reconciled through appropriate investments in mutual understanding, negotiation, and alignment, all of which require time.

In the absence of such investments, conceptual ambiguity can be exploited as cover for entrenched but favored positions adopted by those in power, delaying the ability to focus on what is in everyone's better interests and their potential future gains. Evangelists often dangle the appealing idea that investments will pay their own way and much more, despite the need to somehow hurdle the uncertainties.

Once a shared vision is sufficiently captured, clarified, and embraced, blueprints of adequate fidelity can be defined and used to explore which interventions will shift the needle of measurable progress in an acceptable direction. The resulting focus will produce increased confidence that further investments will deliver increased value even in a landscape of shifting technological and mission evolution, a goal that any healthy business entity must demonstrate periodically.

To demonstrate that necessary outcomes can indeed be accomplished within acceptable levels of confidence, endeavors must learn to:

• survey the environments from sufficient viewpoints for the systems of interest and the purposes being pursued

• analyze the gaps between existing capabilities and those required to achieve the benefits across these contexts

• translate these gaps into the statements of work necessary to realize these complementary capabilities, despite the uncertainties creeping in over multiple business planning cycles, and with inherent affordability constraints.

As their means of production matures, teams can begin to learn how to shape - and even model - the definition of these capabilities, and their realization - by crafting configuration definitions and specifications which can be elaborated into deliverables. All of this must of course be achievable within realistic constraints of time, talent, and resources.

We can visualize these dynamics and related constraints by considering how this uncertainty influences the progressive delivery of value by a system. Figure 2 depicts the end-to-end flow from ‘lust to dust’, i.e. from ideas to the time-value accumulation of benefits realized, influenced by a representative set of factors (shown as circles) and boxes (depicted as stocks) over time. The flow begins in the upper right, with the discovery of worthwhile ideas. It reflects the structure of a dynamic simulation of this flow which is described in more detail in this post.

Such a model allows the capacity, throughput, and returns from this flow to be evaluated across different operating scenarios, which can be evaluated by adjusting the probability density functions which allow characterization of the range and frequency of each individual transformation in the overall flow.

What to do in the face of such uncertainty? Programs, out of necessity, must learn to improve their constituent project outcomes and sniff out dry wells sooner, rather than later. This capability requires a closed-loop control system that can quickly weed out unnecessary variation in bottom-line results while amplifying worthwhile investments in high leverage opportunities. The goals of investments in major new capabilities should be to achieve architecture clarity and feasibility early, while maximizing the potential for achieving target outcomes expected in pursuit of practice, discipline, and learning.

The raw material for this evolution is ideas. These ideas may be cheap to propose, and quite expensive to evaluate, justify, and pursue; clearly, an effective selection process is necessary to organize the corresponding decisions. The patience and temperament of those in charge of these filters may introduce further bias and instability into the pursuit of important target outcomes and can result in resource allocations being suboptimal. These evaluations rely upon a coarse-grained analysis of the relative merit of each idea, with credible projections of necessary resources to create and sustain them over their lifecycle.

Each chosen opportunity requires careful consideration of the minimum viable features worthy of investment, along with a sequencing of the order in which these features should be built. Once the most promising of these ideas have been selected, the work to implement them must be adequately planned and competently executed. Yet benefits from this work will only be realized when they can be made available within the operational opportunities for application of these capabilities and used in ways that achieve the sought-after benefits.

Since limits to growth inevitably constrain the opportunities that can be pursued at any one time, candidate solutions must be carefully evaluated; none may be achievable without fresh thinking, strategic scoping, and deliberate pivots to cultural norms. Each gambler making such bets observes their hands and their competition's plays through their own lenses of knowledge, experience, and exposure to risk. Each play requires eyes wide open watching for circumstances to trigger the need to call or fold.

Projects are bundles of bets on such ideas. In turn, portfolios are bundles of these projects and may be less susceptible to streaks of luck when the aggregation elements are complementary and align with the stars. Investments in each bet require courage given the incomplete knowledge and uncertain future they must confront, and discipline to reduce the collective dependence on this luck.

Building on first principles and notable prior accomplishments is thus a more effective strategy than wishful thinking; the latter is the behavior of a gambler, not a trustworthy custodian of talent and treasure.

A capability is defined as that which provides an ability to achieve a desired effect under specified standards and conditions. Such effects must be observable through changes to the resources that are produced and consumed while performing a defined set of activities. These activities collectively adopt courses of action which provide the structure for performers to pursue individual goals and - in concert with others - contribute to making the world a better place.

Different architectural frameworks have different interpretations of the concept of a capability. For example, the TOGAF framework uses the word to delineate business capabilities for architectures without prescribing how such capabilities might be achieved. The framework uses the concept of 'capability increments' as building blocks that are essential to capability planning, but remains silent about the means of developing, enhancing, and delivering the necessary capabilities, expecting other governance instruments to provide such methods. As a result, when either underlying governance is limited, ambiguous, or inconsistently applied, it can prove difficult to diagnose and resolve problems of performance which may be hidden by the abstract idea of a capability itself.

In contrast, the DODAF framework adopts a more specific meaning for the concept of a capability - that depicted in figure 1. This representation is notable in its modeling of resources as abstractions of information, material, and performers. Not to get too philosophical here, but effective considerations of architectures that promise enabling, enhancing, or extending underlying capabilities must be grounded in an understanding of the various systems of interest's variety, pragmatics, and mereology, as well as the praxis of its production. Such an analysis is far more complicated than Figure 1 implies.

A capability is indeed enacted by performers as they perform activities which consume materiel, resources, and time and produce transformations. The agents implementing these activities, at least in this telling, are called performers in DoD lingo, and agents in most settings today, and can consist of a complicated mix of systems, services, organizations, and individuals assigned to roles. Projects are expected to employ the agents that demonstrate fitness for these assignments, though often they have little freedom to delay waiting to discover and attract their contributions.

Within the DODAF framework, these activities achieve progress by facilitating transformations from one state to another. These agents are expected to follow guidance sufficient to enable them to competently perform these activities and produce acceptable outcomes under specified conditions. Guidance typically introduces constraints which attempt to limit anomalous behaviors. This guidance is provided in many forms, such as rules, standards, and agreements. An important example of such constraints deserves special attention since activities are performed at physical locations, requiring use of resources that are available at those locations.

The essence of capabilities

Capabilities become actionable competencies that an endeavor must possess to operate effectively. They are:

• Concrete enablers of performance

• Stable over time, even as processes or org charts shift

• Composable, forming higher‑order capabilities through integration

• Evaluable, meaning you can assess maturity, sufficiency, or gaps

• Interdependent, but in a more operational than metaphysical sense

In short: Capabilities describe what an endeavor must be able to do reliably.

Information and competency are essential ingredients for performing these activities in each unique context. Unfortunately, performers are often expected to achieve target outcomes under conditions that are less than ideal. For example, agents may have little precedent or practical experience base to draw upon. Such conditions will impact the achievement of the target outcomes, even though such situations may not be immediately apparent. When flexibility is available which tolerates cycles of iteration to achieve these outcomes, progress can still be achieved, though performance may disappoint.

Modeling of capability evolution over time - strategically, tactically, and operationally - should synthesize information from available sources and present it in a form suitable for use by these performers. Viewpoints can be used to produce thematic collections of this information that focus attention on a particular scope of concerns of these performers.  As such, these models should incorporate architectural data using combinations of diagrams, pictures, narrative text, matrices, tables, and dashboards.

Since this information will be essential to shape capabilities and their resources over time, a selected set of viewpoints should be adopted to facilitate these decisions and minimize the rework across the broader communities of interest. These viewpoint definitions should highlight the entities each capabilities produce and consume and must be adequate to realize coherent and effective operations across all performers engaging with the capability overall.

Changes (as shown in Figure 2) are ever-present in the pursuit of each capability's target outcomes. Such changes include intentional modifications to a system of interest's state that result from informed decisions, changes introduced by the environment, and changes necessary to correct or adjust some limitation in the system. In each of these situations, system of interest transitions from one configuration to another through transforming activities which realize this state change over time. Progress is demonstrated by assuring that the value of the system of interest is greater in State B than in State A.

The resources necessary to develop and exploit a capability thus depend upon many factors, including the environment, the fitness and stability of the systems of interest, and the scenarios under which value can be extracted under the immediate and anticipated circumstances. This is particularly relevant when a capability's evolution requires changes to the beliefs and values of the performers themselves. These emotional and cognitive needs are of particular concern since they will be expected to diagnose unfamiliar situations, properly infer meaning form these situations, formulate appropriate intentions in response, and translate those intentions into meaningful and appropriate courses of action. The unfortunate alternative is to abandon the intended purposes of the capability and live with the consequences.