Problems Solved by SystemBlend™, Part 5: Technical Management

This is the fifth in a series of articles discussing the real-world problems addressed by SystemBlend™. For this article, I’ll describe how SystemBlend solves technical management issues.
Managing a Model-Based Design (MBD) project becomes significantly more difficult when it is distributed across multiple organizations. This primarily due to the manager’s visibility and authority, and due to interaction between the engineers:

In-House Project Distributed Project
Manager
Visibility
Manager has visibility into system-level technical issues, such as interface definitions and implementations or shared parameters.

This is achieved through informal interaction with the engineers, or by any other mechanism that fits the team’s dynamics. The manager is aware of the daily activities of the team, and adjusts accordingly.

Manager typically does not have good visibility into the inner workings of the contributing groups.

Informally gathering insight is either less frequent or not available at all. Formally prepared reports cannot convey the daily churn that occurs in any engineering endeavor.

Manager
Authority
The manager can adjust the team dynamics on an almost daily basis as needed to address issues as they arise. The project manager typically has little or no authority to directly alter the workflow and direction of another group.

When the need for change is identified, it typically must be negotiated between group managers.

Engineer
Interaction
Because the engineers are working side-by-side, they can identify and implement adjustments informally among themselves, without managerial input. Engineers do not have informal, daily contact with each other, so identifying needed adjustments is slower and more difficult. It might also require managerial approval.

SystemBlend addresses these three different issues with the one solution, ComponentGuide, which is the part of the SystemBlend application suite that contributing groups use for subsystem model implementation. ComponentGuide becomes the manager’s proxy in the contributing organizations:

  • ComponentGuide ensures the models follow the system-level design, without input from the project manager. Developers can implement the details of the subsystem model according to their engineering judgement, while ComponentGuide provides guidance to ensure the system-level needs are met before the subsystem model is delivered to the sponsoring organization.
  • ComponentGuide focuses on just the system-level details, so subsystem model developers can implement the models however they see fit. If there is a need to adjust the engineering process, it can be done within the contributing group, without input from the project manager.
  • ComponentGuide ensures that the interfaces between the components are complete and follow the design. This in turn ensures that the components will integrate seamlessly, even if the different engineering teams never interact.

Request More Information

Contact Us To Learn More