Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Businesses The Almighty Buck IT

Ships Turned Away As Aussie Customs' IT System Melts Down 327

An anonymous reader writes "Urgent shipments of medicine and goods for the holiday season have been turned away by customs officials due to a massive computer problem. The initial budget for the system upgrade was said to be A$80 million but has since blown out to A$250 million. Customs officials and the government have been forced to admit that they might actually have to revert to the old system if things don't improve. One cargo user said on national TV that he used to process 300 orders daily but the new system is so complex and unusable, he's happy if he can manage 100 orders per day. The system failure is expected to have a massive impact especially on the retail sector this Christmas."
This discussion has been archived. No new comments can be posted.

Ships Turned Away As Aussie Customs' IT System Melts Down

Comments Filter:
  • by ForestGrump ( 644805 ) on Friday October 21, 2005 @02:14AM (#13842514) Homepage Journal
    Simple solution. Push it back 6 months till when it's actually cold!

    Grump.
    • Wonder if the person who modded this as a troll has ever seen the idiot scenes of Santa CLauses running around in heavy red costumes, with a full white beard and hat included, while everybody else is trying to move and to wear as least as possible because of the heat.

      Or hearing people sing songs about snow and dark winter nights while it's +40 `C...

  • by BladeMelbourne ( 518866 ) on Friday October 21, 2005 @02:15AM (#13842517)
    I hope my shipment of inflatable Love Dolls makes it through customs, otherwise it's going to be a lonely new year.
  • From an Australian (Score:4, Interesting)

    by tezbobobo ( 879983 ) on Friday October 21, 2005 @02:16AM (#13842520) Homepage Journal
    This is news generally because of the rarity of this sort of thing. The only real issue I can think of is that our Health Minister has recently announced plans to immunise ALL Australians against bird flu. This could disrupt that (if it was realistic anyway). I guess this is all a part of ever increasing control.
    • Re: (Score:3, Informative)

      Comment removed based on user account deletion
    • It starts off as rare, but you see that little pi symbol in the corner of their website. Don't even think about it...
  • Comment removed (Score:3, Insightful)

    by account_deleted ( 4530225 ) on Friday October 21, 2005 @02:17AM (#13842521)
    Comment removed based on user account deletion
    • Not knowing what they are using I can't exactly say you're wrong but I'd put good money on it that you are.
      The shipping yard they are talking about is huge, having upon hundreds of containers coming in weekly, I highly, highly doubt it is running with comodity user PC's as the backend.
      Also, the problem that is being cited as the reason is the complexity of the system, not that it's running extremely slow.
      • According to transport.nsw.gov.au [nsw.gov.au] Botany transfers 1.1 million 20' containers a year or about 3,000 containers per day. So, no, you are right it won't be a PC in a basement room. It'll be some big iron running this web based app.
        • A cluster farm of commodity PCs is easily capable of handling 3000 transactions per day, assuming that your system isn't run by morons. I'd tend to attribute these problems to more general IT/software development issues, like the customers designing a more complex business process that doesn't address thier current problems, lack of adequate testing and customer feedback, important people (like end users) being left out of the design and testing phases and, of course, the ever popular "new shiny" syndrom
    • by fidoandfido ( 578718 ) on Friday October 21, 2005 @02:24AM (#13842543)
      I am an aussie, and as far as I know the backend is all mainframe based, and the frontend is web based or something. Rumour has it the whole project was a cluster something or other from the outset - it was outsourced to the lowest bidder, poor requirements led to poor design, deadlines missed and another IT disaster. But too much spent now to cancel it.
      • "But too much spent now to cancel it".

        It is never too much spent to cancel it unless it is going to be fixed for free. Don't throw good money after bad.

        [begin: OT]

        Does anyone else feel that this will cause an increase in fuel demand, therefore cause yet another increase in petrol prices? I can see it now, the petrol companies have to operate on Sunday to meet requirement*. To offset the increase in salaries of the employees, the petrol companies have passed the expense to consumers and they will now pay $1.
        • by BenjyD ( 316700 ) on Friday October 21, 2005 @05:27AM (#13842986)
          Yes, petrol companies operate on Sundays. Refineries are so complex these days they can take weeks to switch off or on, so they operate constantly. I have heard of some older ones which have been modified and added to so much over the years that nobody actually knows how to switch them off safely - there are companies whose sole purpose is to go around figuring out the best way to switch plants off.
    • by daern ( 526012 ) on Friday October 21, 2005 @02:31AM (#13842570)

      What OS do they run?

      Why does this matter? It's much more likely that the problems are down to poorly specified, poorly designed or poorly implemented software, which is by no means an exclusive preserve of Windows...

      Too many large scale software projects fail because of poor development methodologies and a failure to interact with users during development and when this happens, it's hardly surprising that the users don't like working with the new system.

    • by ChatHuant ( 801522 ) on Friday October 21, 2005 @02:51AM (#13842631)
      What OS do they run?

      What software do they use?


      CA, NCR and IBM are the service providers; Novell's providing the directory service.

      The ICS (Integrated Cargo System) application is running on an IBM OS390 mainframe; the OS is ZOS, the database is DB2. The web interface is Java, using WebSphere.

      The CCF (Customs Connect Facility) runs on Sun Solaris Unix platforms (using a variety of other servers for validation and transformation). Again, the database is DB2 and the interface uses WebSphere Java.

      More information here [idg.com.au].
      • Wow, I'd like to comment on this but all of the software you just mentioned is such expensive, proprietary software for systems I'll never possibly manage that I have no real idea what's going on with this IT disaster.

        I guess I'm just not sure how such reliable companies using expensive, supposedly reliable products could have been involved in such a failure.
        • Well, yes.. (Score:2, Insightful)

          by musakko ( 739094 )
          all of the software you just mentioned is such expensive, proprietary software for systems I'll never possibly manage that I have no real idea what's going on with this IT disaster.

          I love open source software too, but isn't the budget blowout on this (triggered by scope creep etc. like most projects) going to be the cost of services (ie. people), rather than the software itself? If anything, it would be harder to find enough people skilled up OSS people in Australia and that would make the project cost ev

      • by ErroneousBee ( 611028 ) <neil:neilhancock...co...uk> on Friday October 21, 2005 @05:04AM (#13842942) Homepage
        Ah, its using Java. They just have to wait for the VM to start up and things will start running swiftly, in another fortnight or so...
      • by afd8856 ( 700296 ) on Friday October 21, 2005 @06:20AM (#13843137) Homepage
        I have a feeling that all this "complexity" that they're talking about has nothing to do with the backend and has everything to do with the user front-end. They should have hired some good workflow and interface designers as well, not just expensive consultants.
    • by pookemon ( 909195 ) on Friday October 21, 2005 @06:35AM (#13843180) Homepage
      What OS do they run?

      The same OS they've been using for a while (WinXP)

      What software do they use?

      Is a custom built system - written by EDS I believe.

      And how will their IT people and/or management continue to justify said choices in the wake of this?

      "Their" IT people didn't make the choices - Customs IT is provided by EDS (which is why I believe EDS also developed the system). The choices would have been made by higher management - but ultimately it doesn't matter, if the system is failing then it's the design of the system or the hardware in use - which I would expect is top dollar equipment, charged for at higher than retail prices (it's a government contract). The IT experts in Customs are more for retrieving data of hard disks after they've been seized etc. Customs hasn't managed their own IT for years now.

      This is the sort of thing that needs "big iron". Machines that have uptimes measured in decades. Why do I have the sneaking suspicion that they're running it all on a bunch of commodity PCs (or the like) with off-the-shelf software?

      This is laughable at best. How many "off the shelf" packages have you seen for handling Customs? The new package (and the old I expect) is a custom built piece of software (heck even the summary pointed this out - A$80 million but has since blown out to A$250 million - that is not "off-the-shelf")

      The system itself was written specifically for customs and has great features like it was too big to fit on all the monitors that customs was using (so naturally EDS upgraded all the machines - at a price - to have 19" LCD's).
  • Curious... (Score:4, Funny)

    by the_skywise ( 189793 ) on Friday October 21, 2005 @02:23AM (#13842538)
    It'll be interesting to see what the ultimate culprit is. (overpriced IBM/Accenture contractors, Indian outsourcing, Windows, Linux, etc)

    But I'm 99% sure it'll have something to do along the lines of:

    "Mate, we need a new Customs software system."

    "No prob. We'll do it in [whiz bang technoterm du jour]"

    "That's it?"

    "That's it. [whiz bang technoterm du jour] using [whizbang development process du jour]"

    "But what about things like useability? Proof of concept? Customer Support if the design proves unwieldy?"

    "Top. Men."
    • Re:Curious... (Score:3, Informative)

      by marko123 ( 131635 )
      I listened to a report about it on the radio this morning, and the system was started in 1994 and ran on Windows 3.1. Then they upgraded it to Windows 95. I takes 25 minutes to process what used to take 25 seconds on the old system. 135 million dollars from an initial bugdet of 25 odd million.

      Makes me feel a bit better about my job.
    • Here is a document giving the project numbers [idg.com.au]. This thing is big. Excerpt:

      Integrated Cargo System (ICS)

      The cornerstone of CMR, ICS is an integrated system giving enhanced risk assessment at the border and allowing more efficient cargo tracking. Its software suite has 23,000 function points.

      It operates on an IBM OS390 mainframe [they mean zSeries] running z/OS with transactions in a CICS environment with DB2 database management. MQ-series provides the mainframe interfaces with the CCF gateway and oth

  • was said to be A$80 million but has since blown out to A$250 million.

    And with these latest problems, it's going to get much more expensive. Tra la, la-la-la.

    I love Christmas. Nothing says "Baby Jesus" and "Goodwill towards men" then a $250Million computer blowout, 10000 42-inch Plasma Screen TVs, Tickle Me Elmo and credit card debt up the wazoo. It's like some sick, sad joke.
  • by palndrumm ( 416336 ) on Friday October 21, 2005 @02:26AM (#13842552) Homepage
    All the news and radio reports I've read and heard (including TFA) have made no mention of ships being actually turned away at this stage. So far they're just saying that the storage space at the ports is rapidly filling up, so if the processing rate doesn't improve soon they will have to look at turning ships away. But as far as I can tell, they're planning to roll back to the old system before that becomes necessary...
  • The solution is... (Score:5, Insightful)

    by bmo ( 77928 ) on Friday October 21, 2005 @02:27AM (#13842557)
    For the AU government to let goods travel freely until they fix or bring up the old system. There really is no excuse for what is going on. Yes, that means that the AU government doesn't get its cut of taxes but them's the breaks. The money lost from import fees would be DWARFED compared to the lossess incurred by *not* letting goods through the ports.

    --
    BMO

    • Mod Parent Up... (Score:4, Insightful)

      by Rocketship Underpant ( 804162 ) on Friday October 21, 2005 @02:45AM (#13842617)
      Funny how to the state, free commerce isn't an option, but blowing $250 million that isn't even yours on a computer system that doesn't work is okay.

      "Your papers, citizen! Whoops, my citizen-authorization-scanner just went dead. You'll have to be detained while I get fresh batteries. Oh, and that'll cost $10 - batteries aren't free, you know."
    • by ftoomch ( 700184 ) on Friday October 21, 2005 @02:46AM (#13842620)
      And those incurred losses from *not* letting goods through would in turn be DWARFED compared to the long term economic havoc in a largely agricultural economy caused by pests and diseases (e.g. foot & mouth disease) that are also let through on unchecked goods.
      • by lamasquerade ( 172547 ) * on Friday October 21, 2005 @03:09AM (#13842677)
        Largely agricultural economy? Maybe in 1900. Well I'm not quite sure what classifies as 'largely', but given these [abs.gov.au] stats, I'd say Australia's economy is minimally agricultural. 3.7% to be exact. And the government subsidises that heavily (explicitly because of politics, and implicitly through idiotic short-sightedness, such as cheap-as-hell water for rice farmers, that's right, rice in the second dryest continent on earth). Some say the subsidies outweigh the real contribution to our economy. Maybe the best thing for us would be to have this sector destroyed, then we can get to cleaning up the mess they've created over the last two centuries, such as salination [wikipedia.org].
    • by csirac ( 574795 )
      As an Australian, when I hear "customs" I think: disease and pest control (our single biggest export is primary industries), drug detection, and general enforcement of importation restrictions (this includes import/export of endangered/restricted species, banned or restricted weapons, etc).

      "Oh yeah, they get import duty tax too..."

      For what its worth, what little I've purchased overseas (FPGAs, LCDs and microcontrollers) has never been slugged with import duty, even on a $9000 AUD order from the UK. I guess
  • by Anonymous Coward on Friday October 21, 2005 @02:29AM (#13842565)
    http://www.customs.gov.au/site/page.cfm?c=6361 [customs.gov.au]

    Partial quote...

    "Customs is doing everything possible to resolve technical and business issues arising from the introduction of the new Integrated Cargo System (ICS) for imports.

    "Contrary to some media reports, the new IT system for imports has not failed, nor is its performance solely responsible for the problems that have occurred.

    "The problems experienced in part, flow from inaccurate and incomplete information being submitted by some users, which the new system is designed not to accept for security reasons," the spokesman said.
    • The problems experienced in part, flow from inaccurate and incomplete information being submitted by some users, which the new system is designed not to accept for security reasons

      Operators of systems (whatever they are) look forward to new software so that they can change operational procedures. When the new system comes on line people blame the new system for their problems, when they may be partly a consequence of the modified processes.

      IMHO new systems should aim to be initially funtionally neutral to

    • "The problems experienced in part, flow from inaccurate and incomplete information being submitted by some users, which the new system is designed not to accept for security reasons,"

      This to me sounds like a design problem. They didn't consult the users and now things aren't working right. If the users say that they always have information X but they don't always have information Y, if the designers make information Y a requirement, then it's a poorly designed system.
  • I just can't stand it when they don't post whether it's a windows-based or a unix/linux-based implementation. I need to know whether I can indulge in schadenfreude or whether I have to make excuses.
    • by YrWrstNtmr ( 564987 ) on Friday October 21, 2005 @02:52AM (#13842637)
      I just can't stand it when they don't post whether it's a windows-based or a unix/linux-based implementation.

      How about...'it doesn't matter'.

      This is probably the result of a crappy design, with little interaction between the developers and the eventual users.

      It does what it was designed to do. The problem is the design and implementation does not match what it NEEDS to do.

      • It certainly doesnt matter that somehow they managed to get someone so stupid as to screw up with the very best. which is incidentaly what the entire system is built from

        This is the info [idg.com.au]
        "It operates on an IBM OS390 mainframe running ZOS with transactions in a CICS environment with DB2 database management. MQ-series provides the mainframe interfaces with the CCF gateway and other business applications. "
        And the CCF is run on
        "Communication channel management and CI runs on Sun Solaris Unix platforms and
  • Aussie customs (Score:5, Interesting)

    by Centurix ( 249778 ) <centurixNO@SPAMgmail.com> on Friday October 21, 2005 @02:31AM (#13842571) Homepage
    I was actually part of a company a couple of years ago which put through a proposal to assist with tracking firearms imported into Australia. We were shocked at what we found when we consulted several customs offices.

    There was no integrated network system between interstate customs offices.

    Sure, they e-mailed each other and did some odd bits of communication, but there was nothing solid in place. Part of our proposal was to put in a system where if a shipment of firearms was sent from Melbourne to Sydney the Sydney office would actually know that one was going to arrive. A step up from their existing system at the time, where the firearms actually left Melbourne, turned up at the Sydney customs depot without prior knowledge and then processed!
    • Part of our proposal was to put in a system where if a shipment of firearms was sent from Melbourne to Sydney the Sydney office would actually know that one was going to arrive.

      What's the point? I don't want the post office phoning me to say there's a postman going to be around later. What a waste of time. The sender knows everything important about the delivery, and in this case is actually doing the delivery, so what the hell is the recieving office supposed to do with the information?

      TWW

      • When you're delivering firearms, you want to know when they are expected to turn up, so that you start worrying if they don't arrive on time. Under the current system, the receiving office only knows about the firearms shipment if the sending office enquires whether they have arrived yet, or if they actually arrive.
  • Amazing. (Score:5, Insightful)

    by JavaRob ( 28971 ) on Friday October 21, 2005 @02:34AM (#13842581) Homepage Journal
    I'm no grizzled guru by any means, but damn, I know by now that though it *may* seem cheaper to upgrade all in one fell swoop, you're gonna get hosed every time. The bigger the system, the more likely, just because there's no way you can *test* the thing at that scale.

    Software is *complicated*. Large-scale software rollouts are even *more* complicated, just because now you've involved hundreds or thousands of non-debuggable, unpredictable people into the equation. No matter how many meetings you have about it, no matter how many different people assure you that they will do "whatever it takes" to make sure it goes smoothly, keep in mind that they probably don't have "what it takes", which would often be some kind of deity-level power.

    Let's look now at the "largest e-government projects ever undertaken", introduced "despite industry protests that Customs had not allowed them ample time for the changeover." It's not hard to guess how it's going to go.

    Sometimes, you gotta go the slow way... replace the old system bit by bit, make sure you can flip the switch back every step of the way if something goes wrong. At the very least you have to plan it from the start so that you can roll out piecemeal, just in one site, or run the old/new in parallel, etc..

    This method results in a more expensive *estimate* at the start of the project. But the actual *cost* in the end can be much, much lower.

    Just my 2c...
  • exchange rates (Score:2, Informative)

    by tezbobobo ( 879983 )
    80mil AUD = approx 50mil Euro = 60mil USD
    250 = 156 = 188
  • by TheNarrator ( 200498 ) on Friday October 21, 2005 @02:42AM (#13842609)
    Computer World Article [computerworld.com.au]

    ICS is a cornerstone of Customs' massive Cargo Management Re-engineering (CMR) project. This was intended to replace the export and brokerage industry-developed EDI system Customs Connect with a Web-based model co-developed by Customs and a consortium of IT vendors led by Computer Associates. The project aims to facilitate all aspects of Customs involvement in the import and export process including declarations and GST transactions collected at port.

    Nother Article [idg.com.au]
    More than seven years to this point of readiness, ICS is a cornerstone of Customs' massive Cargo Management Re-engineering (CMR) project, which will replace the export and brokerage industry-developed EDI system, Customs Connect. CMR is a Web-based model co-developed by Customs and a consortium of IT vendors led by Computer Associates, EDS, IBM and Telstra nee Kaz.
  • Who is behind this? (Score:5, Informative)

    by new-black-hand ( 197043 ) <nik@techPLANCKcrunch.com minus physicist> on Friday October 21, 2005 @02:44AM (#13842612) Homepage
    As if they didn't see it coming, the bastards. Here is an article from the SMH from January of 2004 [smh.com.au]:
    Customs Minister Chris Ellison will meet software developers and industry groups tomorrow after finding persistent bugs in the latest version of the Australian Customs Service's ambitious new import and export system. Most of version 3 of the system was delivered to developers last week for testing, but problems have persisted. "Customs is burning money like it is going out of style," one developer told Next.
    The Customs Office and it's IT outsourcing arrangements have previously been the subject of a senate enquiry, lets hope that they get nothing less again this time around and the people responsible are bought to account. One thing I did notice is that not a single article reports on who the developers behind the project are. My knowledge is that Computer Associates have slowly started taking over things from EDS at customs - can anyone confirm?
  • The Real Problem (Score:5, Insightful)

    by Grail ( 18233 ) on Friday October 21, 2005 @02:51AM (#13842633) Journal
    The real problem with this system is that it used the principle of "Big Design Up Front". Ask Joel Spolsky about the benefits of "Big Design Up Front" - you get to make all kinds of assumptions about the environment to simplify development, then find when you turn on the switch that this $80M system just doesn't work right.

    The little things that get you down? Oh... date formats, validating input, units for measurement, using a communications system intended for overnight batch operations to support real-time interactive operations.

    As other posters have mentioned, the bid that got the nod was the lowest one. The bid that should have received the goahead was the one that recommended incremental changes. The one that recommended introducing a new means for handling import declarations - and not cutting over, but rather letting the old one die the natural death of user migration.

    The final nail in the coffin was Customs insisting that more detail be included in these reports - no longer can you submit 300 reports in a day saying that what you're importing is "1 Box of parts", you actually have to specify what the parts are and how many are in the box - I suspect this is what is causing the problem as the system rejects "invalid" submissions and forces the importers to rework and resubmit their import declarations.
    • The problem is ... incremental changes is not a sexy sale. Vendor sales people get lots of incentives and pressure to force the next big thing down a major account's throat.

      Not too aware of who has implemented the new system? If I were to hazard a guess .. they moved from a mainframe based app to something that uses Oracle. :)
  • by spongeboy ( 681073 ) on Friday October 21, 2005 @03:08AM (#13842674)
    Crikey.com.au mentioned this today in their mailout.

    Apparently the issue is that the data coming in (mainly from ships) is quite crufty, whereas the system expects nice clean data (GIGO anyone?).

    Also, apparently a lot of these Brokers have a vested interest in the old system, as the new one will allow major importers (eg. supermarkets) to clear goods themselves, meaning less money for the brokers.

    As for delays and ships being turned back- appears to be mainly FUD, with a little bit of lack of foresight and poor planning.

    Seems like a change management failure to me.

  • by paugq ( 443696 ) <pgquiles&elpauer,org> on Friday October 21, 2005 @03:08AM (#13842675) Homepage
    One factor seldomly taken in account is the user's reluctance to the new system.

    You may have a 100% working new system, with a 1000% improvement over the old system, but if users are not excited about the new system and they do not want to use it for whatever-the-reason (maybe just because he/she now has to learn new things), the new system is going to fail. Users will make sure it fails. I have seen that many times.
    • Users are part of the equation. If your new system does not improve upon the old situation, regardless of what the user's reaction is.. you have failed.
    • Users will make sure it fails. I have seen that many times.

      On one hand, I can completely understand that reluctance to change. Users of complex systems that have a steep learning curve can be particularly recalcitrant.

      On the other hand, if you truly do "have a 100% working new system, with a 1000% improvement over the old system", then users will most certainly be excited and eager to use it.

      Wait, let me try that again...I think I had it backwards.

      If your users are not excited, or at least will

      • No, you are completely wrong.

        Last month I saw users rejecting a new, lots better CMS, just because they had a very good friendship with the Support guy of the old company. You may have a rock-solid, very good software, but you cannot fight against those kind of non-software-related affairs.
  • by nathanh ( 1214 ) on Friday October 21, 2005 @04:02AM (#13842799) Homepage

    The rumour on the grapevine is that the problems don't entirely stem from the software. The data entry now requires details (you want what now?) and that makes it impossible to process cargo as quickly as before. The software is just a convenient scapegoat. The reality is that the old system allowed the data entry to be sloppy (and effectively useless).

    • by Zellis ( 103288 ) on Friday October 21, 2005 @05:18AM (#13842972)
      Partially true. The new system does require considerably more detail and accuracy, but that's only one of the issues that's come up. Another issue that's come up is that more detail = more data to process, and the system appears like it wasn't designed with that in mind: it's been severely overloaded all week. Add to that the non-existant training in the new system (my company was given what amounted to a 3-minute demonstration of the new interface we had to use before being required to use it exclusively), the bugs that are still being worked out (some of which have made data entry impossible for hours at a time), and a very poor effort at explaining the new procedures that Customs have implemented as a result of the change-over, and you get the current situation.

      It's true that the main problem isn't the software (although the bugs don't help): it's the way the new system was implemented

  • Linie Aquavit announced they were expanding their line to include Scotch Whiskey, London Gin, Mexican Tequila, and Peugeot motor cars.
  • by OpenSourced ( 323149 ) on Friday October 21, 2005 @04:14AM (#13842826) Journal
    They say that in a few years a human-engineered microorganism will be created with a selected set of genes. All very well, and I suppose that won't be released into the wild. But I bet that if they ever do it (release it into the wild), it'll last about 5 minutes against its evolution-designed competitors and generally hostile environment.

    The same happens to the IT systems. Legacy systems may be old (how can software be old, anyway?), incompatible, user-unfriendly, and whatever else. But a basic fact so often overlooked is that they have for many years been adapting (or rather being adapted) to their environment (users, other programs, etc). If you look at legacy code you always find odd-looking "if's" with comments like "It must do this to work", or "The other program expects it that way", or no comment at all. The point is that all this spaguetti code has beed polished, adapted and perfected by the work of programmers guided by the reality, as opposed to designers guided by their own desires and incomplete knowledge of the problem.

    So the point is that _all_ scratch designed systems will lose all that ancient knowledge embedded into the code, and there is nothing you can do about it (inspecting all the code would be impossible, and the knowledge can sometimes be into OS parameters, shell scripts, scraps of paper with procedures in the drawers of remote users, or even in the brains of world-scattered users) So the only thing to do is to have it into account when designing a new system of some complexity, and knowing that it will take you like a year at least of real running till it's at the same level of functionality as the old. So probably you'll need a year of overlaping systems (perish the thougth).

    When presented with that reality most managers will think again if they really need the new system, and at least will be prepared for the problems ahead.

    But of course that might not sell the new system, so who's interested in telling those truths to management. Certainly not the seller's marketing dept, their concealing habilities much helped by the fact that they are themselves blissfully unaware of the problem.

  • after EDS let their old mainframes walk out the door [slashdot.org].

    Is it a big suprise that EDS fucked the upgrade as well?
  • by CharliePete ( 923290 ) <slashdot@aces4all.com> on Friday October 21, 2005 @05:14AM (#13842965) Journal
    Dear Project Director,

    Your situation reminds me of the old IT parable that goes something like this...

    On his first day on the job a new IT Director has a meeting with the outgoing one. At the end of the meeting the ougoing IT Director hands the new on 3 envelopes and tells him to use them to get out of his first 3 major meltdowns, "just make sure you wait to open them until you need them."

    About 3 months later the new IT Director has his first major disaster and remembers the envelopes. Opening the first one he sees, "Blame Me" in big bold letters. Which he does and it works.

    Six months after that the second blow up happens and the second letter reads, "Blame the Vendors" which also works.

    One year later when everything falls apart the new IT Director opens the third letter full of hope. It reads, "Write 3 Letters."

    ...I think it's time you opened the third envelope. Good luck in your future endeavors.

    Sincerely,
    The Guy Before You
  • From figures in Customs' CMR: what it is and what it does [idg.com.au], the system adds about $A200 per container or passenger movement. Luckily, this is being picked up by Australian taxpayers, not the importers or exporters :-)

    The article also answers other posters questions about the platform it was delivered on. Certainly no cheap linux stuff used here !

    But really interesting is this:

    A number of service providers were retained to develop and implement systems: Computer Associates' consortium with Kaz, IOCORE

  • ...but does it run Linux?
  • If you're bringing in a complete new computer system then you're
    simply asking for trouble if one night you switch the old one
    off and switch the new one on. New systems (especially ones this
    large and important) should be bedded in, run alongside and
    mirroring the old system (but not taking over from it) in the
    live enviroment while bugs are shaken down and other types
    of problems solved. You NEVER EVER put it live without running
    in parallel first. EVER! If the companies or port authority who
    brought this system
  • by jordg ( 133593 ) on Friday October 21, 2005 @05:54AM (#13843057)
    I have seen this so many times. Big project, Big Budget, Big Names, Big Price, Big Stuffup.
    I believe that a system like this is reasonably simple and can be created by a very small team.
    With big projects you end up with teams of project managers micro managing everything. This is why it gets so diffiult. I was once on a project where my part was to copy files intact from remote locations to a central site. What a mess. The project manager had designed a process that failed every time. Not to mention the bandwith upgrades that happened after the file transfers. All they needed was one person with the know how to get it done and a small team of switched on IT persons to manage the entire thing.
    Companies are concetrating too much on process and management than getting the work done. These types of projects are not that difficult.
  • by yagu ( 721525 ) * <yayagu@[ ]il.com ['gma' in gap]> on Friday October 21, 2005 @10:20AM (#13844177) Journal

    When large new systems like this one wreak this much havoc, I think lessons learned need to be disseminated to the entire industry.

    I've seen many interesting posts about why Australia failed in this new system, but it's mostly conjecture. They should (and I'm guessing, will) conduct a deep and thorough post-mortem and find out what went wrong, down to the lines of code, scheduling decisions, rollout decisions, etc.

    And (here's the controversial part) they should provide every single document to the public.

    When projects gone amok have international impacts like this one why can't the rest of the industry learn from the mistakes by having access to the post-mortem. Involved companies want to maintain control of their Intellectual Propert, but in cases like this, EVERYTHING should be made public. Actually at this point companies involved really aren't protecting IP, but would be hiding behind that canard to deflect the embarrassment of public scrutiny.

    Many similar failures wrought similar havoc. Denver International Airport (DIA) spent millions (don't remember exact numbers, but I'm guessing it was in the $100's of millions) of dollars for their dramatically failed automatic baggage handling system. Today DIA not only handles baggage the old fashioned way (carts and tow-tractors), they have to do it through too-small tunnels not designed for the task because of the hubris of the project they wouldn't need to.

    So, for now, all we have is conjecture from government officials and slashdotters, one demographic of which already shows some deep insights and possible explanations. But that's all we have.

    I hope cause and effect is investigated, and I hope the IT industry gets the opportunity to understand the failures and learn from them.

I have hardly ever known a mathematician who was capable of reasoning. -- Plato

Working...