|
Many of our target markets have 1 thing in common, i.e. the 'Need for Change', either to keep ahead of competitors, to get higher profit margins or because new technologies are needed.
Similar needs have driven the creation of the Concurrent design approach as it is now, i.e.
- The need for speed (time to market)
- The need to involve more and more stakeholders and discipline
- The need to involve geographically distributed stakeholders and discipline experts
- The need to exchange design information in a structured and useful way
This came down to changes in the design/engineering process.
The design process often is serial and even ?Over the fence?, even when a fast start and result is required.
Discipline experts don?t feel responsible for their work, because nobody directly addresses them. Discipline experts give their own interpretation to the work delivered by the previous expert, work is often re-done. The experts don?t feel as a team, there is hardly any communication. The over the fence approach is sensitive to losing time, e.g. if one expert is out sick or on leave the work might end up in his in-box waiting for him to return, or by simply waiting for inputs.
Or the design process is built around 1 project responsible;
this isn?t always a better solution.
The interpretation of the different expert?s work is done by this one project responsible, she/he tries to glue it all inputs together to define one product/system. Team feeling and interdisciplinary communication is limited. The project responsible is overloaded with work and is critical for the project, overloaded and critical don?t go well together.
In both above sketched approaches a real possibility exists that design errors are only seen late in the project, the later an error has to be solved the more expensive it becomes.
Very often a perfectly good design or the knowledge gained during the design process is lost after the project. To start the next design activity from scratch.
|