Managing between the gates of product development Model design to manage product development processes

(1)

Managing between the gates of product development

Model design to manage product development processes

●●●●

A. Biewenga

1270524

Amsterdam

July 2007

●●●●

KLM Royal Dutch Airlines, Schiphol

Drs. P.G.C. Slingerland

Ir. F.H.A. van Halteren

●●●●

Rijksuniversiteit Groningen, Groningen

Ir. F.B.E. van Blommestein

Drs. D.J. Schaap

(2)

The author is responsible for the contents of this thesis; the copyright of this thesis rests on Aico Biewenga

(3)

‘Innovation is… about maintaining the

highest rate of change that the organization

(4)

Abstract

Models representing the product development process include the stage-gate model, innovation funnel and the phase review model. These models have been designed to improve the process of new product development.

This research discovered these models do not always sufficiently support the need to manage the product development process. Especially, organizations with a heavy complex logistical supply chain network fail to manage their product development process. The reason is that parallel processes causes that stage-gates are too far apart to be able to manage the process.

This research designed a model that is in some ways similar to function point counting; a method used in software development. The designed model cuts the product development process in controllable peaces and uses functional attributes of activities to determine the duration of the process. The functional attributes of activities can be classified in: logistical factors, strategic factors and product factors. The factors are used to determine the duration of different activities and thereby the total duration of the process.

This method is used in the development of the PM-Planner: a planning and controlling tool, which reveals critical paths, plans the individual activities for the involved departments and has an ability to learn from historical product developments.

(5)

Prologue

The title of this thesis is called: managing between the gates of product development. The gates have a double meaning. In the first place they refer to stage-gates systems; a widely used method to control product development processes. The second meaning refers to the gates at an airport; a symbol for heavy logistics. Although this double meaning seems so perfect, the fact is that product development and logistics are quite a paradox. In the past eight months I believe I have, for greater part, overcome this paradox in my research and the result lies here before you.

One of the things which cannot be read in this report is the joy I have had in conducting this research at KLM Royal Dutch Airlines. The six months at KLM were very educative and pleasant. I would therefore like to thank the people who made this possible.

In the first place I would like to thank all the people of KLM and her suppliers who enthusiastically have cooperated on this research. Without their investment of time and effort it would have been impossible to conduct this research. Hereby, I want to give my special thanks to my supervisors Peter Slingerland and Frank van Halteren for their excellent guidance.

Besides my supervisors at KLM I also want to thank my supervisors of the Rijksuniversiteit Groningen for their interest and valuable feedback. Without the feedback and support of Fred van Blommestein en Dick Schaap this report had never had gotten its current shape.

Finally, I want to thank my parents and my sister for their dedicative support during my study. They have laid the foundation for an amazing study period, in which this report is its final chapter.

Aico Biewenga

(6)

Chapter 1: Motivation and management question

This first chapter starts with a brief motivation for the start of this research, in which the management question unfolds. This management question can be seen as the initial starting point of this research. The question is placed in the context of KLM Royal Dutch Airlines as case example. This chapter concludes with the research design to give an impression of the build-up of this research.

1.5 Motivation

‘Products and services are the sine qua non of a firm; without products and services to offer, a company has no reason to exist. Customers purchase a firm’s products only when they find those products to be the most effective in meeting their needs. If a company is to be successful (or even stay in business), its product must be more valuable to their customers than other alternatives. Therefore, new products are truly the lifeblood of a company’s long-term economic existence’ (Wilson et al., 1996: 3). This underlines the necessity of new product development.

‘Many New Product Development (NPD) projects are inherently complex, making effective management of the tasks, resources, and teams necessary to bring new products to market problematic. Typically, product development concerns all activities which facilitate the transformation of a market opportunity into a product available for sale’ (Krishnan and Ulrich, 1997).

Organizations that cope with a complex logistical supply chain network have extra difficulty to manage the product development process. The reason is that activities have to be planned way in advance in order to smoothly transit in the supply chain network.

For example, a world wide release date of a new product or service brings along great complexity in the logistical supply. Because it is not just a product what needs to be released, also things like: commercials, advertising, retail instructions and additional products etcetera. Therefore, different internal and external departments need to plan and align all their activities to achieve a smooth implementation on the release date.

(10)

With such a close link between product innovation performance and the organization’s overall success, managers and decision makers must ensure that this process is well managed (Cormican and O’Sullivan, 2004).

1.6 Problem description KLM Royal Dutch Airlines

Since the upcoming of low cost carriers airlines, competition in the airline industry has drastically increased. Airlines are looking for new ways to differentiate from its competition. KLM Royal Dutch Airlines considers passenger appreciation as one of the main driving factors to establish (re)purchasing. To foresee in passenger needs, rapid product development is seen as a necessity.

The product development in this case, is the development of products given as a service on board of the airplane. It involves products like, cutlery, hot towels, napkins, meal boxes, trays, drinking glasses, food, beverages etcetera. The diversity of those products is very high, for there are over 400 products varying from a napkin to an entire “tray concept” including a meal box, cutlery, food, beverages and drinking glasses. See figure 1.1.

Due to the high kerosene prices, one cannot afford to load everything on board at Schiphol Airport. A lot of the products are shipped to outstations, where external caterers bring the products on board. These caterers need instructions how to load the products in the trolleys and into the different airplane types. Caterers use the loading instructions to plan resources and materials. Also every three months different food is brought on board, which makes it necessary to visit the 40

(11)

outstations to organize food presentations. These are just a number of examples which illustrate the complexity of the logistical supply chain network KLM is in.

