Oops, was that me?
I was one of the consultants on the FiReControl project, being there for 2 years, and can answer some of the questions posed here.
The main problem, as with most government IT projects, is that the initial requirements were very poor. There were several thousand requirements written down, which ranged from ones that were barely a sentence, to ones that were half a page of A4. These were further confused as the bid documentation was considered "in contract" to supply.
Even as late as Dec 2010, (some 5 years after contract award and already several years late) there were still arguments going on as to what many of the requirements meant! It was typical end user vs consultancy stuff: where a poorly written requirement wasn't definitive, the customer wanted it to do all that was written PLUS all that was implied PLUS all that they'd thought up in the intervening years (which changed on a weekly bases depending on which customer rep you were talking to), whereas the consultancy wanted to do the minimum that could possibly be interpreted.
This is a real example that I heard about: in the bid submission document the consultancy had said (I'm paraphrasing): "We will supply tablet PCs which have inputs that can connect to a range of external devices, e.g. a fire appliance low battery warning system."
The customer insisted then that a low battery warning system, connection and software was part of the agreed requirements and refused to sign off that part of the design without it. The consultancy contended that it wasn't, and that this was just an example of what could be done had the customer chosen to opt for it. This was one of *thousands* of requirement issues that were raised. As a result, sign off from the customer on any document took literally months and months.
When work was finally done to atomise the requirements into single, simple, unambiguous, testable statements, the requirements count passed 15,000 as I recall. This problem was replicated between the prime contractor and the 9 sub-contractors, as each of these thousands of requirements had to be flowed down to a sub-contractor via a signed off design or held internally.
Put bluntly, the project died under it's own weight in paperwork. It was a classic waterfall IT project fail, that sought to change the systems, processes, people, technology and even locations, all in one almighty big bang. It was never going to work.