Indiana Oncourse Priorities Committee

As I hinted at in my last blog post, Indiana University established a development planning process for Sakai that I think is fairly interesting. Their instance of Sakai is called “Oncourse” and gets extensive use on campus. Of course, even with the talented team IU has, they can’t do everything their users want. So they’ve put into place the “Oncourse Priorities Committee” with works with the development organization to decide how resources will be deployed. The OPC is headed by Stacey Morrone, Associate Dean of Teaching and Learning Information Technologies.

The overall process is documented on the IU website, but essentially this is a group of faculty and faculty support resources who meet occasionally to decide what projects the IU team will work on. The input to this meeting is a list of potential projects, each of which has an approximate cost expressed in terms of effort hours. This list is developed by a related group called the Functional Requirements Committee, headed by David Goodrum, Director of the Teaching and Learning Centers. The FRC takes suggestions via an on-line form, cluster related issues into meaningful groups, clarify the requirements and then estimate the effort hours that it will take to tackle them.

This works extremely well for them. The user community (OPC) gets insight into the real trade-offs involved in the development process and the development group gets real feedback on what is most important to work on. It’s a really nice example and one I encourage you to explore on your campus.

Stacey was kind enough to set up an ad hoc meeting of the OPC while I was visiting IU. I was surprised by the number of folks who took time out of their very busy schedule (first week of classes!) to spend about 90 minutes talking to me. We spoke about many things including quality assurance. One of the interesting topics, though, was whether their process allowed them to thing about long-term, large-scale changes to how Sakai works. Although I may be oversimplifying a bit, I think they agreed that their process isn’t really designed to do that. It’s very good at improving things that the software currently can do, it doesn’t really have a mechanism for imagining a completely different thing the software could do.

I’m beginning to think about a mechanism like this for “generic Sakai” that would operate across the community and result in a more clearly expressed and longer-term roadmap for Sakai. The existing requirements process doesn’t really do that (it did do useful things, but not what I expected it to). I’ll be writing up my thoughts later this week. Please let me know what you think…..

One Response

  1. […] Status Update Jump to Comments David Goodrum asked me to provide an update to the Oncourse Priorities Committee [1] regarding the progress made towards Sakai 2->3 integration and migration. In doing so, it […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: