OracleMontclairAmended

#1719626 v2 110772-75497

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 Oracle’s fraud in inducing the University to retain Oracle to

implement the University’s new integrated enterprise resource planning computer system (the

“ERP System”) and Oracle’s 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 University’s twenty-five year-old aging computer systems and was an integral part of

the University’s plan to improve its administrative and student services capabilities as New

Jersey’s 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.

Case 3:11-cv-02867-FLW -LHG Document 32-1 Filed 12/13/11 Page 1 of 60 PageID: 692

2 #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 University’s business

requirements, the amount of time, resources, and personnel that the University would have to

devote to implement the ERP System, Oracle’s 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 Oracle’s 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


3 #1719626 v2 110772-75497

the BTI Project. As will be discussed below, the University’s selection of Oracle’s 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 University’s finance system, Oracle sought to extort millions of dollars from the

University by advising the University that it would not complete the implementation of the 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 Oracle’s 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 University’s costs for the BTI Project by

more than $10,000,000. Oracle’s 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 University’s legacy system during the extended period of time to complete the BTI


4 #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. Oracle’s 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

University’s 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

University’s 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.


5 #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

University’s more than 3,200 requirements and asked the bidders to state whether the

requirement was met by the bidder’s “Base Product” and, if not, whether a customization of the

bidder’s 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 University’s

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.”


6 #1719626 v2 110772-75497

15. Oracle responded to the University’s 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 University’s 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 Oracle’s 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

University’s satisfaction that the bidder’s base system satisfied the University’s most critical

business requirements.

17. As part of this demonstration process, the University prepared test scripts

identifying the University’s 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 University’s requirements were made, Oracle continued to

represent that virtually all of the University’s business requirements (including, in particular,


7 #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

University’s 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

Oracle’s base product would meet considerably more of the University’s critical business

requirements than the other bidder’s1 base product and that Oracle’s system would therefore

require much less customization and many fewer additional products than the other bidder’s.

Consequently, the University believed that selecting Oracle’s 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 bidder’s product met the University’s

business requirements was given the greatest weight in its selection process.

23. As will be discussed in more detail below, Oracle’s representations -- in writing

and in the live demonstration -- about the extent to which its base system provided the critical

functionality to meet the University’s most important business requirements were not true 1 Only one other bidder responded to the University’s RFP.


8 #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 University’s requirements for an online Enrollment

Management process. The fact is that the on-line application functionality was not part of the

base system. Instead, Oracle’s ultimate implementation plan was to sell the University a third-

party 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

University’s requirements for Enrollment Management and other critical functionality.

B. Oracle’s Misrepresentations About the Sufficiency of the University’s 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.


9 #1719626 v2 110772-75497

26. These representations, which were material to the University’s decision to

contract with Oracle, were made repeatedly by Thomas Ball, Oracle’s 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 University’s 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 so-

called “Accelerated Compass Methodology” pursuant to which Oracle would host certain of the

University’s data on Oracle’s 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 University’s 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.


10 #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, Oracle’s 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. Oracle’s 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

University’s data on the terms the University and Oracle agreed to. Thus, the central efficiency

on which Oracle’s accelerated schedule was based was itself based on a false promise by Oracle.

33. To make the University comfortable with the notion that the University’s limited

resources could meet the University’s 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 Oracle’s project-management and

implementation expertise, the system would be implemented on time and within budget.

34. For instance, in Oracle’s “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.”


11 #1719626 v2 110772-75497

35. Specifically regarding Oracle’s 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. Oracle’s 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 Oracle’s 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. Oracle’s 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 Oracle’s team

members did not know the Compass Methodology and had not been trained in it. Again, in light

of Oracle’s affirmative statements about its project manager’s 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.


12 #1719626 v2 110772-75497

C. Oracle’s Misrepresentations About Its Intention To Perform Implementation Services at the Agreed-Upon Fixed Price.

39. In its initial response to the University’s 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 Oracle’s “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

Oracle’s 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 University’s 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.


13 #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

Oracle’s 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 University’s Evaluation Committee selected Oracle to provide a PeopleSoft

suite of products and implementation services. These products included Oracle’s 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 University’s Board

of Trustee’s 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 University’s Evaluation

Committee again selected Oracle for the BTI Project.


14 #1719626 v2 110772-75497

46. In connection with the University’s 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. In the Fixed Price Exhibit, Oracle, among other things, made the following

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 Because the contract documents are voluminous, are already in Oracle’s 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.


15 #1719626 v2 110772-75497

FPE at 1 ¶ 1(a).

49. The Attachments referenced in the contract are important as they form the core of

Oracle’s 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.

Attachment B Work Products, Services and Deliverables – Description of work products, services, and deliverables for the project.

Attachment C-1 MSU Business Requirements – This document comprised over 3,000 of the University’s 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).

