Oracle Montclair Amended

Case 3:11-cv-02867-FLW -LHG Document 32-1
Filed 12/13/11 Page 1 of 60 PageID: 692
David E. De Lorenzi, Esq. Michael Cukor, Esq. Luis Diaz, Esq. Christopher Walsh, Esq. GIBBONS P.C. One Gateway Center Newark, New Jersey 07102-5310 (973) 596-4500 Attorneys for Plaintiff Montclair State University MONTCLAIR STATE UNIVERSITY, Plaintiff, vs. ORACLE USA, INC., Defendant. Civil Action No. 3:11-cv-02867 (FLW) (LHG) Document electronically filed AMENDED COMPLAINT
Plaintiff Montclair State University (the University), for its Amended Complaint against defendant Oracle USA, Inc. (Oracle), alleges as follows: INTRODUCTION 1. This action concerns Oracles fraud in inducing the University to retain Oracle to
implement the Universitys new integrated enterprise resource planning computer system (the ERP System) and Oracles grossly negligent performance under -- and willful repudiation of -its agreement with the University to implement the ERP System. The ERP System was to replace the Universitys twenty-five year-old aging computer systems and was an integral part of the Universitys plan to improve its administrative and student services capabilities as New Jerseys second largest public university. The ERP System would enable the University to have a common computer platform that would consolidate and manage the vast majority of the information and data needed for the University to run its operations in the twenty-first century.
#1719626 v2 110772-75497
By having a common platform, the University could improve its planning and budgeting capabilities, maintain better administrative controls over its spending, improve services to its students by making course work, financial aid, and other information more readily available and accessible, improve the processing and reporting of its human-resource systems, improve reporting of information for financial and other decision making, and have a fully enabled web solution that provided for increased productivity for University employees and significant service improvements to students. In reliance upon the schedule prepared by Oracle, the project, known as the Bell Tower Initiative or BTI Project, was to be implemented over a twenty five (25) month period. 2. To induce the University to enter into contracts worth more than $20 million for
the acquisition and implementation of the ERP system, Oracle made many intentionally false statements about the critical functionality provided by its base ERP system, the amount of customization of its base ERP system that would be required to meet the Universitys business requirements, the amount of time, resources, and personnel that the University would have to devote to implement the ERP System, Oracles project-management expertise, and its ability to complete the project on time and within budget. 3. In addition, Oracle misrepresented its intention to be governed by the fixed-price
agreement it ultimately entered into with the University. Rather than providing the agreed-upon implementation services at the agreed-upon fixed price, it was Oracles intention from the inception of the contract that it would use change orders to extract additional fees from the University to deliver the functionality that Oracle had represented was present in its base system. 4. In reliance on these misrepresentations, the University chose Oracle over another
competitive bidder and contracted with Oracle to provide the software and services to implement 2
#1719626 v2 110772-75497
the BTI Project. As will be discussed below, the Universitys selection of Oracles ERP system and its selection of Oracle to implement the system was a disaster for the University, causing tens of millions of dollars in damages to the University. 5. In addition to fraudulently inducing the University to buy its ERP system and
implementation services, Oracle breached its implementation contract with the University in several ways. Oracle failed to deliver key implementation services, caused critical deadlines to be missed, refused to make available promised servers and hosting services that Oracle stated would expedite the implementation of its ERP system, failed to deliver properly tested software, and, overall, failed to manage properly the project. Ultimately, after missing a critical go-live deadline for the Universitys 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 BTI project unless the University agreed to pay millions of dollars more than the fixed fee the University and Oracle had previously agreed to. Such actions by Oracle were an anticipatory repudiation of its agreement with the University. 6. As a result of Oracles fraudulent and willful misconduct and its refusal to cure its
failures after many requests to do so by the University, the University was forced to suspend the BTI Project, declare Oracle to be in material breach based on its grossly negligent performance and its anticipatory repudiation of its contract, and seek to hire a replacement systems integration company to complete the BTI Project. This delay has added significant time to the implementation of the BTI Project and will increase the Universitys costs for the BTI Project by more than $10,000,000. Oracles breaches and conduct have further subjected the University to additional costs, losses, and damages in the form of increased internal project costs, the cost of sustaining the Universitys legacy system during the extended period of time to complete the BTI 3
#1719626 v2 110772-75497
Project, and the loss of expected benefits that would have resulted from a successful and timely implementation of the BTI Project. THE PARTIES 7. The University is a public university organized under the laws of the State of New
Jersey located at 1 Normal Avenue, Montclair, New Jersey and is maintained for the purpose of providing higher education in the liberal arts, sciences, and various professional areas in accordance with N.J. Stat. 18A:64-1, et seq. 8. Oracle is a Colorado corporation with its principal place of business in Redwood
City, California. BACKGROUND A. Oracles Misrepresentations About the Functionality of Its Base Product 9. In 2006 the University decided to replace its existing ERP system with a new ERP
system which would seamlessly provide an integrated system for conducting the business of the Universitys various departments and functions, such as finance, human resources, student recruitment and enrollment, course management, and campus life. The University was looking for an off-the-shelf version of an ERP system that contained the mission-critical functionality required by the University and would not require substantial customization in order to meet the Universitys particular business requirements. 10. The University wanted a system that would require little customization because it
realized that it had limited human and financial resources to devote to the project, and it knew that substantial customization would require more work from its staff and therefore place severe strain on its already limited resources.
4
#1719626 v2 110772-75497
11.
To determine whether a particular ERP system would satisfy its critical business
requirements, the University, relying on input from stakeholders throughout the University, devoted an entire year to identifying the particularized requirements that it needed in an ERP system. 12. That effort resulted in the identification more than 3,200 business requirements
for the new ERP system. After identifying these business requirements, in or about October 2007, the University issued a request for proposals (the RFP) to Oracle and two other software companies which specialize in enterprise resource systems for higher education institutions. The RFP described the various systems the University wanted to replace, including those for financial management, human resources, student administration, data warehousing, budgeting, enterprise portal, and user productivity kit (UPK) training. 13. Moreover, to assist the University in identifying which ERP system would require
the least amount of customization in order to meet its requirements, the RFP listed the Universitys more than 3,200 requirements and asked the bidders to state whether the requirement was met by the bidders Base Product and, if not, whether a customization of the bidders base product was needed or whether additional externally-licensed or bidder-developed products would be required to meet the particular requirement. 14. On or about January 8, 2008, Oracle submitted its response to the RFP. In its
Executive Summary and Proposal Overview, Oracle represented that its base PeopleSoft system for higher education organizations would address the Montclair State Universitys requirements with minimum modification to the base system, including extensive self-service functionality and that the system provides high flexibility; which results in a reduced need for customizations. 5
#1719626 v2 110772-75497
15.
Oracle responded to the Universitys RFP by producing a so-called exceptions
report which identified a mere 156 (roughly 5%) business requirements which were not satisfied by its base PeopleSoft system and thereby represented that 95% of the Universitys more than 3,200 business requirements were satisfied by its base system. A partial list of the requirements that Oracle represented were satisfied by its base product is set forth on Exhibit A. As described below this representation was false inasmuch as Oracles base product did not satisfy these requirements. 16. In still another effort to ensure that its new ERP system would not require
substantial customization, the University required the bidders to provide live demonstrations of their existing base systems. The purpose of these demonstrations was to show to the Universitys satisfaction that the bidders base system satisfied the Universitys most critical business requirements. 17. As part of this demonstration process, the University prepared test scripts
identifying the Universitys most important business requirements which required the bidders to show by way of a live demonstration that their base products met these critical requirements. 18. On April 14 - 17, 2008, Oracle gave a live demonstration of what it purported to
be its then-existing base system. During this demonstration, Oracle represented that its base system met virtually all of the business requirements included in the test scripts and, as to the balance of the requirements, that a customization or third-party product would be required to meet the requirement. 19. Throughout the bidding and negotiation of the implementation services contract,
during which modest revisions to the Universitys requirements were made, Oracle continued to represent that virtually all of the Universitys business requirements (including, in particular, 6
#1719626 v2 110772-75497
those set forth on Exhibit A) would be met by its base system. Among other occasions, Oracle made these representations in its May 28, 2008 best and final offer and its February 23, 2009 best and final offer. 20. Based on the bidders respective representations about how many of the
Universitys requirements were met by their base products and based on the live demonstrations of the bidders base products, the University determined that the functionality demonstrated by Oracles base product would meet considerably more of the Universitys critical business requirements than the other bidders1 base product and that Oracles system would therefore require much less customization and many fewer additional products than the other bidders. Consequently, the University believed that selecting Oracles system would place a smaller burden on its limited human and financial resources. 21. Ultimately, as will be discussed in more detail below, the University chose Oracle
over the other bidder. While other factors were considered by the University in making this decision, the relatively small number of customizations and new products that would be needed for the Oracle system -- and the correspondingly smaller burden on the University -- was a material factor in its decision. 22. Indeed, among all the factors that the University considered in choosing Oracle
over the competing bidder, the degree to which the bidders product met the Universitys business requirements was given the greatest weight in its selection process. 23. As will be discussed in more detail below, Oracles representations -- in writing
and in the live demonstration -- about the extent to which its base system provided the critical functionality to meet the Universitys most important business requirements were not true
1
Only one other bidder responded to the Universitys RFP. 7

