Product Development Through Concurrent Engineering

- Advertisement -

The initial QFD analysis that we did in our previous article helped to develop a draft product definition. This product definition needs further detailing and has to go through several iterations before we get our concepts cleared and develop a marketable product plan

In our previous articles on developing a charge controller for wind power, we discussed the features it must have to make the product attractive. We also used the quality function deployment analysis to discover the features, components, manufacturing process, and quality assurance approach of that charge controller.

The draft plan we made so far needs expansion with further details. For instance, we need circuit diagrams, PCB design, product packaging, user manuals, manufacturing plan, sources for materials, marketing plans, budget, pricing, etc. All these skills are not available to a single person, so we need people with electronics engineering, supply chain planners, package designers, embedded software designers, accountants, web developers, and a marketing team.

- Advertisement -

When we start defining the product, we have too many options and very few details about what we plan to make, its features, design, manufacturing plan, supply chain structure, distribution plan, pricing, market, etc. The initial QFD analysis that we had done in our previous article helped to develop a draft product definition. This product definition needs further detailing and has to go through several iterations before we get our concepts cleared and develop a marketable product plan.

There can be various paths of product development. In technical language, we call this path a development model. Each of the product development models has certain advantages and certain drawbacks. The first decision we take in product development is to decide on this development model. Let us look into some of the popular development models and understand where to use which one.

Waterfall model

The traditional approach to product development had been to start with listing the requirements of the product. Once these requirements are frozen, then the product architecture is defined. Then the technical detail design is made, which is followed by an implementation plan, design verification, maintenance plan, distribution plan, and marketing plan. This model is called the waterfall development model (see Fig. 1).

The waterfall model simplifies communication between different skill groups. In this model, each group works on the product concept at a time. Once a team finishes its work, it hands over the outcome of its work to the next team. In the days when communication facilities were in their infancy, computing resources were very costly, and waterfall model was the only option available to product developers. In those days, this model worked nicely.

The problem with waterfall model was the time taken to develop a product. Each team worked in a sequence, which resulted in a long delay between product conceptualisation and its realisation.

The second problem was the lack of interaction between different groups. This lack of interaction often resulted in manufacturing difficulty, poor quality, and maintainability. At times, such poor interactions resulted in costly changes in design and manufacturing processes at advanced stages of development.

The waterfall model is not suitable for developing complex products.

Concurrent engineering

These days we use a process called concurrent engineering (CE). In the CE approach, evaluation, designing, and planning happen together. Team members with different skills get involved in the designing process right from the beginning and evolve the product by working together.

Let me give you a small example of how the involvement of members from different functional groups helps to improve product design. This author was developing a control system of an automated press for making compressed earth blocks. In the press, a mixture of soil and cement is compressed to form blocks. These blocks are an environment-friendly alternative to terracotta bricks.

Manufacturing of these blocks required close dimensional tolerances. As the ram presses the soil it has some inertia. For this reason, power to the ram needs to be cut off ahead of the endpoint. The distance the ram travels after power cut-off is governed by the plasticity of the soil. This property varies widely from batch to batch. Sensing the point where to cut off the power posed a challenge with conventional sensors.

During the prototype trial of the press, one of the production team members came up with the idea to fix a stopper at the endpoint. He suggested using the sound ram made when it hit that stopper as the sensing system for adjusting the endpoint sensor. Under normal conditions, the ram will touch the stopper with a soft click. If the clicking sound is missed, then he will lower the sensor. If the ram made a hard clapping sound, then he will raise the sensor. That operational innovation greatly simplified the design and improved dimensional quality of the bricks.

Current advances in communication and collaboration technologies involving computers, the internet, and video conferencing enable us to interact with people often sitting at different geographic locations easily. In the concurrent engineering approach, the team will discuss and evolve design ideas on a real-time basis. In this process a large number of iterations are possible.

Spiral model

The spiral development model is one of the simplest concurrent engineering approaches (see Fig. 2). In this model, development happens through many development workshops or sprints. These are intense and focused interactions involving all team members to achieve a specific goal. There is no rule on the number of sprints in the spiral process. During the sprint, the team will go through a cycle of planning, developing, evaluating, and suggesting further improvements.

The product development plan starts with a sketchy concept. It gradually evolves into a proof of concept mock-up, a working prototype, pilot samples for test marketing, and finally the marketable product.

The spiral development model enables rapid product development. It uses rapid prototype development technologies like 3D printing, CAD-CAM, simulation, etc. In the spiral development model, all team members can work together.

For instance, while the designers are making a circuit design, the supply chain team can use the shared bill of materials to develop suppliers. The costing team can work out the production economics, while the production team can plan their production strategy right from the start of designing. Each of these teams gives their feedback and works out the best possible options.

