In my career, I’ve worked on several MBD projects that were distributed across multiple groups. Each of these projects proceeded in very different ways, but they all had some commonality in the types of events that defined the lifecycle of the project.
- Project launch
- Upgrade subsystem models
- Add new subsystem models
- Split subsystem models
- Replace subsystem models
- Integration
- Upgrade the architecture
- Deprecate and terminate subsystem models
When you are managing an MBD effort distributed across multiple groups, your project might take on another lifecycle event:
- Introduce a new group to the project
You’ve probably already noticed that there is a lot of overlap in these categories.
For distributed MBD projects, some of these lifecycle events take on more significance. This blog post is the first in a series describing how these events are different when your project is distributed. This initial post starts at the beginning, with project launch.
Project Launch
Obviously, the situation at the initiation of your project will vary widely depending on your particular circumstances. A full discussion of this is beyond a blog post, but two factors will be different due to the distributed nature of the project: Initial Organizational Structure and Initial Subsystem Model Maturity.
Initial Organizational Structure
Depending on your particular situation, your distributed project will initially be structured in one of a few different ways:
- It starts with multiple groups.
- It starts in your own group, with plans to introduce other groups later.
- The initial concept is a simulation within one group, but the situation changes and other groups are invited later.
Launch with Multiple Groups
Most of the distributed MBD projects on which I have worked have started with different groups right from the beginning. This typically occurs for different reasons:
- Another group has an existing subsystem model with a level of maturity that is difficult to replicate. At the beginning, this type of project will be driven by the need to get your own models sufficiently advanced to support the more mature subsystem model.
- You are launching a large project from scratch, and upper management has decided that other groups should be included. This sometimes happens in DoD contracting.
- You are adapting an existing distributed project for a new purpose, such as analyzing a variant of an existing product. Although any organizational structure is possible, my experience suggests that the supporting groups will provide the same engineers that have already been working on the project.
If you are managing this type of project, you’ll have time to adjust the project to the different cultures within, and interaction between, the various groups before the project grows to full scale. In addition, if this is your first distributed MBD effort, you’ll be getting your feet wet while the project is still small.
Launch Within a Single Group, With Plans to Distribute the Project Later
I’ve worked on a several projects that started within just one group, with plans to bring in other groups as needed. These projects were started as either proof-of-concept or feasibility study, with plans to eventually produce a full product.
Although the projects were started within one group, we usually had a good idea of which groups we would add to the project, and which models we would incorporate. Although they were not on the payroll, we could usually get enough of input from the other groups to understand how we needed to structure the project for the future growth. We would not invite the other groups until the simulation was fairly mature and we had demonstrated the viability of the project.
Because we could anticipate the technical needs of the other groups, the engineering difficulties are not very different from starting as a distributed project.
However, introducing another group into a moderately mature project presented organizational challenges. A certain workflow was established in the initial stages of the project according to the personalities and skills within the group, and this would need to be significantly recalibrated to incorporate the culture of another group.
Launch Within a Single Group, and Plans Change Later
I’ve contributed to a few projects in which we invited another group that we hadn’t originally anticipated. There are many reasons for this, but for the projects I supported, it was due to the dynamics of DoD contracting.
This sort of project launch is the most challenging, both technically and organizationally. The project was not initially structured to deal with the challenges of distributed development, and sometimes there is resistance to the change from personnel in both groups.
Subsystem Model Maturity
If your project is completely within your group, your team can usually structure the project so that the components evolve together as fidelity and functionality grow. However, the nature of distributed MBD can mean that your distributed projects can launch with a serious mismatch in subsystem model fidelity.
As I described in my previous post on subsystem model reuse, the fidelity of the components in your simulation should approximately match the fidelity of the overall simulation, and as I described above, a common reason for inviting another group into an MBD project is to take advantage of an existing, mature subsystem model. Starting a project with one high-fidelity subsystem model means that the other subsystem models will need to catch up before the high-fidelity component can even begin to run.
Starting a project with more than one high-fidelity model, each from a different group, can be very challenging. Because the models came from different groups, it is not likely that these components can work together as-is. Strategies to manage this are described in my post on subsystem model reuse.
SystemBlend™
The SystemBlend™ application suite was designed to address the issues in distributed MBD development, while being minimally intrusive. This means that it directly addresses the above issues, because it can be readily introduced to new projects and to projects that are well underway.
Because SystemBlend™ precisely defines the needs of each component, your team can specify what level of fidelity is needed for each component, so that they can be adjusted to match the fidelity needed by your group. This allows the different groups to implement their subsystem models with minimal managerial intervention.
Starting with SystemBlend™ is low-risk, because it supports your project throughout its lifecycle, from initial feasibility studies to a full simulation with enough fidelity to support detailed engineering decisions.
Other Articles in this Series:
- Part 1: Project Launch
- Part 2: Updating Components
- Part 3: Adding Components
- Part 4: Splitting Components
- Part 5: Replacing Components
- Part 6: Component Delivery
- Part 7: Imprecise ICDs
- Part 8: Misinterpreted ICDs
- Part 9: Naming Collisions
- Part 10: Simulation Parameters
- Part 11: Simulator Configuration
- Part 12: Location Independence
- Part 13: Shared Parameters
- Part 14: Data Capture
- Part 15: Architecture Updates
- Part 16: Deprecating Components
- Part 17: Project End-of-Life
Note: This post has been updated with links to other posts in the series