For new products and services it is vital that the implementation smoothly transits in the logistical supply chain network. When transition doesn’t go as planned, the costs to repair are considerable, because a lot of logistics have already been set in motion and new products and services can easily cause disturbance in the supply chain. Because of the high competition, extra costs should simply be avoided at all times.

In organizations, like KLM, where the lead-time of product development goes hand in hand with the restrictions of its complex logistical network, it is more difficult to reveal the possibilities for lead-time improvement of product development.

Beside the disadvantages this supply chain network gives for her product development, it also has a benefit: one can/ must calculate backwards. This means that when the implementation date is set, also the timing of the activities is set.

This might sound obvious and therefore simple, but this is not the case. Each and every (internal and external) department uses their own expertise for each new individual project to give and estimation of the duration of their own activity. Yet, most of the expertise is not cross-functional; therefore it is hard to give estimation when departments have to start their own activity.

Activities owners that are at the end of the process can make the best estimation when the activity should take place and how much time they need to complete the activity. On the other hand, exactly those activities will be the victim of bad planning or delay of other activities, because the end date is simply fixed. Especially the activities at the end of the product development process must gain the time what other activities have lost (which most of the time results in considerable higher costs).

Another problem of non cross-functional expertise is that activity owners in the beginning of the process do not feel the urge of time-management, because they do not see the effect of their own delay or bad planning. Simply, because of a lack of

(12)

knowledge if their activity is on the critical path of the product development process and what time is necessary to complete the other cross-functional activities.

KLM lacks a good process overview which is applicable to multiple product developments. The reason is that there are a lot of different kind of product developments, which makes the process very diverse and therefore hard to catch in a generally accepted process overview. Due to the diversity of product developments KLM was never capable of making a good estimation of the total duration of her product developments.

1.7 Management question

Air France KLM’s pursue of establishing a higher passenger appreciation, unfolds itself into a desire to shorten lead-time of product development. KLM wants an overview of her product development process and likes to know what the possibilities are to reduce lead-time of her product development process, taken into account the boundaries of her complex logistical supply chain network.

1.8 Research design

The design of this research consists of three research phases, the phase of diagnoses, the phase of design and the phase of validation.

Research design overview:

Diagnoses Chapter 1: Motivation and management query Diagnoses Chapter 2: The reflected system

Diagnoses Chapter 3: Product development process Diagnoses Chapter 4: Restrictions stage-gate systems Diagnoses Chapter 5: Research goal

Design Chapter 6: Function point counting: the similarities Design Chapter 7: Methodology for the model design

Validation Chapter 8: The working of the tool Validation Chapter 9: Validation

(13)

Chapter 2: The reflected system

As the initial management query is presented, the second chapter explores the system involved. It is necessary to define the system, because the function assignment of the system reveals the boundaries of this research.

2.1 The reflected system

KLM Cabin Inflight Management (CIM) is the business unit within KLM Royal Dutch Airline responsible for continues delivery and development of services given on board of the airplane. KLM CIM is a business unit which is organized in several departments. These departments involve Planning, Product Management, Contract Management, Loading & Ordering, Communication, Accounting & Control and Procurement. The main task of the departments is to keep the business running, wherein Product Management is the project leader for the different product developments. For an elaborated overview of the organizational chart see appendix A.

Organizations and departments are no systems, but can be seen as one (De Leeuw: 95). This known fact brings along, that Product Management can be seen as a self-functioning system. However, also Cabin Inflight Management (CIM) can be seen as a self-functioning system. In this last example, Product Management is a subsystem of Cabin Inflight Management.

The reflected system is dependent on the aspect one likes to do a research upon. Because the kind of relations, which are going to be secluded, determines the aspect that one likes to examine. The remaining relations are placed out of the scope of the research (In ‘t Veld, 1994:17). The aspect that has been put forward in the initial management query is the product development process.

Furthermore, the aspect system is a subsystem of relations within the system in which the all the element remain unchanged (In ‘t Veld, 1994:17).

Product Management doesn’t cover most of the relations within product development, because most of the activities relate outside Product Management. On the other hand, Cabin Inflight Management does cover most of the relations of

(14)

product development. Hence, Cabin Inflight can be seen as the reflected system and Product Management as a subsystem of Cabin Inflight Management.

A system has two clear characteristics: there is a collection of self-functioning elements and there is a structure of relations between the elements (Nieuwenhuis, 2003). Figure 2.1. Clearly reveals that this is the case for Cabin Inflight Management: There are different departments and relations between these departments (For an extensive overview, see appendix A). Besides the internal elements and structure, one can also point out relations outside the system. These elements give shape to the relevant environment. Within the aspect of product development at KLM the relevant environment is shaped by the following elements:

• Marketing

• Suppliers

• KCS (Caterer)

• Passengers

2.2 The function assignment

Every system tries to achieve something in its environment. What the system wants to achieve is mentioned as the function assignment (Nieuwenhuis, 2003). At Cabin Inlfight Management the function assignment is transposed into its mission statement:

• To develop and deliver a reliable KLM inflight experience that meets the passengers’ expectations at competitive cost

(15)

Out of this mission statement five functions have been defined, that Cabin Inflight Management wants to accomplish:

1. Specify, buy, ensure and evaluate the delivery of the full inflight product, based on the product strategy of Marketing

2. Generate revenue through (inflight) sales 3. Guarantee cabin safety

4. Manage the catering supply chain and cabin crew flight process 5. Organize the necessary crew products

The product development process has impact on the first function, because the foundation of this first function is laid in the product development process. The process of product development is therefore linked with the accomplishment of the first function of Cabin Inflight Management: to specify, buy, ensure and evaluate the delivery of the full inflight product, based on the product strategy of Marketing.

This function must be placed in the context of an element of the mission statement “at competitive cost”. The reason of emphasizing this element is because Cabin Inflight Management is a cost centre, which is budget driven.

