Research in Engineering Design

, Volume 21, Issue 3, pp 153–171

Planning development processes for complex products


    • Design Group, DDEMThe Open University
  • P. John Clarkson
    • Engineering Design Centre, Department of EngineeringUniversity of Cambridge
Original Paper

DOI: 10.1007/s00163-009-0079-0

Cite this article as:
Eckert, C.M. & Clarkson, P.J. Res Eng Design (2010) 21: 153. doi:10.1007/s00163-009-0079-0


Efficient planning of design processes is of critical importance to meet tight deadlines and budgets; and the development of process planning tools is a lively research area. This paper describes current planning practice in industry and the challenges associated with it. In industry, a multitude of plans are used in parallel each focussing on a different aspect. The units of planning and their resulting plans roughly fall into product plans considering cost, bill of materials and procurement considerations; process plans including different milestone, lead-times, task and activity plans; and quality plans. Over the course of a project, the same plan can serve as a prescriptive plan defining steps in the process, a target plan against which process is measured, and a record of the process. This paper argues that organisations work because individuals use more than one plan and have a tacit understanding of the relationships between these plans. Variations between different companies are discussed before the paper concludes with a reflection on implication for planning support.


Process planningEmpirical studiesComplex engineering processes

1 Introduction

Helicopters, aeroplanes and cars are marvels of modern technology. They represent a class of refined and optimised products that have become ever more affordable and increasingly more reliable despite raising complexity. The designers are rightly proud of their products, but would rarely say the same about the processes by which these products have been designed. Designing better products faster puts huge pressure on the design process, especially since many companies are also trying to do so with far fewer people than even a few years ago. Effective management and planning of design processes is vital to avoid the unexpected bottlenecks and iterations that can easily use up profit margins.

Design managers are often responsible for planning—a process that, superficially at least, is simple. They list the activities they need to carry out, work out how long these take, the resources they require, and determine an order to put them in. So, where is the problem? Many companies are less than content with their planning, without analysing where the problems lie. There is a lingering feeling that, if only the manager tried a little harder, the plans would be fine. However, this paper, drawing on several detailed industrial case studies carried out in UK engineering companies over the past 10 years, shows that this in unlikely to be the case as planning is a diverse and complex activity where the different aspects that need to be planned do not map into each other in a straightforward way, so different thinking and methods are needed to do it better.

The term ‘process’ itself has two distinct meanings in engineering design: ‘process’ as the officially specified steps that a project in a company must take, and ‘process’ as the set of activities and tasks that are actually carried out to create a new product. This distinction is rarely made explicit in discussions of processes, process plans and process models, so that descriptions of past, future and idealised processes are mixed in a combination of the “as-is” process and the “as-should-be” process.

A ‘plan’ is defined by the Collins English Dictionary as “a detailed scheme, method, etc. for attaining an objective” or “a proposed, usually tentative idea for doing something”. In this paper, we will take a very broad view of what constitutes a plan, and include, for example, plans to prescribe behaviour as well as plans to monitor and record activities.

A ‘schedule’ is a specific plan that according to the dictionary is “a plan or procedure for a project allotting the work to be done and the time for it”. Scheduling is useful in manufacturing where production steps can be accurately timed, but is more difficult to apply to design, which is frequently riddled with uncertainty.

Planning happens on many levels and in many places in an organisation: from planning a product portfolio at a strategic management level, to assigning available resources at an engineering management level, to the level of individual designers who may wish to plan their own activities. In addition, logistics departments plan the flow of materials, parts, components and products through the organisation; and manufacturing engineers plan the assembly process for each product as part of the entire assembly process. In practice, all business activities, from personnel through management and engineering, need to be planned and these plans are likely to be connected in a complex and often unpredictable way.

This papers aims to explain planning practice in product development projects based on several in-depth case studies in UK companies. Section 2 briefly sets up some of the context of planning complex design projects discussing both the challenges of process planning in terms of coping with uncertainty and iteration, and the tools that are currently being employed in industry and proposed in research. The analysis of planning practice draws on several case studies. The methodology is explained in Sect. 3. Section 4 describes observations about different plans, units of planning, owners of plans and functions of plans. Section 5 reflects on different planning behaviour in different companies; while Sect. 6 looks at the common challenges and problems that all companies are facing over planning. Section 7 discusses the wider implications of the observed planning behaviour, in particular for computer support tools, before conclusions are drawn in Sect. 8.

2 Planning complex and uncertain processes

Engineering design projects are often undertaken on a very different scale from other types of design projects with the possible exception of very large software projects and construction projects. The design of an aeroplane or production facility can involve thousands of person years of effort requiring a high degree of specialist knowledge. Such processes require careful management with a focus on systems and their integration.

While many other business processes seek to do the same thing many times, design projects usually have a certain element of novelty—if the product already existed, it would not need to be designed—and therefore a certain degree of uncertainty. Plans and models of design processes, at least at a meaningful level of detail, can therefore only be drawn from experiences of similar projects and often use elements of old plans that were used to design similar components or systems. This can introduce risk into a design process through mismappings and misunderstanding of the nature of these similarity relationships (Earl et al. 2001). In addition, engineering projects are, relatively, very infrequent. An extreme example would be the design of a helicopter, where a company might only develop a new model every 10 years. However, even in companies producing large numbers of customised designs for a range of customers, the total number of product designs will usually be in the tens or hundreds over a number of decades.

Design processes are unlike workflow processes (Fischer 2005), where the assumption is that tasks are frequently repeated and that staff are interchangeable. All design projects are different, involving different tasks and skills, and even seemingly very similar projects can involve different processes. Yet many large organisations are increasingly adopting a Business Process Excellence approach to all their business processes, which aims to combat variability in all business processes, including the product development processes. Business Process Excellence (e.g. Kirchmer 2008), in a nutshell, refers to the documentation, review, optimisation and automation of business processes with the express aim to improve the productivity of an organisation. Processes are mapped out, analysed and improved with the aim to generate output of even or improved quality in a given time. This is exemplified by the Six Sigma (e.g. Pande and Holpp 2001) DMAIC (Define, Measure, Analyse, Improve, Control) to improve existing processes or the DMEDI (Define, Measure, Explore, Develop, Implement) to develop new processes. These approaches have originated in manufacturing processes, where the process steps are known and the uncertainties are known, and later been applied to workflow processes, such are order handling or procurement.

2.1 Uncertainty in design processes