Attachment D 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.

Attachment E 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.

Attachment G 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).

Attachment J Acceptance Form for Milestone Payments – Specifically, the form stated that the University’s Chief Information


16 #1719626 v2 110772-75497

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 Oracle’s satisfactory completion of

a particular project deliverable. FPE at 368-96.

E. Oracle’s 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 University’s 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 University’s


17 #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 University’s business requirements. At that

point, it became apparent that many of the University’s business requirements that Oracle had

represented would be met by Oracle’s base system were not, in fact, satisfied by Oracle’s base

system and that substantially more customization than Oracle had initially represented would be

needed was in fact required to meet the University’s 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 Oracle’s base system failed to satisfy.

56. For almost all of the instances where the University discovered that a business

requirement was not met by Oracle’s 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


18 #1719626 v2 110772-75497

Oracle and the University and played a material role in Oracle’s failure to meet its first go-live

deadline.

58. Many of the business requirements which were not satisfied by Oracle’s 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 Oracle’s change request or otherwise

risk missing critical go-live deadlines.

59. The additional customization that was required to meet the University’s business

requirements created substantially more work than originally anticipated by the University for its

team and Oracle’s 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 Oracle’s failure to meet the project’s 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. Oracle’s


19 #1719626 v2 110772-75497

representations that it could provide these project-management functions was a critical factor in

the University’s 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 Oracle’s 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.


20 #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.


21 #1719626 v2 110772-75497

67. Oracle’s contract also required it to deliver to the University’s 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 Project’s 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 Oracle’s Project Manager,

Christian Kim, agreed with the University’s status, Oracle’s Lead Project Manager, Robert

Kohler, re-coded FMS to “yellow” (a less critical problem designation) at a project meeting but


22 #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 Oracle’s 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 Oracle’s failure to integrate

University tasks into the reports, the University was constantly requested by Oracle to respond to

tasks with less than 1 week’s 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.


23 #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, didn’t understand it, and

weren’t 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


24 #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. Oracle’s failure to supply accurate and up-to-date project status reports, in

combination with Oracle’s failure to provide an overall integrated project plan and failure to

follow its Compass Methodology, created a situation in which, despite the University’s

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.


25 #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

PMI’s 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

University’s ultimate decision. PMI’s 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. Oracle’s 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,


26 #1719626 v2 110772-75497

2010 delivery date for FMS was selected because it corresponded with the beginning of the

University’s 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 Oracle’s 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.

Oracle’s proposed amendment was inconsistent with Oracle’s obligation to maintain the

University’s 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 Oracle’s 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


27 #1719626 v2 110772-75497

parties had negotiated for months over the terms of their contract, Oracle’s 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, Oracle’s

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


28 #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.


29 #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. Oracle’s

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;

b. User and security configurations were never completed so UAT could not be completed;

c. Interfaces were delivered late making it difficult to test whether the interfaces worked properly;

d. Delivering additional software modules late in the process, making it impossible to perform proper testing before July 1, 2010; and

e. A ripple effect of Oracle’s late delivery of all of FMS components prevented the University from having sufficient time to train its staff to use and test the software.

89. Given the lateness in testing, Oracle recommended that the University conduct the

various tests concurrently, a practice that is not supported by Oracle’s own methodologies or any

generally-recognized industry standards. Although the University rejected Oracle’s offer as

contrary to industry practices and contrary to Oracle’s 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