#1719626 v2 110772-75497
because the system which Oracle ultimately implemented did not contain all of the critical functionality which Oracle had represented it would contain. As one example, Oracle provided a live demonstration of a robust on-line application process for Undergraduate and Graduate Admissions (Enrollment Management) that it falsely represented (i) was an existing part of the base system and (ii) satisfied the Universitys requirements for an online Enrollment Management process. The fact is that the on-line application functionality was not part of the base system. Instead, Oracles ultimate implementation plan was to sell the University a thirdparty product called Embark to satisfy those requirements, suggesting the initial live demonstration was rigged. Consequently, a substantial amount of customization -- the very thing the University was seeking to avoid-- was required in order for the system to meet the Universitys requirements for Enrollment Management and other critical functionality. B. Oracles Misrepresentations About the Sufficiency of the Universitys Resources Required To Complete the Implementation on an Accelerated Basis and Its Project Management Expertise. 24. When the University issued the RFP, it anticipated that, given the limited number
of University employees and other resources available to the University for implementing the BTI Project, the entire implementation process would take approximately 36 to 42 months to complete. 25. During the negotiation and bidding process, however, Oracle falsely represented
that the implementation of its ERP system could be completed in just 25 months, a 31% to 40% reduction of the time the University had contemplated. Oracle further represented that, even though the University had a limited number of employees and resources available to assist in the project, the University had enough personnel and resources to complete the implementation on the substantially accelerated schedule proposed by Oracle. 8
#1719626 v2 110772-75497
26.
These representations, which were material to the Universitys decision to
contract with Oracle, were made repeatedly by Thomas Ball, Oracles vice president of Health and Higher Education, and K.C. Bacher, another Oracle vice president, during meetings held at the University from January 2008 through February 2009. Individuals from the University and its consultant who were present at these meetings include Ed Chapel, Carolyn Ortega, Catherine Rush, Steve Johnson, Denise DeBlasio, David Josephson, Kathleen Ragan, Cathy Bongo, Reginald Ross, Cindy Meneghin, Lucy Flores, Jeff Giacobbe, Jeanette Hanlein, LuzSeneida Flores, Richard Peterson, Patricia Ann Kahn, Thomas Krivda, Brian Ayres, Irma Fabular, and Yai Mareourn. One such meeting during which Mr. Ball and perhaps Mr. Bacher represented that the University had sufficient resources to complete the project on the accelerated schedule occurred on May 7 and 8, 2008 at the Universitys offices. 27. In particular, Oracle falsely represented that the implementation could be
completed on an accelerated schedule as a result of the efficiencies to be gained under its socalled Accelerated Compass Methodology pursuant to which Oracle would host certain of the Universitys data on Oracles servers during the implementation process. 28. When Oracle was telling the University that it had adequate personnel and
resources to complete the implementation on an accelerated basis, Oracle was also negotiating a contract for the implementation of a similar ERP system for the Lone Star College System, which Oracle repeatedly held out to the University as an implementation comparable to the implementation of the Universitys system. 29. The number of personnel and resources available to the Lone Star College System
to complete its implementation, however, was four times greater than the personnel and resources available to the University to implement its ERP system. 9
#1719626 v2 110772-75497
30.
Thus, Oracle knew or should have known that the number of personnel and
resources available to the University was not adequate for completing the implementation under the accelerated schedule proposed by Oracle. Consequently, Oracles repeated and insistent representations that the University had adequate personnel and resources to complete the implementation on the proposed schedule were intentionally or negligently false. 31. Oracles statements about the efficiencies to be achieved by the use of its
Accelerated Compass Methodology were also intentionally misleading. As Oracle must have known when it made such statements, many of its staff and third-party consultants who worked on the project had not been trained in the Compass Methodology and were not otherwise knowledgeable of it. Thus, it was a misrepresentation to suggest that the Accelerated Compass Methodology would achieve any efficiencies in the implementation process. 32. Moreover, as will be discussed in detail below, Oracle never intended to host the
Universitys data on the terms the University and Oracle agreed to. Thus, the central efficiency on which Oracles accelerated schedule was based was itself based on a false promise by Oracle. 33. To make the University comfortable with the notion that the Universitys limited
resources could meet the Universitys obligations under the accelerated time frame that Oracle was proposing, Oracle boasted and misrepresented its project-management expertise and experience and assured the University that, due to Oracles project-management and implementation expertise, the system would be implemented on time and within budget. 34. For instance, in Oracles best and final offer dated May 28, 2008, Oracle stated
that it provides integrated, end-to-end coverage from design and planning to project management which leaves nothing to chance.
10
#1719626 v2 110772-75497
35.
Specifically regarding Oracles implementation and project-management services,
the May 2008 best and final offer also stated that Oracle has a demonstrated repeatable implementation approach for Higher Education with a proven track record of on time and on budget upgrade and implementation projects and that Our project managers: . . . are masters at our proven methodology and can comfortably modify the methodology or approach for each client according to business needs. 36. Neither of these statements were true and Oracle knew that they were not true
when they were made. 37. Oracles ability to implement higher education systems on time and on budget
was not repeatable as they allege because Oracle has failed to implement higher education systems on time and on budget at numerous higher education institutions, including Rutgers and the City University of New York. At a minimum, in light of Oracles statement about its ability to implement higher education systems on time and on budget, Oracle was under a duty to disclose to the University the instances when it failed to implement such a system on time and on budget. 38. Oracles statement that its project managers are masters at its proven
methodology, i.e. the so-called Compass Methodology, was also highly misleading if not completely untrue. As discussed above and below in more detail, many of Oracles team members did not know the Compass Methodology and had not been trained in it. Again, in light of Oracles affirmative statements about its project managers knowledge of the Compass Methodology and the efficiencies supposedly to be achieved by using the methodology, Oracle should have disclosed to the University that many of its team members were not knowledgeable of and had not been trained in it. 11
#1719626 v2 110772-75497
C.
Oracles Misrepresentations About Its Intention To Perform Implementation Services at the Agreed-Upon Fixed Price. 39. In its initial response to the Universitys RFP, Oracle proposed providing
consulting services to implement its PeopleSoft ERP system for the price of $18,818,580. 40. In response to a request for Oracles best and final offer, Oracle, in May 2008,
reduced their proposal to a fixed fee of $14,803,446, a reduction of just over $4 million. Ultimately, after further negotiations, Oracle and the University agreed to a fixed price for Oracles implementation services of $15,750,000. 41. As discussed above and below in further detail, Oracle knew that its base system
did not meet all of the requirements that Oracle said it would meet. Oracle therefore also knew that it would be required to create and implement a substantial number of customizations of its base system in order to provide the functionality it agreed to provide. 42. During the implementation process, however, Oracle demanded additional fees
beyond the fixed fee for the customization work, contending erroneously that such customization work was beyond the scope of the original contract. Thus, Oracle sought to use change orders to increase the fee the University was to pay by characterizing as new features functionality that Oracle represented was contained in its base system. 43. Moreover, as will be discussed in further detail below, after Oracle failed to meet
the July 1, 2010 go-live date for the Universitys finance module, Oracle demanded that the University agree to an increase in the fixed price before it would resume working on the implementation. In particular, Oracle stated that the increased cost to complete the implementation would be $7,923,000, but it expressed a willingness to accept only half that amount, approximately $4 million (which corresponds to the $4 million reduction from its original proposal to its purported best and final offer), in order to complete the project. 12
#1719626 v2 110772-75497
44.
Based on the foregoing, it may plausibly be inferred that Oracle never intended to
perform the implementation for the agreed-upon fixed price of $15,750,000. Instead, it was Oracles intention at the time it agreed to the fixed-price implementation agreement that, through illegitimate change orders for additional customization and other work that Oracle would be required to perform, it would ultimately demand additional money from the University before it would complete the implementation services it agreed to provide. D. The Agreement Between the University and Oracle. 45. Based on the bidders responses to the RFP, the demonstrations of the bidders
respective products, and the representations and assurances provided by Oracle during the bidding process, the Universitys Evaluation Committee selected Oracle to provide a PeopleSoft suite of products and implementation services. These products included Oracles PeopleSoft Financial Management System (FMS), Human Capital Management (HCM), Hyperion (for budgeting), Client Relationship Manager (CRM) and Campus Solutions (CS), Data Warehouse and Analytics, Enterprise Portal, and UPK Training Modules (for training users on how to use the computer systems) (collectively, the Oracle Software). The Universitys Board of Trustees authorized the award of a contract to Oracle on July 24, 2008 subject to final negotiation of a written agreement with Oracle. Oracle and the University failed to finalize the written agreement by November of 2008, and the University issued an addendum to the RFP on January 26, 2009 requesting best and final offers from Oracle and the other leading software firm who responded to the RFP. In or about February of 2009, Oracle and the other leading software firm provided their best and final offers. In or about April of 2009, the Universitys Evaluation Committee again selected Oracle for the BTI Project.
13
#1719626 v2 110772-75497
46.
In connection with the Universitys existing system requirements, on February 27,
2009, Oracle and the University entered into an Ordering Document to purchase Oracle database and technical software products in the amount of $319,152, as well as an Oracle License and Services Agreement (the LSA) and an amendment (Amendment One) to the LSA. 47. In or about April of 2009, Oracle and the University negotiated the terms of
several contracts for the purchase of Oracle Software and implementation services for the BTI Project. On May 29, 2009, the parties entered into three (3) additional Ordering Documents one for additional database and technical software products and support in the amount of $1,548,192.81, a second for the license of the Oracle Software and support in the amount of $2,469,301.79, and a third for implementation services in the amount of $15,750,000. The Ordering Document for the implementation services (the Services Ordering Document) incorporated by reference the LSA, Amendment One, a second amendment to the LSA (Amendment Two), and a Fixed Price Exhibit, dated May 31, 2009 (the Fixed Price Exhibit or FPE).2 48. promises: Using the Oracle-recommended staffing resources set forth in Attachment A, and structured implementation methodologies to produce work products described in Attachment B, Oracle will provide implementation services according to the Timeline in Attachment D and the High Level Project Plan in Attachment E to enable MSU to implement . . . the software products MSU licensed and are listed in Attachment I at the time this Ordering Document is executed to meet the requirements specified and clarified in Attachment C-1.
2
In the Fixed Price Exhibit, Oracle, among other things, made the following
Because the contract documents are voluminous, are already in Oracles custody, and contain information that Oracle may later contend is confidential, they have not been attached. By excluding the contract documents from its Complaint, the University does not acknowledge or admit that they contain confidential information. 14
#1719626 v2 110772-75497
FPE at 1 1(a). 49. The Attachments referenced in the contract are important as they form the core of
Oracles overall contractual commitments to the University. A high level description of these documents is provided below: Attachment A Staffing The Staffing document was generated by Oracle and included the amount and type of resources Oracle recommended the University have to implement the Oracle Software. This was important because the University needed to know before it signed the Services Ordering Document and FPE the number of resources needed to implement the BTI Project. Work Products, Services and Deliverables Description of work products, services, and deliverables for the project. MSU Business Requirements This document comprised over 3,000 of the Universitys business and technical requirements. Oracle stated in the FPE that it could meet the MSU Business Requirements with the Oracle Software (except a limited number that were expressly excluded). Overall Project Timeline The overall time frames in which the Oracle Software would be implemented. This Attachment shows the entire project being completed by June 2011. Preliminary, High-Level Project Plan and Milestones This document included over 850 separate tasks that were required to implement the Oracle Software. A more detailed plan was to be developed by Oracle post-contract signing. Milestone Payments The payment plan for the implementation services. This plan reflected the dates that the University would make payment for Oracle achieving certain milestone events, such as completing a stage of testing of the software. The payment plan generally was synchronized with the dates in the timeline document (Attachment D). Acceptance Form for Milestone Payments Specifically, the form stated that the Universitys Chief Information 15
#1719626 v2 110772-75497
Attachment B
Attachment C-1
Attachment D
Attachment E
Attachment G
Attachment J
Officer (or designated replacement when the CIO is not available) must sign the form to accept Oracle deliverables. Attachment K Methodologies The description of the implementation methodologies that would be used by Oracle to implement the Oracle Software at the University.
50.
The FPE required Oracle to implement the Oracle Software in a manner that met
the MSU Business Requirements. 51. The Timeline and High Level Project Plan included the following completion
dates for the four main pillars: Hyperion - February 26, 2010; Financial Management System - June 30, 2010; Human Capital Management - December 29, 2010; and Campus Solutions and CRM - June 24, 2011. 52. Under the Services Ordering Document, Oracle agreed to perform all of the
specified implementation services for the fixed fee of $15,750,000. That fixed fee was to be paid in a series of milestone payments, each of which was tied to Oracles satisfactory completion of a particular project deliverable. FPE at 368-96. E. Oracles Base System Does Not Possess the Critical Functionality that Oracle Represented It Would Possess; Thus Substantially More Customization than Oracle Represented Would Be Needed Was Required To Meet the Universitys Critical Business Requirements. 53. After executing the Services Ordering Document and FPE, Oracle began its work
on the BTI Project. The FPE defined a systematic approach for designing, configuring, and then testing the software applications. The first step was the design of the computer system to meet the requirements of the University. Oracle led the design sessions where the Universitys
16
#1719626 v2 110772-75497
business requirements were discussed, after which design documents called Conceptual Solution Design (CSD) documents were created. 54. After the preparation of the CSDs, Oracle and the University performed a fit-gap
analysis to determine whether the CSDs satisfied the Universitys business requirements. At that point, it became apparent that many of the Universitys business requirements that Oracle had represented would be met by Oracles base system were not, in fact, satisfied by Oracles base system and that substantially more customization than Oracle had initially represented would be needed was in fact required to meet the Universitys requirements. 55. Listed on Exhibit A are some of the business requirements which Oracle
represented were satisfied by its base system but were not in fact satisfied by it. Since Oracle never completed the implementation of the system, the list of requirements on Exhibit A may not represent all of the requirements which Oracles base system failed to satisfy. 56. For almost all of the instances where the University discovered that a business
requirement was not met by Oracles base system, Oracle contended that additional customization of its base system was required in order to provide the missing functionality and sought to get the University to agree to a so-called change request which would require the University to pay additional money on top of the fixed fee for the required customization. Ultimately, approximately 127 change requests were proposed by Oracle to provide the customization required to meet the business requirements set forth on Exhibit A. 57. For most of the aforementioned 127 change request, a lengthy debate ensued
between the University and Oracle about whether the University should be required to pay additional money to Oracle in order to get the particular business requirement satisfied. This negotiation process wasted valuable time and energy of the project-management teams for both 17
#1719626 v2 110772-75497
Oracle and the University and played a material role in Oracles failure to meet its first go-live deadline. 58. Many of the business requirements which were not satisfied by Oracles base
system and (therefore were the subject of a change request) were so critical to the functioning of the ERP system that the University was forced to agree to Oracles change request or otherwise risk missing critical go-live deadlines. 59. The additional customization that was required to meet the Universitys business
requirements created substantially more work than originally anticipated by the University for its team and Oracles team. That additional work also delayed the implementation of the ERP system. 60. The delay caused by the substantial and unforeseen (by the University, in any
event) customization work played a material role in Oracles failure to meet the projects first go-live date. F. Oracle Is Grossly Negligent in Its Management of the BTI Project. 61. Critical to the success of any large software implementation project, such as the
BTI Project, is the establishment of a project management function and the provision of experienced and competent project managers who are capable of overseeing the entire project and ensuring that the implementation methodologies are consistently used and followed. Competent project managers must, among other things, identify and manage the risks that might delay the project or increase its cost, manage and mitigate any issues that are confronting the project, and ensure that, where dependencies or links exist between two or more aspects of the project, the activities are properly sequenced and deadlines are timely met. Oracles
18
#1719626 v2 110772-75497
representations that it could provide these project-management functions was a critical factor in the Universitys decision to retain Oracle. 62. Oracle contractually agreed to provide these project management services by
using iProjects as the document repository. However, Oracle was unable to create a workable document repository through iProjects after numerous failed attempts. Rather than invest in an appropriate management tool and despite its concerns about the functionality of Blackboard as a document repository, Oracle requested by change order that a document repository be created using Blackboard because the University had a license to use that software. The University agreed to use Blackboard as a document repository based upon representations by Oracle that it would be adequate and to mitigate any further delays due to Oracles failed iProject approach. Blackboard proved ineffective as a project repository because it lacked many simple tools for managing project documentation (e.g., change control, version tracking, etc.). 63. Included as a separate set of activities in the FPE were the development of an
overall program management plan (the Integrated Project Management Plan), as well as ongoing, monthly project management services for which Oracle would be paid $65,800 per month. The Integrated Project Management Plan was to integrate plans across projects to enable tracking of milestones, dependencies and activities. The FPE required the Integrated Project Management Plan to be completed by Oracle and provided to the University within the first few weeks of the project. FPE at 19, 14. This Integrated Project Management Plan was to be a key document supporting the project management function described above. Oracle was responsible not only to produce the original Integrated Project Management Plan, but also to keep it accurate and up-to-date throughout the course of the BTI Project. FPE at 338.
19
#1719626 v2 110772-75497
64.
Oracle failed to timely produce the Integrated Project Management Plan. The
lack of an Integrated Project Management Plan led to confusion amongst Oracle and University staff, preventing either group from addressing resource and task conflicts and from identifying missing integration tasks. Since many of the University staff needed to be involved in multiple tracks, the lack of an Integrated Project Management Plan created major concerns with scheduling their time. 65. Although Oracle ultimately created ostensibly integrated project management
plans, the documents were defective in numerous way and failed to fulfill the critical function of an integrated project plan. Among other things, the documents failed to identify particular University resources and thus failed identify resource and task conflicts. Moreover, the documents were so lacking in detail that they were essentially unusable by the University. The documents also contained numerous inaccuracies, such as inaccuracies relating the percentage of completion of projects, and therefore seemed designed to mislead the University rather than guide the efficient completion of the project. Ultimately, because the project plans prepared by Oracle were so deficient, they were not used by Oracle to guide the completion of the project. Instead, Oracle consultants frequently used their own plans to work with the teams which had a different set of tasks than the integrated project plan. 66. The University, concerned that the BTI Project would be delayed by the lack of a
detailed, reliable, and accurate Integrated Project Management Plan, repeatedly requested that Oracle produce such an Integrated Project Management Plan. Although Oracle acknowledged its obligation to complete the Integrated Project Management Plan, Oracle failed and/or refused to produce it.
20
#1719626 v2 110772-75497
67.
Oracles contract also required it to deliver to the Universitys Project Manager,
on a monthly basis, reports comparing actual scope, schedule and resources to planned scope, schedule and resources; risk issues and mitigations. Each of these items was important because, if timely and accurately reported, it would provide the University with the information to ensure that the BTI Project was being managed properly by Oracle. 68. A critical success factor for a large scale implementation project such as the BTI
Project is the effective management of the issues and risks through an issues/risks log. Oracle did not manage the BTI Projects issues/risks logs and did not insist that many of their issues/risks be documented within the log. Because of this, issues and risks were not properly documented, tracked, and addressed. In fact, by September of 2010, the issues/risks log created for the Project showed 8 items with a high severity were open for 82 days, 13 items with a critical severity were open for 126 days, and 24 other items were open for 113 days. Many other risks and issues known by the University were either not contained in the issues/risks log at all, or deleted from it by Oracle without any resolution. 69. Instead, Oracle chose to embed issues and risks within weekly project status
reports, causing major issues and risks to be lost with simple project problems that required minor fixes. Throughout the course of the BTI Project, many risks or issues noted by the University within the weekly status reports were unilaterally removed or downgraded by Oracle without any resolution. For example, in or about February of 2010, the University created a weekly status report that showed the FMS system was coded red because it was behind schedule (red designating there were significant problems). Although Oracles Project Manager, Christian Kim, agreed with the Universitys status, Oracles Lead Project Manager, Robert Kohler, re-coded FMS to yellow (a less critical problem designation) at a project meeting but 21
#1719626 v2 110772-75497
failed to address the issues impacting the schedule, and the official report issued by Oracle regarding status kept FMS coded yellow. Ultimately, FMS failed to go-live as intended on July 1, 2010 and Oracles unilateral change to the color coding in this report was an intentional act to downplay the seriousness of the risk and mislead the other members of the BTI Project team. 70. Oracle failed to provide accurate and timely project status reports to manage the
application tracks, creating constant uncertainty for the University regarding where they were in the BTI Project, what tasks were to be done next, and who was responsible for what tasks. The project status reports Oracle did provide were oftentimes late and failed to include updated actual scope versus planned scope, actual project schedules versus planned schedules, actual resources needs versus planned resource needs, updated project plans, budget tracking, issues/risks logs and mitigation strategies. As a result, the University was left without critical project-related information to ensure the BTI Project was being implemented on time and within budget. 71. Moreover, Oracle refused to integrate University tasks and resources into its
report to help manage the BTI Project. Since University employees were performing their regular job functions, the University needed advance notice of the assignment of tasks and staffing for a particular need on the BTI Project. As a result of Oracles failure to integrate University tasks into the reports, the University was constantly requested by Oracle to respond to tasks with less than 1 weeks notice which created major last minute scheduling problems. Moreover, certain modules like Budgeting, Hyperion, and EPM were scheduled by Oracle too early making much of the work unusable. Lastly, Oracle sequenced project tasks to align with payment milestones and at the expense of industry accepted best practices for project testing and management.
22
#1719626 v2 110772-75497
72.
The status reports and project plans Oracle did create had no standards in place
which made cross project tracking difficult and the results reported inconsistent. Resource loading was inconsistently shown by Oracle and, because University resources were not included or generalized by using phrases like HCM staff, there was no way to have an accurate picture of the entire project status, resources, and costs. 73. In response to complaints from the University, Oracle acknowledged that it had
failed to meet its obligations under the FPE and randomly updated status reports and project plans after constant insistence by the University. Oracle treated the project planning report as a nuisance rather than the critically important tool it is for effective project management. As with the Integrated Project Management Plan, Oracle failed and/or refused to deliver the status reports as required by its contract, and eventually failed and/or refused to deliver updated status reports in the inadequate format created by Oracle. 74. Oracle required the University to use several Oracle-proprietary implementation
methodologies as a condition of Oracle implementing the BTI Project. These methodologies were described in Attachment K to the FPE and are known as the Compass, Accelerated Compass, and Workbench Methodologies (collectively, the Oracle Methodologies). FPE at 20, 17; see Oracle Proprietary Methodologies, FPE at 424-32. Implementation methodologies are an important component of any complex software implementation project because they provide the overall structure of how services are to be delivered during the project. 75. However, many of the Oracle staff assigned to the BTI Project were
subcontractors who had no knowledge of the Compass Methodology, didnt understand it, and werent effectively trained to use it. When the University pointed to the Oracle Methodologies as requiring the missing status reports and project plans, certain Oracle employees finally 23
#1719626 v2 110772-75497
admitted that they were not familiar with the Oracle Methodologies and were implementing the BTI Project the way they thought they should. 76. Oracles failure to supply accurate and up-to-date project status reports, in
combination with Oracles failure to provide an overall integrated project plan and failure to follow its Compass Methodology, created a situation in which, despite the Universitys expressed concerns regarding whether Oracle was going to meet the timelines for the BTI Project, the University could not assess whether the project was on track. Oracle refused to provide the necessary project information upon which any assessment could be made but constantly assured the University that the project was on track for being completed within the time periods stated in the contract. 77. In addition to its lack of project management, Oracle continually rotated staff into
and out of the BTI Project creating confusion on task and project duration and requiring work to be redone as new Oracle staff wanted to do things their way. Specifically, Oracle assigned 129 people to the BTI Project during an approximately 12 month period, both on- and off-shore resources. Most of the off-shore staff assigned to the project by Oracle worked part-time and often confused the BTI Project with other projects they were working on for other clients. The FPE permits the University to request Oracle remove a particular consultant providing services to the BTI Project if the University reasonably believed that he/she was not providing services as warranted and Oracle, after notice, was unable to resolve such performance issues. FPE at 21, 24. The University voiced many complaints to Oracle regarding problems with the staff assigned and constant rotation of staff, all of which were ignored by Oracle.
24
#1719626 v2 110772-75497
78.
In addition, during 2010, Oracle undertook its own internal audit of the BTI
Project. Although the University was entitled to a copy of this audit report under the terms of the FPE and demanded a copy of the audit, Oracle refused to turn over a copy. 79. Oracle represented to the University that the Project Manager assigned to the BTI
Project had multiple certifications from the Project Management Institute (PMI) and served on PMIs Global Corporate Council, which credentials and experience would assure the project was properly managed. PMI is internationally recognized as being the gold industry standard for project management professional certification. Oracle touted these qualifications as a significant reason why the University should hire Oracle, and they were a significant factor in the Universitys ultimate decision. PMIs Code of Ethics and Professional Conduct, sections 2.2.3 and 2.2.4 required Project Managers to fulfill the commitments they undertook, do what they said they would do, take ownership of errors and omissions, and make corrections promptly. Section 3.3 of the PMI Code also required Project Managers to negotiate in good faith and not exercise the power of their position to influence the decisions or actions of others in order to benefit personally at their expense. Section 5.2 of the PMI Code also required the Oracle Project Manager to earnestly understand the truth, be truthful in communications and conduct, and provide accurate information in a timely manner. Oracles Project Manager failed to adhere to these components of the PMI Code of Ethics in the project management and failed to effectively provide the level of professional management skills that Oracle represented it would provide to the University for the BTI Project. G. Oracle Fails to Deliver a Functional Financial Management System. 80. The first major application set to go live was the FMS system. FMS was
scheduled to be completed and placed into production (or go live) on July 1, 2010. The July 1, 25
#1719626 v2 110772-75497
2010 delivery date for FMS was selected because it corresponded with the beginning of the Universitys fiscal year. Implementing a financial system at any other time, other than a major accounting period ending date such as an interim quarter period, would create significant, complicated and unnecessary accounting work and significant additional conversion work. 81. A necessary step in implementing FMS was to convert certain University
financial data. Conversion activity was to commence in the February 2010 timeframe, which was important because later activities, such as testing, required the use of this converted data. The terms of Oracles contract required Oracle to host the computer hardware (at an Oracle location) needed for the University to convert its data (the Hosted Environment). Yet, when it came time for Oracle to provide the Hosted Environment, Oracle refused to do so unless the University signed a third amendment that, among other things, could have operated to exculpate Oracle from liability if Oracle breached its obligations to keep University data confidential. Oracles proposed amendment was inconsistent with Oracles obligation to maintain the Universitys data confidential under the terms of the parties existing contract as well as applicable state and federal laws including, without limitation, the Family Educational Rights and Privacy Act. As a result of Oracles failure to comply with the express terms of its contract, the University was unable to utilize the hosting site to load testing and training data. 82. Notwithstanding that these newly imposed terms and conditions were not
necessary under the terms of the existing agreement, the University attempted to negotiate with Oracle in good faith so that it could access the Hosted Environment. Ultimately those negotiations broke down when Oracle refused to consider any modifications proposed by the University to the third amendment drafted by Oracle. When Oracle was questioned by the University as to why the terms in the third amendment were necessary given the fact that the 26
#1719626 v2 110772-75497
parties had negotiated for months over the terms of their contract, Oracles Vice President and General Manager Thomas Ball stated it was because we just dropped the ball. Accordingly, beginning in February 2010 and continuing thereafter, Oracle refused to provide the Hosted Environment, causing a direct and material delay on the ability to meet the FMS go-live timeframe and significantly delaying the HCM implementation schedule. Ultimately, the University purchased and installed new hardware to host the Oracle instance. However, Oracles failure to comply with the terms of its contract impacted the testing schedule for FMS, one of the key drivers for the failure to go-live with FMS on July 1, 2010, and caused confusion around testing which was being done simultaneously of multiple environments. 83. Oracle also refused to provide certain implementation services it was required to
provide under the FPE. Beginning in March 2010, Oracle was to take the lead role in defining the security configuration to be included within the FMS application. FPE at 45, 48, 50, 51 (Application Security Design, where Oracle is designated as the Lead). As in any computer system, establishing proper security controls and user privileges is critically important to ensure the systems are secure, users can carry out their assigned responsibilities, and that business process workflows are followed. 84. In addition to the failure to provide the Hosted Environment for FMS when
required and the failure to provide the security configuration activities, Oracle failed to follow proper design and testing procedures. Because the BTI Project was to be integrated among all the various components (i.e., FMS, HCM, CS, etc.), the initial conceptual design sessions needed to take into consideration the design requirements of other software applications. For example, the design of both FMS and CS systems need to take into account the data requirements for each software application. Since Oracle knew how its systems worked and what information was 27
#1719626 v2 110772-75497
captured by each software application, the University relied on Oracle to inform the University when this critical information was needed. The University learned after the FMS, CS, and HCM CSDs were completed that Oracle failed to include within the CSDs critical data from all of these major applications to allow full integration. 85. Once the software applications were designed, Oracle was obligated under the
FPE to configure the Oracle Software to meet the design requirements as represented in the CSD document. Oracle delivered the FMS configurations late, leaving the University with an insufficient amount of time to test the FMS software applications, and without completing key components of the CSD. 86. The contract between the parties required testing to be accomplished in a logical,
incremental fashion, using generally recognized testing steps. The first step is to unit test software, which means an individual software application is tested to see if it delivers the required functionality. If that test passes, then the next test would involve a systems integration test, which is a test to ensure that all the individual software applications work together and that information flows from one application to the other without malfunctions. A critical component of systems integration testing is demonstrating that security configuration is working properly and, if not, User Acceptance Test (UAT) will inevitably fail. Also, during this test, interfaces, or software programs that are created to transfer information from one application to another, are tested. There are other tests along the way, but the last test that is critically important is the UAT. In the UAT, actual users test the software applications to make sure they work without any major malfunctions. Only when all these tests pass, should the software applications be placed into live use.
28
#1719626 v2 110772-75497
87.
The FPE also states that the Compass Methodology requires a testing strategy to
define the goals and purpose of each level of testing for unit, integration, system, and performance testing, and that for each type of test, the goals approach and participants will be clearly defined using a testing strategy document. Oracle failed to comply with the terms of its contract by failing to provide testing plans against which the University could assess whether or not the testing was successful. 88. Oracle materially failed on virtually every aspect of the testing program. Oracles
failures included: a. Delivering the configured software late to the University, thereby leaving insufficient time to test the software and not according to the timelines originally established for testing; User and security configurations were never completed so UAT could not be completed; Interfaces were delivered late making it difficult to test whether the interfaces worked properly; Delivering additional software modules late in the process, making it impossible to perform proper testing before July 1, 2010; and A ripple effect of Oracles late delivery of all of FMS components prevented the University from having sufficient time to train its staff to use and test the software.
b. c. d. e.
89.
Given the lateness in testing, Oracle recommended that the University conduct the
various tests concurrently, a practice that is not supported by Oracles own methodologies or any generally-recognized industry standards. Although the University rejected Oracles offer as contrary to industry practices and contrary to Oracles contractual obligations, the University did perform a test of the software, and the systems integration failed. Despite the failure of the test, Oracle recommended that the University go live, even though security was not ready to be tested and even though there existed major defects in the software applications that were not being 29
#1719626 v2 110772-75497
corrected by Oracle in a timely manner. Specifically, Oracle failed to prepare a security design strategy. As a result, user login and security profiles were not created at the time UAT was to begin. Therefore, UAT was delayed several days and once begun it was necessary to expand individual user security access (i.e., additional security roles were added to profiles) to enable users to get a pass result on the test scripts. This practice allowed users broader security access to the system than justified by the users job responsibilities, opening up the system to potential errors or misuse and thereby placing the Universitys multi-million dollar budget at risk. 90. In fact, the security system was so compromised during the UAT that one user
was able to create vendors in the names of his wife and children, create purchase orders in their names, and then cut checks to them. This is unacceptable to any large organization, particularly a state institution charged with the allocation and preservation of tax dollars. 91. Despite such monumental failures during the UAT, Oracle still urged the
University to go live. 92. The Institute of Electrical and Electronics Engineers (IEEE) established IEEE
829 which defines an international best practices standard for testing procedures to guide the development of any testing strategy document. The IEEE 829 standard requires test completion criteria to be established before the next level of testing begins. IEEE 829 further states that test suspension criteria should be established if the number or type of defects reaches a point where the following testing has no value, makes no sense to continue to the test, and further testing would be a waste of resources. Oracle failed to follow the IEEE 829 standard or its Compass Methodology in creating any testing standards. Moreover, and pursuant to these standards, when the Universitys systems integration tests failed, industry standards would require UAT testing to be suspended. 30
#1719626 v2 110772-75497
93.
When UAT failed, all further testing should have stopped and, pursuant to these
standards, go-live should never have been recommended by Oracle. Accordingly, Oracles failure to develop testing criteria violated both acceptable industry standards and its Compass Methodology incorporated by reference into the terms of its contract. The only possible motivation that Oracle could have had for urging the University to go live despite the numerous and substantial testing failures was to meet a payment milestone in the FPE and get paid. 94. On June 18, 2010, the University provided written notice to Oracle, recapping the
parties discussions and reciting the problems with the security configurations, interfaces, data conversion, missing software, unresolved defects, and untested elements of the FMS environment. The University stated that it would make every effort to go live on July 1, 2010, but if it could not, it would be due to Oracles failures, which had been previously stated. Oracles plan to go live despite the existence of numerous known defects created a host of additional risks, including the possibility of significant data loss and the risk that the University could be left without functioning financial software for an indeterminate period of time if critical errors were identified after FMS was in production. Because FMS was the backbone of the Universitys fiscal planning and day-to-day operations, the University could not risk the possibility that its financial data would be lost or corrupted or that it would be left without functioning financial management software. In addition, the lack of a functioning security module created a grave risk that the integrity of the Universitys financial controls would be compromised. 95. With no real assurances from Oracle that the problems would be corrected, on or
about June 30, 2010, the University made the decision to delay the go live of the FMS
31
#1719626 v2 110772-75497
applications. During this time period, Oracle took no responsibility or accountability for its own failures; instead it attempted to blame the University. 96. Because of its lack of adequate project management and oversight, Oracle was
unable to provide any adequate contingency plan in a timely manner to salvage this important milestone and get the BTI Project back on track. H. Oracle Engages in Dishonest and Bad-Faith Behavior During Performance of the Implementation Services. 97. Throughout the performance of services under the Services Ordering Document
and FPE, Oracles staff regularly engaged in dishonest and bad-faith business practices. 98. For instance, when problems arose due to failings in Oracles products and
services, Oracle would delay acknowledging and taking responsibility for the problem and, instead, would blame the University for the problem. 99. Oracle also submitted to the University acceptance certificates in which Oracle
represented that certain deliverables had been delivered when, in fact, they had not. 100. Moreover, the FPE clearly and expressly required that any acceptance certificates
(which are a prerequisite to the submission of an invoice for payment) be signed by the Universitys Chief Information Officer (or his designated representative if he is not available). But, when the Universitys CIO began to challenge the acceptance certificates, Oracle sought to have other lower-level individuals within the University sign acceptance certificates in an effort to get paid by the University when they were not entitled to such payment. I. Oracles Dishonest and Bad-Faith Business Practices Reach Their Peak in September 2010 When Oracle Repudiates the Contract by Seeking To Extort Millions of Dollars from the University by Threatening to Walk Off the Project. 101. From July to the end of September 2010, numerous communications and several
meetings occurred between the parties, during which time the University repeatedly requested 32
#1719626 v2 110772-75497
that Oracle provide an Integrated Project Management Plan that included a new, achievable timeline to complete the BTI Project. These discussions culminated in a presentation made by Oracle to the University on September 27, 2010, during which Oracle stated that to complete the BTI Project, Oracle required an additional $7,923,000 above and beyond the $15,750,000 fixed price Oracle originally agreed to in the FPE and accompanying Services Ordering Document. Oracle alleged a number of factors, all University based, that caused the failure of the project, but an examination of the factors indicated that either the University had nothing to do with the delay or the factors were precipitated by Oracles own failures. Oracle failed to identify a single item of failure on Oracles part in that report. 102. Oracles unilateral assessment that an additional $7,923,000 was required to
complete the BTI Project was made despite the fact that it was contrary to the change control process set forth in the parties agreement, which required that any expanded scope or fee change be agreed to in writing before any additional expense was incurred or work was performed. 103. On or about September 28, 2010, Oracle sent an email to the University stating
that it was Oracles intent to suspend (or stop) work on the MSU ERP Project if we do not have an amended contract that reflects the new timelines, increases in the scope and effort. The last day that Oracle staff will be on the project is October 28, 2010. Oracle made this demand without even following the change control process, or providing a proposed amendment to its contract to the University for review. Again, Oracle breached its contractual obligation to follow the change control process. For example, there were 244 change orders demanded by Oracle in the approximate amount of $1.1 million that were either functional requirements already specified in the FPE or like-for-like exchanges for customizations (CEMLIs) which are included within the fixed price according to the terms of the FPE. 33
#1719626 v2 110772-75497
104.
The University had no obligation to accept Oracles extortionary proposal in order
to oblige Oracle to complete the project. Oracles unilateral threat to withdraw its implementation staff and cease work on the project was an anticipatory repudiation of its agreement with the University. 105. Oracle also made demands for payment for incomplete deliverables that the
University had not accepted by submitting invoices dated October 29, 2010 and November 16, 2010. 106. As mentioned above, the FPE specifies that a deliverable is accepted only if an
acceptance certificate is signed by the Universitys CIO. FPE at 29, 4. If an acceptance certificate is not signed by the CIO, the FPE states that other indicia of acceptance shall not be effective for purposes of payment and shall not be effective against MSU. Id. 107. In addition to the foregoing, Oracle has demanded payment for numerous
deliverables, which were either not delivered to the University, delivered as incomplete, never accepted by the University, or never invoiced to the University. 108. J. The University has no obligation to pay for such deliverables.
Due to Oracles Repudiation of the Services Ordering Document and FPE and Its Failure To Provide the Implementation Services Required by the Services Ordering Document and FPE, the University Was Forced To Declare Oracle in Material Breach of the Services Ordering Document and FPE and Retain a Replacement Vendor to Fix Oracles Deficiencies and Complete the BTI Project. 109. In compliance with the terms of the LSA, by letter dated October 11, 2010, the
University provided written notice to Oracle that Oracle had materially breached the Services Ordering Document and FPE and specified the nature of the breaches. See letter from V. Van Baaren to S. Holdridge dated October 11, 2010 (the Breach Letter). The University also
34
#1719626 v2 110772-75497
demanded that Oracle immediately cure these breaches within 30 days and further provide a statement of adequate assurances. Id. 110. In addition to the foregoing, the Services Ordering Document states that [n]either
party shall terminate this ordering document related to the other partys uncured material breach until discussions have been elevated to the parties applicable Executive Sponsors, and either of the representatives in good faith concludes that amicable resolution through continued negotiation of the matter at issue does not appear likely. Services Ordering Document 5. 111. Pursuant to the terms of the Services Ordering Document, the University,
represented by its President and its attorneys, met with Oracles representatives on October 25, 2010 to discuss Oracles breaches. At that meeting, the University reinforced its demand that Oracle cure its breaches and that it had until November 11, 2010 to do so. During that meeting, Oracle refused to acknowledge its past breaches and reiterated its threat to stop work on the project unless the University agreed to pay Oracle millions of dollars more than the agreed-upon fixed price. Therefore, since Oracle was unwilling to cure its breaches or withdraw its repudiation of the agreement, the University concluded in good faith that amicable resolution through continued negotiation was unlikely. 112. The Services Ordering Document also required the parties to work in good faith
to transition the project if there was a termination. Services Ordering Document 7. The transition provisions of the Services Ordering Document included very specific and detailed obligations of Oracle to identify and then make available in the Universitys project repository the various project items that it had created. 113. During the 30-day period following the Universitys October 11, 2010 notice,
Oracle failed to cure the material breaches identified by the University and committed new 35
#1719626 v2 110772-75497
breaches of its contract by failing to comply with the detailed transition process in the Services Ordering Document. In addition, after October 11, 2010, when the University notified Oracle of its default and demanded a cure, Oracle began dumping partially completed deliverables on the University, for which it demanded payment after the University had terminated the contract. At this time, Oracle personnel were still on site but were not attempting to cure the breach, choosing instead to conduct business as usual. 114. On November 1, 2010, Oracle staff appeared on campus to continue previously
scheduled data mapping and work on HCM (i.e., business as usual), all of which was inappropriate given the project failures and breaches previously identified by the University. Oracle was advised by the University that Oracle staff should not be conducting business as usual but rather should either be working on a cure of the breaches or assisting with the transition. Otherwise there would be no purpose for the Oracle staff to be at the University. After consulting with Oracles legal counsel, Douglas Konselman, Oracle staff returned to the Universitys Chief Information Officers office, handed the Chief Information Officer the access keys, and said here you go and were out of here. Oracles personnel walked off the project on November 1, 2010 and never returned. 115. By November 11, 2010, Oracle had failed and refused to acknowledge that it had
breached its contract with the University, failed to take any corrective action to cure, failed to even propose a plan to cure the breaches identified by the University, and failed to withdraw its repudiation of the agreement. Therefore, by letter sent November 11, 2010 and after the expiration of the 30-day cure period required by the contract, Oracle was notified that the University was terminating the Services Ordering Document and the FPE for cause and would seek a replacement vendor to complete the project. 36
#1719626 v2 110772-75497
116.
In the event of a termination, the terms of the Services Ordering Document and
FPE required the following: Oracle shall generate a compiled list of all contract deliverables, CEMLI programs [custom programming], and software module configurations, setup parameters and values. The compiled list will serve as a checklist for turning over to MSU deliverables, CEMLI programs, and module configurations. Each entry will be checked as completed, work in progress, or not started. Additionally the iProjects repository of meeting minutes will be provided to MSU. The compiled inventory list will also serve as a catalog of items facilitating MSUs verification that all work was checked into MSU project library. An updated issues log will be turned generated [sic]. Oracle will also provide a listing of the document version, code version, release level and patch log to MSU. Services Ordering Document, 7. 117. Oracle was also under a contractual obligation to mitigate the damages resulting
from any termination, and the turning over of a list of deliverables would have helped mitigate at least in part the Universitys damages. Although the University made numerous requests for Oracle to comply with its obligations to provide the above information, Oracle initially refused and subsequently provided incomplete and inaccurate lists. 118. The lists referenced above were important because the University wanted
potential bidders for completion of the BTI Project to be able to review the project deliverables to determine whether they would be able to re-use the deliverables. The University hoped that if the bidders could use the previously prepared project deliverables from Oracle, it would lower the ultimate price for the successor vendor to complete the implementation services Oracle was contractually obligated to perform. The reason Oracles cooperation was critical was because the LSA states in Section C that the University has a non-exclusive, non-assignable, perpetual, 37
#1719626 v2 110772-75497
royalty-free right to use services upon payment. In numerous communications, the University advised Oracle in clear terms that if a successor vendor determined the deliverable was usable, the University would pay for it. However, Oracle continually refused to permit any viewing of the deliverables by the bidders or other third parties without the University first agreeing to pay for all the deliverables, whether or not they were completed, functional, or usable. The University did not want to pay for project deliverables that might turn out to be useless, but Oracle would not permit the University to allow bidders to review these deliverables without first agreeing to pay for them and threatened to sue the University for infringement if it did so. If Oracle had cooperated with the University by permitting potential replacement vendors to view all of the deliverables created by Oracle, it could have reduced the replacement vendors efforts to complete the BTI Project and mitigated the Universitys costs and damages. Despite the Universitys repeated requests for cooperation from Oracle, Oracle absolutely refused to cooperate and the mitigation of costs and damages was not possible. Notwithstanding, and in the hope of mitigating the costs of completing the implementation of FMS by a different vendor, the University forwarded a check to Oracle on December 22, 2010 in the amount of $368,846.00 as payment of deliverables FMC4, FMC5, HPC1 and HPC3 so that they could be examined by potential bidders. Consequently, when the University solicited bids for completion of the implementation of the BTI Project on February 11, 2011, it made available to bidders only the deliverables which had been paid for by the University. 119. Based on the feedback from the potential replacement bidders, it appears that
most of the work performed by Oracle and paid for by the University (including the deliverables paid for post-termination as a result of Oracles refusal to cooperate with transition) will not be re-useable, as the work failed to meet industry standards. The University previously paid Oracle 38
#1719626 v2 110772-75497
more than $6,000,000 under the FPE for these deliverables. Based on the initial bid responses from the replacement vendors, the direct, out-of-pocket cost to complete the BTI Project will, depending on the vendor ultimately selected, exceed Oracles bid by at least $10,000,000 and as much as $20,000,000. 120. Although it had already charged the University more than $6,000,000 for
implementation services for a non-functional system and despite its abysmal performance under the Services Ordering Document and FPE, Oracle has filed a notice under the New Jersey Contractual Liability Act of its intent to file suit seeking $5,300,000 in additional payments from the University for: a) work that was not authorized by change order pursuant to the terms of the parties agreement, and b) for work partially completed after October 11, 2010 that was not associated with curing Oracles defaults. Oracle claims the work partially completed after October 11, 2010 is payable because it delivered Acceptance Certificates to the University and notice of deficiencies of those deliverables was not issued by the University to Oracle within the time period generally prescribed by the FPE. The University rejects Oracles assertion that this work was authorized or is payable. The Universitys October 11, 2010 notice of default and demand for cure set forth in great detail the numerous deficiencies of Oracles performance and therefore is in compliance with the terms of the FPE. In addition, as a matter of law, Oracle may not claim payment for work it delivered after October 11, 2011 that is unrelated to a cure. 121. Oracle has no basis for demanding or receiving any such payment. COUNT I FRAUDULENT INDUCEMENT 122. The University incorporates by reference each of the preceding paragraphs as if
restated herein in its entirety.
39
#1719626 v2 110772-75497
123.
As discussed in detail above, in its response to the RFP, in its product
demonstration, and in meetings with MSU during the bidding process, Oracle made numerous misrepresentations of material facts about, among other matters, the number of the Universitys business requirements that were satisfied by its base system, the amount of customization that would be required to satisfy the Universitys business requirements, the quantity of the Universitys personnel and other resources that would be required to complete the project on the schedule proposed by Oracle. 124. In addition, in entering in to the Ordering Document and the FPE, Oracle falsely
represented that it intended to perform the implementation services described in those documents at the fixed-price of $15,750,000 when, in fact, Oracle never intended to perform those services at that price. Instead, Oracle intended to demand additional money from the University in the middle of the project before completing the project. 125. At the times that it made these misrepresentations, Oracle knew or believed that
they were false. 126. Oracle made these representations with the expectation and intent that the
University would rely on them in deciding whether or not to retain Oracle to complete the BTI Project. 127. In deciding to retain Oracle to complete the BTI Project, the University
reasonably relied to its detriment on Oracles representations, including the misrepresentations identified herein. COUNT II IN THE ALTERNATIVE, GROSS NEGLIGENT MISREPRESENTATION 128. The University incorporates by reference each of the preceding paragraphs as if
restated herein in its entirety. 40

