built using a tool called UNIFACE. At the time the
FIS was developed, UNIFACE was a very advanced
development tool. However, the KFS enterprise
applications were written in Java Web technology so
from a technical standpoint it was completely new.
We were leveraging the intellectual property within
the old FIS so we knew how the system should work.
We just needed to create it in the new toolset. We
took a document, maybe a Disbursement Voucher,
and all the rules and everything behind it, and we cre-
ated that same document in a Web-based system. The
user interface changed because it is Web-based, but
there are some things that are consistent. The way the
screen is organized is very similar. However, because
of differences between the Web technology and
client/server technology it looks a little bit different.
Going from client/server to the Web presented
some challenges. Client/server is a very responsive
and rich interface. There are things that you can do
which are very difficult with Web-based applica-
tions. The Web is more limited in what you can do in
the user interface because of technological limita-
tions and browser differences. Something that is
really nice and slick that works on Internet Explorer
may not work in Firefox or Safari. So there were
some challenges with the Web, but we worked
through the major user interface problems.
We tried to stay open in terms of the technolo-
gies that we used to avoid major dependencies on
vended software and tools. For example, we ran on an
Oracle database in our development and test environ-
ments. However, we built the system so that someone
can use another database system if they wish. In fact,
in order to provide a pure open-source stack, we test-
ed the code on MySQL, an open-source DBMS. This
allows schools who cannot afford Oracle licenses to
run on MySQL and avoid the Oracle licensing costs.
We are “modular” in that our components are
not tightly integrated. We did not want to require
schools to use the whole ball of wax or nothing. For
example, if you have your own purchasing system
but want to use our Chart of Accounts and General
Ledger, it will be loosely coupled. There will be work
involved to interface your purchasing system with the
KFS module, but it will be limited to the interfaces
between the two modules as opposed to having to
rewrite major components. That said, we also had
some pretty aggressive deadlines. True modularity
takes a lot of time to design and develop. Therefore,
there are places in terms of modularity where we can
do better in the future. To make it the ultimately flex-
ible system takes a lot of time that we didn’t have.464 Part III • Acquiring Information Systems
Managing the Project
Project Manager Jim Thomas was located at Indiana
University-Bloomington, but his Kuali staff of 32 develop-
ers was spread out over at least a dozen locations. The
Mellon grant to Kuali funded a few employees located at IU
and other places, but most of the developers were employ-
ees of and were paid by their own institutions. Some of them
were so valuable that their institutions could not spare them
full-time, so they were only part-time with Kuali. Thomas
managed an organization that was virtual in every aspect.
To complete a project of this size and complexity on
time and on budget has always been a challenge. Doing it
successfully with a virtual organization where the developers
are employed by seven different higher education institutions
spread over five time zones was exceptionally challenging.
Thomas explains how the development process was
organized:We broke the project into modules and had a develop-
ment team for each module. In the first phase, we
worked on the core set of modules with teams for
Chart of Accounts, General Ledger, and Financial
eDocs. Each team had a Development Manager who
managed a team of three to seven developers. I worked
with the Development Managers with the project
plans. The Functional Council decided the scope of
the things that needed to get done based on the devel-
opment team’s time estimates and available resources.
The Development Managers assigned tasks to their
team members and then monitored progress. Some of
the Development Managers were located at IU, but
others were at other institutions. The developers on
each team were scattered at many different locations.
That presented a challenge. Initially, we wanted
each school to have expertise about the whole system.
Rather than having all the developers at a particular
location work on the same module, we assigned them
to different teams. This helped give each institution a
set of developers with a broader understanding of the
whole system. The scope of this project and different
ways in which people manage projects made this diffi-
cult. So, while it was a good idea from the perspective
of broadening knowledge across institutions, it was not
a good idea from the perspective of productivity.
I found that it is good to leverage the fact that people
are located together, in some cases sitting right next to
each other. I found that if developers were located at
the same institutions, we should try to assign them to
the same team when possible. That would help in
terms of productivity and communication. The trade-
off is that their institution’s technical expertise on the
application may be somewhat narrow. Because we had