Most recent article

Toolbox article: concept development - from nothing to something

Nicoline Marselis
By Nicoline Marselis on September 11, 2019


In this blog we share our vision and working method with regard to concept study and development from our series of toolbox articles.

Within system development, establishing a good concept is crucial for the successful development of smart, flexible product platforms and / or innovations. To achieve a good and validated concept, we work according to a structured approach in which we stick to a predefined step-by-step plan. This helps us to keep an eye on the wishes and requirements of the client in all parts of the process and to reduce or eliminate risks in order to ultimately achieve a powerful design within the set budget.

In this article I will describe the steps that go with the concept study and development of Post and Dekker.

First and foremost, the wishes and requirements of the customer are leading for every project. During the entire concept phase, we keep a close eye on the list of requirements (LoR) and work according to the V-model. This forms the guideline for the concept to be realized, something that we will continue to focus on and therefore spend a lot of time and attention on. It runs like a red thread through all steps up to and including the final validation.

  • Determining risks: from risks to user stories
    An important first step is to identify risks. We map the biggest design challenges within the project and draw up a plan to solve them. The aim is to eliminate risks. This is how we "roadmap" the project and increase the implementation success in the market.

    The first step is to determine the risks. This is initially done with a brainstorm. The risks are then translated and brought together into a so-called user stories (categorized risks). These bundled risks must be reduced to an agreed acceptable level in accordance with the List of Requirements during the development process.
    afbeelding vaststellen risicos
  • Action plan - from user stories to deliverables
    In this phase, the stories are translated into pieces of concept and the definition of "solved / completed" is determined per user story. In other words, what needs to be delivered? At the end of the concept development phase, it is important that all these so-called deliverables are developed. Together they form the concept.

  • Specifying the List of Requirements (LoR)
    As stated at the beginning, the wishes / requirements of the customer form the basis for the concept development. Together they form the List of Requirements. During this step we will further specify this list. The product is hereby divided into small parts, called modules, with the aim of making the requirements clearer.

    Next, a brief overview of the module specific requirements is added and the required validation for the concept phase is described for each requirement.

  • Morphological overview
    In the morphological overview, as many design solutions as possible are provided for each individual function. The solutions are presented as an explanatory illustration in combination with a simple explanation.

    Once the overview has been filled in, various solution paths can be drawn along the various functions and the corresponding solutions. The result is a few possible concepts.
    morfologisch overzicht
  • Function definition
    At this step, it is important to determine and describe all individual functions per cluster. A (design) solution will be proposed for each position. Together this forms the input for the morphological overview.
  • Determine the starting point per cluster
    Before the actual concept development can be started, cluster-specific principles and / or preconditions must be established. These things can be very varied. This may involve the net space requirement of the concept, but also the current state, a stress analysis that is required or a list of platform options that (can) influence this cluster.
  • Designing concepts
    Every possible concept path that has emerged from the morphological overview is now described and further developed into a whole concept. Each concept is provided with the advantages and disadvantages. The responsible review team must be able to interpret the explanation quickly.
  • Weighting factors
    Before a concept can be selected, a list of selection criteria must be drawn up. A weighting factor must be assigned to each criterion. The selection criteria must be universal for all clusters in the project.

  • Selection of a concept
    At this point a composite review team comes together to determine what the best concept is during an assessment. It is important here that each team member independently assesses the concepts and therefore assigns a score themselves. However, sometimes this is also done jointly by the team. For this score assignment it is useful to use a score template. The concept that collects the highest score logically is preferred.

  • Development of the concept
    Now it is important to work out the chosen concept to a level that all risks have been removed (at the concept level). This means that the defined user stories have been solved. It is important that everything stays at concept level and that details are not addressed too much.

    Then the other project specific issues that are mentioned in the plan of approach are discussed, developed and / or tested. This includes, for example, installation, supply chain, uniformity of the platform, FMEA stress simulations, etc. It is important that everything happens on a concept level. The outcome will contribute to a clear and complete description of the concept, clear enough to start with the first steps of the engineering phase.

  • Validation
    The validation is the last and one of the most important steps of the concepting phase. At this step it is checked / demonstrated that the requirements have been met and the risks have been eliminated or reduced to an acceptable level.

The concept phase forms a tool and is part of our innovation roadmap. This roadmap forms the basis for integrally and innovatively developed product platforms, optimally tailored to the OEM's market needs, business processes and supply chain.

Whitepaper Creating new business for OEM


Nicoline Marselis
Written by Nicoline Marselis

Related articles

What is the V-model?

A project cannot succeed without a good project approach and accompanying SMART-formulated specifications. At Post & Dekker we...

Nicoline Marselis
By Nicoline Marselis - 28 July 2020
The product road map, the basis of integrally designing of product families

An integrally designed product family is optimally matched to market requirements, business processes and the supply chain. It...

Eric-Jan Dekker
By Eric-Jan Dekker - 28 February 2018