The reason why this function is so important is because improvements in the product development process may never be at cost of the function assignment of the system. Hence improvements must always be placed in the context of the primary function of the system.

2.3 summary

The aspect product development determines, for most part, the reflected system of the research and is linked with the function assignment, the last mentioned is what the system wants to achieve in its environment. For KLM this implies that Cabin Inflight Management is the reflected system and the product development process helps in fulfilling the function to specify, buy, ensure and evaluate the delivery of the full inflight product, based on the product strategy of Marketing at competitive cost. Therefore, it is important that improvements in the product development process never be at cost of the function assignment.

(16)

Chapter 3: Product Development Process

This chapter gives insight in the concept of new product development. The first paragraph describes how the product development process can be classified and which strategy needs to be applied. The second paragraph displays how processes can mature. The third paragraph shows methodologies to manage new product development. The fourth paragraph throws light upon one methodology: the stage-gate system. The final paragraph finishes with a totally different methodology used in the software industry: function point counting.

3.1 Classify business processes

‘A process-strategy matrix can be used to classify business processes and to match it with an appropriate strategy. The process strategy matrix is drawn up by two variables to classify business processes -see figure 2.1- (Harmon 2003: 81-84).

(17)

On one axis of the matrix, the complexity and dynamics is considered of the process, and on the other the strategic importance of the process is considered.

In the lower left, there are processes that must be done but add little value, and are basically straightforward procedures. These are tasks one wants to automate in the most efficient possible way.

Processes that fall in the lower-right quadrant are high-value processes that are straightforward. An assembly process may be straightforward and involve few decisions, but the process results in the product that the company sells, and hence very important. You want to automate these, if at all possible, to reduce cost and gain efficiency.

Processes that lie in the upper-left quadrant are complex processes that have to be done, but don’t add much direct value to your company’s product or services. They just cause problems if they aren’t done, and they are complex enough that they may be hard to automate. In most cases, these are processes that you could probably consider outsourcing to another company that specialises in doing this type of process.

Finally there are the processes at the top right that are high value and complex. They often involve human expertise- processes like new product development or negotiating partnerships- are hard to automate. The important thing, however, is that these are your core processes; those add the most value and define your company. They are the processes it is worth analysing and redesigning very carefully. These are often processes that involve complex employee interactions that you can’t automate but need to make as efficient as possible’ (Harmon 2003: 81-84).

Product development processes therefore, lie in the upper right quadrant –see the yellow star in figure 3.1-. For it involves new product development, which directly supports the fulfilment of KLM CIM’s (core) function assignment -see paragraph 2.2-. As a research direction for process improvements the product-strategy matrix shows that one has to focus on people. At the same time, it eliminates automation and outsource options to improve processes.

(18)

3.2 Improving processes

To improve processes one speaks in literature of processes that can mature. One of these maturing models is the Capability Maturity Model -see figure 3.2- (Harmon 2003: 8). ‘In essence it defines five stages that organizations go through as they move from an immature to a mature understanding of business processes. These stages were defined, using examples from the software organizations, but they apply, equally to any large organization.

The CMM model defines the evolution of a company’s maturity as follows:

• Level 1: Initial. The process is characterised by an ad hoc set of activities. The process isn’t defined and success depends on individual effort and heroics.

• Level 2: Repeatable. At this level, basic project management processes are established to track costs, to schedule, and to define functionality. The discipline is available to repeat earlier successes on similar projects.

• Level 3: Defined. The process is documented for both management and engineering activities and standards are defined. All projects use an approved

(19)

tailored version of the organisation’s standard approach to developing and maintaining products.

• Level 4: Managed. Detailed measures of the software process and product quality are collected. Both the process and products are quantitatively understood and controlled.

• Level 5: Optimising. Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.

Every organisation can be assigned to a maturity level. Most companies studied are in either level 2 or 3. In effect, they had processes but in most cases they weren’t as well defined as they could be. Their management systems were not well aligned with their processes, and they weren’t in a position to routinely improve their processes’ (Harmon 2003: 8).

In case of KLM CIM’s product development process, it can be put that KLM CIM is at a maturity level of 2 –see the yellow star in figure 3.2-. The reason is that there is no general process overview and timing and know-how on activities is principally based on experience of its executers.

It is important that one must achieve process awareness of the product development process. This awareness can be accomplished when one goes through the phases of the capability maturity model –see the yellow arrow in figure 3.2-. In order to reach a higher maturity level of process awareness each phase must be completed in order to move to the next phase. This maturity model and its phases are used in this research to validate the designed model.

3.3 Management systems to improve new product development

‘Models representing the product development process include the stage gate model (Cooper, 1996), innovation funnel (Hughes and Chafin, 1996) and the phase review model (Barclay et al., 2001). These models have been designed to improve the process of new product development’ (Radnor and Noke, 2006).

3.3.1 The phase review model

‘The phase review process lays out the product life cycle into sequential phases that have within each phase a defined set of sequential steps. Each phase and step has

(20)

defined inputs and outputs. Management reviews the outcomes at the end of each phase and makes a go-no go decision’ (Hughes and Chafin, 1996).

3.3.2 The stage-gate model

‘The stage-gate process requires completion of stages before the project can pass through a gate to the next phase of product development, nut it differs from the phase-review procedure in that it uses functional teams that operate in parallel to reduce critical path and to better coordinate the later stages which the earlier ones. This process encourages cross-functional teaming and emphasizes the need for a market orientation’ (Hughes and Chafin, 1996).

3.3.3 Innovation funnel