#1719626 v2 110772-75497
129.
As discussed in detail above, in its response to the RFP, in its product
demonstration, and in meetings with MSU during the bidding process, Oracle made numerous misrepresentations of material facts about, among other matters, the number of the Universitys business requirements that were satisfied by its base product, the amount of customization that would be required to satisfy the Universitys business requirements, the quantity of the Universitys personnel and other resources that would be required to complete the project on the schedule proposed by Oracle. 130. At the times that it made these misrepresentations, Oracle should have known that
they were false and was grossly negligent in making them to the University. 131. Oracle made these representations with the expectation and intent that the
University would rely on them in deciding whether or not to retain Oracle to complete the BTI Project. 132. In deciding to retain Oracle to complete the BTI Project, the University
reasonably relied to its detriment on Oracles representations, including the misrepresentations identified herein. COUNT III BREACH OF CONTRACT (Grossly Negligent Performance of Contractual Obligations) 133. The University incorporates by reference each of the preceding paragraphs as if
restated herein in its entirety. 134. The Services Ordering Document and FPE are an enforceable contract between
Oracle and the University. 135. As described above, Oracle materially breached the Services Ordering Document
and FPE by, among other things, failing to meet deadlines, manage the BTI Project, and 41
#1719626 v2 110772-75497
complete deliverables as well as by demanding payment under threat of abandoning the project for payments not owed. 136. Based on the extreme failures to provide services described above, including
proper project management; refusal to provide proper reporting; failure to provide services after multiple demands; withholding services where there was no legitimate basis to do so; and staffing with Oracle employees who had no knowledge of or experience with the methodologies that were being used to implement the BTI Project, Oracle has been grossly negligent and has engaged in willful misconduct in the performance of its obligations under the Services Ordering Document and FPE. 137. As described above, Oracle has failed to correct its breaches, entitling the
University to recover all fees paid to Oracle for services under the FPE. 138. As a result of Oracles breaches of the Services Ordering Document and FPE, the
University has suffered damages and has been harmed in multiple ways, including, without limitation, by overpaying for incomplete or unusable deliverables and being forced to incur significant additional cost to remedy Oracles failures and complete the BTI Project. In addition, the University has been subjected to repeated business interruptions caused by Oracles failed attempts to go live with incomplete and unstable portions of the system and has been unable to realize the expected administrative efficiencies and cost savings that were to result from the successful implementation of the BTI Project. COUNT IV BREACH OF CONTRACT (Willfull Anticipatory Repudiation of Contract) 139. The University incorporates by reference each of the preceding paragraphs as if
restated herein in its entirety. 42