Engineering design processes are inherently uncertain, a factor which makes them difficult to plan. Earl et al. (2005) classify uncertainty into four categories, known uncertainties, unknown uncertainties, uncertainties in the data (including measurements) and uncertainties in the description. Known uncertainties are those can be described and handled well based on past cases. Unknown uncertainties are those where the specific event or type of event could not have been foreseen, for example, the occurrence of 9/11 and its impact on the aerospace industry. Uncertainty of data includes factors such as completeness, accuracy, consistence and quality of the measurements themselves. This is different from uncertainty in the description (of a system), which focuses on the ambiguity of descriptions, the selection of elements and the lack of clarity in their scope. Hastings and McManus (2004) define in a similar classification uncertainty as lack of knowledge, lack of definition, statistically characterised variables, known unknowns and unknown unknowns. Both lack of knowledge and lack of definition are similar to Earl et al.’s uncertainties in the description. They describe lack of knowledge as “facts that are not known, or are known only imprecisely, that are needed to complete the system architecture in a rational way” and lack of definition as “things about the system in question that have not been decided or specified”. What characterises these uncertainties is that with additional effort, both the lack of knowledge and ambiguity definition can be reduced. In other words, these uncertainties are not irreducible. There are, on the other hand, uncertainties that are irreducible: in other words, only the occurrence of future events will turn these uncertainties into known facts. De Weck et al. (2007) distinguish between endogenous uncertainties that a company can influence, and exogenous uncertainties, which are beyond their control, such as the way products are used, the way the market develops or the cultural and political context the company operates in. Companies can try to reduce endogenous risks, but have to have mitigation strategies against exogenous risks.

2.2 The relationship between models and the subject of the models

Design process planning requires the generation of implicit or explicit models of processes. While philosophers of science have long recognised that scientific theories assert similarity relationships between models and reality (Giere 1999), a similar debate about the role of process models in process planning and management has not yet occurred. Anecdotal evidence, from the studies reported in this paper, indicates that many people think of processes and process models in a similar way to products and product models. A product exists and the mapping between product and its model can be assessed. Even a design that has not yet been produced has many current descriptions that can be compared to each other, and to similar designs created in the past, in order to understand this mapping. However, processes and process models are quite different. Soft system methodologists, such as Checkland (1981), point out that organisational models or processes do not have a real existence and only exist in the minds of the individuals who take part in them. A model may be the only tangible existence of a process; and the way the model is described strongly influences the way people think and act far beyond the scope of planning itself.

Models are inevitable abstractions of reality that are created for a particular purpose. In any modelling activity, one needs to consider what should be reflected and what should not be included.

2.3 Iteration and failure in processes

Engineering design processes are highly constrained, not only by external factors, such as requirements, resources and deadlines, but also by the nature of many technical products where components, functions and systems are strongly coupled (Suh 1990). Engineering design processes are often over-constrained and have conflicting constraints (Stacey and Eckert, in press). Accounting for conflicting constraints in coupled problems almost inevitably leads to iteration, which is known to be a major feature of many engineering design processes (Smith and Eppinger 1997). Iteration may take the form of unplanned iteration, where redesign is necessary due to the failure of the initial design to meet given constraints and requirements, or planned iteration, where it is expected that several iterations will be needed to refine the performance of the product to a satisfactory level.

According to Wynn et al. (2007), iteration can be seen from different perspectives:
  • Rework to correct errors or to cope with problems, such as the knock-on effects of changes to what appeared like a finished component (see Eckert et al. 2004). Cooper (1995) points out that rework is an inevitable part of any product development process and distinguishes between ‘known’ rework, resulting from planned iterations, and ‘unknown’ rework, resulting from errors in the design process that may only become evident after some considerable time delay. For example, mistakes made during conceptual design might not be discovered until design integration or testing.

  • Convergence to generate solution where the relationships between parameters and objectives are complex and a satisfactory solution cannot be identified by inspection or direct analysis, an iterative process is used to converge upon a satisfactory solution. The convergence strategy is used in designer-driven processes as well as automated design and optimisation systems. Convergence cycles are typically planned iterations.

  • Refinements to improve components that have met their requirements, but do not quite satisfy the designers, or to components that do not have objective quality criteria.

  • Repetition when a task is carried out several times for different aspects of a design, for example, to design several configurations for fuel pumps on a diesel engine. These repetitions are entirely planned, but are often drawn as iterations in process models.

Iteration is a natural part of a creative design process, which is the concurrent and iterative exploration of problem and solutions spaces (Lawson 1980). Iteration is also the result of negotiations between different players in a design process, as the contributions from different fields needs to be integrated into a single functioning solution.

2.4 Research on process planning

Academic research has been concerned for a long time with how design processes should best be carried out. Many descriptive and prescriptive models of design processes exist (see Wynn and Clarkson 2005), which are based on empirical studies of design processes. Some of these models could form the foundations of the process models used to guide design. For example, many companies have adopted stage gate models, which prescribe the state a design must have reached to be passed on to the next phase of the process (Cooper 1995). Many companies have developed their own versions of stage gate processes and use them to provide a repeatable structure for their design projects. Browing and Ramasesh (2007) provide an excellent and detailed survey of activity network-based process models. Very few studies have addressed planning directly. Adler et al. (1995) looked specifically at how companies handled time predictions that informed planning. Austin et al. (2000) have spent much time studying planning practices in the construction industry in order to identify common tasks that can serve as building blocks for specific processes. In case studies in several companies, they discovered that most participants have employed some form of flowchart, often on many levels of detail, without additional descriptions. However, the authors’ primary goal was not to understanding planning practice, but to standardise or prescribe processes in order to aid the planning process.

2.5 Process planning tools

Research on support for planning has been very active for many years in different fields; for example, artificial intelligence has long been concerned with problems such as scheduling or timetabling (see, for example, Laborie 2003). Design research, similarly, has long been concerned with developing tools for design processes planning, such as design structure matrices (DSM) (Smith and Eppinger 1997; Browning 2001), Integrated Definition Methods1—IDEF (e.g. Hunt 1996) or Signposting (Clarkson and Hamilton 2000; Wynn et al. 2005).

Commercial planning tools include connectivity maps of the process evaluation and review technique (PERT) and employ the critical path method (CPM) with Gantt charts (see Fig. 1), two of the best-known examples of the more general precedence diagramming method (PDM) (PMI Standards Committee 2000). In all these methods, activities are shown as nodes or boxes on a network where arrows joining the nodes signify the flow of information or material from one task to another.
Fig. 1

A PERT chart to show task dependency and a Gantt chart to display the critical path

Both techniques are primarily concerned with deriving the degree of ‘float’ or scheduling flexibility for each of the activities in a process, differing primarily in the value of activity duration which is used (CPM uses the modal duration, while PERT uses a weighted average of lowest, highest and most likely durations). The two representations are intended as a pair, where PERT chart show connectivity and Gantt charts show sequences. However, many companies only use Gantt charts thus loosing any indication of how tasks are connected.

Structured process planning is far more advanced in manufacturing processes, which are more repeatable than design processes. Companies often apply critical path analysis techniques to generate product schedules (as discussed, for example, in Dolan and Aldous 1993), to generate product schedules. The challenge lies in coordinating the manufacturing of several products at the same time, with limited resources and while avoiding bottlenecks and down-time as much as possible. Bottlenecks can be analysed using analytic information theory measures of complexity such as proposed by Frizelle and Woodcock (1995), Deshmukh et al. (1998) and Calinescu et al. (2000). Complexities in designing and associated decision processes are described by similar entropy maximising measures by Jaynes (1957), Tribus (1969), March (1976) and Suh (1990). These indicate how tasks are spread across available process steps and resources, such as those provided by particular manufacturing equipment. The complexity of behaviour therefore reflects the underlying structure of processes.

3 Methodology