‘Somewhat akin to stage gate, the innovation funnel involves screens along each loop of the in the value proposition cycle. This screening methodology summarizes the company’s critical success factors, allowing the project team to asses the success potential for a new product idea. The objectives of this development approach are continuous learning, identifying the certainty of knowledge used for decision-making, building consensus and focusing on adding value’ (Hughes and Chafin, 1996).

‘The theory behind the innovation funnel is that the idea creation phase of the innovation process is relatively less costly in comparison to the later development stages of the process (Rochford, 1991), it is logical to maximise the output of the idea creation phase. In doing this, a larger number of higher calibre ideas will be available for exploitation by the organisation. Thus, through this greater choice of potential innovations as input for the innovation process, it is probable that the eventual outputs will be more effective and profitable, since increased competition between ideas will ultimately improve the quality of potential innovations being presented to the process’ (Flynn et al., 2003).

3.4 The concept of stage-gate systems

In case of KLM CIM, the emphasis is not on the “hit-rate” of the innovations, but on the control of the product development process, to organize a smooth transition in the logistical supply chain network. Therefore, a model which has an approach that has a more logistical nature is more suitable to apply. The stage-gate system does seem to have that more logistical approach.

(21)

‘A stage-gate system is both a conceptual and an operational model for moving a new product from idea to launch. It is a blueprint for managing the new product process to improve effectiveness and efficiency. Although conceptually quite simple, the intricacies design and operationalization of stage-gate approaches are considerably more complex.

The strategic solution is that management must get better at conceiving, developing new products –not just extensions and incremental improvements, but new products that give the firm a sustainable competitive advantage. This translates into better management of the innovation process. Stage-gate systems are seen as one answer.

Stage-gate systems recognize that product innovation is a process. And like other processes, innovation can be managed. Stage-gate systems simply apply process management methodologies to this innovation process. A good analogy is the production process to manufacture a physical output. The way to improve the quality of output from the process, of course, is to focus on the process itself – to remove variances in the process. A process is subdivided into a number of stages or workstations. Between each work station or stage, there is a quality control checkpoint or gate. A set of quality criteria that the product must pass before moving to the next workstation. The stages are where the work is done; the gate ensure that the quality is sufficient’ (Cooper, 1990).

Stage-gate systems use similar methods to manage the innovation process. They divide the innovation process into a predetermined set of stages, themselves composed of a group of prescribed, related often parallel activities. See figure 3.3.

(22)

‘The entrance to each stage is a gate; these gates control the process, much like quality control checkpoints control the production process. Each gate is characterized by a set of deliverables or inputs, a set of exit criteria and an output. The inputs are the deliverables that the project leader must bring to the gate. The criteria are items upon which the project will be judged, the hurdles that the project must pass at the gate to have the gate opened to the next stage. The outputs are the decisions at the gate typically a Go/ Kill/ Hold/ Recycle decision, and the approval of the action plan for the next stage.

Each project leader is required to provide the specified deliverables and meet the stated criteria at a give gate. Gates are manned by senior managers who act as “gatekeepers”. This gatekeeping group is typically multidisciplinary and multifunctional, authority to approve the resources needed by the project.

Stage-gate systems, although simple conceptually, have a profound impact on the innovation process. Stage-gate models provide the quality focus that is often missing in firm’s new product programs. By building in quality control checkpoints in the form of gates, stage-gate systems ensure that project leaders and teams meet high standards of execution. As the project approaches a gate, he or she knows what inputs are required and that these deliverables will be carefully scrutinized by the gatekeepers. The pressure is very much on the project leader to build quality into his or her project.

Gates ensure that no critical activities have been omitted: an action plan is agreed upon at each gate, and the deliverables for the next gate are clearly specified. The result is no critical errors of omission, no gaps in the process, and a “complete” process ’(Cooper, 1990).

3.5 The concept of function point counting

This paragraph reveals a technique –function point counting-, very different from the ones mentioned earlier. This technique is widely used in the development of software to measure the programming quality and forecast resource requirements such as personnel hours required to complete a programming project (Fleck, 1998).

(23)

‘Function point counting was developed by Albrecht (1979) of IBM as a foundation metric for measuring programming quality and for forecasting resource requirements such as personnel hours required to complete a programming project. Unlike other metrics, such as lines of code, function point counting provides a dimensionless number that is independent of the programming language selected; it counts the “functionality” (added, deleted, modified) of the project delivered to the user. The rationale of function point counting is straightforward: the functionality of a system is measured by first identifying and then counting certain definable attributes (such as files) and weighting them according to a set of rules. The counted functional attributes when multiplied by weights and summed yields the function points in the system. If the number of programming hours (or other resources) was tracked for past projects and if function point values are determined for those projects, then a delivery rate (hours per function point) can be calculated and applied to future projects. The determination of function points in a project has a low variance among trained counters, and the delivery rate is claimed to be quite stable across projects and programmers (e.g. Kemerer and Porter, 1993). Other variants of this process, especially feature points (SPR), have found their way into the literature as methods of either reducing the calculation effort or improving forecasting accuracy (Reifer, 1990; Symons, 1988).

Function point counting begins by classifying functionality according to type and complexity. Function classifications include: External Inputs, External Outputs, Internal Files, External Inquiries, and External Interfaces. The International Function Point Users Group (IFPUG) has codified procedures and definitions for counting function points (Garmus, 1991). The definitions of entities such as Files are central to accurate counting of function points. Other groups, such as Software Productivity Research (SPR), have dissented from IFPUG’s definitions and modified IFPUG’s rules to meet special circumstances (Jones, 1988, 1993; SPR Metric Analysis Reference Card; Bock and Klepper, 1992). Figure 1 is a diagrammatic representation of the relationships among the functional classifications. A key element in determining the number of function points is the accurate determination of an application’s boundary. For example, an external input is defined as a “unique data or control input type that enters the external boundary of the application being measured, and adds or changes data in logical internal file type” (Guide, 1991). When a new system is designed, the application boundary is generally clear: the application boundary

