http://www.techworld.com.au/article/...d_demo_lawsuit
I have seen this scenario so many times, and have been called in to clean up more than once. There is usually enough fault on both sides. Most clients have IT departments, but management often ignores them during the specification development. The vendor's reps usually wag their heads "yes" to every client question, like a dashboard doll, and management eats it up like it was gospel. So often, the folks that make the final decision are the ones with the LEAST software/database experience, yet their egos won't let them admit it. However, when stuff hits the fan, the first to get the blame are the underlings. Most vendors have iron clad contracts which, inside the dense legalese, are loopholes disclaiming any suitability for any purpose what so ever, like all proprietary EULA's I've read.
The last time this happened was where I last worked. I had written a personal program (uisng VFP 5.0) to computerize a manual payroll task required of everyone every two weeks. Bring the total hours forward, add the daily hours worked to get a new total hours, and submit the form. My program, for personal use, had a small db to hold the daily hours and total hours for each pay period. I mimicked the paper form and the only difference between it and the hand completed form was that the hours were typewritten, not hand written. Other developers saw it and asked for a copy. Pretty soon all the developers were using it and others began installing a copy and using it. A few months later the dept head asked me if I could modify my program so that all the dept could use it. I did. A few months later the personnel office asked if it could be set up so that all 500 employees could use it from a single server. And, they wanted some reports.
Later, and this is where Oracle comes in, someone sold the state level management on the idea of using APEX (which was originally IBM's "One World", which was sold to JD Edwards as "PersonSoft" and later purchased by Oracle, IIRC). I was told that when the Oracle payroll program was completed mine would be abandon. When the unveiling time came I was invited by the personnel manager to witness with him the payroll program in action. What I saw STUNNED me. It left the personnel manger in shock. What was delivered could best be described as an application which could have been resurrected from a 20 year old mainframe running RPG4. Unlike modern applications where a record could be created, viewed, edited or deleted from one screen, the "new" payroll program had four separate screens to do each function. First, you had to use the view screen to search and see if a record existed. If not, you could exit the view screen and run the create screen. But, you couldn't edit it. After you created it you exited the create screen and ran the edit screen. When you were done you'd save it. To see that it saved correctly you used the view screen to search for and display the record. etc.... And, to make matters worse, the employee had to carry the total hours forward manually, meaning they had to write down the current total hours on a sheet of paper and use it two weeks later to enter in the initial hours carried forward.
NO ONE had talked to me, or the personnel manager, about the specifications and requirements for payroll activities required by the department. The mantra was that the application was "easily customizable" by ordinary employees who don't need any expertise in developing applications. Just a "little training". On the way out of the door, after the demo, the personnel manager told me not to shut down "TRex" (Time Records). I was asked to modify "TRex" to add a function to create an xls spreed sheet file to import into the APEX app that Oracle and an outside consulting firm had developed. That way employees wouldn't have to work with those awful screens or write stuff down. (We're talking about $6 Million worth of software here!)
Matters stayed that way for a year, then a new gov was elected and all IT services were moved out of the dept and over to the state IT building. All Netware and Linux servers (which were gradually replacing Netware as hardware died) were replaced with Windows servers and Active Directory became default. During the last six months before I retired the fellow who was taking over for payroll apps began working on an APEX equivalent to TRex, but with even more capabilities. At first it looked like it would not be possible because APEX forms had a limit of 60 controls in a form, IIRC. That limit was bypassed by using dynamic HTML, which almost made using APEX moot, but work continued. What my colleague developed in APEX was a masterpiece of employee record keeping. It included a short SQL command that could compute the week days on which all the vacations would fall for the next 50 years. It tracked all forms of absences, both past, present and future. It did everything the personnel dept wanted and more, and exactly the way they wanted it done. The fly in the ointment came during the development of the login screen. Using Netware one could access the login name and password from the login server to validate the name and password of the user wanting to use the payroll system. When the hardware was moved to the state IT building and switched to Windows what was needed was access to the Active Directory login database. State IT refused to give access so there was no way to validate user logins. Without validation the program died. I don't know if they are using TRex now, or not, because I haven't kept up since I retired 3.5 years ago.
New details have emerged in Montclair State University's lawsuit against Oracle in connection with a troubled ERP (enterprise resource planning) project, in a court filing that includes more information about Oracle's alleged failings and also accuses the vendor of extortion as well as "inducing" the institution to take on the implementation.
Montclair's amended complaint, which was filed Tuesday in U.S. District Court for the District of New Jersey, states that Oracle made an array of "intentionally false statements" regarding the functionality of its base ERP system, the amount of customization that would be required, and the amount of "time, resources, and personnel that the University would have to devote."
"Ultimately, after missing a critical go-live deadline for the University's finance system, Oracle sought to extort millions of dollars from the University by advising the University that it would not complete the implementation of the ... project unless the University agreed to pay millions of dollars more than the fixed fee the University and Oracle had previously agreed to," it adds.
...
"This is a textbook example of how to file a legal action against a vendor for failure to deliver," said analyst Ray Wang, CEO of Constellation Research, who reviewed the updated complaint on Wednesday.
MSU made some smart moves to protect itself, such as documenting all conversations and interactions with Oracle, and working out an escalation procedure in the event the project ran into problems. It also was wise to use real-life use cases for the demonstrations, Wang added.
"The documentation on this complaint is solid," he said. "Whether it's true or not, we'll let the courts decide."
Montclair's amended complaint, which was filed Tuesday in U.S. District Court for the District of New Jersey, states that Oracle made an array of "intentionally false statements" regarding the functionality of its base ERP system, the amount of customization that would be required, and the amount of "time, resources, and personnel that the University would have to devote."
"Ultimately, after missing a critical go-live deadline for the University's finance system, Oracle sought to extort millions of dollars from the University by advising the University that it would not complete the implementation of the ... project unless the University agreed to pay millions of dollars more than the fixed fee the University and Oracle had previously agreed to," it adds.
...
"This is a textbook example of how to file a legal action against a vendor for failure to deliver," said analyst Ray Wang, CEO of Constellation Research, who reviewed the updated complaint on Wednesday.
MSU made some smart moves to protect itself, such as documenting all conversations and interactions with Oracle, and working out an escalation procedure in the event the project ran into problems. It also was wise to use real-life use cases for the demonstrations, Wang added.
"The documentation on this complaint is solid," he said. "Whether it's true or not, we'll let the courts decide."
The last time this happened was where I last worked. I had written a personal program (uisng VFP 5.0) to computerize a manual payroll task required of everyone every two weeks. Bring the total hours forward, add the daily hours worked to get a new total hours, and submit the form. My program, for personal use, had a small db to hold the daily hours and total hours for each pay period. I mimicked the paper form and the only difference between it and the hand completed form was that the hours were typewritten, not hand written. Other developers saw it and asked for a copy. Pretty soon all the developers were using it and others began installing a copy and using it. A few months later the dept head asked me if I could modify my program so that all the dept could use it. I did. A few months later the personnel office asked if it could be set up so that all 500 employees could use it from a single server. And, they wanted some reports.
Later, and this is where Oracle comes in, someone sold the state level management on the idea of using APEX (which was originally IBM's "One World", which was sold to JD Edwards as "PersonSoft" and later purchased by Oracle, IIRC). I was told that when the Oracle payroll program was completed mine would be abandon. When the unveiling time came I was invited by the personnel manager to witness with him the payroll program in action. What I saw STUNNED me. It left the personnel manger in shock. What was delivered could best be described as an application which could have been resurrected from a 20 year old mainframe running RPG4. Unlike modern applications where a record could be created, viewed, edited or deleted from one screen, the "new" payroll program had four separate screens to do each function. First, you had to use the view screen to search and see if a record existed. If not, you could exit the view screen and run the create screen. But, you couldn't edit it. After you created it you exited the create screen and ran the edit screen. When you were done you'd save it. To see that it saved correctly you used the view screen to search for and display the record. etc.... And, to make matters worse, the employee had to carry the total hours forward manually, meaning they had to write down the current total hours on a sheet of paper and use it two weeks later to enter in the initial hours carried forward.
NO ONE had talked to me, or the personnel manager, about the specifications and requirements for payroll activities required by the department. The mantra was that the application was "easily customizable" by ordinary employees who don't need any expertise in developing applications. Just a "little training". On the way out of the door, after the demo, the personnel manager told me not to shut down "TRex" (Time Records). I was asked to modify "TRex" to add a function to create an xls spreed sheet file to import into the APEX app that Oracle and an outside consulting firm had developed. That way employees wouldn't have to work with those awful screens or write stuff down. (We're talking about $6 Million worth of software here!)
Matters stayed that way for a year, then a new gov was elected and all IT services were moved out of the dept and over to the state IT building. All Netware and Linux servers (which were gradually replacing Netware as hardware died) were replaced with Windows servers and Active Directory became default. During the last six months before I retired the fellow who was taking over for payroll apps began working on an APEX equivalent to TRex, but with even more capabilities. At first it looked like it would not be possible because APEX forms had a limit of 60 controls in a form, IIRC. That limit was bypassed by using dynamic HTML, which almost made using APEX moot, but work continued. What my colleague developed in APEX was a masterpiece of employee record keeping. It included a short SQL command that could compute the week days on which all the vacations would fall for the next 50 years. It tracked all forms of absences, both past, present and future. It did everything the personnel dept wanted and more, and exactly the way they wanted it done. The fly in the ointment came during the development of the login screen. Using Netware one could access the login name and password from the login server to validate the name and password of the user wanting to use the payroll system. When the hardware was moved to the state IT building and switched to Windows what was needed was access to the Active Directory login database. State IT refused to give access so there was no way to validate user logins. Without validation the program died. I don't know if they are using TRex now, or not, because I haven't kept up since I retired 3.5 years ago.