This paper draws on a number of industrial case studies carried out by the authors and their research team. In the autumn of 2000, the first author carried out a targeted study on processes planning in a small automotive company in the UK. Over a period of 6 week, she interviewed 18 experts in one company on two sites, including engineers, engineering managers and business managers. This study was planned in conjunction with a senior member of the organisation and concentrated on the development of a new model sports car at the company’s second site. This project was later abandoned. These included from the product design function a vehicle architect, a project manager, his assistant, several functional managers, several component team leader and several engineers; and from the other business functions the head of quality control, somebody from accounting, somebody from purchasing and the manufacturing person dedicated to the project. This case study provided the initial insights for the analysis presented in Sect. 4 (see Eckert and Clarkson 2004). A later case study in 2002 that interviewed 17 engineers in an automotive consultancy also aimed to study planning behaviour in the automotive industry and the link between planning and communication, but due to the particular nature of this business carrying out many small disjoint projects, the study yielded few additional insights.

The other case studies listed in Table 1 did not focus on process planning as such, but brought out many important aspects of process planning. For example, the study of customisation of helicopters (Eckert et al. 2004) looked at engineering change, but one of the main problems with engineering change is that it is difficult to plan and that the knock-on effects of changes upset process plans. These studies were used to assess the generality of the findings from the 2000 case study; and informed in particular Sect. 5 on the variability of planning behaviour.
Table 1

Brief description of case studies


No. of interviews


No. of engineers

Industry sector

Context of the study






Support required for tendering and planning of customisation



Planning and communication



New project, new people, no established company procedure



Planning and communication


Automotive consultancy

Change from internal funding to consultancy, hundreds of small projects p.a.





Diesel engines

Planning new product development and numerous versions

The data in bold indicate the main case study that the paper draws on

In addition, observational studies were conducted in the diesel and jet engine companies by doctoral researchers in the research team. In the diesel engine company the researcher spent about 2 months on site over a period of about 18 months carrying out observations and interviews (Flanagan 2006); while the researcher spent 7 months in the jet engine company (Wynn 2007). The first author accompanied both students to key interviews.

Each interview was approached with a set of detailed questions, but interviewees were encouraged to speak freely. The interviews lasted between 30 and 120 min and were carried out in the premises of the companies. All the interviews were recorded and subsequently transcribed and analysed. Detailed analyses of the transcripts of key interviews were carried out by the first author or her colleagues, usually following a combination of grounded theory (Goulding 2002) and deliberate falsification of current assumptions (Stacey and Eckert 1999). During the interviewing period, initial impressions were discussed informally with some of participants who looked after the researcher. The results were presented back to the interviewees and their managers, initiating serious reflection within each company about the efficiency of their processes. The general findings were also discussed with senior designers and design managers from other UK and German companies.

All the companies involved in the studies design highly complex products and, with the exception of some of the consultancy projects and some minor change projects in the diesel engine company, all the projects involved significant product and process innovation. All the companies also pointed out that they worked to reduced time scales compared to similar projects only 5 years previously. While these companies do not represent a statistically significant sample, the authors have no reason to assume that they are not typical of design companies with non-repeatable processes.

The major difference between the companies in the studies is the size of their design teams and the familiarity that the team members have with each other. The most complex products studied were helicopters, aeroplanes and jet engines, where the complexity led to a compartmentalisation of the design process. In all three cases, sub-systems were effectively developed as independent products, such that the companies needed to put significant additional effort into co-ordinating the different sub-system teams and their plans. Conversely, diesel engines are simpler products, where individuals can maintain an overview of the entire product and can therefore solve problems and co-ordinate tasks in a different way. The automotive study involved a far smaller team of designers, who did not know each other very well, so that plans played a considerable part in pulling a diverse team together.

4 Common planning practice in industry

The activity plans that design managers use represent just a small fraction of the wide variety of plans that are used simultaneously in companies. Each company uses its own names for these plans, while the types of plans encountered were similar across all the companies that we have worked with or spoken to. For example, large companies generally use a stage gate process for their new product development processes—where some call this a “stage gate process”, others term it a New Product Introduction process, usually abbreviated to NPI process, and some just refer to it as “the process” using the word in its prescriptive sense. This is both a matter of perspective, as people who work in new product development refer to their process as the “the process”, as well as a matter of company jargon. While not all companies used the term NPI process, all the companies we have studied had stage gate processes for new product development projects.

As a result, the terminology used in this paper should be familiar, but may need to be mapped to the terms the reader is familiar with. This section will therefore try to use terminology in line with the process modelling literature as discussed in Browing and Ramasesh (2007). When designers were asked to show their process model, they provide a mix of different representations. There appears to be little coherence within companies or across companies—some draw process maps as flowcharts (by hand, in a document or slide show), but many show Gantt charts (drawn by hand or using project planning software). Some designers point to time charts on whiteboards; others have large printouts of Gantt charts on their office walls.

This section introduces the different plans used in industry, based on the case studies described in Sect. 3. It begins by describing the units of planning that we have observed. These units, which are related to each other, represent the basic elements of the different types of plans. In practice, people often use more than one plan and achieve coherence between plans by mapping between them as and when required. This section proceeds to discuss the relationship between the members of project teams and the plans they use, before classifying the plans as prescriptive or target plans. It concludes with a reflection of the different functions plans can carry out—sometimes simultaneously.

4.1 Units of planning

During the interviews and observations, designers and managers mentioned a multitude of different units of planning which they are concerned with. These are not independent and can sometimes be translated quite easily from one form to another. However, it is worth discussing them separately since they reflect the ways people think about planning at different times in the process.

4.1.1 Process units

Units of process planning fall into three types: time, resources and activities. However, these can be combined to form the actual units people think about:
  • Procedural milestones are typically derived from the official NPI process used in the company. Typically, these processes have six to ten milestones, each with checklists of requirements that need to be fulfilled and documents that need to be created. There is widespread awareness of procedural milestones, but for large projects these can lead to very coarse planning.

  • Freeze dates or lead-times for long-lead-time items critically influence the timing of a design process. People usually know the target delivery time and plan backwards to establish the latest time before which long-lead-time items need to be ordered. Design processes can be structured around a sequence of time points for freezing decisions; deadlines for ordering long-lead-time items are one type of freeze decision points. For example, in the automotive industry the schedule of style freezes is one of the most common ways to structure the design process.

  • Tasks for suppliers structure the design process since companies like to keep their supplier relationships simple. They therefore try to group the tasks that require interaction with a particular supplier, planning towards placing groups of orders.

  • Test schedules are a vital driving force since many products need to go through a predetermined testing program to achieve certification. Others require on-going testing as part of the design process. In most companies, testing resources (including equipment, consumables and people) are limited and designers need to book testing ‘slots’ ahead of time. Major delays can arise if these slots are subsequently missed.

  • Resources (including cost) determine what skills are available and affect when design tasks may be undertaken. At a high level, resource availability and the resulting costs are the main planning drivers.

  • Activities (including design times) are often used to plan processes on a detailed level. However, activities can only be planned to any level of accuracy over a fairly short time span because the activities undertaken in practice will depend on decisions made during the process. Activities can be broken down in many different ways and are often closely linked to the product components, for example, “design the dashboard”.

