Try reading it again, that's not what it says.
In fact, it explictly states that they *did take into account the pre-launch directories, *and* had sent commands to erase them once the new software was successfully uploaded and functioning as a replacement.
The problem was that the transmission instructing the Rover to delete the old directories was not properly received (due to signal noise), and thus the instructions were rescheduled for retransmission.
But before the retransmission occurred, the Rover's storage space filled up.
It seems inappropriate to blame this on a "Project Management failure".
[Highway55:] Incompetence!
No, bad timing.
[thoughtomator:] Sloppy code... patched by more sloppy code.
It wasn't "sloppy code" that caused the problem. In fact, it was due to being careful enough to keep the original code onboard until they were sure that the new code was functioning successfully and they knew it was safe to issue a command to the Rover to delete the old code. And there's no evidence that the patch was in any way "sloppy". The error arose because the command to delete the old code failed to arrive on time due to normal communication failures.
[quantim:] A classic example of bureaucratic incompetence, not unlike the metric conversion nonsense awhile back. While I totally support these projects, bloated management is responsible.
How do you figure that?
It was incomplete QA that did not take into account these scenarios that were not out ot the realm given the conditions.