By Guenther Schuh, Michael Riesener and Jan Koch
Executive SummaryIn today's competitive global economy, the company that gets the right product to the consumer fastest has a competitive edge. A number of tools can help your enterprise shorten its product development times. First, work to transfer the principles of value stream analysis from production to product development. Then, shorten those times even more with synchronization, takttiming and agile product development. Such product development processes are rare in the manufacturing world, offering your organization a competitive advantage.
In product development, companies are facing rising challenges as a consequence of shorter product life cycles, increasing product complexity and competitive pressures, while teams carry out more development projects simultaneously.
Visualizing and analyzing the value stream in development processes systematically identifies and eliminates waste, enhancing product development efficiency and allowing your organization to come up with innovative products that are differentiated enough to beat their market competitors.
Synchronization and takt-timing the process allows the planning and regulation of the development process in advance. As a result, project development leaders and their teams achieve the highest quality standards in a minimum amount of time while using resources in the most efficient way.
The value stream analysis is a proven concept that increases efficiency in production processes. Lean innovation implies using value stream analysis as a central component, transferring this concept from product production to product development. However, most industrial applications in research and development do not use the value stream analysis consistently.
There are a number of reasons for this, including how difficult it is to transfer the value stream concept from production processes to development processes. After all, production processes and development processes have fundamental differences. Manufacturing processes are characterized by physical products made of raw materials, while development processes are characterized by complex interrelationships and information flows that result in a "recipe" for a new product.
Furthermore, the definition of waste varies when transferred from the field of production to product development. Unnecessary stock or transport, for example, defines waste in the production process. But in terms of development processes, waste could be seen as the late or false allocation of information. This makes it a central challenge to visualize the value stream in development processes to identify waste in a structured manner.
Methods originally devised for the manufacturing process have to be aligned to meet requirements that abound in the product development environment. For this purpose, responsible project leaders and their teams identify activities and make decisions about the development process and their interactions. By depicting the value-added activities from a customer's point of view, it is possible to visualize the value stream of the product development, as shown in Figure 1.
First of all, a retrospective analysis can help you identify frequently recurring weaknesses that are typical for the product development process. Using an interdisciplinary concept, record the activities and decisions, including all involved corporate functions, such as development, engineering or manufacturing, by analyzing completed and ongoing projects. Identifying these weaknesses can help project leaders and their teams define optimization measures for the value stream. Just like in manufacturing, waste follows patterns in development projects. The value stream analysis identifies these issues. Various projects in different industries have shown good results from analyzing and optimizing their value stream.
The following example of a consumer goods manufacturer clarifies the method. In numerous workshops, the project team conducted the process and aimed to increase the efficiency and effectiveness of two product groups. The analysis focused on the concept phase and early development of prototypes.
Before the first workshops, the company chose a representative development project to work on. In the first workshops, the project team detected and documented the as-is value stream. A short review identified typical deficits. Additionally, the head of product development defined the strategic top-down perspective.
In a second workshop phase, the swim-lane method visualized the as-is value stream, a typical procedure for the lean administration analysis. The swim lane presented the activities of each stakeholder within the development process. Switching swim lanes is a way to visualize the transfer of information between different stakeholders of the development process.
In the next step, the team evaluated the processes within the project and identified their parameters, such as inputs and outputs. Team members created a classification that considered the field of action, the grades of standardization and the value creation.
The level of detail depends on the size and complexity of the investigated development process. The processes in the analyzed project typically take six to nine months. Therefore, the level of detail was set to process steps that did not last longer than one to two weeks.
After the project team documented the as-is process, team members could identify and analyze specific defects in the next step. Major defects were overstepping and iteration cycle times. Other issues included communicating customer needs in an unsystematic fashion and insufficiently protecting the first product design prototypes.
The project team also pointed out that the choice for a final product design often was made in earlier stages. This could happen because the company didn't have enough alternate product designs, or perhaps officials thought there wasn't enough time for a redesign if prototypes failed in customer tests. In such cases, projects should have been abandoned. Nevertheless, in many cases the company introduced these products to the market to avoid high penalties.
Using this data, the project team developed and visualized the target process in further workshops and suggested alternatives.
The most radical change was introducing a consequent product development process. This allows a number of design strategies to be developed systematically and concurrently. Design concepts are only abandoned at certain milestones after carefully analyzing market and customer data.
Projects that could cause potentially high damages are backed up all the way to the end of the development process with a so-called fallback solution.
In addition, the team developed a new approach to communicate customer needs during design and agreed to use high-quality prototypes and adjust the testing methods. The final workshop result shows the allocation of all measures in a cost-benefit portfolio from which the final road-map planning derived.
The value stream analysis showed all participants how subprocesses interacted. At the same time, the analysis detected everyday problems and allowed them to be discussed. The value stream analysis not only enhanced the process structure, it also promoted integrating different departments into one value stream.
In addition to the traditional value stream analysis, big data enables new possibilities in systematically identifying patterns in real time as well as initiating appropriate measures to prevent waste. Instead of just retrospective analysis, this information allows for proactive control of development projects as well as the anticipation of problems in real time.
Moreover, the whole value stream can be redesigned and resources allocated to optimize the product development process. Resources should be used primarily for activities that increase the product's value to customers. It is imperative to differentiate between repetitive activities, like working on the bill of materials or engineering drawings, and creative activities, such as developing new solutions or concepts.
A rationalized value stream would automate repetitive activities, allowing employees to focus working time on creative and value-added activities. An interdisciplinary project team can tackle this automation by improving your IT systems. The systems have to be adapted in terms of an intelligent cross-linking of business processes. Perhaps the system can automatically generate bills of materials. Connecting information technologies and physical objects to collect and exchange data, better known as the internet of things, can be the foundation for these steps.
In addition, the trend toward increasing individualization of products results in a rising number of parallel development projects. The rising number of projects that need to be managed means the stage-gate process, which is widespread in practice, is reaching its limits. With the stage-gate process, problems usually are identified every six months or so via the stage-gate target dates. So coordination problems often remain undetected until the stage-gate target date is reached.
Resolving such problems should happen in earlier stages. One typical problem that causes development projects to exceed their planned cycles is the so-called "student-syndrome," where much of the work winds up getting done in the last third of the scheduled period.
Such procrastination forces the company to rearrange capacities and re-plan resources. To counteract these problems, the project leader must take early control of development projects, collaborating with the project team to reduce time between the gates via synchronization and takt-timing.
Synchronization and takt-timing are features of agile product development. Synchronization coordinates parallel activities. Synchronization is required when one activity is dependent on an upstream activity, such as when the results of an upstream activity are required as input information. Meanwhile, takt-timing focuses on the time control of single working tasks. The time period between two gates is divided into a standardized time period with a defined takt.
The concept of breaking down the scope of work is a well-known facet of agile software development. Agile software development encourages adaptive planning, allows step-by-step development and can deliver solutions early. Continuous improvement and the ability to respond to change in a rapid and flexible way characterize this
Agile software development often makes use of the so-called scrum method, an iterative and incremental approach, as opposed to the more traditional, sequential approach. Development teams normally work as a unit to reach a common goal. Within the scrum team, however, each member works independently on his or her set tasks to reach the team goal, which is set by the project leader.
The method subclassifies each development task into single time takts, which are called sprints. The sprints usually vary from as few as five to as many as 20 workdays. Each sprint starts off with a planning event to define the task board and ends with a review meeting. Each day during the sprint, the project team holds a daily scrum meeting to communicate achievements, problems, solutions and additional plans. This process creates a coherent workflow for self-dependent development processes.
The scrum master acts as a coach. She makes sure the scrum method is implemented successfully and sprint goals are reached. She doesn't delegate direct work orders, instead coordinating the teamwork, taking care of personal issues within the team and acting as a communication device between the project leader and the scrum team.
The scrum master tries to protect the team from external distraction. Specifying a sprint cycle time as the control unit rather than a defined task or workload supports a paradigm change from the question "How much time per task?" to the question "How much task per time?"
Transferring this concept of agile software development to the field of product development can help your organization evolve an agile product development process, as depicted in Figure 2.
An example of a gas turbine manufacturer shows how agile product development can be implemented by defining sprints.
The department of systems engineering works as a single unit, operating as the interface between product development and sales. The company is predicting an increase in the number of development projects, which would have the effect of making improved takt-timing, prioritizing and planning indispensable.
The concepts discussed above helped achieve the needed improvements. First, the scrum team used process descriptions to determine synchronization points. An analysis revealed contractually fixed dates with the customer. To identify the synchronization points needed to meet these fixed deadlines, the scrum team analyzed in detail all interrelations of activities and tasks involved in the process.
The results led to the introduction of synchronization points that were both internal to the scrum team and external synchronization points for other departments. This was necessary because the systems engineering department was not going to handle all of the necessary tasks.
Then the project team designed an iterative project plan to synchronize the project management process. Based on the identified process steps and synchronization points, the scrum master introduced sprints with defined takt times rather than defined workloads. The scrum master chose a takt time of seven days.
A takt board, which fit the length of a takt, supported and simplified the implementation of takt-timing and planning. Executing these concepts vastly improved takt-timing and prioritization, and the department was able to increase the number of projects it finished on time.
The concept of agile product development also implies that research and development managers hand responsibilities over to single developers, as each developer handles tasks in his or her respective sprint.
That is why success depends on the concept gaining acceptance among all stakeholders. Your organization will need clear communication to allay the fears of managers who must give away responsibilities to developers, along with the developer's doubts about assuming those responsibilities.
Retrospective and prospective value stream analyses are suitable instruments to avoid waste in product development. A comprehensive value stream analysis as part of a continuous improvement process can enhance the efficiency of your organization's product development.
Furthermore, the development process can be optimized by synchronization and takt-timing. Agile product development that makes use of the scrum method, stronger cooperation between team members and short sprints create a continuous workflow that can reach overall goals faster and more efficiently (see Figure 3).
Control of the project relies on synchronization points, which structure the process in manageable subscopes, and sprints that are executed by different developers. This supports a paradigm change from the question "How much time per task?" to the question "How much task per time?"
Agile product development, a highly iterative method, is currently the exception in manufacturing industries. However, this concept will gain significance in the future if your organization is going to compete in an increasingly complex world with increasingly complex and more numerous product development projects.