So I went ahead and read the MCO Mishap Phase 1 report (linked here: <a href="http:&#x2F;&#x2F;www.icics.ubc.ca&#x2F;~cics525&#x2F;handouts&#x2F;handout_MCO_report_4pp.pdf" rel="nofollow">http:&#x2F;&#x2F;www.icics.ubc.ca&#x2F;~cics525&#x2F;handouts&#x2F;handout_MCO_report...</a>) and I&#x27;m having a hard time finding something that backs up the wiki summary of two navigators raising concerns and having them dismissed.<p>The report does go ahead and state all sorts of organizational (and otherwise &#x27;soft&#x27; issues) that contributed to the end failure.<p>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&#x27;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&#x2F;mitigate the deviations instead of &#x27;solving&#x27; it.<p>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.<p>And of course, the report also states that insufficient verification&#x2F;validation of the supplied software was not completed. The entire section on verification&#x2F;validation (MCO Contributing Cause No. 8) is just a giant cringe fest.<p>The implication is that the MCO project was just... not run well.