4.1.2 Product units

Units of product planning include:
  • Cost (including design time) is explicitly anticipated and planned. In particular, costs relating to the cost of externally purchased components can often easily be measured. Components designed and manufactured in-house may have the design time factored into their manufacturing cost, as well as the time required to integrate externally purchased components. However, some cost plans only look at the cost of parts. Design time, as such, is rarely factored into cost plans. In fact many designers complain that they are investing a significant fraction of their work time into changes for minor cost savings.

  • Bills of materials describe the parts that comprise the product. Many bills of materials are constructed as parts are purchased. This allows companies to keep track of the design process by the number of parts already defined. However, this can be misleading because the breakdown of bills of materials is typically very uneven. For example, in one company an engine was listed at the same level as a screw. For very incremental products, companies use generic bills of materials, and measure process through the number of components finalised.

  • Assembly/manufacturing requirements relating to the technology necessary to assemble components and the order in which they are assembled influences the financial success of a product. Hence, activities and lead-time planning can be combined to incorporate all the components and process steps required to manufacture the entire product or some its components. For example, an assembly plan may be defined for everything that is mounted to the chassis.

4.1.3 Quality units

Quality procedures such as ISO9000/2001 (Hoyle 1996) or Advanced Product Quality Planning (APQP 1994) drive the new product development process in many companies. They outline an auditable set of milestones, standards and procedures that the project and its documentation need to adhere to. These milestones are generic and often not tailored to the individual product or project.

4.2 Types of plan

In each company, we found many types of plan, however, as this study has concentrated on planning design processes and the challenges that are faced by design managers, we have not explicitly studied strategic plans or resource plans at an organisational level. The relationships between the different plans can be seen in Fig. 2.
Fig. 2

Types of plans and their relationship

4.2.1 High-level plans for a project

Each design process plan covered only one project, rather than a range of projects. Some were general procedures, for example, quality procedures or NPI processes that would be applied to any project regardless of its content or context. For each project, time and resources were assigned to generic process steps. These generic plans are on a very high level; the detail is filled in by specific plans, which concentrate on a particular aspect. For example, lead-time plans are presented in the context of NPI milestones, but only include lead-times. None of the plans viewed were suited to planning the integration of projects or assessing multiple plans in parallel.

The plans identified here are not independent from each other. As Fig. 2 shows, they can roughly be divided into quality plans, process plans, business plans and product plans. In some of the companies studied, we found prominent use of quality plans; however, these were completely isolated from any other form of plan and were pursued in parallel to other plans. Quality management was given a very prominent role by top management in the organisation, but was often seen as a burden by designers and managers. The champions of the quality processes were sometimes quality experts with little technical expertise. In other companies, quality management was integrated into the NPI process and people showed very little awareness of quality procedures.

Plans vary in the level of detail that they include. Process planning in most companies begins with making a business case for a new project. This includes rough estimates of time, cost and resources. Typically companies produce many business cases and only a very small number of them ever become projects, therefore their authors invest little time on each individual case and employ very coarse estimates. However, if a business case gets approved these values can easily become constraints for new projects, and can be viewed as a very general plan for a project. For example, the automotive project was planned around the details of the business case, which had been conceived with about half a day’s effort from each of its numerous authors.

Before starting a project, a time frame and target cost are determined. These are based on the business case or a slightly more detailed plan based upon a conceptual design. This time frame is used to work out the timing of individual stages of the NPI process, which typically includes a checklist of activities or documents that need to be completed for each stage. The gateways are set based on experience and legal or certification requirements. At an equally high level, a cost plan will be developed that determines the cost for a product’s main components. The gateways provide target definitions for other plans.

4.2.2 Process plans

Lead-time plans cover items that have long manufacturing times with suppliers. These items will be identified early in the project and decisions will be made as to how their development will be linked to the project gateways. Thus, the timetable for the activities of design teams and individuals are refined, possibly even by pushing the gateways. For example, the longest lead-time item in the interior of a sports car is the airbag, which takes 6 months to arrive. Given that both defining and integrating an airbag takes 1 month, the time frame for car interior is at least 8 months. Similarly, the longest lead-times on the fuselage of a small passenger jet are likely to be for the skins followed by the ribs and stringers—hence, the design of the skins must be completed first if the overall development time is to be kept to a minimum. Freeze schedules are very closely related to lead-time plans, but focus on the order in which key components are frozen, i.e. the time is set at which work on the component stops and no further changes are allowed (Eger et al. 2005). Beside lead-times, this is determined by platform consideration and an internal attempt to structure of process by fixing key interfaces and parameters.

At the same time, a testing schedule is worked out for the product, and slots are booked for test rigs. In most cases, this is fairly generic for the type of product, so that the spacing of later parts of the NPI process is largely determined by the test schedule. The allocation of time and resources for development of major components and systems is often planned around the major long-lead-time items and the testing schedule. These major task plans are typically represented using project planning software and included in project reports as Gantt charts. This enables the generation of resource plans for the entire project. It should be noted that the resource plans and the major task plans are not identical, because the resource plans are more fluid as people are moved between tasks according to requirements and availability.

The major task plans and the resource plans could be developed further into activity plans for individuals; however, activity planning often seemed to be much more ad hoc and short term. Activities were often only planned a few weeks ahead of time—a sensible response to the many unexpected developments within many design projects. Much of the typical day of many designers is taken up by day to day activities, such as replying to email, attending meetings or fixing problems that emerge, which would make accurate planning very difficult.

Much uncertainty in design is inherent and unavoidable. However, much is also the result of ill-considered planning. If problems occur in the process and gateways are threatened, designers and their managers go into firefighting mode. They generate short-term firefighting schedules. These involve an informal list of activities to be undertaken with little concern for other processes and their needs. Many designers we interviewed openly commented that they really enjoy firefighting with clear constraints and open rewards, yet at the same time they feel that firefighting should not be necessary. Firefighting can cause havoc with resource plans, because people are removed from previously planned activities and appropriated from other parts of the organisation.

4.2.3 Product plans

At the beginning of project development, the costing plan is drawn up which sets the overall cost of the product and includes target costs for the major components. This typically covers only the procurement cost of the parts, not the design cost involved in generating the parts, so that if the cost of an expensive part increases major redesigns are often requested to reduce the cost of other expensive parts in order to minimise the overall part cost, even if the design work can be costly and put the timely delivery of the project in jeopardy. Some companies see these cost plans as guidelines and are willing to exceed the costs slightly where necessary. Others are very rigid about their target costs, such that increased costs for one component would have to be offset against savings in others.

As the design progresses, the bill of materials for the new product emerges. While this is the result of a design process, it has been included here as a plan because some companies measure their performance against the bill of materials in determining what proportion of the product is defined at any stage. Other companies use old bills of materials as a starting point, providing a product breakdown, which can be used to inform activity planning. As the final bill of materials emerges, manufacturing experts can begin to generate assembly and manufacturing plans. Similarly, the emerging bill of materials and the lead-time plan are used to compile suppliers’ orders.

