Concurrent Engineering Problem
Once upon a time
There once was a company, with a systemic problem with concurrent engineering and change management. This was a complex organization, with many functional areas. Each functional area, had sub-function divisions. This type of organizational structure is often referred to as a functional organization with the associated hierarchy. These various functional areas design and produce sundry parts that will be assembled together to produce a complex electro-mechanical and embedded software system. A partial drawing of the structure is provided below:
Concurrent Engineering Requires Coordination
Within the systems level, there are sub-system levels. These subsystem levels are departments within the systems department. Each sub-system focuses on a unique aspect of the entire system. There work has some commonality, for example system 1 could be the electrical / electronics engineering discipline. Work within this department is coordinated to meet that of the entire system. Generally speaking, these departments are often co-located, under those circumstances internal department communication can be easer.
The concurrent engineering problem this organization has, is keeping the end target system (or developmental iteration of the) coordinated. This is done to produce a functioning product with the system deliveries from the various departments, and is a function of configuration management, project management and change management.
This difficulty in coordinating the design has produced costly rework and late deliveries as the parts that do not work together as expected are then re-designed, reworked, released and built. These problems occur in two areas. We will write more on that in the next blog.