Complex systems do not “fall into place” of their own volition; if one domino is out of place(1) the chain of blocks will halt. When projects are incremental updates then “day-to-day” leadership is all that is required. But when you are shooting for the moon, new processes are required and understanding orbital mechanics is critical…
Adoption and migration
As a consultant my job is to enable moonshots as I guide companies on the adoption of Model-Based Design software processes. With every company I’ve guided, with the exception of some startups,(2) there is a contingency that says a version of Admiral Hopper’s(3) dangerous phrase. The objections decompose into three categories…
- The way we do it now is positive adjective.(4) The objection here is generally on a technical basis and can be addressed.
- It will take too long to adopt: In the short run, this objection is accurate. But companies that operate in the short run do not have long runs.
- But then what would I do? Adopting new processes necessitates changes to organizations; in some cases this does mean that some roles are changed or are eliminated.(5) But more often this is a chance for people to take on new more dynamic roles.
What leaders offer
Most people want their work to mean something. Leading the MBD/MBSE adoption process makes it easy to offer each individual something(6) that will facilitate their work. Defining with them the current limitations of their processes and enumerating the benefits along the way to change is the first step in transformation.
The <positive adjective> case
Groups raise objections to Model-Based Design based on the perceived technical merits of their current processes. The essence of these arguments can be distilled to the contrast between a master craftsperson and an assembly line. In their objections they select the work of the most skilled team member and compare it to the automated products.
The quality of a master craftsperson’s work will almost always be higher but it takes longer to produce. I shift the question to: where should a master craftsperson be spending their time? In the creation of screws or on the design of the watch? Model-Based Design automates low level processes allowing masters to invest in the high level vision aspect of the project
A second <positive adjective> case exists due to the tension between software and controls engineers. Each has a unique skill set that is critical to the overall product; each has part of their task that is dependent on the other’s work. Unguided, this is a source of conflict.(7) MBD / MBSE provides a common ground where the two sides work together; controls engineers can design to their imagination’s limit while the software engineers can integrate, safe in the knowledge of functional interfaces. Guided, MBD / MBSE enables the two groups to work together while focusing on their domains.
Establishing a new workflow takes time. But if the development timeline is longer than 6 months the downstream ROI is significant.
- Need identification
- Initial rollout
- Workflow augmentation / tooling
- “Final” rollout
Most companies I have worked with come to me at step 3, initial role out.(8) From the initial to final rollout out stage, there is generally a 2 year process with the first benefits realized at the 3 month mark.
The key to maintaining forward motion on a project is to define functional interfaces such that work products can be utilized at any(9) stage in the migration process. Having a road map of the adoption process enables you to see this with clarity.
The truth is that often resistance to change comes from perceived job or group security. In 10+ years of guiding groups towards new processes the only time I have seen groups lose “territory” was when they resisted change arbitrarily.(10)
In the end, everyone in a company is there because they have skills and insights that will benefit the project; the objective of a MBD cartographer is to show them the way. In the end it comes down to showing them they are the engineer, not the hammer.(11)
Are you ready to go on journey?
Most modern organizations are in a state of consistent incremental change. This sort of unguided updating will result in inconstant and incomplete processes. Deciding the journey you need to take is the first step; let’s talk about where you want to go.
- Proper planning however means that no critical path should be dependent on a single domino. The planner has redundancy built into the system.
- In startups there is often the the inverse problem, a rejection of all traditional development practices thus “throwing the baby out with the bathwater.”
- For those not familiar with Admiral Hopper, I recommend this link to see her foundational impact on computer science.
- If you haven’t played “MadLibs” this site gives you a rough idea.
- While some roles are eliminated it is rare that I have seen people laid off due to migration to Model-Based Design / Model-Based Systems Engineering. Also see (10)
- People within an organization are aware in a visceral sense of the problems they face with existing workflows. Tied to their daily tasks they don’t have the freedom to imagine and enact change; leadership illuminates the path forward.
- In an idealized workflow the controls engineer, who has a CS background writes the algorithms in a highly efficient modular fashion that is simply integrated into the network typology defined by the software group.
- Part of my job as a consultant is to identify if they have sufficiently covered steps 1 and 2. When you are new to a process it is easy to overlook benefits and pitfalls of the process and make plans that do not reflect best practices.
- In practice there will be some “throw away” work; however this can be minimized with proper planning.
- The groups that raised issues and facilitated the process grew in size and responsibilities.
- A short version of it can be found here.