(24)

includes all the code being created. External inputs are those files or control data that enter from the environment. Each function classification (i.e. external inputs, etc.) is counted and weighted according to its complexity (low, average, or high), which is determined by the relationship between entities such as file types and data items’ (Fleck, 1998: 63-70).

‘Programmer resources as measured in available hours are often a limiting or constraining resource in software projects and maintenance. A key element in software project management, therefore, is the forecast of required programming hours. Estimates based on past experience and similar projects are generally unreliable and usually underestimate the level of programming resources required. Function point counting provides a reliable methodology for estimating the level of effort required in software projects’ (Fleck, 1998: 63-70). See figure 3.4.

(25)

Chapter 4: Restrictions stage-gate systems

As mentioned in the previous chapter, stage-gate systems are conceptually quite simple, the intricacies design and operationalization of stage-gate approaches are considerably more complex (Cooper 1990). This is also the case at KLM CIM. This chapter expounds the issues related to the stage-gate model.

4.1 The stage-gate system at KLM CIM

KLM CIM uses some sort of stage-gate system. Figure 4.1 displays the process of KLM CIM above the dotted line, below the dotted line the gates are displayed –see appendix D for an enlarged picture-.

There are a few stage-gates in the product development process at KLM CIM. At each gate the senior management of KLM CIM gives a Go/ Kill/ Hold/ Recycle decision. The first one is the “initial screen” which gives the approval to start the product development –gate 1, figure 4.1-. The second gate is the approval of the product specification and the start of the tender -gate 2, figure 4.1-. The third and final gate is the approval of the (new) supplier and the start for production of the new products and the final launch -gate 3, figure 4.1-.

(26)

As you can see, there are many (parallel) activities between the second and the third stage-gate of the product development process at KLM CIM. This makes it hard to control that part of the process. The reason why there aren’t more gates to control the product development process will be clarified in the following two paragraphs.

4.2 Parallel processing

4.2.1 The theory

‘Parallel processing is an important feature of stage-gate systems. It means that activities are parallel rather than sequential. At each stage of the gateways system, many activities take place concurrently and involve different functions of the firm.

Why parallel processing? New products managers face a dilemma: on one hand, they are being urged by corporate management to shorten the elapsed time from idea to launch. On the other hand, the manager is urged to improve the effectiveness of product development: cut down the failure rate; do it right. The desire to “do it right” suggests a longer process. So the new product manager is caught between conflicting demands of time efficiency and project effectiveness. Parallel processing compresses the development cycle without sacrificing quality. In parallel processing, many activities are undertaken concurrently rather than in series.

Parallel processing, an integral facet of stage-gate systems, means that more activities occur in an elapsed period of time, which results in time compression. The process is obviously more complex than series approach, requires more careful management and hence points to the need for a thoughtful game plan. A second benefit of parallel processing is multidisciplinary inputs. Parallel processing means multifunctional, multidisciplinary inputs –different activities in different parts of the firm being undertaken concurrently, but all converging at the next scrum or gate’ (Cooper, 1990).

4.2.2 The practice

A process is a logical, related, sequential (connected) set of activities that takes an input from a supplier, adds value to it, and produces an output to a customer (Harrington e.a. 1997: 1).

(27)

Because a process is a sequential connected set of activities, the total lead-time of the process is build-up by the sum of the lead-times of its sequential connected activities. In a formula this results in:

Total lead-time of the process = Σ (lead-time of its sequential connected activities)

However, when not all the activities are sequentially connected in the process, the activities run parallel. In this case the longest sequential connected set of activities determines the total lead-time of process, thus:

Total lead-time of the process = Longest Σ (lead-time of its sequential connected activities)

If there is a high diversity in product developments, it is not always the same set of activities that determines the total lead-time of the process. This is because the duration of the individual activities can diver a lot in comparison to another product development. This means that not always the same parallel process is critical in the total lead-time of the process.

At KLM CIM this research found four parallel processes that can effect the total lead-time of product development. There are different plausible situations thinkable in which either one of the four parallel processes is critical. See figure 4.2 and appendix C for an enlarged picture.

This fluctuation in duration of individual activities is so high that not always the same activities take place concurrently. Therefore it is impossible to define another gate to control and manage the product development process. Since in terms of the stage-gate system parallel processing means, that different activities in different parts of the firm being undertaken concurrently, but all converging at the next scrum or gate (Cooper, 1990).

(28)

4.3 A visible road map

4.3.1 The theory

‘Stage-gate systems provide a road map for the project leader and team. The project team members, often from different functions and locations within the firm, now have a clearer idea of where the project stands, where it is going and what needs to be done next. “At least they’re reading from the same page of the book”, commented a senior Exxon chemical executive about his marketing and technical people as they implemented a stage-gate system.

Stage-gate approaches lay out the suggested activities for each stage of the process. None of these activities is mandatory –each project is unique- but now the project leader has a good sense of what activities seem reasonable to consider for the next stage of the project’ (Cooper, 1990).

(29)

4.3.2 The practice

The fluctuation in duration of the individual activities -see paragraph 4.2.2. - are the cause that the gates are too far apart. In terms of “reading from the same page of the book”, the pages are too large to be able to control the process.

For example: at KLM CIM the final-phase of the product development process –the launch phase- can take up to 9 months. On the other hand there are situations thinkable that the launch phase only takes 2 months. This makes the alignment of department activities and the control of the product development process really difficult.

(30)

Chapter 5:

Research design