4.3 Owners of plans

The different plans exist to meet the needs of different people in an organisation. Many people are aware of and handle more than one plan at a time, as illustrated in Fig. 6, which relates plans to their owners within an organisation, highlighting the complexity of process planning. The figure uses generic labels as the division of roles and the job titles vary from company to company, but a similar pattern emerges in each case.

The solid lines in Fig. 3 indicate the main plans that individual participants, the thin lines reflect the additional plans used the individual. The dashed lines show the distinction between quality plans, process plans and product plans. There some kind of plans multiple instances exist, for example, there are multiple team leader and multiple engineers, who in turn have their own activity plans or fire fighting schedules. Other groups, such as logistics or configuration management, are not shown since although they also might use a version of the bill of material they are minor players in the planning of the design process.
Fig. 3

Plans and their owners

The figure illustrates quite starkly several key aspects of process planning in large organisations. In smaller organisations, the roles would overlap and therefore the numbers of plans an individual might hold would increase. For example, everybody is using more than one plan and most plans are used by more than one group of people. The project manager and the technical manager have the greatest exposure to different plans. However, this is partly because the process plans are highly interrelated and can only be used effectively when considered in the light of other plans. The project manager rarely has detailed knowledge of the activities of individual teams, whereas the technical manager needs at least some awareness and must also be aware of lead-times and testing. Only the most senior engineers are involved in overall cost considerations and have exposure to the business case. Team leaders and engineers might be aware of the costs of the parts of the system that they are associated with, but certainly not of other parts. The engineering director, who stands above a particular project, would typically be aware of the business case and the NPI schedule and would approve major milestones, but would not be involved in any details.

There is a marked division between the designers and their non-technical managers and other stakeholders in the company. The understanding that quality managers have of other plans depends on the individual quality managers. They have visibility of higher level project plans, but know little about the detail. However, testing schedules are highly relevant for quality control. Designers and design managers have very little awareness of the cost plans. Whereas the project manager and the accountant work together directly, the accountants have little to do with the technical content of the projects that they are assessing.

The involvement of manufacturing experts in the design process varies enormously between companies—some use ‘manufacturing aware’ designers, while others place manufacturing experts into the component design teams. However, all companies have specific plans regarding the assembly of individual components into products.

Quality plans appear to be quite isolated in most companies, where only higher management has a real awareness of them. Two companies we observed tried to use quality procedures as the main driver for planning processes, in both cases with detrimental effects. In one case, it resulted in a Byzantine schedule of meetings; in the other, most of the ‘planning’ was done retrospectively by adding amendments to quality plans once the work was completed or well in progress.

Figures 2 and 3 exhibit a complicated picture of plans and the relationships between them. However, in many ways, it is more interesting to see how many plans do not have an obvious link. Most striking is how little quality plans seem to be connected to other plans. Their units of planning do not decompose into other planning units. The owners of the quality plans have a certain visibility of the process plans, but much less so of the product plans. There is very little connection in the ownership of plans between product and process plans. While design managers had a certain visibility of cost models and the bill of materials, they showed little understanding of manufacturing and assembly plans. The same is true in the other direction: the owners of the product plans only had visibility of high-level process plans and very little understanding of the detailed process. Individual designers are very much locked into their own activities, which they can place into the bigger picture of the process, but they rarely talk about product plans or the more managerial process plans. Quality plans have little impact on their lives.

4.4 The function of plans

Plans have a number of different functions which influence the selection of the units of planning and the types of plans that individuals generate. Plans are generated with one primary purpose in mind, but can serve different functions during their life span in an organisation.

Plans can carry out the following basic functions as illustrated in Figs. 2 and 4. They can simply be a list of tasks that need to be carried out, or operate as a checklist. For example, activity plans for individuals or quality plans can fall into this category. Other plans provide an order of tasks without specifying a time—they do not have to specify an exact sequence, but indicate which tasks would have to precede others. Other plans, such as classical Gantt charts provide a timing of tasks—showing when tasks need to start in addition to defining a sequence. Conversely, a lead-time plan or a freeze schedule has times associated with tasks but no explicit notion of ordering tasks.
Fig. 4

Functions of plans

Another function of plans is to show high-level targets, as a business plan might do, or provide specific goals, such as a bill of materials or a cost plan. A gateway process might also provide goals for the designers to plan to and targets that they are monitored against. Of increasing importance, as process risk assessment and process accountability is becoming more important, is the role of plans as records of the design process.

In summary, we can differentiate between:
  • Prescriptive plans tell designers what they should do and how they should do it, enforcing the order or the timing of plans—these plans are specific and forward looking.

  • Goal and monitoring plans tell designers what state they must reach at what point in the design process, without telling them how they can reach them—the same kinds of plans are also used for monitoring progress.

  • Recording plans are used to record what has happened during a project—such plans are sometimes adjusted retrospectively to capture the actual development of the project.

Many companies work out an official ‘process’ that they would like projects to follow for each kind of project. These ‘processes’ are a type of prescriptive plan that the designers are supposed to follow.

Many plans have more than one function at the same time, as illustrated in Fig. 5. Activity plans for individuals and major tasks plans typically seem to list the tasks only, without prescribing a sequence in which they are carried out. Lead-time plans, resource plans and testing plans are schedules that indicate the order in which events will occur rather than the way in which they occur. Firefighting plans are drawn up to fulfil a specific need and can be lists or sequences of actions.
Fig. 5

Structure of plans and types of plans

The NPI schedule is typically a series of gateways that prescribe what ought to have been achieved by the time the next stage can be reached, but do not provide sufficient details to indicate the details or sequence of tasks. Cost plans measure the current intended cost with no indication of how this could be achieved. Similarly, bills of materials track progress, but do not identify tasks. Suppliers’ order schedules set goals for minor components to be ready for ordering; and an assembly plan is typically an operation schedule.

4.5 Observations

The presence of a multitude of plans can be very confusing for designers and leads to potential for misinterpretation at higher levels of the organisation. Nonetheless, the plans work in many projects, because individuals have access to more than one plan and understand the relationships between them. For example, the technical manager may be conversant with the testing schedule and the major task plan and therefore can consider the implication of a delay in testing for the overall design process, or the effect of a design change on testing in another project, even though these connections are never made explicit.

No two individuals fully share an understanding of the process, and hence individuals make assumptions about plans that others do not share. Often the plans themselves are not available to many people in the organisation—they are discussed, but cannot really be critiqued. For example, a team leader might be unable to understand the cost implication of a design decision, because they have little knowledge of restrictions on the overall cost budget.

5 Variations in planning practice

Companies work out strategies to cope with the planning practices and obligations that they have. In this section, which draws on our wider case studies, we discuss some of these coping strategies to draw attention to them, should they be important in other companies, and to discuss the wide ranging impact seemingly small factors have on planning behaviour as a whole.

5.1 Miracle boxes

