ArgonDigital - enterprise automation experts

Share This Post

Torpedoing Projects

I saw an interesting talk at INCOSE 2007 called Damn the Torpedoes! Lessons from Underwater Warfare. Terje Fossnes, from the Norwegian Defence Procurement Division – Submarines, talked about five cases from history of torpedo failures and went through the core causes behind the those. It was an interesting look at non-software projects in history (and a unique topic) that clearly failed, and to see common issues we still face today.

Here is a summary of the points he made about common issues across those failures:
1. Introducing unstable technology

New technology was introduced too early. They adopted the technology early to
gain a competitive advantage. If it works, that is great, but if not, the
results can be disastrous.

2. Lack of product verification

Engineers tend to believe in their own abilities and shortcut their testing.
There is executive pressure to deliver quickly and cheaply. Consequently,
testing may have been cut short. Though it is much more common to see extensive
testing today, it seems the lesson has been learned.

3. Lack of stakeholder involvement

In the cases of torpedo failures, very few stakeholders were involved. Those
that were involved played roles in planning, testing and accepting results.
However, they did not know of assumptions that were being embedded in the design process.

4. Lack of cooperation and information sharing

The projects with failures demonstrated a lack of collaboration. The crews
reported failures, but were later blamed for incompetence. They were not told
about workarounds that were implemented, so they did their own thing to fix
them, and it turned out worse. And sometimes engineers warn of design issues and
just are not believed.

5. Maintenance and training issues

Errors were introduced in maintenance. They ignored wear on the systems. They
skipped training.

6. Shortcutting the process

It is important to explicitly tailor the process if the activities do not add
value. However, in these projects, the tailoring was typically by accident or
because they were out of time.

All of these are interesting, and we’ve probably all seen them in different forms. The interesting ones to me are 3 and 6, as they relate to the requirements efforts failing – either in not using the right stakeholders or shortcutting the process, specifically the requirements process. These are definitely still problems today.

As an interesting side-note, he shared with us that it is not commonly known that torpedoes actually pass 5m below the ship, instead of impacting it directly. It’s the force of the ship coming down and hitting the water that breaks it. Some of my coworkers challenged this, so no promises that it’s actually correct!

Torpedoing Projects

More To Explore

AI to Write Requirements

How We Use AI to Write Requirements

At ArgonDigital, we’ve been writing requirements for 22 years. I’ve watched our teams waste hours translating notes into requirements. Now, we’ve cut the nonsense with AI. Our teams can spend

ArgonDigital | Making Technology a Strategic Advantage