UBLLessonsLearned

Observations, Findings, Thoughts, Comments & Suggestions

 * Some thoughts from PeterYim (2004.04.12_18:50 PDT)
 * we do need a team structure - at least a temporary hierarchy (e.g. team leadership, team members with defined roles, ... etc.)
 * some funding would have helped (which we did not have)
 * rather than trying to turn all participants into ontologists, we should take inventory on what each participant can and would like to contribute, pool those resources, and develop the project accordingly (leverage on those, and source what's missing)
 * starting with something less grandiose, and then bootstrap from it
 * need better teamwork, and a way to break logjams


 * From Adam Pease (April 12, 2004 9:49 pm PDT)
 * It comes down to effort. We need doers, not observers.  True, not everyone can become a good ontologist, just as everyone doesn't have the aptitude to be a programmer or baseball player, but most people can learn at least passable skills, given that we all have some IT or business background.
 * If the will is there, we can succeed. Maybe what we need is a "signup" sheet.  1/2 hour a week per person of actual work (as opposed to telecon discussion) could be enough to let the group make progress.  People not willing to make that investment shouldn't be part of the group.  I think this would be reasonable for an unfunded effort.  Many folks have attended the telecons at one time or another.  If you've learned something, or listening in has helped in some way, maybe it's time to give something back?  The good news is by giving some time to trying to build an ontology, you'll learn something, and get even more out of participating.


 * Bob Smith's observations (April 13, 2004 9:59 am PDT)
 * I agree with both Peter and Adam's ideas about a need for a team structure and a time committment of at least 1/2 hour to an hour of "production" per week.
 * use the easy editing features of this web
 * develop a format for the Invoice or similar project
 * use some mentoring to provide direct and scheduled feedback


 * Kurt Conrad (2004.04.14 09:48
 * From my perspective, the main strengths of the project are:
 * A diverse set of participants that bring subject matter expertise in the areas of UBL and business processes; formal, informal, and "Big O" ontologies
 * A demonstrated, long-term committment of a core team to participate and contribute to the effort (especially as demonstrated by the willingness of individuals to travel from out of the area to attend the face-to-face)
 * Due to loose objectives and performance requirements, the project has seemed to avoid perceptions of project failure (especially with respect to the OASIS UBL committee)
 * Web-based and telecommunications infrastructure appears to be an effective platform for mediating group communications
 * The following weaknesses are noted:
 * Project launch was inadequate. No attention was given, up-front, to defining objectives and requirements.  The resulting, expected misalignments in participants expectations exhibited itself in a variety of ways throughout the project.
 * The lack of a project manager (traditional project management duties were split amongst an informal group of participants).
 * Relied on an incomplete methodology. Critical aspects of the work process were not worked out, refined, and approved in an explicit fashion.
 * A number of key decisions were driven and concurred with without the majority of the participants having an appreciation of the behavioral and technical implications.
 * A majority of the participants lack the critical technical skills necessary to contribute to the community's collective decisions. This skill gap also limits their ability to participate effectively within the limits of the time that they can volunteer to this effort.
 * The resulting work processes were not reflective of or well-suited to exploiting the skill base and dynamics of the volunteer resource base which has made itself available to this effort.
 * Participants skills were not adequately augmented with effective training programs. (Looking forward, some of these training needs could be mitigated by the adoption of a more structured knowledge collection process that guides the analysis and formalization process.)


 * Pat Cassidy (2004.04.15)


 * I think that we need to:
 * rethink and carefully specify what we intend to accomplish, with more specifics.
 * consider how we can do that, in view of the results thus far
 * each participant should specify what they believe they can contribute to the process, and give an estimate of the time that they can spare for off-line work beyond the teleconferencing
 * based on time estimates, the project managers should suggest specific objectives
 * we should have a monthly review of results versus the objectives
 * we should have a monthly review of results versus the objectives