Design breakdown structures
an extension to the work breakdown structure to manage innovation in new product development projects
Within the field of modern project management, a project is broadly defined as an activity of finite duration with the ultimate delivery of a defined goal. The development of new products fits this definition of a project perfectly. One should therefore, in theory, be able to apply standard project management practices to product development projects and thus be able to effectively manage them.
Though current project management practices do undoubtedly help in managing product development projects, there does however seem to be something missing in them to help manage the innovative factors required by new product development projects. This effect is magnified when one examines product development projects that are constrained by tight deadlines as many often are.
Both a slightly different philosophical approach and an extended set of management tools are required to be able to effectively project manage the introduction of innovation into new product development projects.
Innovation Requires a Paradigm Shift in Project Management
Most project management techniques deal with managing costs, scheduling, resource allocation, etc. of projects elements that are relatively well understood and analyzed. Unknown factors are to be avoided if at all possible and, if not, these unknown factors tend to be dealt with relatively passivity (most commonly by avoidance or insurance) in the field of risk management.
It should be clarified that most projects almost always have areas, which though referred to as unknown, are actually about the “undetermined” rather than the “unknown.” When building a bridge, for example, the soil and ground conditions are often referred to as an unknown, though in reality most soil conditions scenarios are just variables that have yet to be measured, and have already been dealt with by various known contingency plans. Though the soil conditions may at first glance seem to be an unknown, they are not. The reason that they are not really a true unknown is that the method for resolving the question is already well known and established. This is not to say that there are never any unknowns in standard projects, but just to say that true unknowns should not be confused with simply undetermined or unmeasured variables.
Most project managers have an engrained view of the unknown as the evil that must at all cost be banished and replaced by an all-powerful knowledge of every grain of sand that makes up the beach of their project. This omniscient knowledge is what will allow them to manage the project to time, cost, and quality. Their initial instinct on beginning a new project is to identify any unknowns that they may face, and attempt to circumvent or annihilate these areas so as to have a crystal clear picture of the project at hand.
Note that there is nothing wrong with this (possibly slightly exaggerated) view of the world, and that it is good for producing results in conventional “repetitive” projects in which most of the variables are well understood.
Innovative new product development, on the other hand, involves a high number of unknowns. Innovation thrives on the unknown. One does often not yet know at the start of the project how one is going to achieve the ultimate goal of the project. It is this state of “not knowing” that opens the door of opportunity to an unlimited number of innovative solutions.
The factors that cause humans to Innovate are need and knowledge. Knowledge is born out of our need to understand the unknown, and need is born out of the knowledge that we have shortcomings in our current situation, be they mental or physical (Barnett, 1953; Amabile, 1983).
Yet, time and again, product development teams are asked to predict how long a task will take them, when they may not yet have any idea as to how they will resolve it. They therefore rely on past experience in estimating task durations. These estimates are therefore intrinsically flawed, as they are unlikely to approach the problem in the same way as they did previously.
Therefore, to more effectively project manage new product development projects, a new set of tools needs to be added to the project management arsenal that better allows us to deal with these high level of unknown. The project manager must also make a mental adjustment and learn to refocus his or her negative perception of the unknown and come to not only accept it, but even promote it, particularly at the early stages of the project.
Exhibit 1. Long-Term Memory: A Hierarchical Semantic Database
A Perspective View on Innovation
The following may almost seem like a contradiction in terms: Though the end product of innovation is about the new, the process of innovation is about the old.
In the words of Gerald F. Smith, “We cannot imagine anything whatsoever, only things constructed out of existing knowledge. I cannot imagine a colour beyond my visual experience” (Smith, 1998).
Innovation is about finding new uses for things we already know. We cannot think of anything, new or old, that is not already stored in the knowledge banks of our minds. If we recall something from long-term memory without attempting to alter it, then it is just that: a memory. But if we take that data we have in memory, and use it for a different purpose than it was originally intended, or if we take two bits of data and combine them to form something new and useful, then that is innovation. The process of innovation is therefore about taking existing knowledge and data and converting it into something novel and useful.
So, if innovation is about using and adapting things we already know, then why is it so difficult to control? Is it completely random, or do we have some amount of mental control over the process? To try and understand these questions, we need to briefly delve into some background cognitive theory about how our brain thinks and resolves problems.
Mainstream cognitive theory behind how our thought processes function is relatively straightforward: We receive environmental inputs that are stored and processed in short-term memory. We are limited to around seven simultaneous external stimuli, and only a very limited amount of data can be stored in short-term memory for very a limited time (around seven items for between 5 and 20 seconds). Short-term memory includes a scanning process that continuously scans the data stored in this buffer and determines its usefulness, and then either refreshes it or discards it. This combination forms the working memory, similar to the combination of RAM (short-term memory) and software (scanning process) in a computer. The results of working memory can be used to recall other data from long-term memory as, and when required (Blumenthal, 1977; Ellis, 1978).
Long-term memory could be compared to a hierarchical semantic database, in which extra time is required (approximately 0.75msec) for each extra level of the database you descend to (Collins & Quillian, 1996). The links that join the nodes of data in long-term memory can weaken or get corrupted or broken with time, thus explaining memory lost or incorrect memory retrieval. Each data node could be stored as a mental representation of a single bit of data, as an image or, in the case of often used bits of data, as “chunks” of data in which an entire concept is retrievable in a single operation (Birch & Clegg, 1996; Collins & Quillian, 1969).
An event in short-term memory can be used to recall other events from long-term memory, which can then be worked with and turned into something new, providing that combination of the short-term memory content and the item retrieved from long-term memory lend themselves to triggering a new thought combination.
The limited content and duration of short-term memory is one of the main reasons why most people find problem solving, and most other thought processes much easier to handle when they break things down into components that are small enough for the working memory to handle.
When short-term memory attempts to retrieve data from long-term memory, it can follow any of a great number of data link paths to reach the data it wants to retrieve. It is our ability to create new links and choose which existing links to follow through our long-term memory database, which allows us to be innovative or not.
If we follow a path of existing links, a memory is recalled. If we create a new link between one bit of data and another that was previously unrelated, or if we follow a link that would not, under normal circumstances, be associated with the current data in short-term memory, then that is a new thought.
One of the principles of Gestalt theory (A theory in which human beings are viewed as open systems in active interaction with their environment) is the law of Prägnanz, which states that psychological organization will take the route requiring the least effort or energy in the achievement of the spatial and temporal stability of experience (Wertheimer, 1924). To put it crudely, it implies that the mind is lazy and will look for the simplest and most obvious links in long-term memory first. What this also implies is that thinking innovatively requires directed effort and a conscious decision to expend the extra energy required (Blumenthal, 1977).
Functional Fixedness, One of the Road Blocks of Innovation
One of the main mental barriers that prevent us from easily forming the new ideas with existing data is functional fixedness (Duncker, 1945). Functional fixedness is the effect of only being able to see something for what we have traditionally been taught it is by our education, environment, culture, etc.
A commonly used example of functional fixedness is Maier's two-string problem (Maier, 1931). In this problem, the subject is in a room with two strings tied to the ceiling. Both strings are of equal length. The objective is to tie the ends of the two strings together. The problem is that while the strings are long enough to be tied together they are short enough that one is unable to just take hold of one string, walk over to the other string, and tie them together. Scattered around the room there are a number of objects. These objects include a plate, some books, a chair, a pair of pliers, an extension cord, and a book of matches.
To resolve a problem, the real source of the problem must first be located. In the above example, the fundamental source of the problem can be viewed as one of the following:
• The string is too short
• My arms are too short
• The end of one sting wont stay anchored in place while I get the other
• The string won't come to me
Depending on what objects are located around the room, any one of these problem sources can be resolved by, for example, using an object such as the extension cord to lengthen one of the strings, or using an object (such as a chair, for example) to lengthen ones arms, etc. However, if the only object in the room were a pair of pliers, then the solutions become much more limited, as this object cannot be used to resolve all the possible problem sources.
About 60% of the participants in Maier's study failed to find a solution within a 10-minute time limit.
These participants saw the pliers only as the traditional tool they are, not recognizing that the pliers could be used as a pendulum bob, swinging at the end of one of the two strings, thus resolving the “string won't come to me” problem source.
Most of us have difficulty in seeing the pair of pliers in the above example, as anything other than a tool as that is what we have always been taught they are. Through force of habit, we are fixated by the fact that the objects function is that of a pair of pliers. If we can overcome this fixedness, then we can see that they could have many other uses. The pair of pliers could be used as a weight (paperweight, pendulum weight, weapon, fishing sinker, etc.), an electricity conductor (emergency fuse, car jump start kit, etc.), and so on.
Exhibit 2. Functional Fixedness—The Two-String Problem
The reason that overcoming functional fixedness is so important is that, as innovation consists in finding new uses for knowledge we already have, we need to try to get past the barrier that a particular bit of knowledge only has the use it was originally intended for.
The Design Breakdown Structure technique proposed in this paper helps to overcome functional fixedness by breaking the object or concept one is looking at into its fundamental problem areas.
The Work Breakdown Structure
One of the most useful tools currently used in project management, which allows us to easily understand the project as a whole, is that of the Work Breakdown Structure (WBS).
Prior to the mid-1960s, several WBS techniques were used. Any given project could be displayed by the contractor's functional organization, by contract phases, by contract task, or by any other work category (A.F.M.C.F.M. Handbook, 1998).
Today's modern Project Management WBS was amalgamated in August of 1965, when the U.S. Department of Defense conducted a special study designed to establish consistency between system acquisitions and to create a historical database of projects.
This study resulted in the issuance of DoD 5010.20, Work Breakdown Structures for Defense Material Items on 31 July 1968 and MIL-STD 881 was then issued on 1 November 1968. It then went through the incarnations of DoD 5000.2-R, MIL-STD 881b on 25 March 1993, before being finally superseded by MIL-HDBK-881 on 2 January 1998 (Morris, 1998).
The Military Standard (MIL-HDBK-881) defines the Work Breakdown Structure as follows:
“A work breakdown structure is a product-oriented family tree composed of hardware, software, services, data and facilities…. [it] displays and defines the product(s) to be developed and/or produced and relates the elements of work to be accomplished to each other and to the end product(s)” (U.S. Department of Defense Handbook, 1998).
The WBS consists in breaking down the project into the various work packages that make it up. From these work packages, schedules, task lists, resource allocations, etc. can be derived thus allowing the project manager to effectively manage and control the project. The WBS however does not cater well for areas of unknown. How do you break down something that you do not yet know the shape of, or how you are going to achieve?
The Design Breakdown Structure
By adding a further refinement to the WBS, which we will call a Design Breakdown Structure (DBS), we will have a tool that will permit us to deal with those areas of unknown. The DBS consists in breaking down areas and components into the fundamental problem areas that need to be resolved in order to achieve those goals set out by the component. Much like the WBS, it is a graphical family tree showing all the problem areas that need to be overcome and the alternative solutions to overcome them, and how they are related.
Whereas a WBS concentrates on the “WHAT” outputs of the project, the DBS puts emphasis on the “HOW” questions of the project.
The DBS is, in essence, a structured, hierarchical, graphical documented team process where the entire design team, including the project manager, works through the fundamental issues they must overcome to reach their preset goal. It is this well-structured documentation that acts a road map of the project, and spreads an awareness of both the issues that each individual designer faces, and the interconnectedness of all the issues. It forces the team to work as a coordinated, well-knit unit rather than as a team of isolated individuals. This road map is essential towards allowing the project manager to effectively manage the project.
The DBS technique revolves around the following: Developing an innovative idea always consists in finding a novel use for an existing object or concept.
As an example, if one were looking for novel uses for a brick, one might come up with several initial ideas (door-stop, paperweight, etc). Our functional fixedness about what a brick is will have a tendency to limit the alternative uses we can find for the brick. However, if one breaks the brick down into the fundamental properties that make it up (such as weight, rectangular, heavy, porous, does not conduct electricity, rough, small enough to be picked up in one hand, holds heat, etc.), one can usually come up with many more ideas for its use, than when one is thinking of just the brick as a whole.
When problem solving, which is a large component of the product development process, one is in effect attempting to use the above technique, but in reverse. One has already identified the properties that one requires, and one is looking for the “brick” or other solution that will fulfill those properties in a novel way.
By breaking each problem to overcome down into its fundamental problem areas (such as theory, knowledge, energy source, timing, cost, equipment, materials, components, mechanical, etc.), we can identify what the properties of the potential solution will have to be and thus reverse-engineer it.
It should be noted that breaking things down into sub-units, or decomposition as it is often referred to in product development, is nothing new. However, though of some help, just breaking a product down into subassemblies is of limited use, particularly if done in a non-graphical format such as a list. It is the graphical and structural nature of the WBS and DBS that make them powerful tools, as one can almost instantly see the relationships and hierarchy between the various elements that make them up.
The DBS also helps to relatively easily isolate the true constraints of the project as well as isolate those areas that require high levels of creative thinking and those that require merely basic knowledge or mechanical design.
Using a Design Breakdown Structure has benefits to both the project manager and to the design team. It allows the Project Manager to:
• Better understand needs or obstacles the designers may come across.
• Act as a better facilitator in getting the designers the resources or information that they need to overcome the problems.
• Allocate his or her design resources more accurately, as he or she can match the designer with the expertise best suited to solving each problem area.
• More accurately monitor the project, as the sections of the design have been broken into smaller more easily measurable tasks.
For the design team it:
• Crystallizes all the problems that the designer may need to overcome and shows the relationships between all the elements of the product
• Gives them an idea of which areas will require the most creative thought
• Gives the designer has a distinct number of paths to follow
• Gives the designer the ability to give a more accurate estimate of the time it will take to come up with a solution
• Allows design teams to work together as a unit, where one persons' ideas generates new ideas in others
• As the DBS must be well documented to be truly effective, the documentation (particularly if computerized) acts as a knowledge database for future projects.
For the DBS to be effective it must be used as a live communication tool, and much like any other project status type tool, it must be kept up to date and grow with the project.
A DBS would normally be used as an integral part of a WBS. A DBS can be used either for the product as a whole, or for individual elements of the product WBS. DBS elements are often drawn directly from the elements of the WBS and, having gone through the DBS process, are then reintegrated to the WBS. Once the product design has been finalized, if a traditional WBS is required or an existing WBS needs to be updated, it can easily be generated from the Design Breakdown Structure, by simply removing all the “non-deliverable” elements. The DBS can then be integrated to form part of the WBS dictionary, where each DBS element can be included with it's corresponding WBS element, thus showing the process that was gone through to reach the final solution and strengthening the relationship between the various WBS elements.
Ultimately, the objective of any research into product development must be to improve the development process in terms of speed and product outcome quality (cost generally being a factor of these). Using Design Breakdown Structures as an extension of existing project management and design management techniques can be a useful aid in shortening the design time required by innovative product development projects. It is a tool that is of great help to overcoming the functional fixedness that often acts as a barrier to efficient innovative product development.
It is of benefit to the design team in aiding them to comprehend all the issues involved in the product design, and it is of benefit to the project manager in that it gives him the information he or she requires to fulfill some of his or her roles as facilitator, scheduler, prodder, and negotiator, etc.
One of the main keys to innovation is the ability to convert existing knowledge, ideas and concepts into new ones. The Design Breakdown Structure facilitates the designer team's ability to break a problem down into its fundamental building blocks, thus allowing them to more easily overcome the functional fixedness, which prevents them from generating new ideas out of existing knowledge.
The Design Breakdown Structure is a tool that can be extremely effective when used in close conjunction with the traditional WBS. It must be remembered, however, that the Design Breakdown Structure is not suggested as a replacement for the traditional WBS, but rather as an extension of it.
AFMC Financial management Handbook. Work Breakdown Structure. http://www.afmc.wpafb.af.mil/HQ-AFMC/FM/FMRS/noframes/chap10.htm, 1998.
Amabile, Teresa M. 1983. The social psychology of creativity. New York: Springer-Verlag.
Barnett, H.G. 1953. Innovation The basis of cultural Change. New York: McGraw-Hill Book Company Inc.
Paul Birch, & Brian Clegg. 1996. Imagination Engineering, The toolkit for business creativity. London: Pitman publishing, pp. 3–25.
Blumenthal, Arthur L. 1977. The Process of Cognition. New Jersey: Prentice Hall Inc., pp. 19–33.
Chaplin, James R. 1997. The Work Breakdown Structure, http://www.hyperthot.com/pm_wbs.htm.
Collins, A.M., & Quillian, M.R. 1969. “Retrieval time from semantic memory.” Journal of verbal learning and verbal behaviour, 8, pp. 240–247.
Duncker, K. 1945. On problem solving. Psychological Monographs, 58, Whole No. 270.
Henry C. Ellis. 1978. Fundamentals of Human Learning, memory and Cognition, 2nd Edition. Iowa: Wm. C. Brown Company, pp. 86–98.
Maier, N.R.F. 1931. “Reasoning in humans II: The solution of a problem and its appearance in consciousness.” Journal of Comparative Psychology, 12, pp. 181–194.
Morris, P. 1998. The management of projects, A new model. Centre for research in the management of projects, http://www.umist.ac.uk/CRMP/management_of_projects.htm.
Project Management Institute Standards Committee. 1987. PMBOK®, Project Management Body of Knowledge. Project Management Institute.
Smith, Gerald F. 1998. Quality Problem Solving. Milwaukee, WI: ASQ Quality Press.
Turner, R. J. 1993. The Handbook of Project-based Management. McGraw-Hill.
U.S. Department of Defense Handbook. 1998. Work breakdown Structure. MIL-HDBK-881.
Wertheimer, M. 1938. Über Gestalttheorie, the Kant Society, Berlin, 1924, translated by Willis D. Ellis published in his “Source Book of Gestalt Psychology.” New York: Harcourt, Brace and Co.
Wideman, M. 2000, Jan. Combined from the various definitions at: Wideman Comparative Glossary of Project Management Terms 2.0, http://www.maxwideman.com/pmglossary/index.htm.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 · San Antonio, Texas, USA