Capabilities provide stakeholders with the ability to execute specific courses of action necessary to achieve an organization's mission. They must constantly be striking an economic balance between operational stability and potential efficiencies which may be achievable by enhancing the capabilities themselves. This balancing act between short and long term objectives results in competition for resources, talent, and attention within selected parts of a value stream and the related environmental evolution anticipated over a variety of time horizons.
Winston Churchill warned of such operational risks in his book, World Crisis (Vol I, Ch XI): "terrible ifs accumulate". The root causes of their manifestations can usually be traced back to incomplete information, carelessness, distractions, and blind spots. Since the consequences of such risks inflict collateral damage on many parts of the business, it is in everyone's collective interests to reserve a portion of available resources for any endeavor towards mitigating such risks. This mitigation usually relies upon a proper foundation to be in place which establishing appropriate disciplines, conducting focused analysis, and laying in place contingency plans. Yet within most organizations and cultures, incumbents may perceive such changes as threats to their welfare, security, or reputation, or unnecessary constraints on their desire for personal fulfillment, rather than firewalls across the many temporal and organizational aggregations of an endeavor.
The energy of teams at the fuzzy front end of projects is precious and fleeting. As teams attempt to navigate through the many uncertainties that must be confronted, much of their time and efforts may feel like waste. Anytime a search for value reaches a blind alley from which an original objective cannot be achieved, it is necessary to retrace steps, and repeat an earlier process, no matter how many resources are thrown at the current constraint they are presented with. To avoid this fate, teams must navigate a path through a hierarchy of decisions about user utility and design alternatives. Along the way, they must generate realistic options for minimum viable products that address shortfalls in needed capabilities. They must experiment to discover information and validate assumptions about the candidate solution space, incrementally converging on a 'good enough' design and realization strategy. In order for this new offering to differentiate itself, the designers must focus on candidates which offer relative advantage, compatibility, simplicity, and observable effects to help pull existing users towards these options.
As Jeanne Liedka and Tim Ogilvie describe in Designing for Growth,
The reality of human beings and their needs fades as they are tabulated and averaged into categories, reduced to the status of preferences in a conjoint analysis. Lost with that reality is the deep understanding of needs - often ones that aren't even articulated - that is the starting point for profitable growth. This messy reality - that behavior is driven by more than economic logic - is something that designers understand well. They master the skills of observation, of understanding human beings and their needs, while managers learn mostly to evaluate, an activity that rarely involves the kind of empathy that produces fresh insights. Professional doubters are much better at judging than creating.
Teams need a semantic basis for this voyage of discovery. As they create and evaluate alternatives within the solution space, they inevitably engage in lengthy debates for a foggy and shifting landscape. To discover the highest value, they must unite (rather than just look for common ground) across each other's mental models. Unfortunately, such opportunities may be at such high levels of abstraction that nothing ever gets nailed down. Sadly, this produces long and unnecessary voyages to find more rocks, often because the problem they are intending to address has not yet been adequately defined. In Notes on the Synthesis of Form, Architect Christopher Alexander eloquently describes the how the functions and form interact with its operational environment:
The ultimate object of design is form… If the world were totally regular and homogeneous, there would be no forces, and no forms. Everything would be amorphous. But an irregular world tries to compensate for its own irregularities by fitting itself to them, and thereby takes on form. D'Arcy Thompson has even called form the 'diagram of forces' for the irregularities. More usually we speak of these irregularities as the functional origins of the form.
Physical clarity cannot be achieved in a form until there is first some programmatic clarity in the designer's mind and actions; and that for this to be possible, in turn, the designer must first trace his design problem to its earliest functional origins and be able to... find some sort of pattern in them, Every design problem begins with an effort to achieve fitness between two entities: the form in question and its context. The form is the solution to the problem; the context defines the problem. When we speak of design, the real object of discussion is not the form alone, but the ensemble comprising the form and its context. Good fit is a desired property of this ensemble which relates to some particular division of the ensemble into this form and context.
The functions are delivered by mechanisms which transform sets of inputs into outputs, while remaining faithful to design principles that the team has set for themselves. Functions are designed to satisfy a defined set of attributes and constraints with acceptable performance. Functions are a product’s answer to which tasks users will be enabled to perform. Functions are not the same as features, which are aspects of how a user interacts with a product. For example, initiating a call on a cell phone is a function; the dial tone and the keypad are features that are mechanisms provided to accomplish the function of placing a call; note that voice dialing is another feature which provides the same call initiation function. The choices of which functions are worth offering (or eliminated), and how its associated features should be packaged and offered over time, is fundamental to any product management activity.
Multiple perspectives are essential to balance the stakeholder interests for these features. Typically, these stakeholder's needs must be elicited from owners, acquirers, developers, builders, maintainers, end users, and sponsors. The resource bargain strikes an appropriate economic balance across all these perspectives over time.
The choice on whether to include or exclude each function requires consideration of the functional relationships overall. For example, a visual depiction of the functions offered by the (now deprecated) photo sharing site Flickr illustrates why it is necessary to understand these needs and their relationships is necessary. Once these functional relationships are sufficiently defined, and laid out over an implementation roadmap, teams can begin to work through realization cycles for each function, with limited disruption from other teams.
The logical (solution-independent) view of these functions, features, and performance characteristics should be articulated without imposing constraints on how these functions are to be realized by design or technologies. The perspective should also be done with full consideration of the time dimension from creation to disposal, or 'lust to dust'. The constraints imposed on solutions by time and resources should only be introduced deliberately in the form of business or operational constraints necessary for the overall endeavor to be successful.
IIt often can be helpful to prioritize the sequence of this probing and focus on the resources with the greatest scarcity, to assure that a desired balance can be achieved for all stakeholders:
The critical thing about the design process is to identify your scarcest resource. Despite what you may think, that very often is not money. For example, in a NASA moon shot, money is abundant but lightness is scarce; every ounce of weight requires tons of material below. On the design of a beach vacation home, the limitation may be your ocean-front footage. You have to make sure your whole team understands what scarce resource you’re optimizing.
The proper orientation to adopt in balancing act is that of proportionality. Leonardo DaVinci drew his Vivutrian Man to depict the geometrically ideal human proportions of the human body, drawing from the work of the ancient Roman architect Vitruvius. In Book III of his treatise, De Architectura, Vitruvius emphasized the importance of proportion in classical architecture. Leonardo's drawing expanded on Vitruvius's concept until it became the archetypical expression of man's desire to relate to nature from three essential viewpoints: firmitas, utilitas, venustas. In today's language, these goals are achieved by realizing user-centered designs, and assuring that these designs are robust, useful, and beautiful. Each these properties emerge from the whole, and generally cannot be delegated to a single team or subsystem without suboptimization. Each of these properties is only an ephemeral platitude until it is grounded in context and through elaboration.
Russell Ackoff recently announced to his colleagues that "the future of operations research is past" because "managers are not confronted with problems that are independent of each other, but with dynamic situations that consist of complex systems of changing problems that interact with each other. I call such situations messes. Problems are abstractions extracted from messes by analysis; they are to messes as atoms are to tables and charts... managers do not solve problems: they manage messes". Problems are interconnected, environments are turbulent, and the future is indeterminate just in so far as managers can shape it by their actions. What is called for, under these conditions, is... the active, synthetic skill of "designing a desirable future and inventing ways of bringing it about". Engineers encounter unique problems of design and are called upon to analyze failures of structures or materials under conditions which make it impossible to apply standard tests and measurements. Practitioners are frequently embroiled in conflicts of values, goals, purposes, and interests. Each view of professional practice represents a way of functioning in situations of indeterminacy and value conflict, but the multiplicity of conflicting views poses a predicament for the practitioner who must choose among multiple approaches to practice or devise his own way of combining them.
Each of these views deliberately focuses the design team's attention on selected details of the system, while ignoring (or 'separating') other concerns. These different viewpoints can be used to prioritize, communicate, and explore key attributes and unique perspectives around which the design is being optimized. In order for a team's collective communications to illuminate rather than obscure these views, they must be consistent with each other and with the existing or envisioned system's Concepts of Operation. It is only within the lens of these operational concepts and candidate solutions that functions can begin to be mapped onto a design.
In this context, design must be an iterative process whose predictability is dependent upon having foundational precedents that the effort can build upon. In Casting Software Design in the Function-Behavior-Structure Framework, Philippe Kruchten draws on earlier work by John Gero, who has written about how the design process evolves. Gero's design iterations are depicted in the diagram on the right. Gero describes the key aspects of these representations:
Design requires a representation framework which has sufficient expressive power to capture the nature of the concepts which support design processes. The use of a knowledge representation schema such as design prototypes allows for this. It separates the knowledge from the computational processes which operate on it. The use of this representation effectively provides a translator between structure, which may be seen as the syntax of a design, and function, which may be treated as the semantics of a design. Such an articulation is useful not only in the production of designs but also in their analysis and evaluation.
To optimize a design across these views, a common notation must be adopted so that a unified, consistent viewpoint of the critical attributes of candidate solutions can be evaluated and shared. Like the heat in Goldilock's porridge, the level of detail that is used to specify these choices has to be neither too little nor too much, but just right for the situation. Since each requirement incorporated into a specification constrains the choices a designer can make, presenting too many requirements will likely extend the time necessary to produce a solution compliant with all of them. To find this balance, architects need to craft a series of exploratory activities which will discover the sweet spot among these tradeoffs. This balance should characterize the platform necessary for operational use, provide an adequate design margin for existing demand, anticipated growth, and adequate reliability. To deliver solutions within resource commitments, providers must know exactly which needs are to be pursued, and how and when they will need to be delivered, in order for users to take advantages of the new capabilities in achieving target benefits.