This chapter describes the goal of this research goal. The first paragraph defines the research goal, which can be deducted from the previous chapters.

5.1 Research goal

The previous chapters described how hard it can be to control the product development process, even with help of stage-gate systems. Due to the different kind of product developments, the duration of the individual activities fluctuates per product development. Hence, not always the same activities take place concurrently. Therefore it is impossible to define an extra gate to control the product development process.

A method must be found which overcomes this problem and is capable of managing and improve the product development process in a logistical environment.

Research goal:

Create a model/ method, which makes it possible for organizations, with a heavy logistical supply chain network, to manage their product development process, by going through the stages of the Capability Maturity Model.

Diagnoses Chapter 1: Motivation and management query Diagnoses Chapter 2: The reflected system

Diagnoses Chapter 3: Product development process Diagnoses Chapter 4: Restrictions of stage-gate systems Diagnoses Chapter 5: Research goal

Design Chapter 6: Function point counting: the similarities Design Chapter 7: Methodology for the model design

Validation Chapter 8: The working of the tool Validation Chapter 9: Validation

Validation Chapter 10: Conclusion & research restrictions

(31)

Chapter 6: Function point counting: the similarities

The model, which is developed to control the product development process, has some similarities with function point counting –mentioned in paragraph 3.5- . In this chapter the similarities are made clear.

6.1 Functional attributes

Function point counting is able to give a very good estimation of programming hours necessary for the development of software. Function point counting cuts the software in controllable peaces, whereby the total development duration can be predicted. Function point counting uses definable attributes of the software and weights them according to a set of rules.

In new product development, the functional attributes of the product is not determining for the duration of the process. KLM CIM had until the start of this research a classification on duration, based on the functional attributes of the products. This classification was not correct, simply because product development duration did not meet the prescribed duration of the classification.

This research found that, functional attributes of the activities in the process is determining for the duration of the process. This means that the functional attributes of the activities have influence on the duration of the activities and therefore on the process duration –see paragraph 4.2.2.-.

The functional attributes of an activity is defined in this research as: the function the activity fulfils in the process

For example:

The activity “transportation” fulfils a logistical function in the process. The activity “decision-making” fulfils a strategic function in the process. The activity “production” fulfils a product function in the process.

Paragraphs 7.3 will explain this matter further.

(32)

6.2 Function classification

Function point counting is classified by functional attributes. These function classifications include: External Inputs, External Outputs, Internal Files, External Inquiries, and External Interfaces (Fleck, 1998: 63). See figure 3.4.

Also a classification is possible for the functional attributes of activities1. This research found that the functional attributes of activities can be classified in: logistical factors, strategic factors and product factors. See figure 6.1.

For example:

The duration of an activity with a logistical function is determined by logistical factors

The duration of an activity with a strategic function is determined by strategic factors

The duration of an activity with a product function is determined by product factors

The factors of KLM CIM will be thrown light upon in paragraph 7.3.3.

1_{This classification is solitary based on the process of KLM CIM. Applicability to other}

organizations can be questioned, see paragraph 7.3.3

(33)

6.2 Planning

Function point counting is weighted by the number of programming hours. If function point values are determined, then a delivery rate (hours per function point) can be calculated and applied to future projects. The increasing number of software development tools available today enables software systems to be developed in very different environments. Some organizations use a data-centered fourth-generation-language (4GL) software development tool. Data-centered 4GL software development tools enable database-oriented transaction processing systems and/or management information systems to be developed in a rapid manner (Koten, van and Gray, 2006).

In the model that is developed the (functional) factors per activity are weighted by the duration of that activity. This makes that per activity, the combination of a factor and duration, can be applied to future projects. One is therefore also capable of comparing an activity, which takes place in different product developments, when the same factor is used for that activity.

With the help of the developed tool –the PM-planner, see chapter 8- it is possible to control and plan the product development process. This is done by aligning activities, reduce slack and make well considered decisions to speed-up the product development process. In some ways it has the same working as the 4GL software development tool and can thereby be used to speed-up product development processes.

In the following chapters this research shows that the functional attributes of activities can be used to go through the phases of the Capability Maturity Model, by defining, managing and optimizing the process of product development.

(34)

Chapter 7: Methodology behind the model

This chapter describes the methodology behind the model design. As described in the previous chapter the model is shaped by the functional attributes of activities. In the first paragraph process diagramming is introduced to analyze the process. The second paragraph shows how the process is defined; level 3 of the Capability Maturity model –see paragraph 3.2- . The final paragraph shows the method of the model to plan product development, which is used in the development of the tool – the PM-planner- to plan and control the product development process.

7.1 Process diagramming

Processes can be subdivided into smaller units or subprocesses. An activity is defined as the smallest subprocess that is decided to illustrate on process diagrams. The term activity is reserved for the smallest unit of analysis (Harmon 2003: 457).

Process diagrams or workflow diagrams are the methods given in literature to analyze business processes. The diagramming of business processes is called process modeling (Harmon 2003: 111).

‘The process diagram itself is divided into a series of horizontal rows; called swimlanes. Although there are exceptions, as a strong generalization, movement from left to right indicates the passage of time. Thus, a process begins on the left-hand side of the diagram and proceeds to the right. In other words, activities to the left take place before activities to the right.

(35)

In some organizations, a similar diagram might be called a workflow diagram. In a typical workflow diagram, however, the processes would be simply represented by a single line. In a process diagram the functional or organizational entities responsible for the performance of each activity are shown. Thus, the organizational departments or functions become the swimlanes of the process diagram (Harmon 2003: 112-113). An illustrative example is shown in figure 7.1.

