So I went ahead and read the MCO Mishap Phase 1 report (linked here: http://www.icics.ubc.ca/~cics525/handouts/handout_MCO_report...) and I'm having a hard time finding something that backs up the wiki summary of two navigators raising concerns and having them dismissed.

The report does go ahead and state all sorts of organizational (and otherwise 'soft' issues) that contributed to the end failure.

The report notes that earlier deviations between measured and modeled results were noted, however, they were hampered by limited data (in the sense that they couldn't measure what they wanted). It is implied (though not stated) in the report that in the absence of appropriate data, the operations navigation team attempted to contain/mitigate the deviations instead of 'solving' it.

The report also notes substantial organizational issues. Different navigation teams were used in development and operations, and there were insufficient knowledge transfer during hand-off that hampered the operations navigation team ability to notice these issues. Communications between the main operations team and the ops nav team were not effective. They were apparently spatially separate teams. In addition, model-measurement conflicts which were brought up were solved via e-mail instead of over formal processes. The report suggests that systemic use of formal processes may have allowed teams to uncover the problem earlier in time.

And of course, the report also states that insufficient verification/validation of the supplied software was not completed. The entire section on verification/validation (MCO Contributing Cause No. 8) is just a giant cringe fest.

The implication is that the MCO project was just... not run well.

First - Great job finding this report. Thank you for that.

So had a look at the report.

There was one more problem actually. This machine, the MCO, had asymmetrical solar panels which would cause solar pressure ( force by sunlight ) to create a very mild spin ( angular momentum ). Now this angular momentum had to be desaturated time to time in order to keep this machine stable. Now, one module called SM_FORCES calculate this adjustment and feeds to AMD ( Angular Momentum Desaturation ). Now, this SM_FORCES & AMD uses different unit system, which was ignored by whoever wrote this connecting piece of program. Due to this error desaturation was not enough ( or more ) and it kept building over the period of 9 months.

Now, I notice that NASA has a separate team to navigate this machine to mars. There data showed this angular momentum adjustment event occurred 10-15 times more than expected. It was like a man walking with one leg shorter than another. It's a 9 months journey from mars to earth. They must have seen the first sign to inconsistency with in first few weeks only, just guessing though.

In this report, out of 8 possible contributing causes, at-least 3 are attributed to navigation team. I think success of such mission depends not only on meticulous planning but also on thinking on the feet ability of the team. ( Any Apollo 13 fans? :) )

"They" didn't destroy it; it was destroyed by the Martian atmosphere.

…At least, that's the official story. I recall there being a lot of conspiracy theory-like buzz at the time from people who also couldn't believe NASA could make such a stupid error like that. It does make you wonder.