One company we worked with adopted the approach of the “miracle box” (Flanagan 2006). These were high-level tasks that were identified at the beginning of the design process, without the company having worked out how to achieve the task goal in a given time. The company knew that they only had a certain amount of time to develop an innovative solution; hence they allocated their best people to the task and proceeded with planning the rest of the process in more detail. Only once the design process had started, and they knew more about the project that they were carrying out, did they work on planning the tasks in the miracle box. This enabled them to plan on an abstract level and to postpone detailed planning to later. Such an approach locates process risk within certain tasks, making the rest of the design process more predictable. Miracle boxes enable companies to generate partial plans for the whole process without the critical task and also for the miracle box in isolation from the rest of the process.

5.2 Postmortems

Companies rarely have time to reflect about their processes once they have been completed, even though many individuals would like to do so. Those who do conduct postmortems tend to concentrate on lessons learned regarding the product, for example, materials, or technical aspects of the process, such as testing procedures. No company we worked with did a systematic design process evaluation. While it is relatively easy to assign blame for process errors to individuals, a “no-blame culture” often prevents companies from doing this and learning from the results. Equally, when people know that a process was successful, they are likely to spend little effort to learn from their experience.

The variety of plans makes it difficult assess how well the project has been carried out. If success or failure is to be measured against a plan, which plan should the project be reviewed against? Often companies know how well they did compared to the NPI process, because that is the focal point of on-going assessment. However, other plans are less easy to review. For example, how well a lead-time plan fares depends on detailed operations in the supply chain working well.

What seems to be even rarer is companies comparing the plans against the project. If there is general agreement that the project was successful, but did not meet the NPI or major task plan, the question of whether any of the plans were faulty is rarely investigated. In all companies, engineers and planners have complained to us that the company did not learn from planning mistakes in the past, yet none of the companies had a thorough lessons-learned system in place.

5.3 Budgeting, estimating and time booking

In most companies, it is necessary to book time to specific budgets. How this is handled and the units of bookable time influence enormously how the companies behave. We worked with one company where designers had to book their time first by the half day and later by the hour, filling in a form at the end of the week. However, they could only book against an approved project. The booking option for work outside of these projects was by booking to “unproductive time”—not surprisingly nobody did this. The designers had to find another project against which they could book to develop new project ideas. Some project leaders accepted this, while others refused any booking to their projects. Individuals also varied in how willing they were to help out colleagues for short periods of time, particularly when they cold not book to that project.

Projects were planned in accordance with the hours it would take a certain type of resource to undertake the task and progress was monitored by the hours that were booked to the project. However, the effect of the hour booking system was that some projects under spent while others overspent. There was very little understanding in the company of how long the projects really took, and in consequence, many plans in the company were drawn up retrospectively.

Many plans include time estimates, the accuracy of which depends very much on the time units used for planning (O’Donovan 2004). Some companies plan in hours, others in days and some in weeks. The smaller the units of planning, the more likely the predicted figures are to be wrong. However, companies that plan in larger units are afflicted by the effects of rounding inaccuracies—a task that takes 22 h might be rounded to 3 days (2% error) or to 1 week (70% error) depending on the unit used. These errors are cumulative and project managers have very little visibility of the actual time people spend on the task.

5.4 The role of the planning team in the organisation

All the companies we have worked with have a dedicated person or team who monitors the progress of plans. However, there seems to be significant variation in the power and seniority of the members of these planning teams.

At one extreme, the planning team comprised two highly experienced project planners, one of whom had worked his way up from an apprentice engineer and had 20 years experience. He was respected within the organisation and worked closely with the project manager and the quality manager, putting plans together and monitoring progress. He regularly prowled the engineering office checking on the progress of engineers, asking them how they were getting on and requiring explanation when the project was not up to the requirements of the NPI process.

At the other extreme, the planning office consisted of new recruits or people with business degrees, whose task was to put together major task plans from the team leaders and monitor the project from weekly booking sheets. They only talked infrequently with the engineers and did not visit their offices to demand explanations when targets were not met. Team leaders were required to write deviation notes whenever they deviated from the plans. The problem was that the planning office people were in no position to judge the explanations of team leaders.

Planning is very different in the companies where it is seen as part of the quality control process. Since the quality procedures pay little attention to how design is actually carried out, design planning was not well supported.

5.5 Fashionable methods used in the company

Several companies we have worked with have made considerable efforts to introduce specific methods, which in turn influence the way people plan and think about processes. The automotive company aimed to introduce APQP as a quality procedure across the entire organisation. They structured their processes according to APQP principles, which paid very little attention to the detailed requirements of the design process; however, the method put great emphasis on cross-functional meetings to agree on design decisions. Hence, the entire process was planned around a proliferation of such meetings.

Another company was a strong advocate of Six Sigma, which had two distinct effects on the organisation. They tried to improve their design processes through the focussed application of Six Sigma projects. For example, they would define a Six Sigma project to plan a specific project, or to improve communication within a specific project. In consequence, the Six Sigma projects paid less attention to the overall success of the organisation compared to the success of the individual project, for example, by utilising the best possible resources, even if other projects suffered. The other effect was a strong bias towards measurable criteria, which might not always capture the factors that are pertinent to planning.

6 The challenges of planning in industry

The focus of this paper is on the planning of the design process at the level of project managers and team leaders. It is they who have to identify, coordinate and monitor the design tasks and manage the risk within the design process. This section reflects on some of the challenges and problems that they repeatedly mentioned during interviews and discussions.

6.1 Achieving the right overlap between tasks

In designing a complex product, there is inevitably information dependency between tasks, whatever their level of description, and ideally, one task would be completed before the next task is begun. For example, the load cases would be fully defined before the stress analysis is initiated. However, many tasks have mutually dependent information requirements, where the input of one task is the output of another task and vice versa. The temporal order is ideally constructed based on underlying dependencies between tasks, i.e. task B cannot start until task A is finished, because task B requires information or resources from task A. In complex projects, these dependencies can be difficult to see and companies rarely invest time in investigating them carefully. Therefore, customary sequences and overlaps of tasks are rarely questioned. For example, testing procedures often follow a prescribed order without questioning the decision dependencies for a particular product.

To reduce the duration of a project, the overlap between tasks must be optimised. The person starting a task must have sufficiently robust input data to start the task while minimising the likelihood of rework when the final input values are provided when earlier tasks are completed. To enable tasks to overlap, designers need to work with estimates of input data until better values are known, and project managers must make assumptions about the accuracy of specific design data to derive the best structure for the process. Their aim is to find the optimal overlap of tasks, as illustrated in Fig. 6.
Fig. 6

Overlap of tasks

6.2 Expressing task dependency

To indicate dependency a Gantt chart, this is typically displayed as an overlap between tasks (as in the bottom row of Fig. 7). While it is possible to draw arrows to show dependencies explicitly in some planning software packages, engineers often conceptualise dealing with dependency as a period when groups of people have to work together, or one person has to take two viewpoints. The semantics of overlaps can be ambiguous, because an overlap may indicate the ability to carry tasks out in parallel or the need to do them together, while a non-overlap may indicate a dependency or be the result of resource limitations without a particular relation of the tasks.
Fig. 7

Task dependency in Gantt charts

