Conference Presentation

Owned by Former user (Deleted)
Last updated: Dec 03, 2006Version comment
2 min read

A Simple History

Background

  • Some of our hopes for Sakai collaborations
  • Efficiencies for few development resources

The Requirements

  • Timed Release
  • Reordering

The Players and Roles

  • Jim Eng (project lead)
  • UNISA (Usability Design and QA)
  • Whitman College (Design Mockups and Development)
  • Boston University (Design and QA)

Coming out of the Requirements Process

  • the ranking of our requirements mattered little - we just needed these things
  • the articulation of these requirements helped little - we had to
    rework that anyway, once we got down to brass tacks
  • however, we may not have come together in quite the same way otherwise
  • it did make it easier for us to talk about what we were doing
  • it did make it easier to approach Jim with what we wanted to do

Preparatory Work

  • early email discussions
  • Jim put some DB work into 2.2.0 release in preparation for us needing it
  • Chuck helped make the connection with Jim, and an initial meeting at Sakai conference

The Impact of the Community

  • a lot of input early on, during the design phases
  • some concerns about overlapping work
  • some concerns about resources "bloat"

Where it succeeded:

  • requirements met, on time
  • a design-centered process
  • extra functionality QAed and deployed outside the release cycle
  • broad-based input and contributions
  • work conducted transparently
  • collateral communication (things we learned from each other that
    were not specific to this project)

Where it could have done better:

  • broadening resources technical skill (Jim still did all the
    Sakai-centric work)
    • taking some of the development burden off of Jim
  • didn't cement (at least not practically) a long-term investment or
    productivity
  • clarity: who was making decisions, when and how (some time wasted here)
  • communicating ourselves to the community (we were heads-down towards the end)

Risk Management

(or what made it bearable)

  • start early: preparatory engagement with project lead
  • get clear about commitments
  • partner with those under similar pressures
  • focused attention on QA, test plans
  • extra attention from developer(s) when it counts
  • a practical aim, well-defined goals

Lessons Learned

  • don't just think about development resources
    • design + mockups, refine requirements, QA, planning and coordination
  • there are limits to how much community approval can be sought and
    accommodated
  • understand what people are getting out of it: negotiate a useful exchange
  • making use of the wiki as a record, keeping us on the same page,
    and communication
  • don't force the project lead to do all the coordination
  • start early, think about Sakai's release cycle, and how this can
    leverage the broader process

Choosing the Right Project

  • find a tool you have a long-term interest in (understand what your
    users want and need)
  • an area of Sakai that you want to develop an expertise with, and
    be responsive with
  • a project lead you can work with
  • local requirements that are not otherwise being met by other teams
  • find a project of a suitable scope and kind for the resources you can commit
  • developing it for broader use makes others more willing to contribute
  • understand the incentives and limitations of your collaborators