Beagle 2 is back in the news, having been found on Mars. Topped only by Scott in the list of great exploration failures, we can take three important lessons in programme management from this hapless initiative.

Control project costs

The original estimates for the cost of the project were £24 million. It ended up costing more than £42 million. But don’t let the rocket science chic of this project make this seem exceptional. Large cost overruns on technology projects are commonplace and most of these occur with technologies and business processes that are well understood.

Test in realistic environments

Okay, so not many people would argue that simulating the conditions on Mars to test the landing process is easy. We can’t go there to do pre-release testing and we don’t have a great understanding of how it will be when we get there.

But you don’t need to go to Mars to experience these problems. IT systems are routinely tested in environments that have significant and critical differences from the operational environments they will be deployed in. And if you want evidence that we can’t explain how it will be in live, take a look at most projects' non-functional requirements.


And this was probably the biggest failing of Beagle 2: it didn’t communicate. Until now, its lived in the Mary Celeste category of voyages. In fact, a key recommendation of the ESA enquiry into the Beagle 2 mission was that spacecraft must be able to communicate their status during deployment. It’s not just for command and control either. Paolo Ferri (the head of operations at the European Space Agency's mission control) said: "You're allowed to fail, so long as you know why you failed."

Beagle 2 wouldn’t be in the news now if it had been able to send back information, such as where it was or why it failed. We still don’t know why it failed. Maybe Mr Ferri will never be able to give Beagle 2 permission to fail.

Contact acutest