30 #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 University’s 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 University’s systems integration tests failed, industry standards would require UAT testing to

be suspended.


31 #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, Oracle’s

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 Oracle’s failures, which had been previously stated.

Oracle’s 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

University’s 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 University’s 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


32 #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, Oracle’s staff regularly engaged in dishonest and bad-faith business practices.

98. For instance, when problems arose due to failings in Oracle’s 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

University’s Chief Information Officer (or his designated representative if he is not available).

But, when the University’s 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. Oracle’s 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


33 #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 Oracle’s own failures. Oracle failed to identify a single

item of failure on Oracle’s part in that report.

102. Oracle’s 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 “Oracle’s 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.


34 #1719626 v2 110772-75497

104. The University had no obligation to accept Oracle’s extortionary proposal in order

to oblige Oracle to complete the project. Oracle’s 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 University’s 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. The University has no obligation to pay for such deliverables.

J. Due to Oracle’s 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 Oracle’s 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


35 #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 party’s 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 Oracle’s representatives on October 25,

2010 to discuss Oracle’s 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 University’s project repository

the various project items that it had created.

113. During the 30-day period following the University’s October 11, 2010 notice,

Oracle failed to cure the material breaches identified by the University and committed new


36 #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 Oracle’s legal counsel, Douglas Konselman, Oracle staff returned to the

University’s Chief Information Officer’s office, handed the Chief Information Officer the access

keys, and said “here you go” and “we’re out of here.” Oracle’s 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.


37 #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 MSU’s 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 University’s 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 Oracle’s cooperation was critical was because the

LSA states in Section C that the University has a non-exclusive, non-assignable, perpetual,


38 #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 vendor’s efforts

to complete the BTI Project and mitigated the University’s costs and damages. Despite the

University’s 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 Oracle’s refusal to cooperate with transition) will not be

re-useable, as the work failed to meet industry standards. The University previously paid Oracle


39 #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 Oracle’s 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 Oracle’s 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 Oracle’s assertion that this

work was authorized or is payable. The University’s October 11, 2010 notice of default and

demand for cure set forth in great detail the numerous deficiencies of Oracle’s 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.


40 #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 University’s

business requirements that were satisfied by its base system, the amount of customization that

would be required to satisfy the University’s business requirements, the quantity of the

University’s 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 Oracle’s representations, including the misrepresentations

identified herein.

COUNT II IN THE ALTERNATIVE, GROSS NEGLIGENT MISREPRESENTATION




41 #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 University’s

business requirements that were satisfied by its base product, the amount of customization that

would be required to satisfy the University’s business requirements, the quantity of the

University’s 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 Oracle’s representations, including the misrepresentations

identified herein.

COUNT III BREACH OF CONTRACT

(Grossly Negligent Performance of Contractual Obligations)



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


42 #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 Oracle’s 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 Oracle’s failures and complete the BTI Project. In addition,

the University has been subjected to repeated business interruptions caused by Oracle’s 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)




43 #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 “Oracle’s 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



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 Oracle’s conduct, the University has been deprived of its reasonable

expectation and benefits under the Services Ordering Document and the FPE.


44 #1719626 v2 110772-75497

COUNT VI DECLARATORY JUDGMENT



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 Oracle’s 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.


45 #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


#1719626 v2 110772-75497

EXHIBIT A

Requirement Req No. Req. ID Reproduce prior-period statements; allow the students to reprint prior-

period statements 47 114

The system allows for restricted access and protection of FERPA information (Family Educational Rights and Privacy Act)

8 108

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

5 6

13

328

435

442 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.

8 15

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)

7 128

Include a Point of Sale system (POS) or interface with a third party POS system

1 17

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

2 18

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

3 19

Interface with third-party systems to generate refund checks or send money electronically to a bank of the students choice

4 20

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

5 34

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

6 35

Deposit payments to an unlimited number of configured bank accounts. 25 92


- 2 - #1719626 v2 110772-75497

Produce Student Bills directly through the system; allow for individual reprints; archive information according to predetermined dates.

36 103