This can pose problems for designers putting plans together. For example, we observed a planning meeting for a small project, where a senior engineer had asked a younger designer to draw up a plan. The young engineer arrived with a typical Gantt chart, as shown on the left side of Fig. 7. His boss complained that the tasks will never be quite finished and that he therefore should taper the boxes, as in the middle diagram. When the young engineer pointed out that he could not display this using the current choice of project planning software, he was instructed to draw each task for the duration of the entire project, as in the right hand diagram of Fig. 7. When he returned with a chart with many parallel bars, his boss was satisfied. Yet the chart had become nothing but a checklist and lost any temporal meaning.

While this is an extreme case, aspects of this kind of behaviour can be found in many companies. When somebody views a Gantt chart, they do not know what the overlap of the tasks means and how individuals have resolved the limitations of the representation—the same situation might be displayed by one person as a short overlap while others would show it as long parallel tasks.

6.3 Processes awareness amongst designers

All design managers complained bitterly—with some justification—that their designers “only ever want to get stuck into designing and not worry about processes”. They want to keep designing until they are satisfied at every stage rather than provide a sub-optimal but sufficient solution to meet cost targets or deadlines. In one company, this was referred to as the “Concorde design syndrome”. Individual designers, as opposed to their managers, often have little awareness of the overall process that they are involved in. They typically only consider the part they work on or the sub-system it belongs to.

Companies succeed to some extent in educating their employees about processes; however, these are often the quality processes that are required to get ISO9000 accreditation. Designers, in general, generate plans for their personal activities but they often resent the constraints that process plans place on them, especially when they feel that they have not been consulted about the scope of their tasks or the way they want to undertake them. The problem with this is that companies find it difficult to get designers to commit time to planning their activities and, in particular, to provide accurate financial estimates for tasks.

6.4 Partial understanding of processes

Any understanding of complex design processes is almost inevitably partial. The sheer amount of knowledge that is ideally required to plan a complex design process in detail is huge. Individual designers generally only understand a part of a particular process, since most carry out similar tasks in different design projects and know what they are likely to have to do to carry out their job. They know where their information is likely to come from, where they can get it if this fails, and whom they need to give the results of their work to. They also have a sense of the number of iterations they typically have to go through to reach their goal.

Process planning requires knowledge in two complementary areas:
  • Technical knowledge about details of the product—these dictate the tasks that will have to be undertaken to design the product and how unexpected interactions between parts can affect these tasks.

  • Organisational knowledge about the ways in which the particular organisation procures and manufactures a product—these dictate the tasks that will have to be undertaken by the organisation and the constraints that will be imposed upon the design process by the proposed manufacturing processes.

Individuals exhibit a certain bias in what they know. Technical experts understand very well the components and systems that they have personally worked on or contributed expertise to, while their technical knowledge of other areas is likely to be far more superficial (see Eckert et al. 2004). Jarratt et al. (2004) argue that very few designers have an overview of the entire product, and report on an experiment which found that experienced designers missed fundamental links between components (such as control links), if they were not thinking about these links regularly.

An understanding of the overall process of designing a product from conceptual design to delivery, through service to recycling, can only be gained—according to many senior engineers—by having experienced the entire life cycle of a design (at least once), which can take ten or more years with complex products. Often the pitfalls are only encountered and recognised when designers have seen more than one process. Understanding of processes depends on experience and expertise which is difficult to gain in a short space of time. This puts those companies who are losing experienced engineers under great pressure because less experienced people are not only struggling with the technical aspects of a design, but also the planning of the design process (Flanagan et al. 2007).

This lack of understanding of the processes across an organisation also makes it difficult for managers to communicate the design process. They resort to verbal explanations or draw process maps or Gantt charts, at a level of detail that conveniently fits on a sheet of A4 paper. These ad hoc representations are often necessary, because the official plan be can fairly impenetrable. In one of the observed companies, the official process Gantt chart contained approximately 10,000 lines. Only a fraction of these could be shared with designers at any particular time.

6.5 Obtaining time estimates

For managers, estimating development time is very difficult without understanding the design problem in detail, which is not always possible. Managers are also suspicious about time estimates from designers. Some feel that designers often overestimate the time they need, but when they are pushed on time still deliver very good solutions. Subsequently, reducing design time estimates by up to 75% of the original time estimate does not worry some process managers. Others found that especially inexperienced designers underestimated the time it takes to complete a task by up to a factor to three. One of the challenges of planning is understanding the very personal nature of estimates.

In most companies, designers are not rewarded appropriately for providing accurate estimates for planning. Consider, for example, two designers who provide estimates for the same task that—as it turns out later—takes 3 weeks. When one designer estimates the task will take 1 week and the other estimates 3 weeks, the first is initially praised for planning to do it quicker. When they are not finished after 1 week, they can develop a rescue plan, which would get them back on target, possibly at the expense of other tasks. However, they still get praised for finding a way to complete a problematic task. The second designer just gets on with the task and rarely gets praise for doing exactly what was planned. While real projects are rarely as dramatic as this example, overcoming this underestimate-and-rescue culture is a major challenge in many companies. However, this is a manifestation of the prevailing firefighting culture (Bohn 2000).

6.6 Contingencies

Design processes seldom go entirely to plan, resulting in delays or increased costs. To acknowledge this possibility, plans must include some slack on contingency. There is a danger that each person on each level of planning put in contingences to cover their own iterations, so that the contingencies would be put in multiple time and thus be far too high. To avoid duplication of contingencies, the automotive project we observed adopted an ideology characterised as “no time for error”, and most people claimed that no buffer had been included. However, the vehicle architect admitted to having included time for design iterations in the original time estimates for the business case without ever making this explicit. The problem of contingency planning is amplified by the difficulty of gaining accurate time estimates from engineers and the desire of many engineers to refine their solutions. Therefore, the process managers really need to have their own understanding of time requirements.

7 Discussion

Planning is vital to understanding the process by which a project is carried out and to co-ordinate the activities that need to be performed This is usually not a task that can be carried out by a single individual, but something that needs to be undertaken by the entire group. In all but very simple products, individuals’ understanding of the product and the process is partial. They understand their own area and, to a lesser extent, those that are adjacent to them. They know much less about issues that they are not directly concerned with. This applies at all levels of an organisation and to all roles. Chief engineers know their own product, but know much less about the projects of their chief engineer colleagues. Team leaders look after their own teams, and maybe know about the work of other teams they work closely with or that are located in close proximity. They know little about teams that they have little to do with. Perhaps the starkest example of this is the lack of mutual awareness between control engineers and mechanical engineers, which we have observed in several companies, because companies often sub-contract the development of control software, in one case to the other end of the world in New Zealand, or introduce a system group as a go between. Similarly, our studies have shown a lack of mutual understanding between the engineering functions in an organisation and the people who are responsible for finance and manufacturing.

Planning works to the extent that it does work, because a sufficient number of people have an understanding that goes beyond their own roles and their own main plans. Typically, only a few people have key integration roles, such as chief engineers and integration experts who are specifically assigned to tasks involving multiple systems, such as noise experts. Many companies are undertaking organisational measures to increase the synergy between different component or functional teams. For example, manufacturing engineers are increasingly located in design teams or at least invited to early design meetings. The main motivation for this is the avoidance of design errors, but it also has a beneficial effect on the visibility of plans.