[signinlocker id=”87626″]

Vee (V) model

A spiral development model faces the challenge of keeping the focus on the original requirement. As the project becomes large, the team tends to lose focus. We also have the challenge of engaging a widespread, complex team for fruitful discussions. In 1979, Barry W. Boehm proposed another model primarily for software development, which is now known as the Vee model. For product development Vee model is quite popular.

The Vee model is an extension of the traditional waterfall model. In this, the distinct phases of the waterfall model and the spiral model are superimposed. This results in distinct phases of conceptualisation, development, and validation. In the Vee model validation phases are tied-up with conceptualisation phases (see Fig. 3).

The structure of the Vee model enables us to engage smaller and focused teams at different phases of product development. Unlike the spiral model, Vee model phases have a specific and well-defined deliverable. This structure helps to manage the project, track progress, and keep the team focused on main requirements. Unlike the spiral model, the author has worked with a development team that comprised around seventy members spread across five continents successfully using the Vee model.

While popular, the Vee model is criticised for being too rigid. Where requirements are fuzzy and contain a high risk of changing, the Vee model is not suitable. In such a situation, it is often advisable to rapidly get a small product lot in the market and gradually evolve the product in continuous new version releases. We see this practice in operation in high technology products like cell phones, operating systems, computers, etc.

Apart from these, there are many other development models. We have to select the correct development model for the product. No model will fit all sorts of products. Each of them has certain advantages, and each of them has certain disadvantages. However, the popular models described here will fit the most common product development requirements.

The waterfall model is good for the development of our charge controller. It is a small and simple product and will not require a large team or much development effort. But we shall use the Vee development model to demonstrate the process.

Requirements for CE

Concurrent engineering processes need some basic infrastructures. First of all, there has to be participation from all functional departments. The development team should have dedicated members who are knowledgeable and empowered to take decisions. Preferably. The development team should sit together. If that is not possible, they must meet in a well-defined periodic manner and devote specific time to the project.

Next, the team should have a shared document repository. Preferably, it should have a version control system. There are various version control software options. Some are proprietary software. Under open source, there are options like Subversion. Concurrent versioning systems (CVS), Git, etc. Even the most common office software products like Microsoft and Open Office suits have options to document and monitor changes. The team should adopt any of these options and maintain a change history.

Under concurrent engineering development processes, many changes will happen in parallel. Some of these changes will have inter-relations. When we make any change in the design or processes its impact on the other related areas needs to be evaluated, and the agreed changes incorporated into the documents.

It is a good practice to mention the related steps in each document. Establishing a lookup table with the document dependencies and the latest version numbers is also a good idea. Such documentation helps to ensure proper analysis of changes and helps to avoid unnecessary work of checking change impact for unrelated areas.

Development stages

We shall look into the stages of the Vee developmental model with the example of the charge controller. So far we have completed the requirement analysis phase. Next, we shall do system design. Requirement analysis gives us the product specifications and its basic modules. System design takes these inputs to evolve the technical drawing of the product.
During system design, our main task is to explore various technical alternatives and finally select the basic technical configuration of the product. Each of the steps in the Vee model has specific tasks and deliverables.

As we progress in these stages, we also make our cost and profitability projections more and more accurate. The initial stages start with rough ballpark estimates. Initially, we have little idea about the product, so we select our alternatives using published data and guidelines. As we get more and more clarity on our final product, we also collect accurate information. The table above gives the details of the activity, data accuracy requirements, and the deliverable of each stage.

Gateway review

In the Vee development model, we re-evaluate our business plan at the end of each stage. We evaluate it for technical and commercial viability after incorporating our new learning. The learning will come from the collected information and experience gained from the prototype development, trial, and the environment.

Product development is a time taking activity. Many things change during the development of a project. New technologies emerge, policies shift, prices change, and other competitors may come out with some new products. All these changes have an impact on the business case of the product.

At the gateway review, a decision will be taken on Go, Rework, or Drop the development project. An assessment of the risks and an honest evaluation of the project are always required.

Delay in calling a nonviable product development project causes unnecessary investment and time. If we look around, there are plenty of examples of companies that have gotten into financial trouble for such delays in dropping their nonviable business plans. Periodic evaluation and risk assessment are equally important as technical development.

In our next article, we shall use these concepts for evaluating various technical options and learn about the economic evaluation of the product development project while developing the system design.

Soumyanath Chatterjee is former TVS Motors Chair Professor at Industrial and Systems Engineering Department, IIT Kharagpur. His expertise is in Product Development and Supply Chain Management

[/signinlocker]