Post payments (Cash, check, credit card) against receivables in real time. 43 110 Process all formats of refunds for credit card transactions through the

credit card service provider or interface. 44 111

Allow the students to view an account balance based on a specific term or point in time.

48 115

Allow automation of student payments including EFTs. Allow students to print receipts or track payments

1 131

Allow students and third-parties to make payments online in real time; allow students to send notification of payment if needed; print transaction

history.

3 133

Allow students and third-party entities to review account information and status online based on a specific term or point in time.

10 140

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

11 40

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

that’s due; update billing address

6 136

Create, maintain and publish an annual Master Schedule with view access to other departments.

1 122

Maintain an institutional, transfer, major, minor and overall grade point average for each student.

3 454

Automate graduation checking based on user-defined criteria, in batch or on demand.

9 493

Assign an unlimited number of faculty members to a section, checking for time and room conflicts.

6 523

Automate movement and notification of students when a class is cancelled 14 531 Enter faculty assignments individually at the class schedule level or all at

once for a faculty member. 33 550

Establish faculty workload calculation rules broken out by workload term rules and workload contract rules, and perform the analysis on-line.

35 552

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.

47 565

Interface with an administrative analysis and projection system 6 611 Interface with National Clearing House and provide a repository for

historical submissions. 7 612

Load prospects and test scores from ACT, SAT, GRE, and GMAT, MAT, PRAXIS, TOEFL, et al. from electronic sources.

17 43


- 3 - #1719626 v2 110772-75497

Course Catalog Reports 7 138 Course Offerings Reports 8 139

Generate NSC data for verification of eligibility. 1 368 Calculate degree honors. 6 457

Calculate the academic standing (good standing, probation, dismissal) of a student.

7 458

Provide quick and easy graduation checkout processing. 24 508 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.

26 509

Display and resolve room scheduling conflicts 28 545 Duplicate a section on-line from an existing section. 29 546

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.

40 557

Maintain faculty workload information 45 562 Query for an available faculty member. 51 568

Record faculty department, college, home indicator and percentage of responsibility to the department and college.

53 570

Track and update course information, as needed, by future effective term without impacting current processes, minimizing data input.

70 587

Track instructional workload. 72 589 Interface course descriptions with registration sections and degree audit

results. 76 593

Upload faculty data, name, dept, ran, date of birth with HR 80 597 Perform auto section numbering during initial scheduling. 81 598

Ability to enter free form information regarding course at inventory and term section level.

84 601

Interface with Human Resource system. 12 617 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.

4 626

Capture, calculate and maintain multiple GPA types, 6 628 Store multiple calculated GPAs for each GPA type 13 635

Provide ability to end cumulative academic statistics and start a new within same academic records.

20 641

Provide ability to suppress specific semester’s grades from appearing on transcripts and degree audits while grading is being processed.

22 643

Display exception notifications such as disclaimers and course related information when student registers for a class prior to the confirmation of

enrollment.

24 669


- 4 - #1719626 v2 110772-75497

Display the sections causing time conflict to occur. 26 671 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.

31 676

Identify all sections of a course that are open and do not conflict with a student’s schedule

36 681

Locate on-line all sections of a course with a selected status such as closed, canceled, with specific seats taken, capacities, and seats available.

38 683

Maintain accurate, up-to-the-minute enrollment counts on-line. 39 684 Maintain on-line a history of the verification requests and to whom the

information was sent. 41 686

Manage wait-lists using various user-definable algorithms. 44 689 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)

75 720

Maintain the history of enrollment certification requests 79 724 Access various forms, route for electronic signatures. 11 746

From registration, allow student to select course description, degree audit, and easily toggle back and forth.

12 747

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.

15 750

Provide for next-of-kin and emergency contact name, address, phone number, email

20 779

Provide for unlimited academic action rules 22 781 Provide for unlimited Dean’s List rules 25 784