Usually processes and subprocesses are not represented on the same diagram. Instead, a number of processes are represented that are all at more or less the same level of granularity. It is possible to drill down each process. So that eventually, swimlanes represent specific managers or employee roles. How far you drill down depends on the level of analysis (Harmon 2003: 113).

Rummler and Brach are the first to introduce the use of swimlanes on business process diagrams. Swimlanes provide managers and design teams an easy way to see where a process flow crosses a departmental or functional group line. It focuses on handoffs, co-ordination, and feedback problems. Rummler and Brache also put a lot of emphasis on aligning the goals and measures managers’ use when they evaluate activity outcomes and on the people who perform the manual activities. They often find as many disconnects in the management of processes as in the processes itself.

(36)

In the analysis there are three points of focus. The first one is on the process itself; process design. It refers to the actual workflow and the activities performed by systems or employees. The second one and third one refer to the management activities: the planning of the process, and the monitoring of process outcomes. Even at the process and activity levels many of the gaps and disconnects are caused by management failures’ (Harmon 2003: 249-251).

The elaborated process diagram that was fabricated during the research of the product development process at KLM CIM is included in appendix B and shown in figure 7.2. To illustrate the use of a process diagram -shown in figure 7.2-, an example is made of the product development of a tray concept2_{at KLM CIM. The}

idea-phase ends with writing a functional specification of the build-up of the tray by Product Management. During this activity Procurement does a market research for possible suppliers to join the closed-tender. When the functional specification is approved the tender is opened. When the tender closes, procurement makes a short list of suitable suppliers. The suppliers on the short list get the time to make a mold sample of the products. The different products will be tested by a passenger test organized by Product Management. The test result, other findings and advice will be presented for the Higher Management of KLM CIM. When the final tray concept is chosen four parallel processes are starting up –see appendix C-. The supplier starts with the production preparation and with the production of a sample batch of 100 pieces made by a hand mold. Planning starts with blocking the article numbers in SAP. By doing so, Loading & ordering can use the article numbers to start the loading plan and catering instructions in another program called Space. The sample batch is used for food presentation for the local caterer (KCS) and for the outstations by respectively Contract Management ex-Schiphol and Contract Management Outstations. In this way the four parallel processes –process of equipment, process of food ex-schiphol, process of food outstations and the process of instructions- have been set in motion–see appendix C-.

Appendix C is in essence the same diagram as appendix B, the difference is that in the diagram of appendix C the owners are visible and in the diagram of appendix B the four parallel processes.

2

(37)

(38)

7.2 Defining the process

In be able to manage a process properly, the process must first be defined to achieve process awareness. This is level 3 of the Capability Maturity Model –see paragraph 3.2-. The process must be documented for both management and engineering activities and standards are defined. All projects use an approved tailored function of the organisation’s standard approach to develop and maintain products. This paragraph describes how the standards and activities are defined, which lays the foundation of the designed model.

7.2.1 Activities

Processes can be subdivided into smaller units or subprocesses. An activity is defined as the smallest subprocess that is decided to illustrate on process diagrams. The term activity is reserved for the smallest unit of analysis (Harmon 2003: 457).

The model defines an activity when it can be appointed to one owner. The reason is that an activity cannot be managed if responsibility cannot be determined. Hence, an activity may never transcend functional departments. Or in other words: an activity ends when it changes responsibility.

Of course it is possible to define multiple connected activities instead of one activity, which can be appointed to one owner. The problem is that defining more activities than essentially necessary, only leads to a product development process overview that is applicable to less product developments. Hence, the more is describes in detail, the less general applicable it becomes.

The decrease of applicability is not linked with the complexity of the process, but with its diversity of product developments. If there are many kinds of different product developments, the applicability will be less on a highly detailed process overview. Therefore, the model does not define multiple connected activities when the responsibility stays the same, but just one.

(39)

7.2.2 Owner definition

As mentioned in the first paragraph activities are owner dependent. Owners within the reflected system determined by function/ job description. See the organizational chart of appendix A.

However, there are also activities that take place outside the reflected system. For example, the production takes place at the external supplier. One could say that although this activity takes place outside the reflected system one can appoint an owner within the reflected system. That person/ department is responsible for the progress of the external activity. At KLM CIM the research appointed for external activities no internal owners, but external owners. External owners are therefore represented on the process diagram, which gives a clearer overview of the process3.

In a product development process not all the activities can easily be appointed to one owner. For example, the final decision of the product, because this is an activity, where many people from different departments want to give their opinion upon. For activities that cannot be directly appointed to one owner, this research appoints the person or department which has the greatest influence on the lead-time of that activity. In case of KLM CIM, the Product Manager is responsible that everyone has given the opportunity to give their opinion on the product and therefore is the one person who can speed-up the decision process.

7.2.3 Activity standards

The activities and its owners are defined. Per activity standards should be agreed upon. This involves defining clear in- and output for the activities and defining standard lead-times. At KLM CIM the in- and output of activities have already been clear defined before the start of this research. On the other hand lead-times were not.

This is because the duration of the individual activities can diver a lot in comparison to another product development, as mentioned in paragraph 4.2.2. This fluctuation in duration of activities makes it hard to set standards.

3

(40)

Nevertheless, this research found out that it is certainly possible. Because one has to focus on the factor(s) which causes the different lead-times per activity. If you are able to link the factors per activity with activity duration, you can set standards.

For example:

The duration of the transportation from the supplier to Schiphol is dependent on the location of the supplier. If the supplier is situated in Europe, transportation takes 14 days. If the supplier is situated outside Europe, one should take 40 days into account for transportation. The factor production location determines the duration of that particular activity.

7.3 Planning

7.3.1 Complexity

