Technology and pre-development

You have defined a technology strategy and derived a synchronised Product- and Technology Roadmap. With your project management, you have defined relevant pre-development projects and planned them in multi-project management. However, you will only reap the rewards of this strategic planning work if you manage to successfully implement these pre-development projects. Given the relatively high level of uncertainty, agile working methods are virtually predestined. However, regardless of whether you work in line with an agile or classical approach, you need your own pre-development process and a supporting organisational structure.

Objective

The aim of a pre-development project is to check whether a technology- or a technical concept can realise the functional customer requirements at acceptable manufacturing costs and, at the same time, is also a viable option from a production perspective. In other words, proof of functionality, quality, costs and manufacturability is provided. You will never “pre-develop” an entire product, but rather concentrate on a few new functions or a technological update relating to individual modules or assemblies. The result is to be pre-developed to the extent that the risks for the “decreasing” product development project are as low as possible and the final optimisation and validation of function, quality, manufacturability and costs in the product development project can take place without endangering the cost and schedule framework.

Agile pre-development

You have not yet gained any practical experience with agile working methods and agile leadership. Then simply take your next pre-development project as your first agile pilot project. Pre-development projects are predestined for an agile approach characterised by dynamic requirements management and iterative development because of the uncertain requirements and technological risks in play.

The pre-development process

You are used to conducting your product development projects with a classical Stage-Gate Process. Then why not do the same for your pre-development projects? After all, your pre-development results must be available at a defined time according to your Product- and Technology Roadmap, in order to be “part of the journey” with the product development project. And you have to achieve defined goals. Admittedly, the course of your pre-development project is uncertain and not entirely predictable. But, on the other hand, you are not conducting open-ended research, you have to deliver. And an interdisciplinary process based on simultaneous engineering does not stand in contradiction to agile ways of working.

Also, conduct pre-development projects according to a clearly defined process. This can have four phases, for example. As in a good product development process, you start with a pre-planning phase, where you define the goals and framework conditions for the project and have it released with the budget for the next phases. In the subsequent conceptual phase, you develop and evaluate alternative technical concepts. In the function development phase, you check and verify whether the goals can be achieved. It is best to have defined a maturity model for this purpose, after which you can decide whether the pre-development results are ready for adoption in a product development project. If this check is positive, you can transfer your pre-development result to the product development project.

Synchronising pre-development and product development

If you have done everything right in your Product- and Technology Roadmap and in the scheduling of projects in multi-project management, you have already synchronised the results of pre-development projects with decreasing product development projects.

In order to transfer pre-development results to a product development project in a targeted and smooth manner, it is best to determine how this is to be done in your process model. It has proven useful to let the last two phases of the pre-development process run in parallel with the first two phases of the product development process.

If the product development project is still to be released or is already in the pre-planning phase, you decide in the function development phase of the pre-development project as to whether the results are mature enough for handover. The product development project can then take this information into account. Potentially, if the maturity level of the pre-development result is negative, the product development project will not even be started.

The product development project then begins with the concept development phase, which is concluded classically with a functional specification or leads to ever-better customer requirements in an agile manner by way of continuous product backlog refinement. The pre-development project supports this phase by incorporating the technical results into the development of the technical product concept and by handing over initial manufacturing cost estimates. At the same time, it is agreed which residual verification or validation work will still be carried out as part of the pre-development project. Depending on your organisational model, the pre-developers involved now become part of the project team behind the product development project.

Organisational structure

The organisational mapping of pre-development is an exciting question. There are various alternatives here, each of which harbour advantages and disadvantages.

If you struggle in your company with the fact that series support projects basically cannibalise resources of new product developments and these, in turn, suck up resources of pre-development projects, you will never achieve the planned pre-development scopes and results. This can be an argument in favour of depicting pre-development as a separate organisational area, as this would better protect the allocation of resources to pre-development projects. The argument against this is that this renders it necessary to hand over to product development projects and that they may suffer from the rejection of pre-development results (“not-invented-here syndrome”). However, you can avoid this by synchronising the processes as described above. Pre-developers could also switch to the product development project as a person and thus take “their baby” with them. This could also be a model to initially introduce newcomers in the “hard” series development business to experienced colleagues in pre-development before they go on to make the switch there. In this way, you create a “flow heater” with which you continuously integrate young development engineers into the company and, at the same time, use their fresh (university) knowledge.

Alternatively, there is much to be said for carrying out pre-development within these areas in R&D structured according to assemblies or modules. This is where the knowledge of module history and practical requirements lies. The disadvantages of the above solution then do not occur. However, you need to have the risks of cannibalisation under control.

Which of the solutions outlined above is the right one for you, in particular, whether your pre-development projects can be carried out agilely or according to waterfall processes, depends on many factors. CO Improve’s consultants have experienced a wide variety of constellations in their consulting practice and are on hand to advise you on the selection and implementation of the right solution approaches until you achieve an irreversibly good result.

The benefit to you

  • You organise your pre-development with a defined process.
  • You achieve your pre-development goals more reliably.
  • You organise the transfer of pre-development results into product development projects.
  • You shorten the time-to-market and optimise your costs by avoiding the unnecessary duplication of work.
  • You find an organisational solution to realise the pre-development projects as planned.