In First Things First, I made a case for partitioning the front end of the development process into a concept planning phase and a detail design phase. In effect, this separates the “what” from the “how” in the process of creating and giving form to an idea.
The value of this is multifold:
- It encourages wider exploration—finding the “right” mountain to climb before rushing to the peak.
- It enables alternative concepts to be investigated at low cost before major investment commitments have to be made and concepts are still malleable.
- It reduces the likelihood of costly revisions forced by insights realized late in the development process.
- It opens the door to broadened strategic planning employing multiple, low-cost concept studies overlapping or in parallel (see the description of Escalator Delivery in Reforming the Development Process).
- If the planning are formed with members from across the organization, it shares the development process broadly, building organization-wide commitment and the ability to continue to contribute
With a lot of good, comes a little bad. To achieve these benefits, an important challenge must be met: high levels of inventiveness and involvement need to be sustained across transfers between teams. In a society where competitiveness is highly regarded, the “not invented here” syndrome is a potential killer when serial teams are involved.
The syndrome takes two forms in serial team transfer:
The first affects the concept team. Its members see the subtleties and richness of their carefully thought out system lost in the abstraction required of a specification. The proud parents are reluctant to release the baby without acknowledgment and respect for all that they know about it.
The second affects the design team. In the pure sense of “not invented “here”, its members are certain they could do a better job of defining the concept (as well as doing the design). Accordingly, they resist the specifications and invest valuable creative time in putting forward alternative ideas validating a different approach.
The result is usually a compromise with all the sub optimizations that frequently accompany political solutions. With the competitiveness of organizational politics, the actual moves are not always visible, but the end product is usually less than optimal, reflecting political wins and losses among players who are competing—when cooperating would further both their and the organization’s objectives.
The problem is how to pass the torch from one team to another without compromising either team’s contributions and without losing the potential additional contributions possible with continued involved cooperation.
The Plan
The product of planning is a plan. Literature on business plans, organizational plans and various kinds of strategic, marketing, financial and other plans is plentiful, so those wheels for the most part need not be reinvented. For product development, though, there are a few things to note. Information on three important topics should be present early in the process: concept, finance and implementation. The financial component deals with where funding will come from and how it will be spent. The implementation component develops thinking for internal and external operations, product introduction, marketing and sales. Both of these components are critical, but the component of importance in this discussion is concept. This should be the product of the conceptual phase of the development process, prepared for handoff to the design team, but it should also be the first element of the overall plan. It is essential for approval of continued development—critical for the formation of the financial and implementation plans. And, it can have positive impact on the not-invented-here syndrome!
Surprisingly, until recently, the concept component has received relatively little attention. Most probably, this was because business competition was less about elements of design than issues of producing, marketing, distributing and selling. That has changed. Decision makers today want to know more about what the concept is what its properties and features are, how it functions as a system, and how it will perform for its users. Competition has turned global and the voices of the users are now being heard.
Today, a concept worth its salt will in all likelihood be complex (but not complicated) rather than simple, will have multiple components that work together systemically, will be adaptive, and will offer values of more than one kind—social, economic, functional, aesthetic. It will need detailed, thoughtfully organized description for full understanding.
Elements of a Conceptual Plan
Figures 1, 2 and 3 show one of 61 elements of a plan for an award-winning Future Living housing system developed in 2009 at the Institute of Design. Its structure illustrates the areas of focus necessary in transferring complex concepts. Seven sections deal with organizational and retrieval issues typically of concern for knowledge bases: Originator, Contributors, Source, Superset Elements, Subset Elements, Fulfilled Functions and Associated Design Factors. Most of these are self explanatory and, in any case, are not critical to this discussion. Functions are discussed in Covering User Needs, Design Factors in Insight and Ideas.
The remaining five sections are critical. They are the channels that convey the concept. Used well, they transfer ideas at a level general enough to allow the design team creative freedom to explore detail options, yet specific enough to transmit strong guidance from the concept team in matters of direction. Figure 1, the first page of the System Element, contains the first three of these sections.
Description has the most familiar role of the three. Its job is simply to capture the essence of the element in brief—to encapsulate the idea at a level of generality appropriate for overall understanding.
Properties and Features, the next sections, are the “specification”. They are similar to the Properties and Features used in Solution Element documents (see Capturing Ideas), but should be worked over again carefully to be sure all the properties intended by the concept team to be in the design are covered and all of the features the design is expected to perform are listed. These will be the guidelines for the design team’s efforts. They should be treated as specifications with the expectation that their goals will be achieved, but not with the constrictive insistence accorded legal specifications prepared for contracts. Their role is to shine a light, not enforce strict compliance.
To supplement them and fill in the uncertainty that always surrounds abstracted specifications, two more sections, Discussion and Scenario, are included. These sections are very important to the torch passing process. Both are intentionally verbose—in contradiction to Description, Properties and Features. Both exist to allow the concept team to explain in as much detail as it wishes what the ideas are, what forms they might take, and how they would work in a real situation. These sections should be open-ended, mining the ideas the concept team has speculated upon during exploration. In effect, they should be a deliberate message to the design team: “See what we have seen and, if you do not find something better, consider developing these ideas further”.
Discussion and Scenario parallel Properties and Features in their focus Discussion concentrates on the components: what they must be and what characteristics they must have. Components may be any of physical parts, subsystems, services, processes, policies, activities, events, communications—whatever is necessary to fulfill the functions the System Element addresses. Scenario puts the System Element in motion, concentrating on how it works and how its users work with it. Treating the Scenario as a story teases out the actions that the concept team envisions, what the system does as its users engage it, what progressions of actions occur. In moving words or moving images, describing the system’s use as an event adds another full dimension to understanding. Together, Discussion and Scenario provide static and dynamic conceptions.
Communicating Structure
If there are more than a few elements in a Plan, complexity raises its head again; the elements will have to be well organized for the overall system to be understood. This is quite the normal situation. Almost any development project an organization might contemplate today will be complex—not in itself undesirable. To be complicated, on the other hand, is not good, and to prevent that in passing the torch, an appropriate organizing principle must be found to make the plan understandable to the design team receiving it as its Charter.
Figure 4 shows a “Communication Structure” for the 61-element Plan. The System Elements shown in the bottom two layers (offset vertically to make the structure more compact) are in clusters according to which work most closely together. Higher level clusters simply continue the aggregation, using the same organizing principle that System Elements (and now, clusters) are linked or associated if they are strongly related in the performance of tasks.
A Communication Structure is a navigational aid for a conceptual Plan. Close relationships for groups of System Elements can be seen directly in the structure. For any individual System Element, its document lists its strong links to other Elements. Following these, just as following roads to different towns on a map, initiates an exploration of all of its associations. Titles given to clusters based on what their element members do help to map out the overall nature of the system, region by region. And, as towns can belong to more than one higher level organizational entity (e.g., townships, congressional districts, state legislative districts, etc.), System Elements can belong to more than one cluster. System Element 20 (circled), the Guardian System introduced in Figures 1-3, appears in two places in the structure (as do others) marking the structure as a semi-lattice, not a tree, a more flexible kind of structure well-suited to organizing ideas. The hierarchy is best for a birds-eye view, but the graph of all the System Elements and their links can also be used as-is as the documents and hyper-links for a planning data base.
Knowledge Creation, Transfer and Maintenance
The complexity to be expected in modern products and product/systems only echoes what we are experiencing in life around us. It has become virtually impossible for individuals to work independently on projects of significance. We expect to work on teams, and we expect to have our fellow team members possess expertise different from our own so that together we can articulate the full range of expertise needed.
Increasingly, the tools that we use match the complexity of the problems we address. For development, the single most important part of the process to be improved has been the formulation, manipulation, organization, use and transmission of qualitative information. Available tools in the past did not provide the depth, consistency or capacity necessary for handling complex information, and did not define the basic forms for the information necessary to build an information processing system capable of dealing with qualitative as well as quantitative information.
The System Element is an information package containing, referring to, and itself one of such information elements. As the form for transferring knowledge about elements of a plan, it demonstrates the kind of qualitative approach necessary to capture relevant background (Associated Design Factors), required functionality (Functions Fulfilled), the components of an idea (Properties and Discussion) and goals for what these components and the concept as a whole should do (Features and Scenario).
Beyond transfer of ideas, the System Element also supports tracking back and construction of a qualitative knowledge base. For anyone interested, the bases for the ideas described in its Properties, Features, Discussion and Scenario can be tracked back to insights about function performance in Design Factors referenced in the Associated Design Factor section. Additional reasons for the qualities developed in the System Element can be inferred from the Functions it fulfills, listed in the Fulfilled Functions section. The answers to “why” questions stimulated by a System Element are available for the looking. All of this suggests creation and maintenance of a growing qualitative knowledge base built with contributions from a procession of advanced planning projects. Its value can only increase with time.
