Case Study III-4 • The Kuali Financial System: An Open-Source Project 465Meeting deadlines builds credibility with the
users, and the developers get a feeling of accomplish-
ment. Deadlines also encourage progress. You do not
have the luxury of spending endless amounts of time
debating this or that feature. You make a decision
that will work and move on. If it turns out to be a bad
decision, you can change it later. Deadlines help you
avoid “analysis paralysis” and get the software in
front of the users. This type of iterative process has
been a successful model for us here at IU.There are lots of challenges for the manager of a
project like this one. Thomas describes some of the diffi-
culties he faced as project manager:It is hard enough to manage people right here in the
same building. Despite the challenges of managing a
large group of developers, with those located here at
least I can go down the hall and talk to them and see
how things are going. When managing a team of
developers located in different time zones throughout
the country, you can probably multiply the difficulty
by about 50. There are logistical issues with schedul-
ing meetings. They are probably used to doing things
a bit differently than we are in their shops back home.
We do not know each other very well. This presents
some challenges when trying to keep them motivated
and productive on the project.
We have our own style and culture here at
Indiana that may be different from the way they
work at Cornell or Hawaii or Arizona or the other
schools involved. The way we approach systems
development may vary from institution to institution.
The way we manage our project plans may be differ-
ent. The way we communicate assigned tasks may
be different. The way we motivate may be different.
It is a challenge to work through these differences
when managing developer resources from many dif-
ferent schools. Our managers had to find ways to
connect with each of their developers and identify
the most effective approach for communicating task
assignments, monitoring progress, and providing
feedback. What works for one developer may not
work for another. This is true with developers at the
same institution but becomes even more noticeable
with developers at different institutions.
Another challenge is that I managed a project
differently than what some of the Kuali developers
were accustomed to. These differences in terms of
management style, communication, and organiza-
tional culture can create problems. The developers
had to learn what I expected of them. I had to learna consistent development methodology and standards,
this was not a major problem.
In a virtual organization good communication
is critical. We used mail lists, teleconferencing, and a
lot of videoconferencing. We also used Atlassian’s
Confluence for collaboration and JIRA for task track-
ing. Confluence is a place where we put documents
so that people could share and jointly edit them. You
put documents there and you can share them with a
group of people who can make comments and contri-
butions. This was all done online and avoided having
to track long e-mail threads around a particular docu-
ment or discussion. JIRA is a task-tracking system.
When I had a task that needed to get done, I created
an issue and assigned it to a developer. The develop-
ers went into JIRA to see what tasks were assigned to
them. The Development Manager can put due dates
and priorities on tasks and categorize them by mod-
ule. These have been useful productivity tools in
managing the day-to-day operations of the project.
With people spread out so widely, face-to-face
interaction together in one place is very important.
Getting the development teams together in a room
for a week or two at a time is really critical. I don’t
think this project could have been successful without
doing that. Face time establishes relationships and
builds trust. Trust is critical. If teams go too long
without that sort of personal contact, trust and com-
munication start to break down a little bit. That can
be really problematic. Getting together and estab-
lishing and maintaining those relationships, that
trust, simply getting to know each other on a per-
sonal level, are really important things to do. This is
what makes it truly “community source”. We always
realized the benefits of these gatherings.
We were deadline-driven. Deadlines give you
targets to shoot for to get things done. The initial
product won’t be perfect. However, it will be good
quality and it will perform the required functionality
reliably. We will always have time to refine things
and make them better in the future. You can pretty
much guarantee that users are going to want some
changes anyway after they begin using the system.
Our strategy was to get something out in front of the
users as soon as possible. They will tell you if it is not
what they expected. Getting that feedback sooner
rather than later makes the software better. The users
are a part of the design and development process
throughout the life of the software. In that sense, it
becomes THEIR software. They will like it much
better. We will continuously improve the system over
its lifetime.