As mentioned in paragraph 1.2, KLM CIM uses backward scheduling in order to plan process activities. This is for greater part caused by the heavy logistical network, since activities need to be planned a long time in advance in order to transit smoothly in the supply chain.

The problem with a product development process with activities that fluctuate per product development is that it is hard to predict activity duration. At the product development process of KLM CIM this research discovered 30 activities that play a role in the duration of the product development process divided over 8 departments/ owners4. This means that if one owner wants to plan their own activities that person also needs to know the duration of the other 26 activities5. Hence an activity ends when it changes ownership.

At KLM CIM this research found approximately three different possible lead-times per activity. For the total development process this results in:

30 (activities) * 3 (different lead-times per activity) = 90 different lead-times

4 _{See appendix B}

5

(41)

In order to plan these 30 activities a lot of cross-functional expertise is necessary to be able to take the 90 different possible lead-times into account. The cross-functional expertise depends on the person involved and his or her experience with similar product developments. The problem is that this experience will be lost when that person leaves his or her position. Therefore the CIM KLM organisation is very dependent on employees with cross-functional expertise, because these persons are the only one who can come up with a cross functional planning. This emphasizes the necessity of the setting of activity standards.

7.3.2 Functionality of activities

To overcome this complexity of planning, it is necessary to get an understanding of the factors that play a role in the variation of lead-times per activity. The research perspective is that, if one is able to understand the factors that play a role in the duration of the lead-times per activity, one is also able to plan the total lead-time of the product development process.

This research found three or four factors that play a role in the duration of each activity. Therefore it might sound likely that with 30 activities, this would lead to:

30 (activities) * 3 (factors per activity) = 90 different factors

Fortunately this is not the case: the duration of the individual activities is mainly dependent on the same factors. In the research at KLM CIM there were just 15 factors that played a role in the duration of the product development process. 15 instead of 90.

Because the number of factors that play a role in the product development process is limited, process seems less complex. Because there are only 15 factors that determine the duration of the 30 activities.

The question is what causes this limitation of factors?

7.3.3. Function Classification

This research found that the activities can be subdivided into three functional groups. These groups are: Logistical factors, Strategic factors and Product factors.

(42)

The first group are activities that have a logistical nature. Therefore there are logistical factors that determine the duration of these activities.

For KLM the logistical factors are:

Implementation during a service change - Yes, No Final destination - Europe,

Intercontinental Linkage with a service schedule - Yes, No

Shipment to outstations - Yes, No

Production location - In Europe, outside Europe

Visit outstation with - Sample, final product

The second group are activities that have a strategic nature. The level of strategic importance determines the duration of these activities

For KLM the strategic factors are:

The class - Business, Tourist Tender for equipment - Yes, No

Complexity of decision making - High, Medium, Low Perform passenger test - Yes, No

Perform operational test - Yes, No

The third group are activities where duration is influenced by product attributes. The product attributes determines the duration of these activities.

For KLM the product factors are:

What - Concept, Equipment

Dimensions - Same, Different Material - Rotable, Disposable Needs mold making - Yes, No

(43)

It cannot be said that for every product development process, the same classification can be applied. Simply because KLM CIM is the only organization of which this classification is made by this research. Although, it can be seen that in the process of product development, activities have a function in the process and that these functions can be classified into similar groups. Therefore, it is likely that similar factors can be used for different activities. This limitation of factors thereby can be used in planning the process.

(44)

Chapter 8: The working of the tool

When the process is mapped and the lead-times and its factors are determined it is possible to calculate which path is critical and its duration. Except, the calculation takes a lot of time, because many the matrixes with activities, factors and lead-times need to be used in order to do so. This conflicts with the usefulness of this method of diagramming. If the calculation takes too much time or is too complex to understand it is not likely the Product Manager will use this way of modelling to make a overall planning. Hence for each and every product development one is forced to make another calculation because of the high diversity of the product developments. The reason why the Product Manager does want to use this way of modelling is because it aligns department activities and creates a indication of development time. Nevertheless, this research states that one must find a method which overcomes the calculation complexity and time in order to stimulate the Product Manager in the usage of this way of modelling.

8.1 The development of the PM Planner

As spoken of in the previous chapter, the factors that determine the duration of activities is limited -see paragraph 7.3.3- . The limitation of factors, gave the idea to develop some kind of tax form where the Product Manager could fill-in (15) checkboxes at the beginning of the product development process. This tax form would then calculate per activity the lead-time and give an impression of the total development lead-time.

This idea unfolded in the development of the PM-planner. The PM-planner is a planning and controlling tool. It is a very user-friendly tool and calculates the total lead-time, reveals critical paths and plans the individual activities for the departments involved. It combines all matrixes of activities, with their factors and lead-times and one can still adapt activity duration when found necessary. Besides the usage for planning and control, the PM-planner also has an ability to learn from historical product developments.

(45)

8.2 The PM-planner & Capability Maturity Model

This paragraph gives a quick tour through the PM-planner in order to get an understanding of its usage and features. The paragraphs are shaped, like the levels of the Capability Maturity Model –see paragraph 3.2-.

8.2.1 Defined

When the PM-planner is opened you see an overview of the product development process, with all its activities. See figure 8.1. These activities have been accepted throughout the organization. Together with the activities, the owners and the factors and duration have been accepted and incorporated in the organization –see paragraph 9.3-.

8.2.2 Managed; Planning

The PM-planner starts with a questionnaire of 15 questions. The answers are checkboxes. When all the questions are filled-in the PM-planner shows a preliminary planning. The Product Manager can alter the answers in the checkboxes and he or she can directly see the impact on the duration of the activities. Figure 8.2 shows an example of a preliminary planning of the PM-planner.

Managing between the gates of product development Model design to manage product development processes