System Engineers in the Organization

Let’s assume a product development organization practices concurrent engineering and organizes in a set of interlocking teams. The top level team is often called the core team. A core team for a medium to large development program is composed of representatives from the major contributing functional organizations in the enterprise and might look like Figure 3-6.

Figure 3-6 A typical core team for a medium to large product development program has representatives from all the contributing functions.

A circle structure rather than a tree is used for the organization because each member of the core team is functionally independent and has responsibilities both to the product development or core team and to his/her functional organization. This means for example that the contracts representative operates within the team in the best interests of the product development program but is also constrained to follow the policies and procedures the parent organization defines for the contracts function. Similar rules apply to the other members of the core team. Each member of the core team is a leader of a support team, e.g. the engineering member of the core team is the lead engineer for the engineering team.

Now we can look at how the engineering work is organized and how its organization fits with the core team. This is shown in Figure 3-7.

Figure 3-7 The engineering integrated product team (IPT) is typically organized with a Systems Engineering and Integration Team (SEIT) and a number of teams responsible for the various systems or engineering functions such as software or test.

In Figure 3-7 SE stands for a systems engineer and DE stands for an engineering specialist other than a systems engineer. The engineering leader is called the project engineer, as in this figure, or chief engineer, or lead engineer. The leader of the System Engineering and Integration Team (SEIT) is usually called the lead systems engineer. The engineering IPT is thus composed of a number of subordinate IPTs, here labeled A through N, which are responsible for subsystems or for specialty functions like test or software. The systems engineers shown under the subordinate teams in Figure 3-7, or the subordinate team leaders, are members of the SEIT as well as their respective IPTs. If the system being developed is large and complex than there are likely many more layers of IPTs. Think of each of the DE blocks being an IPT with the SE block being a lower level SEIT.

Not explicitly shown in Figure 3-7 is how members of the operations team, the product assurance team and key suppliers support the engineering team and vice versa. In some cases it may be sufficient to only have the structure shown in Figures 3-7 and 3-8 but in most cases an operations engineer and a quality engineer should be a member of the SEIT and a member of the SEIT should be a member of the operations IPT and possibly the product assurance IPT. Usually an engineer knowledgeable about a supplier’s product is responsible for coordinating with the supplier and bringing the expertise of the supplier into the design process at each phase of the design work.

The principle to be followed in organizing the engineering team is to break down work so that at the lowest level IPT the craftsman model applies. This is the work assigned to each of the lowest level IPTs can be thoroughly understood by the team leader. Thus the team leader is a “chief engineer” for the work assigned to his/her team.

The nesting of interlocking IPTs can continue as necessary to handle the size and complexity of any large system. This nesting of teams reduces the time non managers spend in communications meetings. In the three tier example shown in Figures 3-7 only the lead engineer, here called the project engineer, needs to attend core team meetings although sometimes the lead systems engineer may attend. Engineering coordination meetings are held at two levels. The project engineer meets with all the team leaders and then the team leaders meet with their respective teams. This approach limits the amount of time workers spend in coordination meetings and limits the meeting topics to just those items of interest to each team. Few things are more frustrating to working engineers than having to sit through meetings on topics that are of little or no interest to them; plus it’s a waste of time and money to have working engineers sitting in nonproductive meetings.

Product development programs usually have documentation called a work breakdown structure (WBS) that assigns code numbers to various elements and  phases of the  work so that budgets can be generated and managed. The WBS can map to the organization to facilitate cost management although this is not a strict constraint.

Figure 3-7 shows that there is systems engineering specialty work to be done in each of the subordinate IPTs even if the person doing the work is called a design engineer rather than a systems engineer. Some design engineers think that they don’t have to do systems engineering work, which just isn’t true. They do systems engineering work even if they don’t use all of the tools used by systems engineering specialists. Since a system is always part of a larger system then there is systems engineering work in all product development at all levels of “systems”. Even though an engineer is developing the design for an assembly or component of a system there is systems engineering work required. Of course this systems engineering work must be tailored to the level of complexity of the design element.

Systems engineers can perform a variety of roles on IPTs, from lead systems engineer to contributing engineer or analyst on one or more other teams. Since the IPTs are multidisciplinary, it is critical that the systems engineers understand their roles and responsibilities on each team. A good practice is to hold roles and responsibilities meetings with all members of an IPT as soon as the team is staffed.

The engineering team for a small product development program can be simplified from that shown in Figure 3-7. An example of an engineering IPT for a small project is shown in Figure 3-8.

Figure 3-8 The engineering IPT for a small development program can be simple with the engineers having responsibility for both systems engineering and design engineering.

Figure 3-8 shows an engineering IPT with just seven engineers; a project engineer (PE), a system engineer (SE), an electrical engineer (EE), a mechanical engineer (ME), a quality engineer (QE), an operations engineer (OE) and a test engineer (TE). This organization might be sufficient for developing the design of a small electrical or electro-mechanical system. Note that this organization clearly illustrates the multidisciplinary nature of IPTs and is what might also be used on one of the subordinate IPTs of a large development program.