Category: Systems Engineering

By Posted on

Shortly after midnight Moscow time on the 27th of September 1983, Stanislav Yevgrafovich Petrov saved the world. This incident, unknown outside of the Soviet air defense forces until 1998, is a highly relevant case study as we accelerate the pace of automation and artificial intelligence in complex military systems. Cold War backdrop Cold War tensions between the US/NATO and USSR/Warsaw Pact were higher than they’d been since the Cuban Missile Crisis. Both sides had intermediate-range nuclear missiles on alert, treaty negotiations were breaking down, and NATO was preparing to deploy upgraded Pershing II and additional Ground Launched Cruise Missile systems …

Artificial Intelligence and Human Judgement: A Cold War Cautionary Tale Read more »

By Posted on

Our world and our systems are safer than ever. A major reason why is that we’ve learned from prior mistakes. Many of our practices, rules, and standards are “written in blood” from past, tragic failures. We learn so that we don’t repeat the same mistakes. Of course, we first identify the proximate causes—the specific events directly leading to a casualty. To truly learn, we must take a step back to examine the larger context: what were the preceding holes in the Swiss cheese, and how do we account for them in our systems engineering practice? This approach is increasingly important …

Written in Blood: Case Studies of Systems Engineering Failure Read more »

By Posted on

One of my favorite items in my small model collection is a 1:34 scale Grumman Long Life Vehicle (LLV) with sliding side doors, a roll-up rear hatch, and pull-back propulsion. The iconic vehicle has been plying our city streets for nearly 40 years, reliably delivering critical communiques, bills, checks, advertisements, Dear John letters, junk mail, magazines, catalogs, post cards from afar, chain letters, and Amazon packages.

By Posted on

The Navy installed touch-screen steering systems to save money. Ten sailors paid with their lives. ProPublica Ten sailors died after the crew of the destroyer USS John S. McCain lost control of their vessel, causing a collision with the merchant tanker Alnic MC. There was nothing technically wrong with the vessel or its controls. Though much of the blame was put on the Sailors and Officers aboard, the real fault rests with the design of the Integrated Bridge & Navigation System (IBNS).

By Posted on

The concept is simple: create a version of your solution that’s just good enough and put it out in the real world to validate assumptions about the product and market. That way, if your assumptions are wrong, you can pivot or shut it down without having spent too many resources on a failed idea. If your assumptions are right, you’ll have some great feedback to propel you along and help populate your product roadmap.

The term is often misapplied. Learn what an MVP is, what it isn’t, and how to leverage them for the success of your concept.

Read more ›

By Posted on

A common misconception is that Agile development processes are faster. I’ve heard this from leaders as a justification for adopting Agile processes and read it in proposals as a supposed differentiator. It’s not true. Nothing about Agile magically enable teams to architect, engineer, design, test, or validate any faster.

Read more ›