#1719626 v2 110772-75497
140.
As discussed above, on or about September 28, 2010, Oracle sent the University
an e-mail, advising the University of Oracles intent to suspend (or stop) work on the MSU ERP Project if we do not have an amended contract that reflects the new timelines, increases in the scope and effort. The last day that Oracle staff will be on the project is October 28, 2010. 141. The statement by Oracle was a definite and unconditional declaration that it
would not render the performance it agreed to render on the terms it agreed to render them on. 142. Not only did Oracle fail to withdraw this unconditional declaration, it renewed it
during the meeting of October 25, 2010 that was attended by the parties Executive Sponsors. 143. As a result, Oracle anticipatorily breached the Services Ordering Document and
FPE, thus excusing the University from future performance and making Oracle responsible to the University for damages. COUNT V BREACH OF DUTY OF GOOD FAITH AND FAIR DEALING 144. The University incorporates by reference each of the preceding paragraphs as if
restated herein in its entirety. 145. Oracle owed a date to the University to act in good faith and deal fairly and
honestly with the University. 146. As discussed above in detail, Oracle intentionally deliberately, and in bad faith
refused and failed to discharge their contractual obligations to the University, and failed to deal honestly with the University. 147. As a result of Oracles conduct, the University has been deprived of its reasonable
expectation and benefits under the Services Ordering Document and the FPE.
43
#1719626 v2 110772-75497
COUNT VI DECLARATORY JUDGMENT 148. The University incorporates by reference each of the preceding paragraphs as if
restated herein in its entirety. 149. Pursuant to the Declaratory Judgment Act, this Court has authority to issue a
declaration of the parties respective rights and status under a contract where an actual case or controversy exists. N.J. Stat. 2A:16-50, et seq. 150. As described above, an actual controversy exists between the University and
Oracle on the basis of Oracles claim that the University has breached the Services Ordering Document and FPE. 151. The University has paid for all deliverables for which it was required to pay and is
not in breach of the Services Ordering Document and FPE. 152. As a party in material breach of the Services Ordering Document and FPE, Oracle
has no legal right to seek continued performance from the University by way of additional payment. WHEREFORE, the University respectfully demands judgment against Oracle awarding the University compensatory damages, punitive damages, all court costs, and such other relief as this Court deems appropriate.
44
#1719626 v2 110772-75497
GIBBONS P.C. Attorneys for Plaintiff Montclair State University
By:___________________________ David E. DeLorenzi Michael Cukor Christopher Walsh Luis J. Diaz
Dated: December __, 2011
45
#1719626 v2 110772-75497
EXHIBIT A
Requirement Reproduce prior-period statements; allow the students to reprint priorperiod statements The system allows for restricted access and protection of FERPA information (Family Educational Rights and Privacy Act) Link work study funds made available as part of a financial aid package with the payroll or accounts payable systems. Provide for the creation of a transaction file of student employment authorization information for institutional use. Interface with HR for the disbursement of work-study payments 13 8 442 15 Req No. 47 8 5 Req. ID 114 108 328
435
Record the collection agency to which a past due account has been transferred by date of transfer, term and amount sent. If account is sent to more than one. System must include core programming that creates a full extract of all basic data elements that can be exported to a query able Operational Data Store (ODS) or in Excel or CVS format. (accounts receivable reports; other reconciling financial reports) Include a Point of Sale system (POS) or interface with a third party POS system Have the ability to generate refund checks based on an overnight process; have the amount feed to FRS/Accounts Payable to either send money electronically or print a check Ability for the student to enroll online to have refunds sent electronically to a bank of their choice; have rejection notices sent from the bank directly to the student if information is incorrect Interface with third-party systems to generate refund checks or send money electronically to a bank of the students choice Automatically calculate the amount of financial aid refund to be disbursed to students from each program, generate the checks, EFT transfer information, print a check, distribution ledger, and post to appropriate financial aid ledger Automatically charge an account a fee for posting of a non-sufficient funds check; flag and update a student record with a notation of the returned payment; send an electronic notice to the student Deposit payments to an unlimited number of configured bank accounts.
128
1 2
17 18
19
4 5
20 34
35
25
92
#1719626 v2 110772-75497
Produce Student Bills directly through the system; allow for individual reprints; archive information according to predetermined dates. Post payments (Cash, check, credit card) against receivables in real time. Process all formats of refunds for credit card transactions through the credit card service provider or interface. Allow the students to view an account balance based on a specific term or point in time. Allow automation of student payments including EFTs. Allow students to print receipts or track payments Allow students and third-parties to make payments online in real time; allow students to send notification of payment if needed; print transaction history. Allow students and third-party entities to review account information and status online based on a specific term or point in time. Generate and update billing statements on-line for the student to view 24/7; give the student the ability to add viewing privilege to other interested parties Allow students to enroll in EFT for refunds, view and submit health insurance waivers (have submitted waivers go into a batch file that will update their student account); view all account holds with the payment thats due; update billing address Create, maintain and publish an annual Master Schedule with view access to other departments. Maintain an institutional, transfer, major, minor and overall grade point average for each student. Automate graduation checking based on user-defined criteria, in batch or on demand. Assign an unlimited number of faculty members to a section, checking for time and room conflicts. Automate movement and notification of students when a class is cancelled Enter faculty assignments individually at the class schedule level or all at once for a faculty member. Establish faculty workload calculation rules broken out by workload term rules and workload contract rules, and perform the analysis on-line. Perform trend report on course demand and historical course data; perform future course offering needs based on this analysis as well as results of batch degree audits. Interface with an administrative analysis and projection system Interface with National Clearing House and provide a repository for historical submissions. Load prospects and test scores from ACT, SAT, GRE, and GMAT, MAT, PRAXIS, TOEFL, et al. from electronic sources. -2-
36 43 44 48 1 3
103 110 111 115 131 133
10 11
140 40
136
1 3 9 6 14 33 35 47
122 454 493 523 531 550 552 565
6 7 17
611 612 43
#1719626 v2 110772-75497
Course Catalog Reports Course Offerings Reports Generate NSC data for verification of eligibility. Calculate degree honors. Calculate the academic standing (good standing, probation, dismissal) of a student. Provide quick and easy graduation checkout processing. From results of degree audit, allow student to select course and check for semester offering to process registration, select course description and easily toggle back and forth. Display and resolve room scheduling conflicts Duplicate a section on-line from an existing section. Locate sections on-line with a selected status (i.e. closed, canceled) and/or specified capacity or enrollment information. Also provide this option for students during self service registration. Maintain faculty workload information Query for an available faculty member. Record faculty department, college, home indicator and percentage of responsibility to the department and college. Track and update course information, as needed, by future effective term without impacting current processes, minimizing data input. Track instructional workload. Interface course descriptions with registration sections and degree audit results. Upload faculty data, name, dept, ran, date of birth with HR Perform auto section numbering during initial scheduling. Ability to enter free form information regarding course at inventory and term section level. Interface with Human Resource system. Automate grade changes (e.g. Incomplete to F after expiration time range) on a pre-defined date range and notify staff and students regarding such changes. Capture, calculate and maintain multiple GPA types, Store multiple calculated GPAs for each GPA type Provide ability to end cumulative academic statistics and start a new within same academic records. Provide ability to suppress specific semesters grades from appearing on transcripts and degree audits while grading is being processed. Display exception notifications such as disclaimers and course related information when student registers for a class prior to the confirmation of enrollment. -3-
7 8 1 6 7 24 26
138 139 368 457 458 508 509
28 29 40
545 546 557
45 51 53 70 72 76 80 81 84 12 4
562 568 570 587 589 593 597 598 601 617 626
6 13 20 22 24
628 635 641 643 669
#1719626 v2 110772-75497
Display the sections causing time conflict to occur. Generate student enrollment certification forms and letters (e.g. in good status letter) based on student attributes such as student status, requests and other user specified criteria. Identify all sections of a course that are open and do not conflict with a students schedule Locate on-line all sections of a course with a selected status such as closed, canceled, with specific seats taken, capacities, and seats available. Maintain accurate, up-to-the-minute enrollment counts on-line. Maintain on-line a history of the verification requests and to whom the information was sent. Manage wait-lists using various user-definable algorithms. Automatic notification to student when a conditional enrollment becomes a failure after current grade cycle is completed (i.e students who end up failing a pre-requisite course) Maintain the history of enrollment certification requests Access various forms, route for electronic signatures. From registration, allow student to select course description, degree audit, and easily toggle back and forth. Allow students to apply on line for graduation using administratively applied criteria, submit formal name for diploma including accents and special characters. Close access to change various submissions controlled by administrative office. Provide for next-of-kin and emergency contact name, address, phone number, email Provide for unlimited academic action rules Provide for unlimited Deans List rules Record and maintain an unlimited number of student attributes (e.g. data of birth, gender, ethnicity, parents name, high school Allow students to check the availability of course sections by searching for courses alphabetically, by day and time, by course and Allow students to print their unofficial transcripts, schedules and degree audits; provide last activity date to schedules. Display on-line detailed information for each student about all transcripts requested, pending or produced. Manage recruitment, admissions, and retention metrics. Interface with Advisor system
26 31
671 676
36 38 39 41 44 75
681 683 684 686 689 720
79 11 12 15
724 746 747 750
20 22 25 47 1 2 16 15 14
779 781 784 806 824 825 839 84 619
-4#1719626 v2 110772-75497
Ability to transmit Commonline data records from to loan servicer Ability to receive Commonline data records from loan servicer
13
272
14 Ability to transmit Commonline data change records to loan servicer Ability to receive EFT data records from loan services 15
273
274
Automate grade changes of repeats when course is repeated Perform automatic grade changes of repeated courses, set by administratively defined rules. Import and export EDI transcripts Prevent registration into the same section or into a class for which credits have been previously earned. This is also intended to prevent students from re-taking a course to achieve a higher grade. Allow administrative enabling/disabling and setting of c Allow students to apply on line for graduation, using administratively applied criteria, submit formal name for diploma including accents and special characters. Close access to change various submissions controlled by administrative office. Store commencement name pronunciations. Graduation Reports Support bar-coding and other asset tracking features to assist in inventory management. Enable users to review as of balances, pointin-time balances, and average balances per user specified period. Generate reports on all transfers to external entities.
16 17 1 2 53
275 639 725 607 698
15
750
35 11 21 13
794 142 32 258
7 Generate interest management reports detailing earnings and allocations by multiple user-specified criteria. Checks generate must pass bank inspection. 10 2
398
406 172
-5#1719626 v2 110772-75497
Ability to provide for the issuance of manual checks produced at a MICR printer. The manual check should have the same appearance as an automatically created check. Generate checks and payment advices in batch and individually based on user-specific criteria. Integrate seamlessly with receivables processed to collect funds from vendors and recover overpayments. Map check data to bank accounts and check generation processing. Notify users of a potential duplicate payment according to userconfigurable business rules prior to processing the payment. Provide fully integrated check processing capability and printing support. Ability to provide an manual check process that automatically updates the General Ledger and liquidates associated encumbrances even if processed intra-day
10
180
13
183
14
184
15
185
16
186
17
187
Integrated with in-house check generation functionality, including but not limited to integrated Accounts payable systems and third party check generation applications such as Bottomlines Paybase Express. Vendor Compliance and Non-Compliance Repots
18 4
188 174
Process and approve purchase orders based on user-configurable work flow processes
3 27
3 483
-6#1719626 v2 110772-75497
Support the generation of financial statements in final presentation format with audit trail drill down capability Enable automatic and manual generation of year-end closing journals (e.g. income statement and balance sheet journals) based on user configurable business rules. Automate the reversal of prior year balance sheet journals(e.g. accruals) and update balances for the new fiscal years. Support encumbrance and budget balance carry forward based on userconfigurable business rules. Support the use of an adjusting period in the accounting calendar configuration Support manual and automated opening of the first accounting period in the new fiscal year.
436
438
439
440
8 Define and maintain controls and business rules to assist with and maintain uniform closing processes across organizations. 9 Ability to generate the Comprehensive Annual Financial Report (CAFR) with the State of New Jersey standard reports 10
441
442
443
444
-7#1719626 v2 110772-75497
Reporting must conform to guidelines as required by GASB, FASB and NACUBO Must also conform to standard AICPA and GAAP standards, including a statement of revenue and expenses, balance sheet and cash flow. Drill-down access from the financial reports to the all supporting data including imaged documents and approvals. Generate Trail Balance and other general reports to support audit requirements and data presented in final reports Support the generation of financial statements in final presentation format with audit trail drill down capability. Ability to generate the Comprehensive Annual Financial Report (CAFR) with the State of New Jersey standing reports. Reporting must conform to guidelines as required by GASB, FASB, and NACUBO.
445
446
447
448
436
1 Must also conform to standard AICPA and GAAP standards, including a statement of revenue and expenses, balance sheet and cash flow. 2
444
445
446
-8#1719626 v2 110772-75497
Ability to provide standard reports at the lowest level of detail, with consolidation of the data according to the user-defined chart of accounts Ability to provide on-line funds availability checking for user defined transactions. Ability to provide recurring journal vouchers Ability to provide for on-line review of all supporting tables during transaction processing. Ability to provide for the encumbrance of purchase orders, and other user defined transactions. Provider for transfer of encumbrances from a requisitions to a purchase order. Ability to define and utilize embedded workflow to route and approve journal voucher documents and other account create/edits, cash receipts and disbursements electronically. Ability to provide authorized user overrides to by-pass funds availability checking. Ability to provide a translation table for definition of external report codes to the institutions chart of accounts for reporting to external agencies. Ability to restrict user access to see and review only authorized departmental funding sources Ability to provide for user-controlled rule-based transaction processing and editing. Ability to provide default values or data entry short cuts and data integrity checking. Enable users to generate reports based on user-specified criteria, including but not limited to account analysis reports, trial balance reports, budget reports, chart of accounts reports, consolidation reports and journal reports.
336
337
10 11
338 339
12
340
13
341
14 15
342 343
16
344
17
345
18
346
19
347
399
-9#1719626 v2 110772-75497
Support the generation of financial statements in final presentation format with audit trail drill down capability. Enable automatic and manual generation of year-end closing journals (e.g. income statement and balance sheet journals) based on user configurable business rules. Automate the reversal of prior year balance sheet journals (e.g. accruals) and update balances for the new fiscal year. Support encumbrance and budget balance carry forward based on userconfigurable business rules. Support the use of an adjusting period in the accounting calendar configuration. Support the manual and automated opening of the first accounting period in the new fiscal year.
436
438
439
440
8 Define and maintain controls and business rules to assist with and maintain uniform closing processes across organizations. 9 Ability to generate the Comprehensive Annual Financial Report (CAFR) with the State of New Jersey standard reports. 10
441
442
443
444
- 10 #1719626 v2 110772-75497
Reporting must conform to guidelines as required by GASB, FASB, and NACUBO. Must also conform to standard AICPA and GAAP standards, including a statement of revenue and expenses, balance sheet and cash flow. Drill-down access from the financial reports to the all supporting data including imaged documents and approval. Generate Trail Balance and other general reports to support audit requirements and data presented in final report.
445
446
447
Ability to provide for the matching of outstanding checks with cleared checks. Generate payment reconciliation reports. Ability to provide a complete bank reconciliation process. Enable the configuration of multiple banks and bank accounts at the institutional level and individually Establish and maintain all forms of transaction exchange required for transaction processing (e.g., ACH, EFT, and positive pay) among MSU, its Affiliates, and their banks
5 61
448 144
78 81
161 164
234
- 11 #1719626 v2 110772-75497
Paper Invoices can be scanned into the system and be treated as an electronic invoice in the workflow. Support the processing of vendor invoices via EDI. The process needs to validate the data, including PO match before accepting the upload into AP. Support the scanning of documents related to a request, purchase order or invoice and provide a link to those documents/files. Define and maintain aging rules and categories. Generate and maintain invoices through manual entry and enable automatic invoice generation for invoice data received electronically. Enable authorized users to modify and correct invoices
64
147
65
148
67
150
74
157
75
158
Ability to provide for the matching of outstanding checks with cleared checks. Generate payment reconciliation reports. Ability to provide a complete bank reconciliation process. Enable the configuration of multiple banks and bank accounts at the institutional level.
76 61
159 144
78 81
161 164
234
- 12 #1719626 v2 110772-75497
Automatic interface with Finance Records system for salary and benefit expense. Provide position detail in interface with Finance Record system. Interface with payroll or accounts payable systems to generate paychecks, W-2s, and I-9s as per federal, state, (e.g., unclaimed funds sent back to the state) and city regulations. Have the ability to generate refund checks based on an overnight process; have the amount feed to FRS/Accounts Payable to either send money electronically or print a check. Provide the capability to format for pay forms and advices. Provide the capability to view current and historical pay information (checks and advices). Maintain multiple years of play history on-line. Create electronic format for direct deposit. Produce a benefits statement for each employee. Support of State Retirement System and the Public Employees Retirement System (PERS). Provide the capability to interface with the systems of the benefit providers. Calculate and report FTE according to PERS requirements for the purpose of calculating contribution amounts. Define effective dates of each benefit/deduction based on service date, first actual work day, beginning of current month, beginning of next month, or user-specified date. Establish mandatory approval levels based on personnel action. Provide position detail in interface with Finance Records system. Establish mandatory approval levels based on personnel action. Provide the capability to establish processing and notification rules for appointment renewals.
103
362
36
402
15
444
2 36 39
18 295 298
52 74 16 57
311 333 60 147
30
74
7 11
97 55
7 36 7
507 402 507
30
210
- 13 #1719626 v2 110772-75497
Define a Fair Labor Standards Act (FLSA) classification for each position. Provide the capability to set up FLSA rules and rates. Provide the capability to set up FLSA rules and rates. Provide an online roster of current and previous incumbents for each position. Provide an on-line roster of positions by department. Provide an on-line roster of positions by job classification. Provide the capability to track work study students and any change in their student statuses for FICA taxability impact. Maintain multiple years of pay history on-line. Calculate multiple year budgets. Capture budget history on fringe budgets by position. Capture budget history on premium earnings budgets by positions.
12
102
34
293
34 15
293 423
16
424
17 38 52 11 12
425 297 311 377 378
13 Capture position budget history on salary budgets by position. 14 30 30 30 30 30 30 2
379
Provide the capability to interface with the systems of the benefit providers. Provide the capability to interface with the systems of the benefit providers. Provide the capability to interface with the systems of the benefit providers. Provide the capability to interface with the systems of the benefit providers. Provide the capability to interface with the systems of the benefit providers. Provide the capability to interface with the systems of the benefit providers. Provide the capability to create rules, templates, and schedules, work hour limits at job title level and with high-level of variability. - 14 -
380 74 74 74 74 74 74 460
#1719626 v2 110772-75497
Provide the capability to interface with the systems of the benefit providers. Provide the capability to import time entries from 3rd party systems / data collection devices.
30 10
74 468
- 15 #1719626 v2 110772-75497

Oracle Montclair Amended

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Oracle Montclair Amended

Uploaded by

Copyright:

Available Formats

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 1 of 60 PageID: 692

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 2 of 60 PageID: 693

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 3 of 60 PageID: 694

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 4 of 60 PageID: 695

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 5 of 60 PageID: 696

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 6 of 60 PageID: 697

Oracle responded to the Universitys RFP by producing a so-called exceptions

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 7 of 60 PageID: 698

Only one other bidder responded to the Universitys RFP. 7

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 8 of 60 PageID: 699

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 9 of 60 PageID: 700

These representations, which were material to the Universitys decision to

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 10 of 60 PageID: 701

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 11 of 60 PageID: 702

Specifically regarding Oracles implementation and project-management services,

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 12 of 60 PageID: 703

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 13 of 60 PageID: 704

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 14 of 60 PageID: 705

In connection with the Universitys existing system requirements, on February 27,

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 15 of 60 PageID: 706

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 16 of 60 PageID: 707

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 17 of 60 PageID: 708

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 18 of 60 PageID: 709

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 19 of 60 PageID: 710

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 20 of 60 PageID: 711

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 21 of 60 PageID: 712

Oracles contract also required it to deliver to the Universitys Project Manager,

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 22 of 60 PageID: 713

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 23 of 60 PageID: 714

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 24 of 60 PageID: 715

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 25 of 60 PageID: 716

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 26 of 60 PageID: 717

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 27 of 60 PageID: 718

Case 3:11-cv-02867-FLW -LHG Document 32-1

Filed 12/13/11 Page 28 of 60 PageID: 719

Case 3:11-cv-02867-FLW -LHG Document 32-1