Politicians and Computer Systems

[Dunners]

I've had to lead on a few IT procurement projects over the years, and the ones that I'd describe as a relative success were always simple, and where it was possible for me to be very clear about what outputs I required.

However, all to often, you end up with vague wish lists compiled by committee and usually just to address an audit recommendation for which nobody remembers the reason it was made.

Another problem is that, in the time taken to decide an IT system is needed, and when it is delivered, the world will have completely moved on. Agile working aims to reduce the impact of this but I have yet to see it completely eradicate the effect.

I like the aviation sector's approach. Their over-riding requirement behind any IT is that it is entirely reliable. Therefore, something like an in-flight navigation system will be based on hardware and software that is at least ten years old. It is tried and tested, boring, out of date - but you know what it will do and that you can depend on it to work.

[BoniO]

I've had to lead on a few IT procurement projects over the years, and the ones that I'd describe as a relative success were always simple, and where it was possible for me to be very clear about what outputs I required.

However, all to often, you end up with vague wish lists compiled by committee and usually just to address an audit recommendation for which nobody remembers the reason it was made.

Another problem is that, in the time taken to decide an IT system is needed, and when it is delivered, the world will have completely moved on. Agile working aims to reduce the impact of this but I have yet to see it completely eradicate the effect.

I like the aviation sector's approach. Their over-riding requirement behind any IT is that it is entirely reliable. Therefore, something like an in-flight navigation system will be based on hardware and software that is at least ten years old. It is tried and tested, boring, out of date - but you know what it will do and that you can depend on it to work.

I broadly agree with you here but, re your last paragraph, hardware that is "at least ten years old" is not reliable. Computer hardware failure rates are best described by an inverse bell diagram (or bathtub diagram). Failures are high during the first year, rapidly falling away over the next 3-4 years then rising dramatically into the 5th year and onwards. Of course, this is an average picture of many hundreds of thousands of systems. There will always be outliers. But the point is that old systems are not reliable.

[Disoriented]

I've had to lead on a few IT procurement projects over the years, and the ones that I'd describe as a relative success were always simple, and where it was possible for me to be very clear about what outputs I required.

However, all to often, you end up with vague wish lists compiled by committee and usually just to address an audit recommendation for which nobody remembers the reason it was made.

Another problem is that, in the time taken to decide an IT system is needed, and when it is delivered, the world will have completely moved on. Agile working aims to reduce the impact of this but I have yet to see it completely eradicate the effect.

I like the aviation sector's approach. Their over-riding requirement behind any IT is that it is entirely reliable. Therefore, something like an in-flight navigation system will be based on hardware and software that is at least ten years old. It is tried and tested, boring, out of date - but you know what it will do and that you can depend on it to work.

I broadly agree with you here but, re your last paragraph, hardware that is "at least ten years old" is not reliable. Computer hardware failure rates are best described by an inverse bell diagram (or BELLEND diagram).

Fixed for you.