Bootstrap

Design process

Sketch-Icon

Starting a new product development has to our opinion two main focus area's

  • Requirements engineering
  • Concept generation

In the sections below we elaborate on these subjects. This way of approaching projects has always led to consitent and succesful results. However to empasize, in our approach we will always balance the "overhead" of the process to the complexity of the product. In small or less complex projects some of the process steps will be slightly touched upon or even skipped. We see the design process as our supporting process were we can rely on, espcially in complex projects.

Requirement engineering

We talk about requirement engineering because we see this as a process rather than only a list of demands

Project template
Our perspective and terms on engineering

Critical to Quality (CTQ) requirements are the driver requirements of the product. In general these requirements determines the perfomance of the product. CTQ requirements should be measurable and their sensitivity (deviation) is often key for 'secondairy' (derived) product specifications.

Next to the CTQ requirements we have the secondary (derived) and common specifications of the product. Often these specifations play an important role in decision making of the concepts that are generated. In general in most cases the CTQ's are clear in terms of ranking the concepts, the secondary (derived) and common specifications often need more consultation with the stakeholders

Secondary specifications are the ones that strongly relate to the CTQ requirements, an example of these specifications are the ones that are parameters in the equation that determine the outcome of the CTQ

Common specifications are the ones that are generaly speaking applicable of all products, examples are manufacturability, ergonomics, costs, etc.

Stakeholders are important for the end-result of the product, communication with the stakeholdes is key for input with regards to the product specifications.
Informing the stakeholders is also part of our expectation management.

Ranking the generated concepts is to our opinion one of the key moments in the project, it will in the end determine the direction of the project.
Because of this importency we have developed our specific way of ranking the concepts, in which the basis is that it should not be subject to personal preference.
By this we mean, that we rule out personal opinion as much as possible for the benifit of clear and mutually committed decision of the baseline concept.
The benefit of our methodoloy of ranking concepts is that there is a clearity and common agreement on the weighing factors that determine the baseline concept.

The design process of course needs to be documented, we will balance the documentation "over-head" with the actual design effort.
Some of our customers have there own way of documenting their design process, where we than of course will contribute to.
In most cases it will suit to our own design process and in cases of customer documentation it is almost always an extension of ours.
For less complex projects will the level of detail documented of course be less, as stated it is a supporting process not a goal on it's own.

Concept generation

In most cases there are multiple solutions possible to solve the technical asignment, the items below we think lead to a clear and manageble decision making

Concept generation is important to us, since it forces engineers to think of multiple way's in solving the technical challenge.
As described in the section "ranking", the best designs will be the ones that are mutually agreed upon and in cases there is nothing to choose from, the risk of personal preference comes into play
Mutually agreed decisions are, especially in complex projects, a key to success and will hardly disturb the design process since they will form a solid foundation where going back to concept decisions in the design phase will scarcely happen.
Changing baselines is obviously an unwanted event in a product development process.

Preliminary Design Review (PDR) is the review moment where concept designs are presented and include the ranking of the concepts.
At this time the CTQ's, derived and common specifiactions should be clear and agreed upon since it is the foundation for the ranking process
The deliverable of passing the PDR is the mutually agreed concept or in other words the baseline decision has been taken.
Important to note is, that before baseline is known changing scope a 'manageable' impact has on the project, while scope changes after the baseline is set a high (costly) impact has

Critical Design Review (CDR) is the review moment where detailed design of the baseline concept is presented.
The contents of the CDR presentation is somewhat project dependant, at least it should contain the following subjects

  • Detailed model of the product
  • Overview of the solutions for the key functions
  • Overview of remaining risks
  • Additions to concept including rationale (if applicable)
  • Manufacturability and cost
  • Spareparts (if applicable)
The deliverable of passing the CDR is the mutual agreed product design, next phase is realization.

The 'documentation'-deliverable of the concept generation phase are the following key documents

  • PDR presentation
  • Concept designs ranking list
  • CDR presentation
For smaller and less complex projects we often only have one project presentation, which of course incorporates the contents of the documents listed above.