One of the obstacles to integration of different plans and thus effective process planning is the difficulty of expressing any form of plan. Unless the plans are on a very high level, such as an NPI schedule, they are usually complex and involve many interconnected elements. In an extreme case, the Gantt chart for a complex engineering product can have over ten thousand lines. Even the activity list for an individual component can encompass many entries. One way to cope with this is to abstract plans, as it is manifested in the hierarchy of details between NPI schedules, major task plans and activity plans. Another approach is to concentrate on certain aspects of an overall problem. For example, lead-time plans only highlight the time when a design needs to be handed over to a supplier. Fire fighting schedules are also a response to the need to break complex problems down in understandable chunks. They only include those tasks required to meet a typically short-term goal and ignore issues pertinent to other goals or other projects. Fire fighting is as much a cause for other problems as it is a solution to the problem at hand.

Process planning is hampered by the difficulty inherent in expressing plans. The modes of representation largely fall into two categories: plans that are drawn in a hoc fashion and those drawn in commercial software packages. These informal plans are often only scribbled down on a piece of paper, but sometimes designers spend huge amounts of time drawing them neatly in a presentation package or as a spread sheet. Having spent all this effort to express a plan, they are reluctant to change it. For example, the APQP quality plan had been beautifully drawn on an A4 sheet of paper with tasks neatly aligned in rows and colour coded lines between them. This not only dictated the order of the tasks and the degree of connectivity highlighted in the description between, but also made the designers very unwilling to include changes in the plans. Commercial planning packages on the other hand enable designers to draw plans quite easily, but very much dictate the way designers have to think about plans. Typically, it is very difficult to annotate a computer-generated plan in any storable or reproducible way; and the core functionality of the programs cannot be changed, as the example of the tapered ends of tasks shows. But, maybe more fundamentally, the notation influences the way designers think about processes. If they cannot express iterations in a plan, they might not think about how likely they are to iterate a task. If they cannot slowly fade out a task, but have to develop a strategy for deciding when they consider a task finished for planning purposes.

The difficulty in expressing plans and the difficulty in reading plans, which are either very large or drawn up by particular groups for their needs and in their style makes it very difficult to negotiate the content of plans. Planning is often considered a nuisance. Designers therefore often do not want to discuss plans, and it also very difficult for them to do so. They cannot easy check their own task and question their relationship to other plans. This makes it difficult to challenge time allocation and task orders. A discussion of planning would be a way of generating a shared understanding of processes. This is a major problem in design processes, as so many plans change their role from a behaviour plan to a monitoring plan. When designers provided information for a plan, they might have submitted their best guess of what they are planning to do, but find that even though the problem has changed in the meantime, they are still monitored against this initial plan. Plans should be able to evolve with the changes of the problem, as uncertainties unfold. However, these changes are often not reflected in the plans, or at least not in a coherent traceable way across the different types of plans. The relationship between planning behaviour and monitoring behaviour is a difficult one, as processes can be speeded up, by putting pressure on people through a target schedule, but at the same time, the monitoring targets need to be realistic to be meaningful.

Current planning tools do address the need for industry to express and evaluate design plans. They support the predominant paradigm of Gantt and Pert charts adequately, but do not push improvements beyond this. Designers need support in identifying the tasks they have to carry out and when thinking through the logic of their processes. They need concise ways of visualising design processes and appreciating their properties by looking at the process plans. They want to play with a plan and explore the behaviour of processes to understand what might happen if they change a task or allocate new resources. Companies are under increasing pressure to assess the risk of design processes to provide their customers with risk estimates of project duration and cost.

These issues are being hotly discussed in the design process research community, but robust solutions have not yet reached the market place. As outlined in Sect. 3, the DSM community is using matrix-based displays of processes to identify dependency loops in tasks which could lead to iteration, and to find ways to tear the dependency of these tasks. While this is a huge step from Gantt Chart displays, a DSM still contains little explanation about how tasks are connected. Signposting-based models, such as P3 (Wynn 2007) are modelling the connectivity between tasks through parameters and qualifiers indicating the nature of these links. These models can be described in flowchart-like displays that can be generated automatically from task and connectivity information.

However, these tools are more knowledge intensive than conventional planning techniques. They require considerably more data and a far deeper understanding about the nature of these processes. Companies need to commit themselves to building these detailed models on a large enough scale to capture an entire design process or at least a meaningful subset of a process. By investing in detailed design process, modelling companies can gain far more than just better plans—they can also obtain a greater understanding of their processes. Detailed process models could serve many additional purposes, by becoming boundary objects, i.e. objects that can be understood by several groups with very different backgrounds (see Star 1989, Bucciarelli 1998), which allow a negotiation of processes amongst team members; or communication maps (see Flanagan et al. 2005), which show the flow of parameters through a process. They could also function as risk assessment tools, to identify weak points in processes and calculate the overall process risk or become a means to assess a trade-off between process and product quality (see Flanagan 2006).

8 Conclusions

At the beginning of this paper, the Collins English Dictionary was cited as saying a plan is a “detailed scheme, method, etc. for attaining an objective”. This paper has argued that within the same company a number of different plans will exist and be used by many different stakeholders. Many descriptions, such as quality procedures or product descriptions, serve as a kind of plan for people who interact with them. No company was found to use a unified process plan that covered all aspects of the different types of individual plans. However, coherence was achieved between the different plans through the people that used them.

Senior people in an organisation juggle several different plans at the same time. They translate and synthesise information from these plans on an ad hoc basis as part of their regular decision making. In an uncertain environment like design, plans are subject to many changes and are bound to be at least partially inaccurate. The same plans can carry out different functions at the same time or over the course of a project. Even as a plan is rendered inaccurate, it can still be useful.

At present, many companies design highly successful products without fully understanding the process that they need to go through or in practice undertake. Their processes are highly iterative and depend on the enthusiasm and expertise of the individuals involved. They often succeed in spite of their plans, not because of them. As development times become shorter and design and production locations fragment geographically, more and more pressure will be put on the design and development processes. Hence, process plans will play an increasing role in dividing and co-ordinating the work. This research represents just the beginning of a wider study of planning practice. It has taken a high-level view to characterise the multiplicity of the phenomenon typically referred to as planning. Further work is now required to research more detailed questions, such as (to name but a few):
  • How do people make decisions using plans?

  • How do people reason with information from multiple plans?

  • What roles do individual plans play over the course of a project?

  • How do the properties of the product influence the plans with which they are generated?

  • How do the properties of the plans influence the products they are generating?

This paper has sought to describe how planning is currently undertaken in industry. However, the research has been carried out with the view of trying to develop tools and methods to improve design processes and enable companies to design better products faster.



The authors wish to thank the UK Engineering and Physical Sciences Research Council (grant GR/R64100/01) for funding this research. We are indebted to the numerous designers we interviewed and also the designers and design managers with whom we discussed our findings. We are very grateful to David Wynn, Tomas Flanagan, Martin Stacey and Iestyn Jowers for commenting on earlier versions of the paper.

Copyright information

© Springer-Verlag London Limited 2009