Record and maintain an unlimited number of student attributes (e.g. data of birth, gender, ethnicity, parent’s name, high school

47 806

Allow students to check the availability of course sections by searching for courses alphabetically, by day and time, by course and

1 824

Allow students to print their unofficial transcripts, schedules and degree audits; provide last activity date to schedules.

2 825

Display on-line detailed information for each student about all transcripts requested, pending or produced.

16 839

Manage recruitment, admissions, and retention metrics. 15 84 Interface with Advisor system 14 619


- 5 - #1719626 v2 110772-75497

Ability to transmit Commonline data records from to loan servicer

Ability to receive Commonline data records from loan servicer

Ability to transmit Commonline data change records to loan servicer

Ability to receive EFT data records from loan services

13

14

15

16

272

273

274

275 Automate grade changes of repeats when course is repeated 17 639 Perform automatic grade changes of repeated courses, set by

administratively defined rules. 1 725

Import and export EDI transcripts 2 607 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

53 698

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.

15 750

Store commencement name pronunciations.

Graduation Reports

35

11

794

142 Support bar-coding and other asset tracking features to assist in inventory

management. 21 32

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.

Generate interest management reports detailing earnings and allocations

by multiple user-specified criteria.

13 7

10

258

398

406 Checks generate must pass bank inspection.

2 172


- 6 - #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 user-configurable 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

13

14

15

16

17

18

180

183

184

185

186

187

188 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

4 3

174 3

Process and approve purchase orders based on user-configurable work flow processes

27 483


- 7 - #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 user-

configurable 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.

Define and maintain controls and business rules to assist with and maintain uniform closing processes across organizations.

Ability to generate the Comprehensive Annual Financial Report (CAFR)

with the State of New Jersey standard reports

3 5 6 7 8 9

10 1

436

438

439

440

441

442

443

444


- 8 - #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.


with the State of New Jersey standing reports.

Reporting must conform to guidelines as required by GASB, FASB, and NACUBO.



2 3 4 5 3 1 2 3

445

446

447

448

436

444

445

446


- 9 - #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.

8 9

10

11

12

13

14

336

337

338

339

340

341

342 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 institution’s 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.

15

16

17

18

19 1

343

344

345

346

347

399


- 10 - #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 user-

configurable 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.

Define and maintain controls and business rules to assist with and maintain uniform closing processes across organizations.


with the State of New Jersey standard reports.

3 5 6 7 8 9

10 1

436

438

439

440

441

442

443

444


- 11 - #1719626 v2 110772-75497

Reporting must conform to guidelines as required by GASB, FASB, and NACUBO.



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.

2 3 4 5

445

446

447

448 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

61

78

81 1

144

161

164

234


- 12 - #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

65

67

74

75

76

147

148

150

157

158

159 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.

61

78

81 1

144

161

164

234


- 13 - #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.

103

36

15 2

362

402

444

18 Provide the capability to format for pay forms and advices. 36 295

Provide the capability to view current and historical pay information (checks and advices).

Maintain multiple years of play history on-line.

39

52

298

311 Create electronic format for direct deposit. 74 333

Produce a benefits statement for each employee. 16 60 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.

57

30 7

147

74

97

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.

11 55

Establish mandatory approval levels based on personnel action. 7 507 Provide position detail in interface with Finance Records system. 36 402 Establish mandatory approval levels based on personnel action.

Provide the capability to establish processing and notification rules for

appointment renewals.

7

30

507

210


- 14 - #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.

12

34

34

102

293

293 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.

15

16

17

423

424

425 Provide the capability to track work study students and any change in

their student statuses for FICA taxability impact. 38 297

Maintain multiple years of pay history on-line. 52 311 Calculate multiple year budgets.

Capture budget history on fringe budgets by position.

Capture budget history on premium earnings budgets by positions.

Capture position budget history on salary budgets by position.

11

12

13

14

377

378

379

380 Provide the capability to interface with the systems of the benefit

providers. 30 74


30 74


30 74


30 74


30 74


30 74

Provide the capability to create rules, templates, and schedules, work hour limits at job title level and with high-level of variability.

2 460


- 15 - #1719626 v2 110772-75497


30 74

Provide the capability to import time entries from 3rd party systems / data collection devices.

10 468


Date post:	29-Nov-2014
Category:	Documents
Upload:	idg-news-service
View:	533 times
Download:	0 times