UNITED STATES TAX COURT
Agency decision
Ask Donna
What actually matters in this document.
Text
110 T.C. No. 34
UNITED STATES TAX COURT
NORWEST CORPORATION AND SUBSIDIARIES, Petitioner v.
COMMISSIONER OF INTERNAL REVENUE, Respondent
Docket Nos. 13908-92, 20567-93,
26213-93.1
Filed June 29, 1998.
Between 1986 and 1991, N, a bank holding company
whose affiliates provide banking and other financial
services, developed or modified previously developed
software for the internal management and administration
of its businesses (internal use software). N seeks tax
credits for increasing research activities pursuant to
sec. 41, I.R.C., with respect to expenditures associated
with the development of its internal use software. The
parties selected 8 of 67 internal use software activities
to serve as representative or sample activities to
determine whether all or part of the 67 activities
constituted qualified research for purposes of the tax
credit.
1
These cases are consolidated for trial, briefing, and
opinion solely with respect to the issue of whether petitioner's
activities constitute qualified research pursuant to sec. 41,
I.R.C. (the research and experimentation credit, or R&E credit).
- 2 Sec. 41(d)(1), I.R.C., sets forth four tests for
qualified research: (1) The expenditures must qualify as
expenses under sec. 174, I.R.C.; (2) the taxpayer must
discover information which is technological in nature;
(3)
the
taxpayer
must
discover
information
the
application of which is intended to be useful in the
development of a new or improved business component; and
(4) substantially all of the research activities must
constitute elements of a process of experimentation.
In the conference report accompanying the Tax Reform
Act of 1986 (TRA 1986), Pub. L. 99-514, 100 Stat. 2085,
H. Conf. Rept. 99-841 (Vol. II), at II-73 through II-74
(1986), 1986-3 C.B. (Vol. 4) 1, 73-74, Congress set forth
three additional tests for qualified research under sec.
41, I.R.C., for the development of internal use software:
(1) The software must be innovative; (2) the software
development must involve significant economic risk; and
(3) the software must not be commercially available.
The
parties
agree
that
in
order
for
the
representative internal use software activities to
constitute qualified research for purposes of the tax
credit, all seven tests must be satisfied.
1.
Held: The three additional tests for qualified
research in the development of internal use software
enunciated in the conference report accompanying the TRA
1986 require a higher threshold of technological
advancement and functional improvement than is necessary
in other fields of research.
2.
Held, further: One of the eight representative
internal use software activities, the development of the
Strategic Banking System's (SBS) customer module,
satisfies all seven tests and constitutes qualified
research pursuant to sec. 41, I.R.C. SBS was a concerted
effort at advancing the state of technology in the field
of computer science and pushed existing technology to new
heights.
3.
Held, further: N failed to establish that the
remaining seven representative internal use software
activities constitute qualified research.
- 3 Mark A. Hager, Albert G. Lauber, Julie W. Davis, Carl S.
Kravitz, James Sottile IV, John R. Kalligher, and Matthew W. Frank,
for petitioner.
Barry J. Laterman, Paul Colleran, Michael Goldbas, Tyrone J.
Montague, and Bruce G. Warner, for respondent.
CONTENTS
Page
FINDINGS OF FACT ............................................
7
1.
2.
Background ............................................. 7
Software Development Methodology ....................... 8
A. Phase 1: Request .................................. 9
B. Phase 2: Project Initiation ....................... 9
C. Phase 3: Definition ............................... 10
D. Phase 4: Logical Design ........................... 10
E. Phase 5: Physical Design .......................... 11
F. Phase 6: Development .............................. 11
G. Phase 7: Testing .................................. 11
H. Phase 8: Implementation ........................... 12
I. Phase 9: Postimplementation ....................... 12
J. Application of the Software Development Methodology. 13
3.
The Eight Sample Internal Use Software Development
Activities ............................................. 14
A. Strategic Banking System ........................... 15
B. Trust TU ........................................... 23
C. Success ............................................ 28
D. General Ledger ..................................... 33
E. Money Transfer ..................................... 36
F. Cyborg Payroll ..................................... 42
G. Trust Payment ...................................... 44
H. Debit Card ......................................... 46
OPINION ..................................................... 50
1.
Section 41 ............................................. 51
2.
Internal Use Software .................................. 56
- 4 3.
The Seven Tests ........................................ 59
A. The Section 174 Test ............................... 60
B. The Discovery Test ................................. 64
C. The Business Component Test ........................ 69
D. The Process of Experimentation Test ................ 70
E. The Innovativeness Test ............................ 74
F. The Significant Economic Risk Test ................. 76
G. The Commercial Availability Test ................... 77
4.
Summary of Internal Use Software Requirements Under the
Seven Tests ............................................ 78
5.
United Stationers, Inc. v. United States ............... 79
6.
The Experts ............................................ 82
A. Petitioner's Expert--Dr. Drew McDermott ............ 83
B. Respondent's Experts ............................... 87
i.
Dr. Randall Davis ............................ 87
ii. The Tower Group .............................. 92
7.
Analysis of the Eight Sample Activities ................ 97
A. Strategic Banking System ........................... 98
B. Trust TU ........................................... 112
C. Success ............................................ 115
D. General Ledger ..................................... 117
E. Money Transfer ..................................... 118
F. Cyborg Payroll ..................................... 119
G. Trust Payment ...................................... 121
H. Debit Card ......................................... 123
Conclusion .................................................. 125
JACOBS, Judge:
determined
the
By separate notices of deficiency, respondent
following
deficiencies
in
petitioner's
Docket No.
Year
Deficiency
13908-92
1983
1984
1985
1986
$2,605,571
2,442,134
29,187
19,301,530
20567-93
1987
1988
93,413
3,999,398
income taxes:
Federal
- 5 -
26213-93
Respondent
also
1989
determined
10,532,064
additional
interest
under
section
6621(c)2 for 1983, 1984, 1986, 1988, and 1989.
Following the filing of petitions contesting respondent's
determinations, petitioner engaged Coopers & Lybrand, LLP (Coopers
& Lybrand), to ascertain whether it was entitled to credits for
increasing research activities pursuant to section 41 (the research
and experimentation credit, or R&E credit) between 1986 and 1993
with
respect
activities.3
use
software
to
certain
internal
use
software
development
Coopers & Lybrand concluded that 67 of 118 internal
development
activities
qualified for the R&E credit.
petitioner
engaged
in
On the basis of the Coopers &
Lybrand study, petitioner sought and was permitted to amend its
petitions to claim the R&E credit for 1986 through 1989.
Subsequently, petitioner again sought and was permitted to
amend its petitions in order to carry back the R&E credit from 1990
2
Unless otherwise indicated, all section references are
to the Internal Revenue Code as in effect for the years in issue,
and all Rule references are to the Tax Court Rules of Practice
and Procedure.
3
Petitioner did not claim the R&E credit on any of its
U.S. Corporation Income Tax Returns for 1986 through 1991. The
engagement of Coopers & Lybrand in August 1994 followed the
Department of the Treasury's issuance of proposed regulations
that further defined research and experimental expenditures under
sec. 174. See sec. 1.174-2, Proposed Income Tax Regs., 58 Fed.
Reg. 15821 (Mar. 24, 1993).
- 6 and 1991 to 1989 and to increase the R&E credit for 1986 through
1991.
For purposes of trial, briefing, and opinion, the parties have
selected 8 of the 67 internal use software development activities
to serve as representative or sample activities to determine the
outcome of the other 59.
The parties agree that $20,552,274 of the
$22,658,829 in expenditures claimed by petitioner as associated
with the eight internal use software development activities have
been substantiated.
In addition, the parties agree that the
remaining 59 activities are deemed substantiated in the same ratio
(90.7 percent) as the 8 sample activities.
The parties further
agree that if we determine that any of the 8 sample activities
qualify for the R&E credit, the remaining 59 activities will be
deemed
qualified
for
the
credit
according
to
an
agreed-upon
formula.
The sole issue we must decide herein is whether Norwest
Corporation & Subsidiaries (petitioner or Norwest) is entitled to
the R&E credit with respect to any or all of the eight sample
internal use software development activities conducted between 1986
and 1991.
Resolution of this issue requires us to interpret and
apply the four statutory requirements for the credit provided in
section 41, and the three additional requirements provided by
Congress in the conference report accompanying the Tax Reform Act
of 1986 (TRA 1986), Pub. L. 99-514, 100 Stat. 2085, specifically
- 7 relating to internal use software development activities. H. Conf.
Rept. 99-841 (Vol. II), at II-73 through II-74 (1986), 1986-3 C.B.
(Vol. 4) 1, 73-74 (and as adopted by the Department of the Treasury
in its proposed regulations, section 1.41-4(e)(5), Proposed Income
Tax Regs., 62 Fed. Reg. 83 (Jan. 2, 1997)).
FINDINGS OF FACT
Some of the facts have been stipulated and are so found.
The
stipulation of facts and the attached exhibits are incorporated
herein by this reference.
Norwest Corporation, a Delaware corporation, is the common
parent of an affiliated group of corporations that timely filed
consolidated U.S. Corporation Income Tax Returns (Forms 1120) for
the years in issue.
It is a bank holding company whose affiliates
provide banking and other financial services.
At the time the petitions were filed, Norwest Corporation had
its principal place of business in Minneapolis, Minnesota.
1.
Background
During the years in issue, petitioner engaged in numerous
projects involving the development of internal use software--that
is, software developed solely for petitioner's internal business
and management purposes.
Most of these projects were managed and
executed by Norwest Technical Services, Inc. (NTS or Norwest
- 8 Technical
Services),4
Corporation,
which
a
wholly
employed
owned
between
subsidiary
600
personnel, such as computer programmers.
and
800
of
Norwest
technical
NTS occasionally sought
the assistance of outside consultants and contractors to provide
technical support for its projects.
All of the eight sample activities at issue in this case
involve software applications.
Software enables a computer to
perform
providing
specific
functions
by
computer in the form of source code.
instructions
to
the
The source code is written
in a programming language, often according to an architectural
design, which commands the computer to perform the specific tasks.
(A compilation of programs or tasks necessary to operate the
software often is referred to as a system.)
The source code is
then converted, through the use of a compiler, into executable code
that is readable by the computer.
2.
Software Development Methodology
To maintain discipline, structure, and standardization in the
software development process, Norwest Technical Services created a
formalized approach known as the Software Development Methodology
(sometimes referred to as SDM).
SDM was developed to prevent the
need
by
to
"reinvent
the
wheel"
providing
managers
with
a
documented process in developing software. The result was that SDM
4
Norwest Technical Services, Inc., was formerly known as
Norwest Information Services, Inc.
- 9 improved controls and managed risks. SDM was applied in developing
new
software
by
Norwest
purchased from vendors.
personnel
and
in
modifying
software
The SDM procedures were applied to each
project activity, with the exception of small maintenance projects
that were grouped together for purposes of SDM.
SDM involved the following nine phases, which permitted an
incremental approach to funding and development:
A.
Phase 1:
In
the
modification
Request
request
of
phase,
the
those
software
seeking
evaluate
the
development
the
cost/benefits, and risks associated with the project.
phase,
the
business
problem
to
be
solved
is
or
feasibility,
During this
described,
and
potential business and technical solutions are discussed.
B.
Phase 2:
In
the
Project Initiation
project
initiation
phase,
expectations
regarding
project scope, deliverables, approach, costs, and schedules are
agreed upon, documented, and approved.
Determinations are made
with respect to the skills required to complete the project, and a
project team is assembled.
Additionally, resource commitments are
made for future phases.
During
this
phase,
a
Project
Risk
Assessment
Form
is
completed. This form "is used to evaluate the risk associated with
completing a project [and] * * * is intended to help the Project
Manager determine the kinds of structure and controls that are
- 10 necessary to ensure project success."
the project's technical risk.
The form does not measure
Rather, the form is focused on
process risk; that is, whether the experience and skills of the
project team will allow completion of the project within the
project's parameters, as they have been determined, including time
and cost.
C.
Phase 3:
Definition
In the definition phase, the business requirements and needs
are analyzed and prioritized.
Additionally, the project's impact
on business and technical functions is reviewed.
D.
Phase 4:
Logical Design
In the logical design phase, the design (how it will be done)
of
the
business
solution
is
completed
on
the
basis
of
the
requirements (what needs to be done) set forth in the definition
phase. The logical design phase performs a so-called external view
of the project (that is, examining the project from a business
person's perspective to determine whether the needs of the business
can be met) before the development of the technical solution,
because the design of the business solution will often constrain
the technical solution. Also in this phase, consideration is given
to whether the necessary software can be purchased.
investment
decision
is
made,
and
the
Finally, an
cost/benefit
(previously performed in the request phase) is verified.
analysis
- 11 E.
Phase 5:
Physical Design
In the physical design phase, which is sometimes referred to
as the technical design phase, the technical solution to the
business
problem
described
in
the
logical
design
phase
is
determined. The technical approach to building the system requires
consideration of the interfaces; that is, how the software operates
in conjunction with other applications or systems.
During this
phase, the tools for building the system are described, as well as
the nature
of
the
interfaces
between
the
software
and
other
systems, the estimates of volume that requires processing, and the
timeframe for processing.
F.
Phase 6:
Development
In the development phase, physical system components are
constructed, documented, and verified.
During this phase, the
programmers write the source code that will allow the computer to
perform the required tasks, and initial plans are made for testing
the software.
G.
Phase 7:
Testing
In the testing phase, the technical development portion of the
project is completed.
During this phase: (i) Unit testing is
performed to determine whether the individual components of a
system
are
technically
ready
for
production,
(ii)
integrated
systems testing is performed to determine whether all components of
- 12 a system can operate together, and (iii) acceptance testing is
performed to determine whether the business user's requirements
have been satisfied.
Further, during this phase, the programmers
correct errors in the coding process (known as debugging) as well
as in the design process.
Typically,
the
testing
known
performed on prerecorded data.
as
regression
testing
is
The use of prerecorded data is
important because the testers have known solutions and outcomes
against
which
the
software
can
be
tested,
and
new
methods,
capabilities, and functions can be tested without risk to real
(production) data.
H.
Phase 8:
Implementation
In the implementation phase, the software is placed into
production
process.
(also
known
as
going
live),
usually
in
a
gradual
During this phase, the software application is used on
actual data by the end users (those who will be using the software
product).
It is also during this phase that the end users are
trained in the use of the software.
I.
Phase 9:
Postimplementation
In the postimplementation phase, the software is maintained
through continuous debugging, updating, and enhancing to meet new
business needs.
- 13 J.
Application of the Software Development Methodology
The development of software applications does not end with any
particular phase of the Software Development Methodology.
The
process is often iterative in that unanticipated problems are
discovered in one phase that require the developers to return to a
prior phase. For example, during the testing phase, the developers
may learn that the software is not sufficiently scalable; that is,
that it cannot handle variances in the volume of data to be
processed.
In such a case, the project may be returned to the
physical design or development phase to reconsider the technical
approach or the source code used and, after modifications, resume
the testing phase.
This iterative process continues until either
the software is operational to the satisfaction of those involved
or the project is abandoned because of either technical or business
constraints.
Throughout the SDM process, some form of technical risk (the
risk that the project will not succeed for technical reasons) is
present, even after the software is placed into production.
(The
risk of failure exists throughout a project because problems that
arise because of volume or scale cannot be resolved until the
- 14 implementation
phase.5)
Norwest
did
not
maintain
any
formal,
documented method of reporting this technical risk.
3.
The Eight Sample Internal Use Software Development Activities
During the mid-1980's, Norwest made a concerted effort to
expand its banking and financial services business.
Between 1986
and 1991, Norwest's assets grew from approximately $20 billion to
more than $38 billion (and by 1995, Norwest's assets further grew
to over $75 billion).
Given the anticipated growth of Norwest's
business that was forecast in 1986,6 Norwest Technical Services was
assigned the task of determining the necessary data processing
support structure and technology to handle this expansion.
The eight sample activities, and the substantiated expenses
incurred by Norwest with respect to each activity for the years in
issue, are as follows:
5
The testing of software for volume or scalability
cannot be completed before the implementation phase because of
the cost required to replicate a full production environment.
6
In 1986, petitioner expected that most States would
liberalize their branch banking restrictions and permit more
interstate banking services.
- 15 -
1986
1987
1988
1989
1990
1991
Total1
$451,386
$1,367,679
$2,441,576
$2,696,099
$2,260,394
$3,073,334
$12,290,468
Trust TU
373,469
623,538
551,729
742,462
649,270
650,161
3,590,629
Success
---
---
129,320
138,196
410,030
303,452
980,998
General
Ledger
173,596
136,735
94,744
384,237
175,020
183,468
1,147,800
Money
Transfer
85,179
173,925
193,493
224,109
125,610
180,462
982,778
Cyborg
Payroll
73,881
90,923
100,683
74,991
82,056
130,714
553,248
Trust
Payment
93,265
171,334
182,047
101,704
---
---
548,350
Debit Card
---
---
22,687
435,318
---
---
458,005
Activity
Strategic
Banking
System
2
1
The total expenses for the eight activities equals $20,552,276. The $2 discrepancy for the
total amount the parties agreed in their stipulation was substantiated is unexplained.
2
The expenses incurred on the Strategic Banking System project for 1986 were contract expenses
paid to Electronic Data Systems Corp.
A.
Strategic Banking System
Strategic Banking System (SBS) was a large7 joint effort by
three entities to develop an integrated banking system in which a
number of software applications would operate together. Electronic
Data Systems Corp. (EDS) of Dallas, Texas, and Bank One, Columbus,
N.A.8 (Bank One), of Columbus, Ohio, began the SBS project on
August 18, 1986.
The purpose of the SBS project was to develop a
software system in which all information regarding the bank's
financial products centered around the customer (the customer
7
By 1993, the three entities involved in developing SBS
had incurred approximately $125 million in expenses and written
10 million lines of code.
8
Corp.
Bank One, Columbus, N.A., is an affiliate of Banc One
- 16 module) rather than a particular account.
Before the development
of SBS, information relating to individual bank accounts or other
financial products was not linked but rather was maintained in
separate systems.
Thus, when information about one account was
retrieved on a computer, the user would have no way of obtaining
information
about
other
accounts
customer or a related customer.
owned
or
maintained
by
the
The SBS project sought to change
that situation by integrating all account software systems around
the customer.
information
Security
The customer module, which would contain basic
about
number,
the
and
customer
(e.g.,
demographics),
name,
would
be
address,
Social
integrated
with
deposit and loan (or credit) modules so that information relating
to customer deposit and loan accounts could be readily accessed and
retrieved.
Because of concerns that SBS was becoming specific solely to
Bank One's needs, in late 1986 Norwest was asked and agreed to join
in
the
development
perspective.
of
SBS
to
provide
more
of
an
industry
In exchange for sharing in the development costs of
SBS, Norwest received a perpetual license to use the system.9
9
Norwest paid a base development charge of approximately
$6.5 million to Bank One (although the Participant Agreement
between Norwest and Bank One required a $7 million payment) in
exchange for a percentage of the royalties to be paid to Bank One
by Electronic Data Systems Corp. (EDS). Further, Norwest paid
$1,750,000 to EDS in exchange for a perpetual license to use SBS.
(continued...)
- 17 Before joining the SBS development project, Norwest considered
other alternatives.
In this regard, Norwest examined commercially
available
in
software
the
market,
considering
the
products'
functionality, economic benefit, scalability, and applicability to
interstate banking activities.
In particular, Norwest focused on
a software product offered by Hogan Systems, Inc. (Hogan). Norwest
ultimately rejected the Hogan product because it did not meet
Norwest's volume and economic benefit criteria.
Norwest also considered building its own system. It abandoned
this idea, however, believing that the opportunity to enter into a
development project with EDS and Bank One would enable it to
achieve its goal and limit its risk.
Accordingly, on December 16,
1986, Norwest entered into a Participant Agreement10 with Bank One,
and a separate Participant License Agreement with EDS.
Section 3.2 of the Participant Agreement between Bank One and
Norwest provided for Norwest's role in the development of SBS:
In connection with the development of the Financial
System by EDS as contemplated under the [EDS-Bank One]
Participation Agreement, Norwest will, on a timely basis
9
(...continued)
As part of a separate license agreement, Norwest paid EDS $1.2
million to use the software in connection with services provided
to nonaffiliated financial institutions.
Under the participant and license agreements, EDS maintained
all ownership rights to the SBS system.
10
The Participant Agreement was amended on Sept. 8, 1988,
Feb. 8, 1992, and again in July 1992.
- 18 as requested by * * * [Bank One] so long as this
Agreement shall be in effect:
(a) Perform its tasks in connection with the
Development Plan including providing banking
expertise required from time to time by * * *
[Bank One] and provide management decisions
and support as reasonably required by * * *
[Bank One] to develop the Development Plan.
(b) Develop
with
the
cooperation
and
assistance of * * * [Bank One], test data and
test conditions which * * * [Bank One] will
use in connection with its obligations with
EDS in order to perform system testing
designed to establish that each component of
the Financial System functions in accordance
with the applicable Functional Specifications.
(c) Cooperate with * * * [Bank One], and, if
requested, with EDS, by, among other things,
making available as reasonably requested by *
* * [Bank One], office space and services at
Norwest's premises, personnel, information,
approvals, and acceptances in order that the
work required of EDS or of * * * [Bank One]
may be accomplished in accordance with the
Development Plan.
EDS' primary tasks in the development of SBS were to define
the technical environment for SBS, to provide the necessary tools
for its development and production, and to ultimately construct the
system (including the writing of the source code).
Bank One's and
Norwest's primary tasks were to provide the business requirements
for the software (the logical design phase, which was the greatest
expense
for
the
participant
banks
in
the
SBS
project).
In
addition, Bank One and Norwest provided the technical expertise as
to how such systems should operate in a banking environment.
- 19 Ultimately, though, only EDS actually developed the technology and
the source code.
Bank One and Norwest employees worked with EDS employees to
determine
the
appropriate
products for SBS.
technical
environment,
tools,
and
(At any given time, approximately 100 people
from each entity worked on the SBS project.)
Employees of the
three entities met approximately every 6 weeks to review and
critique the work done to date and to recommend changes to the
technical
design.11
As
part
of
this
process,
NTS
personnel
conducted research and proposed solutions to design problems.
As part of the logical design phase, EDS technical personnel
met with Bank One and Norwest employees to learn about the banking
11
For example, Bank One and Norwest employees raised
concerns about whether DB2, a relational database system EDS
proposed using for SBS, could handle the volume of data the
parties projected would be run on the system. Ultimately, Bank
One and Norwest employees conceded that DB2 was appropriate when
EDS demonstrated its success in other high-volume environments.
Another concern raised by Bank One and Norwest employees
related to the use of so-called dummy terminals. EDS proposed
maintaining all data in a mainframe computer (which would perform
all data processing and run all applications) and placing
nonintelligent dummy computers at user stations (e.g., bank
teller windows and desks). The dummy computers could access the
mainframe's data and software applications through a special menu
screen but could not perform any processing functions on their
own. Bank One objected to this proposal primarily because it was
already using personal computers (PC's), which enabled its users
to access data from a host computer, to input new information
through software applications processed locally on the PC's, and
to ship the new data back to the host computer for updating.
(This is known as a client-server architecture.)
- 20 business requirements and needs for the system (a process known as
data modeling).
The bank employees (e.g., bank tellers) would
explain to the EDS personnel the types of functionality (i.e.,
information) that they needed to access in using the SBS system.
Additionally, business analysts at Norwest examined the various
functionality requirements of the bank employees and drafted design
documents indicating the recommended design approaches or changes.
After EDS completed the initial design and development phases,
Norwest was used as the test bed for SBS.
A large database of
sample test data was created, and as early design releases arrived
from EDS, Norwest ran SBS in its computer environment to test the
software.
These
tests
were
conducted
on
multiple
days
of
transactions to observe the performance of the system over a
specific time span.
After a test run, the results were analyzed,
EDS employees were debriefed, and suggested changes to the design
were made.
These testing and redesigning phases continued for
approximately 3 years in the case of the customer module and for
approximately 4-1/2 years in the case of the deposit module.
Norwest discovered hundreds of problems in the modules it
received from EDS.
One problem that arose in the development of
the customer module was its interface link to the deposit and loan
application systems already in place at Norwest during that time,
which was necessary until the new SBS deposit and credit modules
- 21 were developed.
Another problem that arose was the development of
a so-called pointer system which allowed the end user to access
information about a customer through one of various identification
sources (e.g., name, account number, Social Security number, etc.).
The pointer system was one of the more critical functions of the
SBS software.
Many of the problems were reviewed and corrected during the
testing phase by Norwest technical staff, who would inform EDS
personnel of the problems and recommend corrective changes to the
software.
(A small group of programming experts was assembled
specifically to handle the SBS problems through the use of a
specialized case tool called PACBASE, which was selected by EDS.)
Norwest employed a repeatable testing process to isolate problems
and find solutions.12
A running list of these technical problems
was maintained in a system provided by EDS.
Not all problems were
resolved in this process, and often new problems arose from the
correction of old ones.
Some of the problems that arose in the
development of SBS were attributable to poor programming and the
12
This was a particularly difficult process because three
different entities were working on the development of SBS.
Norwest had to reconcile all of the changes and discover the
source of the problems. This process required the isolation of
each change made by each entity for testing purposes. Often the
attempts to correct one set of problems created new ones.
- 22 delivery of faulty code by EDS; others were attributable to poor
technical design.
Ultimately,
the
customer
module
of
SBS
was
successfully
developed (although it contained many bugs). During 1989 and 1990,
it was placed into production (the implementation phase) by Norwest
in its banks and used for a number of years.13
The deposit module
was a technical failure. The failure was attributed to the deposit
module's inability to produce the results sought by the users in
13
A test pilot program for the customer module began in
Norwest's Duluth, Minnesota, bank in November 1989 and continued
through early 1990. After the pilot proved successful, it was
implemented throughout 1990 in Norwest's other banks around the
country in what was known as release 1.2. During 1991, EDS
issued a new upgraded release of SBS which required Norwest to
"retrofit" the core functionality and design changes with the
customization performed by Norwest in the interim period since
the prior release. The upgraded release required a new round of
testing and modifications by Norwest technical staff in
conjunction with EDS. Many of these changes related to technical
problems (such as the source code for the pointer system), and
others related to nontechnical cosmetic problems (such as
changing the name of a database field or the way a screen looks
to the end user, or modifying reports produced by the software).
A statement of work dated Oct. 10, 1992, reported:
The migration of the Customer system from EDS
Release 1.2 to Release 1.3.2 was completed
for all Norwest banks using Customer in June
of 1992. Installing Release 1.3.2 involved a
massive effort of customization, testing and
converting the existing data bases to the new
release. Since the banks have been using
Customer 1.3.2, problems have been
identified.
- 23 terms of stability and reliability, as well as its inability to
timely process or handle the volume of data required.
Because of the failure to adequately develop the deposit
module, which was supposed to work in conjunction with the customer
module, Norwest abandoned SBS in 1993 and turned to an alternative
system created by Hogan.
Following a 5-year joint venture with
IBM, Hogan developed a customer module system which performed
approximately 90 percent of the functions needed by Norwest and met
Norwest's critical volume requirement.
After the period in issue, both the customer and deposit
modules were eventually successfully implemented at Bank One.
The
record does not indicate the ultimate success or failure of the
credit module and its implementation at Norwest or Bank One.
B.
Trust TU
The
Trust
TU
system
consisted
of
a
group
of
software
applications designed to maintain trust accounts, including the
tracking of assets, purchase and sale of securities, and collection
and disbursement of income.
The software for this system was
purchased from a vendor in 1979 and installed in 1981.
made numerous changes to the system in subsequent years.
Norwest
- 24 Between
1986
and
1991,
Norwest
instituted
hundreds
of
projects14 to improve the Trust TU system's functionality (including
compliance and regulatory changes) and to reduce processing costs.
These projects involved all stages of the Software Development
Methodology.
Between two and five senior programmers were assigned to
accomplish the goal of reducing the monthly cost per trust account
that was being maintained.
Before 1987, the average monthly cost
per account was approximately $9.
By 1990, the monthly cost per
account was reduced to approximately $4 or $5.
The programmers were also assigned the goal of increasing the
volume of trust accounts maintained in the Trust TU system.
In
1986, there were approximately 25,000 trust accounts running on the
system, and the number of trust accounts was increasing by 10 to 12
percent per year.
It was assumed that the existing system could
not handle more than 30,000 trust accounts.
To accomplish both goals (reduction in cost and increased
volume), NTS had to increase the speed of the so-called batch
process15 that occurred each night.
(During the day, the Trust TU
14
Some of the smaller projects included building reports,
updating software to reflect regulatory changes, converting
acquired bank trusts customers, and changing screens.
15
The batch process consists of editing information,
posting information, extracting information, and producing
(continued...)
- 25 system was on-line and transactions were stored.
Beginning at 6
p.m., the on-line system was shut down, and the trust accounts were
updated on the basis of the transactions that had occurred during
the day.)
There was a maximum 12-hour window to accomplish the
batch process.
Before the start of the project to increase the speed of the
batch process, approximately 10 of the 12 hours of available time
for batch processing were being used.
To reduce this time and to
more efficiently use the mainframe computer's disk space (where the
trust account data was stored), NTS needed to determine how to
increase
the
number
of
processing
concurrently rather than serially.
jobs
that
could
be
run
To accomplish this goal, NTS
developed a module of as many as 20 processes to determine which
batch processing jobs had to be run concurrently and which had to
be run serially. This required a determination of those processing
jobs that were independent and those that were interdependent.
In
this respect, the jobs had to be organized in a manner so that no
two jobs were updating the same account at the same time.
After the module was designed and built, unit testing was
performed on a subset of accounts on the mainframe computer.
The
test outcomes produced varied results. Some of the concurrent jobs
15
(...continued)
transactions for the following day.
- 26 ran more slowly than they did as serial jobs, and others ran
faster. To determine why some concurrent jobs ran more slowly, the
programs that constituted the module had to be reexamined and
reorganized using a different approach to the module's design.
At
times, different modules were considered and used to increase
efficiency.
Hundreds of test batch processes were performed over
a 3-year period to accomplish NTS' goals.
Eventually, NTS was able
to reduce the total batch processing time to approximately 6 hours.
The Trust TU system was abandoned when the number of trust
accounts reached 40,000.
In 1993, NTS switched to another system
(known as Compass) which used newer technology.
One of the numerous projects relating to the Trust TU system
during the years in issue involved the development of an interface
between Norwest's trust system and a vendor-supplied fiduciary tax
reporting system called Fasttax.
The interface was necessary to
transfer trust account information to the tax system in order to
calculate the appropriate tax and thereafter send that information
back to the trust system in order that checks could be issued and
remitted to the various taxing authorities.
The primary concerns
involved in
the
this
interface
project
were
accuracy
of
the
information coming from Fasttax to the trust system and the ability
to process that information in a timely manner for filing tax
- 27 returns.
The
development
of
this
project
followed
the
SDM,
including extensive testing on a separate test bed.
Yet another project, the Micro IS system, which was vendor
supplied,
was
designed
investment securities.
to
automate
purchases
and
sales
of
This portfolio management system permitted
a "what-if" analysis whereby the user could examine the impact of
hypothetical purchases and sales.
When Micro IS was purchased, it
was written in Lotus (a spreadsheet program). The processing time,
as much as 5 minutes, was unacceptable to NTS.
Consequently, NTS
suggested to the vendor that the application be written in a
"higher" language, such as C, to increase the efficiency of the
system.
The
vendor
accepted
application for Norwest.
the
suggestion
and
rewrote
the
The result, after an iterative testing
process by Norwest taking approximately 6 to 9 months, was the
reduction in response time to less than 5 seconds.
The Micro IS system required two other notable changes.
One
was to increase the speed by which data could be extracted from the
mainframe computer (which updated the data the night before) and
sent to the Micro IS system.
The trust portfolio data had to be
extracted and loaded on to the Micro IS system from the mainframe
each morning by 7 a.m., at which time portfolio managers arrived at
work.
As a result of this time constraint, the vendor had to
rewrite
a
portion
of
the
system
in
the
C
language.
Norwest
- 28 conducted iterative testing on its accounts following the vendor's
rewriting of the software.
The second notable change was to increase the speed by which
the purchases and sales of securities by portfolio managers could
be sent from the Micro IS system to the Trust TU system.
This
change required the writing of polling software that essentially
checked the Micro IS system every 8 to 10 seconds in order to
determine the occurrence of any trades that needed to be sent to
the Trust TU system.
The increased speed was achieved by writing
the program in a language called Clipper, after the rejection of
two other languages.
Each of these changes resulted in increased efficiency in the
use of the Micro IS system both in terms of cost per account and
speed of nightly batch processing.
C.
Success
The Success system was designed in-house by Norwest to improve
the speed and efficiency of the data processing for Norwest's
equipment leasing business.
It supported all aspects of leasing
activity, including origination of contracts, tracking assets,
invoicing
customers,
tracking
collection,
management, and off-line reporting.
accounting,
cash
Success was developed between
1988 and 1991 by a group of 15 to 20 people within the Norwest
Financial Information Services Group (NFISG), the data processing
- 29 department for Norwest Financial, Inc. (Norwest Financial), a
Norwest Corporation subsidiary.
Norwest Financial is in the
consumer finance business and provides various types of lending
products, sales finance, and revolving charge products, as well as
data processing services to other unaffiliated consumer finance
companies in the industry.
Before the development of Success, Norwest Financial Leasing
(the
subsidiary
of
Norwest
Financial
for
which
Success
was
developed) used a system known as Infolease for its equipment
leasing business which was not meeting its needs.
The Infolease
system was causing delays for the users with respect to month-end
data processing which in turn required the system to be off-line
for approximately 3 days. During the time the system was off-line,
users had to maintain records manually, and the data could be
entered only after the system was on-line and running again.
If
problems arose in the month-end processing, the system could be
down for 7 to 10 days.
NFISG
lacked
the
expertise
to
Infolease
system.
As
a
NFISG
result,
maintain
was
or
enhance
unable
the
to
make
use
the
improvements to that system.
The
development
of
Success
required
NFISG
networking of various operating system platforms.
to
In Norwest's
leasing offices, where the end users were situated, minicomputers
- 30 were in place.
Data would be input into the minicomputers, which
would then send the information to a mainframe computer, known as
a Tandem system.
(The Tandem system was a highly reliable and
scalable data processor which stored static data; that is, data
which would not change on a regular basis.)
The Tandem system
would then send a message back to the minicomputers indicating the
receipt and update of the new data.
required
number
crunching,
the
If the entered information
Tandem
system
would
send
the
information to the transaction processing facility (TPF) known as
SWIFT.16
These three systems--the minicomputers, Tandem, and the
TPF--were
all
on-line
systems,
which
meant
that
they
were
continuously updated and processed in real time, so that the
results could be verified immediately.
After a transaction or data input was completed, a real-time
activity (RTA) record would be created which provided a snapshot of
what had occurred.
The RTA records would then be written onto a
tape which was used to create off-line reporting or month-end batch
processing on an IBM MVS system.
During the first 6 to 9 months in the development of the
Success system, NFISG personnel met with the intended end users of
the
system
16
to
determine
their
needs.
These
meetings,
which
Examples of the processing performed by SWIFT included
billing, aging of accounts, earnings calculations, and
depreciation.
- 31 continued throughout the design, coding, and testing phases, were
designed to ensure a minimum level of functionality in the new
system, as well as appropriate improvements from Infolease.
As
part of this development process, NFISG needed to learn many
aspects of Norwest Financial Leasing's business. Additionally, in
the early development phases, NFISG studied the Infolease system to
determine what data records needed to be maintained.
The primary17 technical concern at this point was the TPF
system.
The
existing
system
was
designed
to
handle
"short
records"--referring to the size of the transactions--between the
mainframe computer and the minicomputers. To obtain the efficiency
needed,
NFISG
sought
to
create
a
system
transactions with longer and varying sizes.
that
could
handle
As a result, NFISG
examined the development of a message system that could pass
information
efficiently.18
Further,
accessibility
of
through
the
data
NFISG
considered
direct-access
minimize disk space and increase response time.
indexing
the
to
Additionally,
17
Other issues included human interfacing--the user's
ability to navigate through the system according to the screens
set up on the system. Additionally, NFISG addressed off-line
reporting capabilities of the system.
18
To increase efficiency in the TPF system, NFISG
programmed the system using an "assembler-based" language, which
is a lower level (i.e., each assembler instruction can be
directly interpreted to machine language) and less descriptive
language than most other programming languages.
- 32 there was concern over "error recovery" to maintain data integrity
--the
need
to
return
the
system
to
its
state
prior
transaction in the event the transaction process failed.
to
the
In order
to address the problem of error recovery, the technical support
staff developed a design through macros (code that is frequently
used throughout the system and which, through standardization,
ensures data integrity and reliability).
All of these technical
concerns were addressed and ultimately led to an initial design and
conceptualization of the TPF system for Success.
Following the development of a basic design of the TPF system,
the project was divided into smaller projects and assigned to
different analysts.
Code development then began, including the
development of macros.
(Following the coding process, the divided
projects were reintegrated for the testing phase.)
Additionally,
some redesigning occurred upon the discovery of concepts which did
not operate as anticipated.
Throughout this development phase,
unit testing occurred on two separate test beds (one for the TPF
system and the other for the IBM MVS reporting system) followed by
systems
testing
(e.g.,
the
TPF
acceptance testing for the users.
with
the
Tandem
system)
and
This coding and testing phase
lasted 1-1/2 to 2 years.
Success was implemented and placed into production following
the coding and testing phases, although there was some delay.
As
- 33 part of the implementation phase, NFISG was required to convert the
data from the Infolease system to the Success system.
This
required parallel operations of both systems to ensure that the
data had been properly converted and that all aspects of the new
system were working in accordance with the users' needs.
After
production began, NFISG sought to improve the response time of the
minicomputers in retrieving information.
Ultimately, the Success system improved speed and efficiency
in the month-end processing, reducing the processing time from 3 or
more days to overnight.
The Success system was leased out to other leasing companies
affiliated with Norwest Corporation.
D.
General Ledger
The General Ledger (G/L) system was an integrated collection
of software applications designed to support and maintain Norwest's
general ledger accounts and to produce balance sheets, income
statements, and other similar reports for Norwest.
Approximately
five NTS persons were assigned to work on the G/L system.
During the years in issue, the corporate controllers who used
the G/L system annually met with NTS personnel to discuss their
business goals. The primary purpose of these meetings was to
discuss ways to improve the source code in order to expedite the
month-end closing of the corporate books.
- 34 The G/L system was based on a widely used vendor-supplied
package known as Financial Control System (FCS).
After purchasing
the FCS G/L system, Norwest customized approximately 25 percent of
the vendor code.
Throughout the relevant time period, NTS needed to upgrade the
system and install new vendor releases.
This posed problems
because of the customization work already conducted by NTS on the
vendor code. The upgrading required NTS to study how to "retrofit"
the new vendor code with both the old code and the customized code
without sacrificing the functionality and efficiency needed.
The
retrofitting process involved the use of Norwest's SDM and included
reiterative unit, integrated, and acceptance testing.
The testing
usually sought to isolate problems in the code that required
debugging or rebuilding.
During the retrofitting process, NTS found that the vendor
code was inefficient with respect to the corporate consolidation
component
various
(consolidating
corporate
and
divisions)
eliminating
of
the
transactions
software.
required a redesigning of the software by NTS.
This
of
the
problem
To accomplish this
redesign, NTS examined various structures (containers for holding
the data) and tools for providing similar functionality as provided
in the vendor code but with greater efficiency.
- 35 Another corporate consolidation project involved automating
the
corporate
consolidation
process.
Before
NTS'
work,
the
corporate consolidation process was manual, requiring corporate
personnel
to
examine
cost
center
reports
and
determine
the
appropriate location of transactions to appropriate accounts.
The
automating of the corporate consolidation process through SDM
involved four or five technicians conducting extensive testing over
a 2-year period.
Another project with respect to the G/L involved the on-line
component of the system.
Every evening, the mainframe computer
went off-line and updated the G/L system with transactions that had
occurred during the day.
However, often during the day the
corporate controller's office or other Norwest personnel needed
access to the G/L system to obtain on-line updates for ad hoc
reporting.
This presented a problem because the updating occurred
at night--whereas users often needed real-time updates during the
day.
To accommodate the users' needs, NTS developed a "shadow
file" system, which was a secondary set of files, copied from the
primary files, that could be used for off-line reporting.
As a
result of the shadow file system, the users had access to shadow
files with real-time updates.
The shadow file system presented technical issues for NTS.
The shadow file system worked on a DB2 database system which, at
- 36 the time, was new to both the vendor (IBM) and to Norwest.
The
Norwest users found DB2 to have a slow response time; consequently,
as users queried the database files for access to data, the queries
became backed up--each query waiting for the query ahead of it to
be
completed.
Although
the
resolution
of
this
problem
was
important, it involved no more than basic troubleshooting by IBM
and NTS personnel.
Another problem, which was similar to the one resolved by the
shadow file
system,
involved
processed each evening.
wanted
reports
the
great
number
of
batch
jobs
Because of the large number of users who
processed
following
the
evening
updating,
the
mainframe often became locked out (known as getting IO bound) so
that jobs requiring access to the same data at the same time could
not be completed.
As a result, NTS both developed a system that
provided multiple data files for the jobs to run against and
created a mainframe scheduling system that allowed an organized
processing of the batch jobs.
There were several other, albeit smaller, projects that were
addressed by NTS personnel during the years in issue, ranging from
report writer customization to new releases to interface tasks.
E.
Money Transfer
The money transfer, or wire transfer, system was a software
package that enabled Norwest to move funds electronically in real
- 37 time from its accounts, through the Federal Reserve System (the
Federal Reserve), to the destination financial institutions.19 (The
software
Norwest.)
also
permitted
transfers
from
other
institutions
to
During the years in issue, NTS was engaged in many
projects20 designed to address Federal Reserve regulatory changes
and Norwest's business needs. (Norwest was experiencing a large
growth in the wire transfer business--20 percent or more per
year.21)
19
To effectuate a wire transfer of funds, Norwest set up
a contra account (also known as a due-to/due-from account) with
the Federal Reserve. When a Norwest customer wanted to make a
transfer, Norwest would debit the customer's account and credit
its own account at the Federal Reserve. The Federal Reserve
would then debit Norwest's account and credit the destination
institution's account. This procedure was used for all domestic
wire transfers; international wire transfers did not go through
the Federal Reserve.
Initially, the wire transfer system used by Norwest did not
provide for international wire transferring of funds.
International transfers occurred through other, antiquated,
systems which were manual and paper based. Norwest converted the
international wire transferring to the MoneyNet system, which
provided on-line, real-time transfers and validation. This was a
large project that took several months of work.
20
Some of the smaller projects included additions and
changes to the screen and reporting functions of the system.
21
Norwest was processing approximately $5 to $7 billion
in wire transfers per day. The expansion of this business raised
critical security issues that had to be addressed any time new
technology was instituted. (In fact, Norwest was the victim, on
at least one occasion, of a fraudulent wire transfer ring that
infiltrated the system.) Thus, any software development was
constrained by security concerns.
- 38 The
money
transfer
system
was
based
on
vendor-supplied
software, known as MoneyNet, purchased by Norwest during the early
1980's.
Although the MoneyNet system did not provide all of the
functionality Norwest needed, following an assessment of all other
software on the market, NTS determined that MoneyNet was the most
viable for its long-term needs.
In anticipation that changes to
MoneyNet would be necessary, Norwest acquired the system's source
code from the vendor.
The first major regulatory change to affect Norwest was the
Federal Reserve's so-called 5 p.m. rule.
In general, this rule
stated that all wire transfers were to be completed by 5 p.m. each
business day.
For years prior to 1986, the Federal Reserve did not
enforce the rule, staying open as late as necessary to accommodate
businesses whose systems failed or which otherwise could not
complete their transfers before 5 p.m.
But by the late 1980's, the
Federal Reserve began strictly to enforce its rule, which required
institutions
such
as
Norwest
to
develop
systems
that
were
sufficiently reliable to ensure the timely transfer of the funds.
The failure to complete transfers by 5 p.m. could result in severe
consequences to Norwest: (1) It would be liable for interest
payouts on the funds it was unable to transfer (an estimated $1
million per day); and (2) it would be potentially liable for any
- 39 business deals of its customers that were not completed because it
was unable to transfer funds.
In response to the Federal Reserve's enforcement of the 5 p.m.
rule, NTS examined the timeliness of the MoneyNet system in terms
of logging and processing the wire transfers. To protect itself in
the event the system crashed, NTS developed a contingency site22
(also known as a disaster site or hot site) in which all logs of
wire transfers were copied or mirrored from the production site to
a second site in real time.
Thus, if the production system failed,
the users could simply move over to the contingency site and
complete the transfers on that system.
At the same time, NTS
needed to quickly recover the production system from the point at
which it crashed so that the users could continue logging transfers
for its customers.
The second major Federal Reserve regulatory change affecting
Norwest was the so-called daylight overdraft rule.
Often, because
of the large number of transfers to and from wire institutions,
many of which were not settled until the end of each business day,
some institutions maintained negative balances in their Federal
Reserve accounts during some part of the day, which placed a risk
22
The wire transfer system's lack of a contingency site
resulted in Norwest's being cited by the Office of the
Comptroller of the Currency and Norwest's internal auditors
because of the potential for large losses.
- 40 on the Federal Reserve if the wire transfers were not settled.
In
general, the daylight overdraft rule stated that the Federal
Reserve would not permit wire transfer institutions to maintain
balances in their Federal Reserve accounts below a specified
minimum
level.
The
same
prohibition
applied
to
the
bank's
customers with respect to their bank accounts from which the wire
transfers were coming and going.
In response to this rule, Norwest developed (over a 9-month
period) two programs (one each for the Federal Reserve accounts and
for customer accounts) that monitored the wire transfers and
essentially froze all transfers from an account once the minimum
credit level was reached.
Another project, referred to as the distributed wire project,
involved Norwest's attempt to consolidate all wire transfers among
its branch locations to one bank location in Minneapolis.
Norwest
was concerned with the manual, paper-based systems used in its
branch banks, particularly in the Des Moines and Omaha branches,
which had a history of crashing (which meant the systems were down
until repaired) because of too much volume.
NTS sought to run all wire transfers on the MoneyNet system.
The bank branches were provided with a fault-tolerant system which
provided protection against system crashes similar to that used in
the 5 p.m. rule project's contingency site system.
One technical
- 41 problem
with
the
MoneyNet
system
addressed
by
NTS
was
the
software's inability to take into consideration the multibanking
environment of Norwest. In this regard, the software did not fully
recognize all of the accounting relationships among the different
Norwest banks, and thus the accounting records were often incorrect
following a wire transfer.
NTS allocated five or six technicians to remedy the problem.
The technicians mapped out the appropriate accounting entries in
order to determine which entries were not properly made following
a wire transfer.
They then filled in the gaps in the code.
Following each change to the code, the changed code was tested and
retested. The distributed wire project improved efficiency through
the elimination of much of the paper process.
It also improved
reliability through the fault-tolerant system.
During the years in issue, the vendor released upgrades of the
MoneyNet software.
The installation of these new releases posed
compatibility problems for Norwest as a result of prior changes to
the
code
made
by
NTS.
The
retrofitting
process
comparison
of
the
new
and
old
codes
to
ensure
that
of
the
modifications
the
vendor
required
required
with
a
the
NTS
functionality
was
employed
SDM
maintained.
For
all
MoneyNet
projects,
NTS
the
process, continually testing the modifications to the system to
- 42 ensure that the code worked properly and that functionality was not
compromised.
F.
Cyborg Payroll
The Cyborg payroll software was a payroll management system
designed to automate the calculation and payment of wages to
employees and taxes to Federal, State, and local authorities.
It
also maintained and processed audit reports of those payments. The
Cyborg software was vendor acquired in the late 1970's, although it
was originally designed in the mid-1960's.
Given the age of the
system, much of NTS' effort was focused on "trying to keep it
running".
Eventually, after the period at issue here, Cyborg was
replaced by a payroll system known as Peoplesoft.
Cyborg was customized by Norwest to meet its needs, including
the need to make nonstandard payments to certain employees and to
maintain different types of reports. NTS developed its own "method
code" which permitted the users to customize payments or deductions
for employees--a function not fully available on the original
version of Cyborg.23
During the years in issue, there were as many as 50 discrete
service projects with respect to Cyborg.
23
They included:
Payroll
For example, customization of the various payments and
deductions was necessary to reflect different tax withholding
rates in different States and to reflect the imposition of local
or county taxes in some jurisdictions.
- 43 method code JL--calculating the amount of paycheck deductions for
savings and investments plans; Cyborg release 34--implementation of
a new vendor release of the system; payroll work facility--a mail
station identifier for the users; payroll general ledger reports-changes to the reports made from the interface with the general
ledger; and payroll Cyborg yearend--customizations with respect to
the yearend production of documents.
Upgrades and new releases were common, particularly with
respect to changes in the tax laws that required changes to the
payroll system.
The many customization projects involved changes
to each of the three programs (the edit program, the calculation
program, and the print program) that constituted the heart of
Cyborg.
In using the Software Development Methodology to customize the
Cyborg
software,
NTS
reviewed
the
old
and
new
source
codes
(obtained from the vendor) to determine where the customized code
could
be
written
without
sacrificing
required
functionality.
Following the design and development phases, NTS conducted test
payroll and reporting runs in order to ensure that the users' needs
were met.
As part of this process, in order to verify that the
results were consistent, NTS tested the system both before and
after the changes were made.
- 44 One area that created a problem in customizing Cyborg for
Norwest's needs was the programming language for the reporting
function.
The three main programs of Cyborg were written in an
older COBOL language (a common mainframe programming language), but
the reporting program was in a language specific to Cyborg which
had severe limitations.
Moreover, the Cyborg language was not
designed for the mainframe systems used at Norwest, but rather for
personal computers.
Besides customization, NTS was responsible for converting the
payroll systems of the banks acquired by Norwest to the Cyborg
system.
handle
The Cyborg software was not developed specifically to
conversions
of
this
nature.
Consequently,
NTS
had
to
determine a means of converting the payroll data, or perform the
conversions manually (in the case of small banks).
G.
Trust Payment
The Trust Payment system was created in-house by Norwest in
1987 as
a
means
for
making
disbursements
from
pension
trust
accounts to beneficiaries, maintaining trust account records, and
reporting tax-related information.
Norwest chose to build this
system itself after a determination was made that commercially
available trust systems were unable to meet its needs.
The Trust Payment system automated many manual processes as
well
as
providing
integrated
check-cutting
capabilities.
- 45 Initially, NTS developed the system using DB2 technology, as
indicated supra, a relatively new relational database24 offered and
heavily promoted by IBM.
Even though NTS had little experience
with the technology, NTS used DB2 because it possessed many of the
characteristics Norwest needed for its pension system.
NTS experienced various problems in building the Trust Payment
system.
First, the system ran slowly, taking several days rather
than only a couple of hours to process data and produce a batch of
checks.
Second, occasionally, pension checks were issued in
negative dollars; that is, pensioners received checks in negative
amounts.
Third, the system crashed when too many users were
seeking to access the same data.
Ultimately, these problems were
solved by the NTS personnel assigned to this area.
After the Trust Payment system was implemented, NTS conducted
(over a 2-year period) a thorough review of the system to determine
its ability to handle timely the anticipated increase in the number
of trust account checks that would need to be issued in the future.
This review focused on the use of the DB2 technology and whether
there was a means of making the system run faster.
had a reputation for being sluggish.)
(The DB2 system
NTS considered several
possible reasons for the slowness of the Trust Payment system but
24
In general, a relational database allows the user to
store data in one table which relates to (and can be used with)
other tables for reporting and updating purposes.
- 46 was sure of neither the reasons nor the solutions.
The process of
improving the Trust Payment system required code review, the
rewriting of several Trust Payment system functions, and then
testing
the
improvements
approaches.
system
to
were
not
observe
the
satisfactory,
processing
time.
NTS
on
went
to
If
the
other
Throughout this process, NTS received assistance from
IBM.
Although developed for in-house use by Norwest, the Trust
Payment system was examined by two other companies interested in
purchasing the system.
H.
Debit Card
The Debit Card software system was built to support the
issuance of Norwest's debit card product.
A debit card is a
financial product that permits payment of point-of-sale purchases
directly from the card holder's checking (or other) account.25
To
accomplish payment, a number of transactions occur, as follows:
Upon presentation of the debit card to a merchant, the transaction
is sent to a card association network processor (in this case
Visa);26 Visa then seeks to identify the transaction as being made
25
This is as opposed to a credit card system in which the
card holder makes purchases against a preestablished line of
credit.
26
The card processor, in addition to routing transaction
requests to the issuing bank, also performs card holder and
(continued...)
- 47 with a particular financial institution's (here Norwest's) product;
following recognition of Norwest as the appropriate financial
institution,
Visa
sends
a
communication
to
Norwest
seeking
authorization of the transaction; Norwest then verifies that the
card holder has sufficient funds in his or her account to make the
purchase,
authorizes
the
transaction,
and
finally
debits
the
holder's account.
Once Norwest decided to enter the debit card market in 1989,27
NTS was under pressure to complete the project by yearend so that
Norwest could market the product before its competitors.
time
Norwest
entered
the
debit
approaches to issuing the card.
card
market,
there
At the
were
two
The first approach was through a
credit card processing system by which a third party handled all of
the transactions in a credit-card-like fashion and then sent the
transactions to the card issuer (Norwest) for payment and debit.28
26
(...continued)
account authentication and transaction authorization.
27
Typically, projects were identified in the year prior
to the time Norwest's business units wanted the projects
completed. However, in the case of the debit card software
project, the decision to enter the debit card market was not made
until early 1989, and the goal was to complete the project by the
end of that same year.
28
Under this approach, two messages are sent from the
merchant: One seeking authorization and one seeking settlement.
However, settlement is performed by the credit card processing
company in an off-line batch job (which is usually done at
(continued...)
- 48 The second approach, the one used by Norwest, involved direct
access to the checking (or other) account for debiting, skipping
the processing middleman.
This latter approach gave Norwest
greater control over the product and its use.
Although by the late
1980's the credit card processing version of the debit card product
had been used throughout the United States, it was not available in
the nine States in which Norwest competed--and thus, Norwest chose
to use the direct access approach.29
To build the debit card system and links to Visa,30 NTS, which
applied Norwest's Software Development Methodology, relied on the
Base 24 operating system that ran Norwest's automatic teller
machines
(ATM's)
and
the
Visanet
module,
which
developed by Visa and ACI, the vendor of Base 24.
was
jointly
The Visanet
module was necessary to connect the Base 24 operating system to the
Visa debit card system.
Norwest was the first bank to acquire,
28
(...continued)
night). This requires extension of short-term credit by the
issuing bank to the customer, a risk banks generally consider
appropriate for 60 to 80 percent of their customers.
29
First Data Resources (FDR), the credit card processor
used by Norwest for its credit cards, lacked experience with the
debit card product at the time Norwest entered the market.
Further, Norwest was not comfortable with FDR's having direct
access to its checking accounts.
30
As part of their partnership in developing the debit
card system, Visa provided Norwest with technical manuals,
transaction simulators, and an access point communications
device.
- 49 install, and test the connection of the Visanet module to the Base
24 system for the debit card product.
NTS and Visa experienced problems with communications between
the two systems.
(Two types of communications are necessary for
the debit card to operate properly:
(1) A communication from Visa
to Norwest seeking authorization for a purchase (this is referred
to as an on-line transaction); and (2) a communication from Visa to
Norwest
posting
Norwest's
the
general
significant
transaction
ledger
communication
to
the
checking
account
and
as
settlement).)
The
most
to
the
(known
problem
was
with
respect
transaction posting communication, which often failed entirely-potentially resulting in customers' purchasing goods and services
without having their Norwest accounts correspondingly debited.
Because the settlement information was not being received from
Visa, NTS had to create its own set of transactions and run them
through a test system to ensure that other systems (including the
checking account and general ledger systems) that were dependent on
the
settlement
communications
operated
correctly.
This
communication problem required a Norwest team of four or five
technicians working for 4 or 5 months to redesign the code and
retest the system until communications were correctly established.
The introduction of the debit card product required several
changes to other systems that operated in conjunction with the
- 50 debit card system. Although these changes were relatively minor in
comparison to the process of connecting the Visanet module to the
Base 24 system, they still required a pattern of trial and error
through testing and retesting.
Further, because the debit card
operated on the same system that operated the ATM card, it was
important for the various Norwest systems to recognize that the
debit card was a distinct product.
Ultimately,
the
debit
card
went
into
implementation in January 1990, as scheduled.
production
and
Norwest entered the
market with the debit card approximately 3 months ahead of its
nearest competitor, First Bank.
OPINION
Our task herein is to determine whether any or all of the
eight
sample
internal
use
software
development
activities
of
Norwest constitute qualified research for purposes of the tax
credit provided by section 41.
The parties agree that section 41
and its legislative history, combined, set forth seven tests to
determine whether internal use software development activities
constitute qualified research.
This is a case of first impression in this Court.
However, we
are mindful of the recent decision of the District Court for the
Northern District of Illinois in United Stationers, Inc. v. United
States, 982 F. Supp. 1279 (N.D. Ill. 1997), on appeal (7th Cir.,
- 51 Dec. 23, 1997), which addressed the application of section 41 to
qualified research in the development of internal use software. We
discuss that case infra.
1. Section 41
Section
41,31
captioned
"Credit
For
Increasing
Research
Activities", provides a nonrefundable credit against a taxpayer's
U.S. income tax liability as provided in section 38 (general
business credits).
Any excess credit may be carried forward or
carried back as provided in section 39.
The credit is computed as
an amount equal to the sum of 20 percent of the excess of the
taxpayer's qualified research expenses over a "base amount", and 20
percent of the taxpayer's basic research expenses. Sec. 41(a)-(c).
Qualified
expenses
include
those
amounts
paid
for
"in-house"
research services (i.e., wages) or supplies, or "contract" research
by nonemployees.
Sec. 41(b).
Section 41(d) defines qualified research and provides in part:
SEC. 41(d). Qualified Research Defined.--For purposes of
this section-(1) In general.--The
means research--
term
"qualified
research"
(A) with respect to which expenditures
may be treated as expenses under section 174,
31
The R&E credit under sec. 41 expires on June 30, 1998,
with a limited exception. Taxpayer Relief Act of 1997, Pub. L.
105-34, sec. 601(a)(1), 111 Stat. 788, 861.
- 52 (B) which is undertaken for the purpose of
discovering information-(i)
nature, and
which
is
technological in
(ii) the application of which is
intended to be useful in the development of a
new or improved business component
of the
taxpayer, and
(C) substantially all of the activities
of which constitute elements of a process of
experimentation for a purpose described in
paragraph (3).
*
*
*
*
*
*
*
(2) Tests to be applied separately to each business
component.--For purposes of this subsection-(A) In general.--Paragraph (1) shall be
applied separately with respect to each
business component of the taxpayer.
(B) Business
component
defined.--The
term "business component" means any product,
process,
computer
software,
technique,
formula, or invention which is to be-(i) held
license, or
for
sale,
lease,
or
(ii) used by the taxpayer in a trade
or business of the taxpayer.
*
*
*
*
*
*
*
(3) Purposes for which research may qualify for
credit.--For purposes of paragraph (1)(C)-(A) In
general.--Research
shall
be
treated as conducted for a purpose described
in this paragraph if it relates to-(i)
a new or improved function,
- 53 (ii)
performance, or
(iii)
reliability or quality.
(B) Certain purposes not qualified.-Research shall in no event be treated as
conducted for a purpose described in this
paragraph if it relates to style, taste,
cosmetic, or seasonal design factors.
Section 41 excludes certain activities from qualifying for the
credit, including the development of internal use software--except
to the extent provided by regulations or to the extent the software
is developed for use in an activity or process that otherwise
qualifies for the credit.
Sec. 41(d)(4)(E).
The R&E credit under section 4132 was first created by Congress
as part of the Economic Recovery Tax Act of 1981 (ERTA), Pub. L.
97-34, sec. 221(a), 95 Stat. 172, 227, which provided for a
nonrefundable
income
tax
credit
for
certain
research
and
experimental expenditures paid or incurred by a taxpayer during the
taxable year in carrying on a trade or business.
The purpose of
the credit was to "stimulate a higher rate of capital formation and
to increase productivity", S. Rept. 97-144, at 76-77 (1981), 1981-2
C.B. 412, 438-439; H. Rept. 97-201, at 111 (1981), 1981-2 C.B. 352,
32
The tax credit was first designated sec. 44F by the
Economic Recovery Tax Act of 1981 (ERTA), Pub. L. 97-34, sec.
221(a), 95 Stat. 172, 227, and was then redesignated sec. 30 by
the Deficit Reduction Act of 1984, Pub. L. 98-369, sec. 471(c),
98 Stat. 494, 826, and then sec. 41 by the Tax Reform Act of 1986
(TRA 1986), Pub. L. 99-514, sec. 231(d)(2), 100 Stat. 2085, 2178.
- 54 358, and to "encourage business firms to perform the research
necessary to increase the innovative qualities and efficiency of
the U.S. economy", S. Rept. 99-313, at 694 (1986), 1986-3 C.B.
(Vol. 3) 1, 694; H. Rept. 99-426, at 177 (1985), 1986-3 C.B. (Vol.
2) 1, 177.
ERTA
adopted
"experimentation"
section 174.
33
as
the
definitions
those
terms
ERTA sec. 221(a).33
are
of
"research"
generally
defined
and
under
ERTA failed to address how
ERTA sec. 221(a) defined qualified research as follows:
For purposes of this section the term "qualified
research" has the same meaning as the term research or
experimental has under section 174, except that such
term shall not include-(1) qualified research conducted outside of the
United States,
(2) qualified research in the social sciences or
humanities, and
(3) qualified research to the extent funded by any
grant, contract, or otherwise by another person (or any
governmental entity).
In TSR, Inc. & Sub. v. Commissioner, 96 T.C. 903 (1991), we
considered a taxpayer's claim to the R&E credit under then sec.
44F for 1981. The taxpayer, a manufacturer of historical and
fantasy games, sought the credit for its historical research into
the development of the games. In considering the taxpayer's
claim, we applied the plain meaning to the terms "experimental"
("relating to, or based on [experiment]") and "laboratory" ("a
place devoted to experimental study in any branch of natural
science or to the application of scientific principles in testing
and analysis"). We ultimately rejected the taxpayer's claim
because we found that the R&E credit was originally intended by
(continued...)
- 55 research expenditures in developing software operated within the
credit, but the House report accompanying ERTA indicated that the
credit applied only where the costs were "incurred in developing
new or significantly improved programs or routines that cause
computers to perform desired tasks (as distinguished from other
software costs where the operational feasibility of the program or
routine is not seriously in doubt)".
114, 1981-2 C.B. at 360.
H. Rept. 97-201, supra at
This language was not adopted by the
conference report which accompanied ERTA.
H. Conf. Rept. 97-215,
at 223 (1981), 1981-2 C.B. 481, 495.
In 1986, Congress became concerned with the lack of an express
statutory definition of qualified research in the R&E credit and of
taxpayers' abuse of the credit.
The Senate Finance Committee
report accompanying the Tax Reform Act of 1986 stated:
After reviewing available information and testimony on
the actual use of the credit to date, the committee
believes that the statutory credit provision should set
forth an express definition of qualified research
33
(...continued)
Congress to apply only to technological discoveries and not
historical or other nontechnological research.
In Yellow Freight Sys., Inc. & Subs. v. United States, 24
Cl. Ct. 804 (1991), the Court of Federal Claims considered (on a
motion for partial summary judgment) whether the taxpayer's
development of software programs constituted qualified research
under then sec. 44F for 1983 and 1984. That court found that
material facts were in dispute, and thus it did not address
whether the taxpayer's activities fell within the court's
understanding of research and experimentation under sec. 174.
- 56 expenses for purposes of the credit.
The committee
believes that the definition has been applied too broadly
in practice, and some taxpayers have claimed the credit
for
virtually
any
expenses
relating
to
product
development. According to early data on the credit, the
Treasury has reported, many of these taxpayers do not
engage in high technology activities.
S. Rept. 99-313, supra at 694-695, 1986-3 C.B. (Vol. 3) at 694-695;
see also TSR, Inc. & Sub. v. Commissioner, 96 T.C. 903, 919 (1991);
H. Rept. 99-426, supra at 178, 1986-3 C.B. (Vol. 2) at 178.
Congress amended the R&E credit by TRA 1986 sec. 231(b), 100
Stat. 2173, to provide the definition of qualified research that
now is codified in section 41(d).
2. Internal Use Software
As part of the 1986 amendment to the R&E credit, Congress
addressed the application of the credit to the expenditures paid or
incurred in the development of internal use software. Congress did
not define what it meant by internal use software, other than to
indicate that the phrase refers to software that supports general
and administrative functions (such as payroll, bookkeeping, or
personnel management) or provides noncomputer services (such as
accounting, consulting, or banking services).
H. Conf. Rept. 99-
841 (Vol. II), at II-73 (1986), 1986-3 C.B. (Vol. 4) 1, 73.
(The
parties herein agree that each of the eight sample activities
constitutes internal use software.)
- 57 In the conference report accompanying the TRA 1986, the
conferees gave the Department of the Treasury responsibility for
promulgating regulations relating to the application of section 41
to
research
software.
with
respect
to
the
development
of
internal
use
In this regard, the conferees stated:
The conferees intend that these regulations will
make the costs of new or improved internal-use software
eligible for the credit only if the taxpayer can
establish, in addition to satisfying the general
requirements for credit eligibility, (1) that the
software is innovative (as where the software results in
a reduction in cost, or improvement in speed, that is
substantial and economically significant); (2) that the
software development involves significant economic risk
(as where the taxpayer commits substantial resources to
the
development
and
also
there
is
substantial
uncertainty, because of technical risk, that such
resources would be recovered within a reasonable period);
and (3) that the software is not commercially available
for use by the taxpayer (as where the software cannot be
purchased, leased, or licensed and used for the intended
purpose without modifications that would satisfy the
first two requirements just stated).
The conferees
intend that these regulations are to apply as of the
effective date of the new specific rule relating to
internal-use software; i.e., internal-use computer
software costs that qualify under the three-part test set
forth in this paragraph are eligible for the research
credit even if incurred prior to issuance of such final
regulations.
Id.
at
II-73
through
II-74,
1986-3
C.B.
(Vol.
4)
at
73-74.
Congress provided that these rules would be effective to guide
taxpayers until the Department of the Treasury issues regulations
pursuant to the quoted language.
The Department of the Treasury
issued proposed regulations with respect to the R&E credit for
- 58 internal use software in January 1997. The regulatory language was
nearly identical to that provided in the conference report.
Sec.
1.41-4(e)(5), Proposed Income Tax Regs., 62 Fed. Reg. 83 (Jan. 2,
1997).
Ordinarily, proposed regulations carry no more weight than a
position advanced on brief by the Commissioner. F.W. Woolworth Co.
v. Commissioner, 54 T.C. 1233, 1265-1266 (1970).
However, with
regard
Congress
to
the
R&E
credit
under
section
41,
has
specifically expressed its position with respect to the three
internal use software tests.
Thus, we look to the tests as an
expression of legislative intent rather than a position of the
Commissioner.
The proposed regulations add two features worthy of note that
are not expressly provided in the conference report accompanying
the TRA 1986.
First, the regulations provide that all facts and
circumstances shall be considered in determining whether a taxpayer
satisfies
the
requirements
for
qualified
development of internal use software.
research
in
the
Second, the regulations
require that the software meet a "high threshold of innovation" to
obtain the credit under section 41.
Sec. 1.41-4(e)(6), Proposed
Income Tax Regs., 62 Fed. Reg. 83 (Jan. 2, 1997).
- 59 3.
The Seven Tests
The parties agree that the combination of section 41 and the
conference report accompanying the TRA 1986 results in a total of
seven tests that taxpayers must satisfy to obtain the R&E credit
with respect to qualified research in the development of internal
use software:34
(1) The section 174 test (the research expenditures must
qualify as expenses under section 174);35
(2) the discovery test (the research must be undertaken for
the purpose of discovering information which is technological in
nature);
(3) the business component test (the research must be
undertaken for the purpose of discovering information the
application of which is intended to be useful in the development of
a new or improved business component of the taxpayer);
(4) the process of experimentation test (substantially all of
the activities which constitute elements of a process of
experimentation must relate to a new or improved function,
performance, reliability, or quality);
(5) the innovativeness test (the software must be innovative
(as where the software results in a reduction in cost, or
improvement in speed, that is substantial and economically
significant));
34
Tax credits are a matter of legislative grace, and the
taxpayer bears the burden of proving entitlement to the credits.
Rule 142(a); Interstate Transit Lines v. Commissioner, 319 U.S.
590, 593 (1943); Segel v. Commissioner, 89 T.C. 816, 842 (1987).
35
Sec. 41(d)(1)(A) provides that "qualified research"
means research "with respect to which expenditures may be treated
as expenses under section 174". We believe that the statutory
phrase "may be treated as expenses under section 174" means that
the expenditures must "qualify" for the deduction under sec. 174.
See infra.
- 60 (6) the significant economic risk test (the software
development must involve significant economic risk (as where the
taxpayer commits substantial resources to the development and also
there is substantial uncertainty, because of technical risk, that
such resources would be recovered within a reasonable period)); and
(7) the commercial availability test (the software must not
be commercially available for use by the taxpayer (as where the
software cannot be purchased, leased, or licensed and used for the
intended purpose without modifications that would satisfy tests (5)
and (6))).
These
seven
tests,
however,
must
be
applied
with
an
understanding of some of the terminology used by Congress which is
not defined.
ordinary
To understand these tests, we will rely on the
meaning
of
the
language
used
in
the
statute,
see
Commissioner v. Soliman, 506 U.S. 168, 174 (1993); United States v.
American Trucking Associations, Inc., 310 U.S. 534, 543-544 (1940),
as well as the legislative history surrounding the promulgation of
the TRA 1986, see Landgraf v. USI Film Prods., 511 U.S. 244 (1994);
Trans City Life Ins. Co. v. Commissioner, 106 T.C. 274, 299 (1996).
A.
The Section 174 Test
The section 174 test requires that the research expenditures
qualify as expenses under section 174.
allows
as
expenditures
a
current
which
are
deduction
paid
or
Section 174 generally
research
incurred
by
and
experimental
the
taxpayer
connection with the operation of a trade or business.
in
Section 174
does not define the phrase "research and experimental", but the
applicable regulations require that the expenditures represent
- 61 research and development costs "in the experimental or laboratory
sense".
Sec. 1.174-2(a)(1), Income Tax Regs.
The regulations
further provide:
Expenditures represent research and development costs in
the experimental or laboratory sense if they are for
activities intended to discover information that would
eliminate uncertainty concerning the development or
improvement of a product.
Uncertainty exists if the
information available to the taxpayer does not establish
the capability or method for developing or improving the
product or the appropriate design of the product.
Whether expenditures qualify as research or experimental
expenditures depends on the nature of the activity to
which the expenditures relate, not the nature of the
product or improvement being developed or the level of
technological advancement the product or improvement
represents.
T.D. 8562, 1994-2 C.B. 30, 31.36
"Product" refers to any pilot,
model, process, formula, invention, technique, patent, or similar
property.
Sec. 1.174-2(a)(2), Income Tax Regs.
On brief, respondent concedes that the expenditures associated
with all eight of the sample internal use software activities "may
be treated as expenses under I.R.C. § 174" (emphasis added), the
language used in section 41(d)(1)(A).
Respondent asserts that it
is the Commissioner's policy not to disturb a taxpayer's method of
accounting with regard to computer software expenditures if the
36
The 1994 regulations under sec. 174 are effective for
all taxable years after Oct. 3, 1994. Because the amendments
provided in the 1994 regulations only clarify the definition of
research or experimental expenditures, retroactivity was
unnecessary. 59 Fed. Reg. 50159, 50160 (Oct. 3, 1994).
- 62 requirements of Rev. Proc. 69-21 are satisfied.
1969-2 C.B. at 303,
Rev. Proc. 69-21,
states that "The costs of developing software
* * * in many respects so closely resemble the kind of research and
experimental expenditures that fall within the purview of section
174 * * * as to warrant accounting treatment similar to that
accorded such costs under that section."37
Respondent notes that
his concession of the section 174 test "does not mean, however,
37
The 1983 proposed regulations under sec. 174 provided
extensive language and examples relating to the treatment of the
development of computer software. The proposed regulations
provided that the term "research or experimental expenditures"
included the costs for developing "new or significantly improved
computer software. The term does not include costs paid or
incurred for the development of software the operational
feasibility of which is not seriously in doubt." Sec. 1.1742(a)(3), Proposed Income Tax Regs., 48 Fed. Reg. 2799 (Jan. 21,
1983). This language appears to have been derived from the House
report accompanying ERTA, which discussed the treatment of
computer software development under the R&E credit (under then
sec. 44F). H. Rept. 97-201, at 114 (1981), 1981-2 C.B. 352, 360.
The treatment of computer software in the 1983 proposed
regulations was criticized by commentators because the proposed
regulations treated computer software differently than other
products, imposing a more difficult test. 54 Fed. Reg. 21225
(May 17, 1989). The 1989 proposed regulations removed the
controversial language and stated that computer software was to
be treated the same as other products. Id. at 21227.
Although Notice 87-12, 1987-1 C.B. 432, indicated that the
IRS intended to issue regulations further explaining the
treatment of computer software under sec. 174, no regulations
were forthcoming. The 1993 proposed regulations only indicated
that no additional conditions were to be imposed on computer
software development activities, and that taxpayers could
continue to rely upon Rev. Proc. 69-21, 1969-2 C.B. 303. The
1994 final regulations are silent altogether. Sec. 1.174-2,
Proposed Income Tax Regs., 58 Fed. Reg. 15821 (Mar. 24, 1993).
- 63 that respondent concedes that petitioner has met the requirements
of I.R.C. § 174, which is simply not an issue in this case."
Petitioner objects to respondent's claim that its expenditures
"may be treated" as expenses under section 174 without in fact
meeting the section's requirements for a deduction.
Petitioner
hazards a guess that respondent wants to have it both ways; that
is, respondent wants to avoid an adverse ruling on the issue (and
its potential impact on other tests under section 41) without
conceding that the section 174 requirements are actually satisfied.
We believe that the phrase "the research expenditures may be
treated as expenses under section 174" is meant to require the
taxpayer to satisfy all the elements for a deduction under section
174.
The
legislative
requirement.
history
of
section
41
supports
this
See H. Conf. Rept. 99-841 (Vol. II), supra at II-71,
1986-3 C.B. (Vol. 4) at 71 ("the conference agreement limits
research
expenditures
eligible
for
the
incremental
credit
to
'research or experimental expenditures' eligible for expensing
under section 174. * * * Under the conference agreement, research
satisfying the section 174 expensing definition is eligible for the
credit").
Thus, on the basis of respondent's concessions, each of
petitioner's eight sample activities satisfies the elements for a
deduction under section 174.
- 64 B.
The Discovery Test
The discovery test requires that the research be undertaken
for the purpose of discovering information which is technological
in nature.
In the conference report accompanying the TRA 1986,
Congress explained the discovery test as follows:
The determination of whether the research is
undertaken for the purpose of discovering information
that is technological in nature depends on whether the
process of experimentation utilized in the research
fundamentally relies on principles of the physical or
biological sciences, engineering, or computer science3-in which case the information is deemed technological in
nature--or on other principles, such as those of
economics--in which case the information is not to be
treated as technological in nature.
For example,
information relating to financial services or similar
products (such as new types of variable annuities or
legal forms) or advertising does not qualify as
technological in nature.
3
Research does not rely on the principles of
computer science merely because a computer is employed.
Research may be treated as undertaken to discover
information that is technological in nature, however, if
the research is intended to expand or refine existing
principles of computer science.
H. Conf. Rept. 99-841 (Vol. II), supra at II-71 through II-72 &
n.3, 1986-3 C.B. (Vol. 4) at 71-72 & n.3.
The purpose of the discovery test is to limit the type of
information discovered to that which is technological in nature, as
opposed to nonscientific information, such as in the fields of the
social sciences, arts, or humanities, that is specifically excluded
by section 41(d)(4)(G). See TSR, Inc. & Sub. v. Commissioner, 96
- 65 T.C. 903 (1991).
Additionally, the test is intended to limit the
form of discovery to the "process of experimentation", which is
defined elsewhere by the conference report accompanying the TRA
1986 and which is discussed infra.
Congress did not statutorily define the word "discovery".
Petitioner asserts on brief that "discovery" has the same meaning
as in the regulations under section 174, see sec. 1.174-2(a)(1),
Income Tax Regs., directing the Court to the structure of section
41(d)(1)(B).
Consequently,
petitioner
contends,
if
Norwest's
activities satisfy the section 174 test, there is no need to
address whether Norwest performed discovery in the context of the
second test.
Respondent contends that the discovery tests under sections
174 and 41 are different.
For several reasons, we agree.
First,
the discovery test under the section 174 regulations was not
adopted until 1994, 8 years after the discovery test in section 41
was created in the TRA 1986--thus, we find it difficult to conclude
that Congress intended the tests to have the same meaning.
Second,
the discovery test under the section 174 regulations relates to
"uncertainty
product".
concerning
the
development
or
improvement
of
a
The discovery test under section 41, on the other hand,
relates to information which is "technological in nature" and which
"fundamentally relies on principles of the [hard sciences]". Thus,
- 66 the
tests
relate
to
the
discovery
of
different
information.
Finally, we note that the legislative history of section 41 reveals
that in 1986, Congress sought to tighten the requirements for
obtaining the R&E credit because taxpayers were not using the
credit for high technology purposes.
H. Rept. 99-426, at 178
(1985), 1986-3 C.B. (Vol. 2) 1, 178; S. Rept. 99-313, at 694
(1986), 1986-3 C.B. (Vol. 3) 1, 694-695. Congress effectuated this
goal by adding three tests to section 41, including the discovery
test, but did not change the meaning of section 174 (and presumably
the discovery test subsequently created under the section 174
regulations).
H. Conf. Rept. 99-841 (Vol. II), supra at II-76,
1986-3 C.B. (Vol. 4) at 71, 76; see also S. Rept. 97-144, at 81
(1981), 1981-2 C.B. 412, 441.
We therefore conclude that Congress
intended to treat the discovery test under section 41 more narrowly
than the discovery test created under section 174.
The dictionary definition of "discover" is "to make known or
visible" or "to obtain sight or knowledge of for the first time".
Webster's Ninth New Collegiate Dictionary (1985).
The legislative
history of section 41 dictates that the knowledge gained from the
research and experimentation must be that which exceeds what is
known in the field in which the taxpayer is performing the research
and experimentation--in this case, the computer science field. The
fact that the information is new to the taxpayer, but not new to
- 67 others, is not sufficient for such information to come within the
meaning of discovery for purposes of this test.
The purpose of the
R&E credit was to stimulate capital formation and improve the U.S.
economy--not merely the taxpayer's business.
See H. Rept. 97-201,
at 111 (1981), 1981-2 C.B. 352, 358; H. Rept. 99-426, supra at 177,
1986-3 C.B. (Vol. 2) at 177.
The legislative purpose of the discovery test in section 41
was to narrow the scope of the research and experimentation under
section
174
to
that
which
is
technological
in
nature.
The
technological-in-nature requirement is consistent with Congress'
concern that the R&E credit was not being used for high technology
research before the 1986 amendments.
S. Rept. 99-313, supra at
694-695, 1986-3 C.B. (Vol. 3) at 694-695; H. Rept. 99-426, supra at
178, 1986-3 C.B. (Vol. 2) at 178.
Thus, Congress specifically
stated that the discovery process must fundamentally rely on
principles of the hard sciences--namely, physical or biological
sciences, engineering, or computer science.
The
parties
dispute
the
significance
of
note
3
of
the
conference report, H. Conf. Rept. 99-841 (Vol. II), supra at II-71
n.3, 1986-3 C.B. (Vol. 4) at 71 n.3, accompanying the TRA 1986.
That footnote states that the research must "expand or refine" the
principles of the hard sciences.
Respondent contends that the
phrase "expand or refine" is meant to explain the nature of the
- 68 discovery required by the taxpayer, noting the legislative history
of section 41. On the other hand, petitioner contends that "expand
or refine" is only illustrative and is intended to contrast the
mere use of a computer which in and of itself does not necessarily
involve fundamental reliance on the principles of computer science.
We believe the purpose of the first sentence of note 3
("Research does not rely on the principles of computer science
merely because a computer is employed.") is to emphasize that
Congress intended the R&E credit not for the use of the hard
sciences per se, but for the use of the principles of the hard
sciences in conducting research.
comprehensive
and
fundamental
"Principle" is defined as "a
law,
doctrine,
or
assumption".
Webster's Ninth New Collegiate Dictionary (1985). Clearly, the use
of
a
computer
does
not
necessarily
require
reliance
on
any
fundamental laws, doctrines, or assumptions.
The purpose of the second sentence of note 3 ("Research may be
treated as undertaken to discover information that is technological
in nature, however, if the research is intended to expand or refine
existing principles of computer science.") is to indicate that the
taxpayer must discover information with respect to the principles
of the hard sciences on which it fundamentally relies.
Note 3 sets
forth two means of discovering information about the principles of
the hard sciences--either by "expanding", or by "refining"--either
- 69 or both of which allows the taxpayer "to make known or visible" or
"to obtain sight or knowledge for the first time", the definition
of discovery discussed above.
Congress' goals of stimulating a
higher rate of capital formation and improving the U.S. economy
cannot be achieved unless the taxpayer goes beyond the preexisting
knowledge of the principles of the hard sciences.
Expanding or
refining those principles are two, but not the exclusive, ways of
satisfying these goals.38
C.
The Business Component Test
The business component test (which is actually part of the
discovery test) requires that the research be undertaken for the
purpose of discovering information the application of which is
intended to be useful in the development of a new or improved
business component of the taxpayer.
This test was addressed by
Congress as follows:
Under the conference agreement, research is treated
as conducted for a functional purpose only if it relates
to a new or improved function, performance, reliability,
or quality. (Activities undertaken to assure achievement
of the intended function, performance, etc. of the
business component after the beginning of commercial
production of the component do not constitute qualified
38
Respondent relies on the language in TSR, Inc. & Sub.
v. Commissioner, 96 T.C. 903 (1991), in which we stated that the
technological-in-nature requirement amounted to a requirement of
a "technological breakthrough". Id. at 920. Inasmuch as TSR,
Inc. did not involve the R&E credit as it exists under sec. 41,
we do not consider that language an element of the discovery
test.
- 70 experimentation.) The conference agreement also provides
that research relating to style, taste, cosmetic, or
seasonal design factors is not treated as conducted for
a functional purpose and hence is not eligible for the
credit.
H. Conf. Rept. 99-841 (Vol. II), supra at II-72, 1986-3 C.B. (Vol.
4) at 72.
The parties do not seriously dispute the meaning of the
business component test or the legislative history.
Indeed, it is
evident that Congress intended only that the taxpayer's activities
provide some level of functional improvement, at a minimum.
D.
The
The Process of Experimentation Test
process
of
experimentation
test
requires
that
substantially all of the activities which constitute elements of a
process of experimentation relate to a new or improved function,
performance,
reliability,
or
quality.
The
process
of
experimentation test, which is referenced in the discovery test, is
explained by Congress as follows:
The term process of experimentation means a process
involving the evaluation of more than one alternative
designed to achieve a result where the means of achieving
that result is uncertain at the outset. This may involve
developing one or more hypotheses, testing and analyzing
those hypotheses (through, for example, modeling or
simulation), and refining or discarding the hypotheses as
part of a sequential design process to develop the
overall component.
Thus, for example, costs of developing a new or
improved business component are not eligible for the
credit if the method of reaching the desired objective
(the new or improved product characteristics) is readily
- 71 discernible and applicable as of the beginning of the
research activities, so that true experimentation in the
scientific or laboratory sense would not have to be
undertaken to develop, test, and choose among the viable
alternatives. On the other hand, costs of experiments
undertaken by chemists or physicians in developing and
testing a new drug are eligible for the credit because
the
researchers
are
engaged
in
scientific
experimentation. Similarly, engineers who design a new
computer system, or who design improved or new integrated
circuits for use in computer or other electronic
products, are engaged in qualified research because the
design of those items is uncertain at the outset and can
only be determined through a process of experimentation
relating to specific design hypotheses and decisions as
described above.
H. Conf. Rept. 99-841 (Vol. II), supra at II-72, 1986-3 C.B. (Vol.
4) at 72.
Unlike the regulations under section 174, which are silent
about the means of discovering information, the conference report
accompanying the TRA 1986 made it clear that a more structured
method of discovery is required with respect to section 41.
By
requiring that at the outset uncertainty exist about the ability to
develop the product in the scientific or laboratory sense, the
process of experimentation test is aimed at eliminating uncertainty
about the technical ability to develop the product--as opposed to
uncertainty as to whether the product can be developed within
certain business or economic constraints, even though the taxpayer
knew that it was technically possible to develop it.
As evidence of the required uncertainty, Congress mandated the
evaluation of more than one alternative, which in turn may require
- 72 the use of a structured process of experimentation through the
continuous development of hypotheses that require testing and
analysis until the method for reaching the objective is discovered.
Congress did not specify that any particular number of hypotheses
be developed by the taxpayer, but the more hypotheses that are
developed, tested, and analyzed, the more likely the project will
satisfy the process of experimentation test.
This test also requires that "substantially all" of the
activities constitute elements of a process of experimentation.
This requirement raises two questions: (1) What does the term
"substantially all" mean? and (2) what activities come within the
elements of a process of experimentation?
Respondent contends that "substantially all" means at least 80
percent, referring to section 1.41-2(d)(2), Income Tax Regs., which
defines the term "substantially all" with respect to qualified
wages under section 41 as meaning at least 80 percent of the wages
paid or incurred by the taxpayer for the employee. Petitioner does
not dispute respondent's proposed 80-percent test.
We agree with respondent and hold that in the context of
section 41, the term "substantially all" refers to at least 80
percent of the activities that constitute elements of a process of
experimentation.
This
interpretation
is
consistent
with
the
- 73 existing definition of "substantially all" in the regulations under
section 41 with respect to qualified wages.
Congress indicated in the conference report accompanying the
TRA
1986
those
experimentation.
elements
They
which
include
analyzing of hypotheses.
the
constitute
developing,
a
process
of
testing,
and
They do not include activities performed
after commercial production or implementation or otherwise set
forth in section 41(d)(4).
See H. Conf. Rept. 99-841 (Vol. II),
supra at II-72, 1986-3 C.B. (Vol. 4) at 72.
However, in the case
of internal use software, exceptions are made for the modifications
of commercially available software.
See infra.
Thus, at least 80 percent of the activities engaged in by a
taxpayer
with
respect
to
the
preproduction
or
implementation
development of a product must involve the development, testing, and
analysis of hypotheses that are designed to eliminate technical
uncertainty as to the development of that product.
This then
raises the issue of which activities in a project are to be
examined together and which are to be examined separately for
purposes of section 41.
Congress has provided us with some
guidance in a so-called shrinking back test:
The term business component means a product,
process, computer software, technique, formula, or
invention that is to be held for sale, lease, or license,
or is to be used by the taxpayer in a trade or business
of a taxpayer. If the requirements described * * * [in
the first four tests under section 41] are not met with
- 74 respect to a product, etc. but are met with respect to
one or more elements thereof, the term business component
means the most significant set of elements of such
product, etc. with respect to which all requirements are
met.
Thus, the requirements are applied first at the
level of the entire product, etc. to be offered for sale,
etc. by the taxpayer.
If all aspects of such
requirements are not met at that level, the test applies
at the most significant subset of elements of the
product, etc. This "shrinking back" of the product is to
continue until either a subset of elements of the product
that satisfies the requirements is reached, or the most
basic element of the product is reached and such element
fails to satisfy the test.
Treasury regulations may
prescribe rules for applying these rules where a research
activity relates to more than one business component.
H. Conf. Rept. 99-841 (Vol. II), supra at II-72 through II-73,
1986-3 C.B. (Vol. 4) at 72-73.
We conclude that the shrinking back
test must be examined on a case-by-case basis to determine which
activities are part of the same product or process, and which are
so discrete as to warrant a separate evaluation.
E.
The Innovativeness Test
The
innovativeness
test
requires
that
the
software
be
innovative "as where the software results in a reduction in cost,
or improvement in speed, that is substantial and economically
significant".
Id. at II-73, 1986-3 C.B. (Vol. 4) at 73.
The
parties disagree over the meaning of the innovativeness test.
Respondent contends that the legislative history of section 41
mandates that we require a "high threshold of innovation", the
phrase that appears in the House and Senate reports accompanying
the TRA 1986, S. Rept. 99-313, at 694-695 (1986), 1986-3 C.B. (Vol.
- 75 3) 1, 694-695; H. Rept. 99-426, at 178 (1986), 1986-3 C.B. (Vol. 2)
1, 178, and as used by the Department of the Treasury in its
proposed regulations, section 1.41-4(e)(6), Proposed Income Tax
Regs., 62 Fed. Reg. 83 (Jan. 2, 1997).
Further, respondent asserts
that we should read this and the other internal use software tests
narrowly inasmuch as they are exceptions to the general rule that
internal use software activities are not eligible for the R&E
credit.
Sec. 41(d)(4)(E).
Petitioner argues that the language in the innovativeness test
is straightforward and that we should focus on its plain meaning.
Petitioner analyzes the meaning of "substantial" and "significant"
to reach the conclusion that these words connote a range of 5- to
20-percent improvement in the product or process.
In support of
this conclusion, petitioner cites several statutes, regulations,
and Nabisco Brands, Inc. & Consol. Subs. v. Commissioner, T.C.
Memo. 1995-127 (applying 25 percent in the context of section
1253(b)(2) and discussing the various statutes and regulations
which define the term "substantial").
We do not believe that quantifying by way of a percentage that
which is "substantial" and "significant" will materially assist us
in
determining
whether
the
innovativeness
test
is
satisfied.
Suffice it to say, the extent of the improvements required by
Congress with respect to internal use software is much greater than
that required in other fields.
The business component test (the
third of the seven tests, which applies to all research and
- 76 experimentation under section 41) requires only a "new or improved"
function, whereas the innovativeness test (which applies only to
internal
use
software
development)
requires
substantial and economically significant".
change
"that
is
H. Conf. Rept. 99-841
(Vol. II), supra at II-73, 1986-3 C.B. (Vol. 4) at 73 (emphasis
added). We therefore agree with respondent that only a "high
threshold of innovativeness" will satisfy this requirement.
F.
The Significant Economic Risk Test
The significant economic risk test requires that the software
development
involve
significant
economic
risk
"as
where
the
taxpayer commits substantial resources to the development and also
there is substantial uncertainty, because of technical risk, that
such resources would not be recovered within a reasonable period".
Id.
Petitioner contends that the significant economic risk test
requires that
only
a
20-percent
risk
need
exist,
because
of
technical uncertainty, to prevent the taxpayer from recovering its
investment within a reasonable period of time.
Petitioner reaches
this conclusion on the basis of the same analysis it used with
respect to the innovativeness test. Respondent, on the other hand,
emphasizes the magnitude of the technical risk as a key factor in
analyzing the internal use activities under this test.
Again,
we
find
significant
Congress'
requirement
of
a
substantial uncertainty.
In both the contexts of the regulations
under
the
section
174
and
explanation
of
the
process
of
experimentation test provided in the conference report accompanying
- 77 the TRA 1986, only uncertainty is required.
The use of the word
substantial here requires a further step in the context of the
development of internal use software. As in the case of the
innovativeness test, we believe the significant economic risk test
requires a higher threshold of technological advancement in the
development of internal use software than in other fields.
G.
The Commercial Availability Test
The commercial availability test requires that the software
not be commercially available for use by the taxpayer "as where the
software cannot be purchased, leased, or licensed and used for the
intended purpose without modifications that would satisfy [tests
(5)
and
(6)]".
Id.
Although
this
language
is
fairly
self-
explanatory, respondent argues that a taxpayer's expenses incurred
in the implementation of vendor releases of commercially available
software can never satisfy this final test because the releases are
commercially available.
We refuse to adopt such a bright-line rule.
anticipated
that
some
modifications
to
Congress clearly
commercially
available
software can satisfy the fifth and sixth tests of our seven-test
analysis.
We must examine those modifications, including any
modifications resulting from the implementation of commercially
available software, on a case-by-case basis.
- 78 4. Summary of Internal Use Software Requirements Under the Seven
Tests
The
higher
threshold
of
technological
advancement
and
functional improvement in the development of internal use software
vis-a-vis other fields of research is consistent with the general
rule that qualified research under section 41 excludes internal use
software development.
Sec. 41(d)(4)(E).
Although the reasons for
such discrimination are not readily apparent, they nonetheless do
exist.
The
conclusion
we
draw
from
these
higher
threshold
requirements is that Congress sought to limit the development of
internal use software under section 41 only to those endeavors that
ventured into uncharted territory.39
We are mindful, however, that
39
We recognize that commentators to the 1983 and 1989
proposed regulations under sec. 174 were concerned with language
that could discourage the "evolutionary" nature of research. The
Explanation of Provisions in the 1989 proposed regulations to
sec. 174 states in pertinent part:
A number of commentators suggested that the [1983]
proposed regulations could be read to require a
significant improvement for an activity to qualify
under section 174. They suggested that such a reading
would be overly restrictive because research and
development activities may in many instances be part of
an evolutionary process involving a series of minor
improvements that, when taken together over a period of
time, lead to a significantly improved product. The
regulations proposed by this document do not include
the reference to "routine" or "periodic" improvements.
* * *
54 Fed. Reg. 21225 (May 17, 1989).
The Explanation of Provisions in the 1993 proposed
regulations to sec. 174 states in part:
(continued...)
- 79 we should apply these higher threshold requirements reasonably and
practically and assume that Congress set standards that are not
impossible
to
meet.
See
United
States
v.
American
Trucking
Associations, Inc., 310 U.S. 534, 543 (1940); Venture Funding, Ltd.
v. Commissioner, 110 T.C. 236, 264 (1998) (Ruwe, J., dissenting).
In applying each of the seven tests under section 41 to the facts
herein,
we
shall
consider
the
facts
and
circumstances
in
determining whether the taxpayer performed qualified research.
5.
United Stationers, Inc. v. United States
Both parties rely on the District Court's decision in United
Stationers, Inc. v. United States, 982 F. Supp. 1279 (N.D. Ill.
1997), in advancing their differing positions as to whether Norwest
engaged
in
qualified
research
under
section
41.
In
United
Stationers, the taxpayer, a large office supply wholesaler, sought
the R&E credit with respect to eight software projects.
To
automate its business operations, the taxpayer acquired from a
vendor a software package which it then customized to meet its
particular needs. The court principally relied upon the report and
recommendation of a magistrate judge to find the facts in the case,
see United Stationers, Inc. v. United States, 79 AFTR 2d 97-1761,
39
(...continued)
Commentators argued that the "time-line" approach of
the 1989 proposed regulation was unrealistic because
progress in research and development is often achieved
only in small, incremental steps. * * *
58 Fed. Reg. 15819 (Mar. 24, 1993).
- 80 97-1 USTC par. 50,457 (N.D. Ill. 1997) (report and recommendation
of magistrate judge), although the court did not accept all of the
magistrate judge's findings.
The Government therein, as in this
case, conceded that the taxpayer satisfied the section 174 test.
In analyzing section 41, the District Court disallowed the
credit on several grounds.
First, the court concluded that the
taxpayer did not discover information that was technological in
nature.
Applying
a
dictionary
definition
for
technological
("resulting from improvement in technical processes that increases
the productivity of machines and eliminates manual operations or
the operations done by older machines") and discovery ("to make
known" or "to obtain for the first time sight or knowledge of"),
the court found that the taxpayer did no more than use the software
package
as
a
building
block
and
that
it
information that was technological in nature.
failed
to
discover
In that regard, the
court found that the taxpayer did not expand or refine existing
principles of computer science, stating:
"Rather, Stationers
merely applied, modified, and at most, built upon, pre-existing,
technological information already supplied to it.
This is a far-
cry from what Congress contemplated when it spoke of research
directed at the `principles of computer science'."
982 F. Supp. at
1284.
The court next considered the process-of-experimentation test.
The court defined experimentation as "the act, process, or practice
of making experiments" and defined an experiment as "a test or
- 81 trial" or "a tentative procedure or policy; [especially] one
adopted in uncertainty as to whether it will answer the desired
purpose or bring about the desired result".
The court then cited
the legislative history of the test and found that it was necessary
to
determine
the
extent
taxpayer's projects.
of
uncertainty
that
existed
in
the
The court concluded that "while the aspired
benefits of the projects were in doubt, the development of the
means that would allow Stationers to potentially achieve those
benefits was not."
Id. at 1285.
Despite the court's finding that the taxpayer failed to
satisfy both the discovery and process-of-experimentation tests, it
considered whether the taxpayer could have satisfied any of the
internal use software tests.
In doing so, the court rejected the
magistrate judge's findings that the taxpayer did not satisfy the
innovativeness test. Instead, the court noted that the "Magistrate
Judge was correct in reasoning that Stationers' projects `simply
increased efficiency and revenues for Plaintiff'," but nonetheless
concluded that "[the projects] all fall under the plain meaning of
the definition included in the legislative history" and were thus
innovative.
Id. at 1287-1288.
The court did, however, agree with the magistrate judge and
find that the taxpayer failed to satisfy the significant economic
risk test because "`the ability to implement [the projects] was
clear from the outset.
The only risk or uncertainty was whether
- 82 the [projects] would produce the desired efficiency, not whether
they could, in fact, be developed.'"
Id. at 1288.
The District Court's opinion is, unfortunately, of little
benefit to us because of the lack of a detailed record from which
we can compare the facts therein to the facts before us.
we are not bound by the District Court's analysis.
Moreover,
See A.E. Staley
Manufacturing Co. & Subs. v. Commissioner, 105 T.C. 166, 208
(1995), revd. on other grounds and remanded 119 F.3d 482 (7th Cir.
1997); Estate of Schwartz v. Commissioner, 83 T.C. 943, 952 (1984).
Consequently, we will not rely on or otherwise refer to United
Stationers in evaluating the present case.
6.
The Experts
Both parties rely upon the opinions of experts in support of
their respective positions. Both parties' experts prepared initial
and rebuttal reports and testified in support of those reports.
The
experts
reviewed
thousands
of
pages
of
documents
and
interviewed many Norwest employees in the process of preparing
their reports and testimony.
We look to the parties' experts to aid us in applying the
facts relating to Norwest's eight internal use software development
activities to the seven tests for internal use software under
section 41.
We evaluate the opinions of an expert in light of the expert's
qualifications and all other evidence in the record.
Estate of
Christ v. Commissioner, 480 F.2d 171, 174 (9th Cir. 1973), affg. 54
- 83 T.C. 493 (1970); Parker v. Commissioner, 86 T.C. 547, 561 (1986).
We are not bound by the opinions of an expert, especially when they
are contrary to our own judgment.
Orth v. Commissioner, 813 F.2d
837, 842 (7th Cir. 1987), affg. Lio v. Commissioner, 85 T.C. 56
(1985); Silverman v. Commissioner, 538 F.2d 927, 933 (2d Cir.
1976), affg. T.C. Memo. 1974-285. Instead, we may reach a decision
based on our own analysis of all the evidence in the record.
Silverman v. Commissioner, supra at 933. We may accept the opinion
of an expert in its entirety, Buffalo Tool & Die Manufacturing Co.
v. Commissioner, 74 T.C. 441, 452 (1980), or we may be selective in
the use of any portion of such an opinion, Parker v. Commissioner,
supra at 562.
entirety.
We may also reject the expert's opinion in its
Palmer v. Commissioner, 523 F.2d 1308, 1310 (8th Cir.
1975), affg. 62 T.C. 684 (1974).
A.
Petitioner's Expert--Dr. Drew McDermott
Petitioner offered the opinion of Drew McDermott, Ph.D., a
professor of computer science at Yale University.
Dr. McDermott's
area of expertise is artificial intelligence, and he has widely
published on that topic.
He also has an extensive knowledge of
programming language design and implementation, formal learning
theory, and philosophy of mind.
However, Dr. McDermott readily
admitted that he does not maintain much familiarity with the
banking industry or banking software in particular.
Dr. McDermott opined that all eight of the sample internal use
software activities he examined qualify for the R&E credit based on
- 84 his understanding of the seven tax law tests.
However, in his
rebuttal report and at trial, he expressed reservations as to
whether the Cyborg Payroll project so qualified.
When asked to
rank the eight activities from most to least characteristic of
research, Dr. McDermott provided the following list:
Success and
SBS; Trust TU; MoneyNet, Trust Payment, and General Ledger; Debit
Card; and finally Cyborg Payroll.
Dr. McDermott summarized his general findings as follows:
There is usually little room for debate about whether a
project passes tests T4 and T7, having to do with
"improved
business
component"
and
commercial
availability. The main goal of most projects was a piece
of software that automated a process that was previously
done by hand, or that did essentially the same job as an
earlier piece of software, but had more features and
better performance. Even when the project failed, a goal
of this kind was usually clearly present and explicitly
stated. As far as commercial availability is concerned,
I was impressed by how thoroughly Norwest searched for
commercial products, proceeding to develop software
internally only when it had to, and usually by beginning
with a commercial product and adding functions to it that
were crucial to the banking business. * * *
Another criterion that is usually met fairly easily is
T3, the use of a process of experimentation, involving
the development and testing of hypotheses. There was
always some process of experimentation involved in the
eight sample projects. The process was generally not as
systematic as one would find in a physics or chemistry
lab.
I think that reflects the state of practice in
computer science, where effects are usually less subtle
than in physics, and require less rigorous experimental
methodology.
*
*
*
*
*
*
*
For these eight projects, it is clear that there was a
process of experimentation to reduce significant
computer-science uncertainties in every case. There are
some areas of uncertainty that were not involved in any
- 85 of these projects, although I saw evidence that they were
addressed in other Norwest projects.
Dr. McDermott defined computer science as "the study of what
can be accomplished by various classes of algorithm on various
classes of computer architecture in a certain amount of time, or
using memory in a certain way."40
He stated that these limitations
make computer science a "science". Dr. McDermott testified that in
software development the issue is rarely whether something can be
done at all,41 but rather, whether something can be done given
constraints, particularly in the computer environment, e.g., the
type
of
hardware,
the
programming
language,
the
degree
of
reliability, or the level of security.
In each of the Norwest activities (other than the Debit Card
project), Dr. McDermott found that the programmers were attempting
to "push a little bit beyond the current state of the art in order
to produce their next product", and the question was "whether
[fairly familiar elements] * * * could be put together in a
40
By "algorithm" Dr. McDermott referred to the steps a
computer is supposed to execute; and by "architecture" he
referred to the types of elementary steps that are available.
The "time" referred to both the time necessary to develop a
program and the time necessary for a program to process the
selected task.
41
Dr. McDermott agreed that none of the Norwest projects
confronted the question of whether they could be done at all. He
stated that Norwest was more concerned with whether it was
"technically possible to do this with the resources available,
that is, with controllable development costs, manageable schedule
delays, and acceptable performance when completed".
- 86 slightly
new
combination".42
These
types
of
activities,
Dr.
McDermott claimed, are distinguishable from what he identified as
"cookbook" results--"where past practice has codified a way of
solving problems of a certain kind, and it requires no creativity
or experimentation to apply that method to a new problem of that
kind."
Dr. McDermott claimed that a computer science project is
considered research if it has "a significant chance of failure due
to uncertainty regarding questions of computer science".
He
further identified eight types of uncertainty that when present can
result in a project's characterization as research:
(1) Ill
definedness--the inability to formally define a problem to be
solved; (2) time and space complexity--lack of sufficient computing
power due to growth in data that requires an exponential growth in
computing power; (3) intractability--the inability of a program to
work with many different data sets; (4) software engineering--the
management
of
complex
programming
projects;
(5)
architectural
constraints--the process by which the computer completes its tasks;
(6)
asynchronousness--the
organization
of
several
computers
operating in widely separated places; (7) security--the proper
authority
to
enter
a
system;
and
(8)
friendliness of a computer to the user.
42
user
engineering--the
Dr. McDermott estimated
Dr. McDermott conceded that the work performed by
Norwest on the eight sample activities would not produce
publishable results for a textbook on algorithms.
- 87 that, to the extent that it is possible to quantify, a 20-percent
level of
uncertainty
(in
the
ability
to
predict
a
program's
behavior) in a project constitutes "technical risk"43--which, in
turn, would result in a significant chance of failure.44 Dr.
McDermott was of the belief that Norwest would not have engaged in
any project in which there was a greater than 50-percent chance of
failure in the first place.
Finally, Dr. McDermott noted that the field of computer
science does not engage in research in the same manner as other
fields--i.e.,
the
"white
lab
coat"
experiments.
Rather,
he
asserted that computer science research is less formal.
B.
Respondent's Experts
i.
Dr. Randall Davis
One of respondent's experts was Randall Davis, Ph.D., a
professor of management in the electrical engineering and computer
science department at Massachusetts Institute of Technology (MIT).
He previously served as an associate director at the Artificial
Intelligence Laboratory at MIT.
Dr. Davis has been a consultant
43
In his rebuttal report, Dr. McDermott defined the type
of technical risk that arises in most cases as "the risk that a
given computing configuration, or `architecture,' might not be
programmable to perform a task within realistic time and space
bounds, assuming that there are compelling reasons to use that
architecture."
44
Dr. McDermott noted, however, that software projects
fail for many reasons that have nothing to do with research or
technical risk, but rather with a vendor's failure to deliver a
product on time, changing conditions, or the incompetency of the
programmers.
- 88 for numerous corporations and has served as a court-appointed
expert.
Dr. Davis concluded that all eight of the sample internal use
software activities failed to satisfy one or more of the seven
tests for the R&E credit.45
He summarized his findings as follows:
It is my opinion based on the sources [provided] * * *
that the work performed by Norwest involved normal and
routine software development. The software produced, in
terms of the products and services provided, and the
technology used to support it, was all within the then
current state of the art in the industrial work of
management information systems. None of the documents
provided suggest that any of the software developed by
Norwest was, among other things, innovative or involved
a significant degree of technical risk.
Dr. Davis described five types of projects associated with
software development:
(1) Design and implementation (the de novo
creation of a body of software); (2) installation and testing (the
purchase
and
installation
of
software
from
a
vendor);
(3)
maintenance (ongoing adjustments to the code); (4) enhancement
(adding
of
functionality
to
the
program);
and
(attempting to do something for the first time).
(5)
research
Dr. Davis found
that each of Norwest's activities involved at least one of the
first four types of projects, and generally characterized Norwest's
work as installation, interfacing, and testing. When asked to rank
the eight activities in order from most to least characteristic of
research, Dr. Davis provided the following list:
45
SBS; Success and
However, Dr. Davis opined that one of the activities
not included in the eight sample activities, known as Expert
Systems, qualified as research and experimentation under sec. 41.
- 89 Trust TU; Debit Card, Trust Payment, and Money Transfer; and
General Ledger and Cyborg Payroll.
Dr. Davis stated that routine software development must be
distinguished from software research efforts.
He contended that
software research is characterized by the search for information
(as opposed to the production of code),46 the use of test data (as
opposed to production data), and the presence of technical risk.
By "technical risk", Dr. Davis referred to the development of novel
tasks, the use of familiar technology in a new manner,47 or the size
or complexity48 of the project.
However, according to Dr. Davis,
whether a software project is research cannot be cast in terms of
black and white:
the fact that the task has been done before is
46
Dr. Davis dismissed Norwest's activities as not
qualified research because Norwest produced operational software
and not information about principles.
47
As an example of this research, Dr. Davis referred to
the development of spreadsheets in C language as opposed to the
lower level assembly-based language. At the time this was first
done, both the C language and spreadsheets were commonly known
and understood, but C had never been used to develop a
spreadsheet. The use of C reduced the amount of memory spent by
the computer in running the spreadsheet program, but it was
unclear until the project was completed that C would also be fast
enough to operate on the then-current generation of personal
computers.
48
As an example of a large project that constitutes
research, Dr. Davis noted the attempted development of a single,
comprehensive reservation system among an airline, a hotel, and a
car rental company which spanned three different businesses,
their operating divisions, and thousands of sites. As an example
of a complex project that might constitute research, Dr. Davis
referred to the efforts of running multiple programs on multiple
machines over a network.
- 90 not controlling as to whether it is necessarily research because of
the different environments in which the tasks are attempted.
Further, Dr. Davis contended that technical risk49 cannot entirely
be eliminated from any project, even up to and through the time of
production.
Dr. Davis explained that routine software development is
characterized by the use of commercially available tools or known
methodologies, both applied within their expected limits, and
skilled practice.50
He stated that routine tasks often include the
moving of an existing application to a new operating system or to
a new machine, translating code from one programming language to
another, or putting a new interface on an existing code.
Dr. Davis
asserted that these projects, although difficult and challenging
and
requiring
considerable
time,
effort,
and
skill,
are
not
research but merely the typical part of any development effort.
Further, Dr. Davis maintained that although routine software
development
often
involves
uncertainty,
trial
and
error,
and
experimentation, such factors do not convert the projects into
49
Dr. Davis defined technical risk in his initial report
as arising "when we don't know whether it's possible to
accomplish the task in the current state of the art." However,
at trial, Dr. Davis amended his definition by stating that
technical risk can arise due to constraints in, for example, the
type of hardware used or the resources available. In this
regard, once again Dr. Davis suggested that technical risk, like
his definition of research, was a matter of degree.
50
As an analogy, Dr. Davis referred to the building of a
skyscraper which, although a large and difficult task, involves
the application of known methodologies and skilled practice.
- 91 research efforts.
He stated that within the computer science
community there is general agreement as to the basic elements of
the routine software development process:
specification,
design,
implementation,
Problem definition and
integration
and
system
testing, installation and field testing, and maintenance.
The
development involves a constant, cyclical process of designing,
testing, and modifying.51
Finally, Dr. Davis claimed that failure in the software
development process is usually not attributable to technical risk,
but is more often due to people and project management concerns.52
Additionally, he insisted that Norwest's use of the SDM was meant
to minimize risk because Norwest was developing "mission-critical"
software where it could ill afford to redesign a system late in the
development
process.
Dr.
Davis
conceded,
however,
that
the
activities generally appeared to provide a new or improved business
function.
51
Dr. Davis testified that in the early stages of
development, the modification efforts are generally characterized
as redesigning, while in the later stages, as the development
approaches production, the efforts are generally characterized as
debugging.
52
Dr. Davis stated that as much as 30 percent of all
software projects fail or are canceled before completion.
- 92 ii.
The Tower Group53
Respondent's other expert was Diogo Teixeira, president of the
Tower
Group,
a
research
and
consulting
firm
specializing
information technology in the financial services industry.
Teixeira
is
widely
published
on
issues
involving
in
Mr.
software
applications in the banking industry. He lacks formal education or
training in computer science or software development, or research
in either of those fields.
The Tower Group report, although not specifically concluding
that the eight sample internal use software activities failed to
qualify for the R&E credit, found that Norwest did not develop any
technology that was not within the then-current state of the art of
the banking industry.
The Tower Group summarized its findings as
follows:
It is our opinion, based on the documentation submitted
by the petitioner and on our knowledge of the US banking
industry, that the work performed by Norwest was the
normal and routine data processing activities of a bank.
The software produced by Norwest, in terms of the
products and services provided and the technology used to
support them, were all well within the then current state
of the industry. We find no characteristics which would
distinguish the overall work performed by Norwest within
the claim from the nearly $17.5 billion spent by US
53
Before trial, petitioner sought to disqualify Diogo
Teixeira and the Tower Group from serving as an expert witness at
trial because of a prior relationship between the Tower Group and
Norwest. After hearing arguments at trial and, upon due
consideration, we denied petitioner's motion for reasons
expressed on the record.
Mr. Teixeira was assisted in the preparation of the Tower
Group report by George T. Kivel, the group director of Wholesale
Banking and General Technologies.
- 93 commercial banking industry between 1986 and 1991 on
routine data processing implementation. Norwest, as a
result of the work performed within the claim, developed
no approaches or components that were conceptually or
fundamentally different from those already in use within
the banking industry.
In its report, the Tower Group stated that nothing Norwest
developed
could
be
considered
unique
possessed the necessary information.54
because
Norwest
already
The Tower Group report also
stated that three factors determine whether a banking software
application is unique:
Product (e.g., checking account, credit
card), channel (e.g., bank branch, ATM), and volume.
Mr. Teixeira
asserted that Norwest did not offer any products or services that
were unavailable
transactions
was
in
the
banking
typical
of
industry,
and
banks
Norwest's
of
the
volume
of
size.55
Consequently, Mr. Teixeira insisted that Norwest had numerous
sources from which it could learn about software applications, and
that any uncertainties Norwest faced were unique to it but not to
the banking industry.56
54
According to Mr. Teixeira, the sources of this
information are vendors, consultants, conferences, and
newsletters.
55
Mr. Teixeira stated that Norwest was never a top 15
bank (in terms of asset value) but fluctuated between 17th and
33d. Banks such as Citibank, Chase Manhattan, Wells Fargo, and
Security Pacific were all two to three times larger than Norwest.
Citibank had total assets of approximately $220 billion in 1991,
while Norwest's total assets reached approximately $40 billion in
1991. In this regard, Norwest's transactional volumes never
reached the levels of the larger banks'.
56
Mr. Teixeira opined that, on the basis of the channels,
(continued...)
- 94 Mr. Teixeira characterized the nature of Norwest's work as the
automation of processes that previously were performed manually.
In
this regard,
he
claimed
that
Norwest's
work
was
oriented
primarily toward routine maintenance (correcting problems with
existing
applications),
enhancement
(adding
new
features
to
existing applications), and the implementation (deploying) of those
projects, but it was not research and experimentation.57
Further,
Mr.
Software
Teixeira
emphasized
that
Norwest's
use
of
the
Development Methodology was designed to limit risk and prevent the
undertaking
of
any
implementation
projects
with
significant
uncertainty.58
56
(...continued)
products, and volumes supported within the banking industry at
the time, no significant technical risk existed in the eight
sample activities. He found that after Norwest investigated its
needs and the information available to it, the only risk that
remained related to business and ability to execute; but no
technical risk existed. He also indicated that generally even
where technical risk exists in a bank technology project and
causes its failure, the failure is usually attributable to the
cost of correcting the problem--not the ability to correct it.
Thus, the solution is often the purchase of more expensive
technology.
Further, Mr. Teixeira described Norwest as a conservative
user of technology that generally spent its time attempting to
catch up to the technology already deployed by other U.S. banks.
57
Mr. Teixeira believed that Norwest's expenditures on
maintenance and enhancement projects generally reflected industry
trends.
58
Mr. Teixeira contended that he "[found] no evidence
that technical risk was factored into the [return on investment]
calculation of the projects claimed indicating that the
expectation that it would impact delivery of the project was
minimal."
(continued...)
- 95 Mr.
Teixeira
maintained
that
Norwest
did
not
engage
in
research and experimentation because "At all times after the design
phase, Norwest was working with just one option--not a set of
alternatives."
technology
Mr. Teixeira identified two main attributes of
research
deliverable"
and
the
in
the
banking
"project
industry:59
approach".
The
According
"primary
to
Mr.
Teixeira, the primary deliverable in technology research in the
banking industry is information which helps make decisions about
other information technology projects rather than a production
system. He further stated that the project approach60 in technology
58
(...continued)
Further, through his understanding of the Software
Development Methodology, Mr. Teixeira claimed that most risk
would be resolved before the logical design phase (the business
requirements phase), which is where only 20 to 30 percent of all
expenditures in information technology projects occur in average
U.S. banks. Mr. Teixeira asserted that very little of the work
prior to the logical design phase involved research or
experimentation.
59
Mr. Teixeira noted that many top U.S. banks fund a
technology research entity within their information technology
organization for the purpose of "understanding when a technology
is sufficiently mature for use within the bank and working with
the lines of business to determine where the technology may be
deployed effectively". These research groups account for less
than one-half of 1 percent of the total information technology
organization's budget, and even less at a bank of Norwest's size.
Given these percentages, Mr. Teixeira projected that Norwest's
expenditures for research and advanced development were over 50
times greater than he would have expected from an entity of its
size.
60
The technology research project approach has a pattern
of: (1) Posing a question (stating what information the project
is trying to determine); (2) performing targeted work (e.g.,
model, prototype, or literature review aimed at resolving the
(continued...)
- 96 research in the banking industry involves identifying the critical
elements and capabilities of the technology under study and then
modeling them in context.
In the case of Norwest, Mr. Teixeira
found that the work was intended to deploy a production system, not
to provide information or identify the elements of technology.
Mr. Teixeira distinguished experimentation from the testing
performed by Norwest.
He asserted that experimentation addresses
the issue of how to achieve a goal, whereas testing shows whether
the goal has been reached.
In this regard, he stated that most
banks perform feasibility experiments which ask the question "can
it be done at all?".
However, at trial, Mr. Teixeira testified
that these experiments also involved questions of whether the goal
can
be
achieved
given
certain
constraints
in
the
business
environment.
Finally, Mr. Teixeira attributed much of the inability of
Norwest to complete its projects on time and within budget to
management issues, not technical difficulties or risk.
He defined
technical risk as the probability that the chosen technological
architecture
combined
with
the
user's
determined
functions, and volumes would not go into production.
features,
He believed,
that on a percentage basis a 10- to 20-percent chance of failure
would constitute technical risk.
60
And with respect to Norwest's
(...continued)
question); and (3) applying the resulting information to other
projects (e.g., to implement or not).
- 97 projects, he found the technical risk very low; however, he did not
determine any specific percentage in his analysis.
Mr. Teixeira
conceded that all of the activities at issue provided a new or
improved business function to Norwest, although not to the banking
industry.
7.
Analysis of the Eight Sample Activities
The parties' experts aided the Court in understanding research
in the context of the computer science field and the banking
industry.
We did not find any one of the experts more helpful than
another.
Mr.
Teixeira
assisted
the
Court
by
explaining
the
existing state of technology in the computer science field as
related to the banking industry.
Drs. McDermott and Davis offered
particular insight into software development issues, although they
were often abstract or vague.
Unfortunately, with respect to all
of the experts, much of their reports and testimony was of limited
use
because
they
applied
definitions
and
standards
that
are
inconsistent with our interpretation of the seven tests that must
be satisfied to obtain the R&E credit.61
61
See Alumax, Inc. v.
There were several problems with the definitions
provided by each of the experts. For example, Dr. McDermott
appears to apply a 20-percent test to the definition of
substantial uncertainty--which we have rejected for the reasons
expressed. Additionally, his example of a hypothesis, as in the
case of the SBS project, is overly simple and not workable: "This
collection of algorithms, run on such-and-such a hardware
configuration, can perform such-and-such an account-management
task with no errors, in such-and-such a period of time." This
hypothesis cannot be used to develop true alternatives which can
be examined and considered by the taxpayer.
(continued...)
- 98 Commissioner,
109
T.C.
133,
171-172
(1997);
Phi
Delta
Theta
Fraternity v. Commissioner, 90 T.C. 1033, 1041 (1988), affd. 887
F.2d 1302 (6th Cir. 1989).
Thus, while we will rely on the
experts' technical findings, we will generally discount their
conclusions with respect to the seven tests.
A.
Strategic Banking System
Petitioner's expert, Dr. McDermott, contended that at the time
SBS, the integrated banking system, was developed, no existing
product could have accomplished the increase in data processing
capability Norwest required.
He insisted that SBS was subject to
several uncertainties, particularly those relating to time and
space complexity, software engineering, and user-friendliness.
He
concluded that "The painful complexities and ultimate failure of
SBS ought to be evidence that there was significant risk due to
61
(...continued)
Dr. Davis' definitions were too academic and did not conform
to the language used by Congress. For example, he stated that
"discovery" is the result of an experimental or laboratory
effort, which he defined as "the creation of an isolated
situation intended to mimic the real world in some respects, but
tightly controlled in all other respects." We recognize that Dr.
Davis was attempting to explain his understanding of research and
experimentation as understood in the computer science community-but in reaching judicial decisions the definitions used by
Congress are controlling.
Mr. Teixeira and the Tower Group, as well as Dr. Davis, also
assumed that the ultimate goal in research is information rather
than a product. This is inconsistent with the language of sec.
41, which clearly permits the ultimate goal to be a product.
Also, both of respondent's experts used definitions of
innovativeness that, although more familiar to us, are not
consistent with the language used by Congress in the conference
report accompanying the TRA 1986 on the innovativeness test.
- 99 technological
uncertainty."
This
conclusion,
Dr.
McDermott
claimed, is bolstered by a statement of Brian Phillips, former
president of NTS, that SBS had a 50-percent chance of failure at
the outset of the project.
Dr. Davis stated that the SBS project was within the thencurrent state of the art and asserted that any uncertainties could
be eliminated through information that was reasonably available to
Norwest.
Further, he claimed that any risks that existed during
the project were attributable to business risk, not technical risk,
despite the large-scale nature of the project.
Mr. Teixeira, in the Tower Group report, contended that the
SBS customer module was first implemented by GMAC, a division of
General Motors, in 1990, and involved nearly five times as many
accounts.
He further explained that the failure of SBS was due to
continual changes in the banking industry and the growth of banks
such as Norwest and Bank One and was not due to technical risks.
Mr. Teixeira attributed innovative qualities in the SBS project to
the building of the customer module as the centerpiece of an
integrated banking system and the use of the PACBASE development
environment.
A July 1993 Tower Group report was more generous in
describing the SBS project, noting it as a "monumental effort * *
* based on providing a bank with state of the art technology".
The
July 1993 report also stated that the customer module had the
ability to contain up to 12,000 pieces of data, or six times more
than any other system available.
- 100 In both the Davis and Teixeira reports, it appears that
respondent's
experts
found
that
Norwest
was
not
engaged
in
qualified research in the SBS project because the majority of the
work was performed by EDS.
was
not
performing
This is only relevant, however, if EDS
contract
research
on
behalf
of
Norwest.
Respondent contends that EDS did not perform contract research.
We find that together Norwest and EDS engaged in qualified
research in the SBS project with respect to the customer module.
See sec. 1.41-2(e)(5), Examples (5) and (6), Income Tax Regs.
(allowing R&E credit where in-house and contract research are
performed together).62
In making this finding, we are influenced
by the writings of respondent's expert, the Tower Group, which were
prepared before its involvement in this case and are a part of the
record.
The
SBS
project
was
a
massive
effort
at
developing
an
integrated banking system that could interact with several other
systems and handle a tremendous volume of data.
Although some
integrated systems existed in 1986 (about 25 percent of the top 100
U.S. banks had such systems according to Mr. Teixeira), none of
them could handle the volume of data in the SBS system, nor were
they customer based (rather, they were product or account based).
62
Although petitioner claimed that it was a "development
partner" with EDS in the development of the SBS system, neither
petitioner nor respondent suggests that Norwest and EDS were
engaged in a partnership that would implicate the rules under
sec. 1.41-2(a)(4), Income Tax Regs.
- 101 The Tower Group expected that the customer-centric module of SBS
would become the "core foundation around which a bank can integrate
all of its customer information".
The development of the deposit and credit modules, however,
does not constitute qualified research.
The record is void of any
testimony or evidence (other than reports dated after 1991, after
the timeframe in issue) from which we can evaluate the nature of
the work performed on the deposit and credit modules.
We note
however Mr. Teixeira's indication that the deposit and credit
modules provided "no significant functional innovations to the
industry".
The SBS customer module project involved the discovery of
information
which
was
technological
in
nature
and
expanded
principles of computer science--namely, the ability to create a
customer-based system that could integrate with other banking
systems and handle large volumes of data.
In this regard, we note
that qualified research for purposes of section 41 is not limited
to the development of new technology but also encompasses the use
of existing technology in new and dynamic ways.
There is no doubt that SBS provided a new or improved business
component of Norwest in terms of customer service and growth
opportunities.
The Tower Group described the GMAC customer module
system as providing "quicker, more efficient underwriting, and a
faster, accurate understanding of changes in automobile purchase
behavior".
The sheer volume capacity of SBS, as compared with the
- 102 preexisting banking systems, resulted in a new or improved business
component at Norwest.
The SBS project went through a process of experimentation.
EDS, Bank One, and Norwest personnel met regularly to review and
critique the EDS technical development of SBS and recommend changes
to
the
system's
design.
Specific
concerns
were
raised,
for
example, with respect to the volume capacity of the database
system, DB2, which was one of the critical elements of SBS.
In
addition, concerns were expressed as to the user architecture and
the use
of
the
PACBASE
tool.
Alternatives
were
proposed
and
discussed for each of these concerns (although apparently not
adopted by EDS).
These alternative suggestions, together with Mr.
Phillips' claim (to Dr. McDermott) of a 50-percent chance of
failure of the SBS project, buttress a finding that there was
uncertainty at the outset of the SBS project.
through
data
Other issues
concerning
functionality,
modeling,
were
also
discussed.
These issues and others were tested extensively at
Norwest with respect to the customer module over a 3-year period,
resulting in the discovery of hundreds of problems, some of which
were attributable to poor technical design and others to poor
programming of the source code.
This process of developing,
reviewing, testing, and analyzing the various approaches proposed
by EDS constituted at least 80 percent of the development of the
SBS system and satisfies the formal standards of experimentation
sought by Congress.
- 103 In concluding that the process of experimentation test is
satisfied, we believe the activities in the development of the SBS
system should be examined in toto, rather than separately.
activities
were
interdependent
and
built
on
each
The
other.
Separately, the activities were of no utility.
The SBS system was an innovative effort that had the potential
to
result
in
substantial
benefit to Norwest.
efficiency
and
significant
economic
McKinsey & Co., Inc. (McKinsey), which was
hired by EDS to conduct a valuation of the SBS system for Norwest
in September 1987, found that SBS would provide better crossselling of products to customers, improved relationship pricing,
and the completion of backlogged development projects.
McKinsey
concluded that these improvements would result in an increase in
pretax profits for Norwest of approximately $24 million for its
retail banking business.
Further, it was believed that Norwest
would save approximately $6 million in data processing expenses as
a
result
of
the
use
of
fourth-generation
integration, and business model design.
technology
tools,
Finally, another $1
million in pretax savings would result from better collection
procedures and personnel productivity.
The McKinsey report stated
that "the system's major value will be allowing banks to develop
innovative products and target their customers more effectively.
Maximizing these capabilities gives a participating bank a clear
advantage over its bank and `near bank' competitors."
M
This text is long and has been trimmed here. Open the source document for the complete record.
This is a copy of a public record, reproduced as it was published. It is not legal advice, and it may not be the version a court would rely on. Check the official source before you cite it.