Introduction

Moving a company from traditional engineering processes to model-based processes (or any new process for that matter) is a tricky endeavor.  It’s easy to start enthusiastically, and then witness the whole effort crash and burn, or just fade into oblivion.  For those of us who are enthusiasts for modern practices, this can be extremely frustrating.  For those of us who have been given the tricky task of implementing a model-based process in our organization, it can be demoralizing to see our efforts fail. What can we do about these outcomes, other than run away in fear from a presumed MBSE monster?  If you want to avoid a monster movie playing out, this two-part article is for you.

Over my decades of systems engineering, I’ve seen many variations of attempts to install modeling processes of some form or another into the system engineering process. I’ve learned to predict accurately whether a company will succeed or fail with their efforts, and I can predict it as early as the first 90 days of the start of an MBSE initiative.

Pretty bold claim? Well, I see things. I see dead processes. There are a lot more of those than living ones.  Part 1 addresses the issues that destroy your attempts at updating your process, and Part 2 addresses key elements to make it succeed.

Let’s start by getting a little more analytical about why efforts fail.

Part 1: Don’t Kill the Baby

You don’t want a process that’s DOI (Dead On Initiation) do you? You want an MBSE process that survives and benefits your organization. Before I tell you how to be successful, I feel I should give you an overview of what kills your MBSE process. After all, it makes no sense to nurture a new process at the same time you’re strangling it to death. So first take heed of these cautionary points to “process-proof” your organization before starting an MBSE initiative.

Grass roots efforts are doomed to fail

If you are relying on grass-root efforts among the engineering staff to boot-strap your MBSE initiative, you’re dooming yourself to failure. Sure, the grass-roots, die-hard MBSE engineers are the ones who will jump aboard the MBSE band wagon when it shows up (if at all.) They even provide the fertilizer to help the seeds of MBSE to grow. On the other hand, they cannot direct other engineers to follow MBSE standards, nor direct change in programs or organizations.

If you’re relying on grass-roots efforts, your MBSE initiative has already succumbed to drought, chinch bugs and died below the surface.

Dropping tools onto engineers computers is just fumbling the ball

So maybe you’ve decided to fork over some of your budget and purchase a set of licenses for the latest and greatest MBSE tool. Then you push the tool to all your engineer’s computers and let them have at it. Nice thought, but ultimately a bad idea. The engineers probably don’t have the time or charge number to learn how to use the tool. If they do find time, each engineer will fumble around until they develop their own approach and methods. There is no ability to transfer tool skills between work groups or programs if everybody is engineering their models differently.

If you think all you need is an MBSE tool pushed out to engineering, you are sadly mistaken. When push comes to shove, your lack of attention to your tool roll-out will have pulled your MBSE initiative to its death.

Executive mandates are ignored in the trenches

Maybe, in a fit of hubris, you decided to issue an executive mandate to use MBSE techniques on all programs, and use the company selected tool. I’ve even heard the suggestion to make MBSE techniques part of the yearly performance review criteria. On the surface this seems to make sense. It shows the company backs the MBSE initiative.

On the other hand, down in the engineering management trenches, the staff knows there’s a much more important mandate: get the job done on schedule and make a profit. As a result, the MBSE implementation will be absolutely minimal, that is, just enough to check the box that the MBSE mandate was followed. MBSE will ultimately have little or no impact on the program.

If you think all it takes to get MBSE off the ground is a mandate from the VP of Engineering, then feel free to tick that box on your management checklist. The box is checked, but the entire MBSE initiative checked out long before the use case analysis began.

Exceptions multiply like weeds

Maybe you’re smarter than most organizations and bootstrapped an MBSE initiative without falling into any of the previously described traps. Did you recognize that sometimes MBSE will not be appropriate, or that some engineers or manager will not be up to speed when necessary? If so, you’ve probably granted some exceptions to the MBSE process, or have been otherwise lax in enforcing your process. Maybe the engineers are bringing Visio and PowerPoint versions of their diagrams to peer reviews, or even to more formal reviews. After all, Visio makes a more pleasing diagram than most MBSE tools, right? Maybe the engineers are skipping use case analysis because they see no value to it. After all, they never needed to do it before. It’s easier to follow the old, familiar path than try this new MBSE stuff. The engineers can make the case that following the old path is faster than doing all these new, unfamiliar MBSE processes.

Sure, Visio drawings might look better, but you can’t accurately engineer a solution using non-standard artist’s renditions of the proposed solution. You need the engineering drawings, and those come out of your MBSE process and tool using standard notation. You need ALL the engineering artifacts in your process to be in your MBSE tool’s database in order maintain correct and useful relationships from top to bottom.

And of course, there is a learning curve to deal with in any new endeavor. Don’t forget, the OLD processes had learning curves too.

Do remember, that if you allow exceptions whenever the engineer feels like it, you’ll see everything grow except the MBSE process you wanted.

Bad Management Practices You Can’t Change

Naturally, these are not all the anti-patterns leading to failure. There are other systemic issues to be aware of. Changing executive management in the middle of an MBSE roll-out will often kill off the initiative. Changing corporate values to satisfy the shareholders at the sacrifice of company performance will do the same thing. These are not MBSE specific issues, but overall management problems than run rampant through corporate culture. There’s little an engineering manager can do to fix these.

On the other hand, the engineering managers in charge of MBSE processes do have things in their power they can leverage to make MBSE work. Those will be addressed in part 2.

Subscribe to vmcse.com for updates and more articles addressing these information management problems and more.