FIRST THERE WAS YAHOO GROUPS

This is the first of at least two posts on designing communication and workflow infrastructure for multi-organizational project teams.  Here I’ll speak to the general features needed.  In the next post[s] I’ll focus on how to do a system “audit” of what is available in a particular setting and the roles of adoption/implementation for both the technology and the team practices.

How will this discussion differ from project management applications?  Project management systems (Basecamp being one that gets solid reviews) are a commitment to a particular system, and at least one of the users must be footing the bill.  The licensing has improved in that, using Basecamp as an example, they allow unlimited clients/users and bill by the project, apparently without limitations as to organizational boundaries.  (In the old days, many of these systems were “site” licenses and so not appropriate for multi-organizational teams.)

How does this go beyond my earlier posts on visualization for teams?  There the focus was more on team member activities, here it is more on organizing the work, with team member activities as a part of that.  While this style of project management is a start towards full-blown visualization, I think we still have some distance to go to provide full visualization to virtual groups (e.g., anticipation of availability as discussed by Begole and Tang at Sun Labs.

Now we have the ability to design our own tools.  Both Google Sites and Facebook provide a “lego” style capability of clicking together electronic file cabinets, pages of links, discussion forums, and applications/widgets to suit your team’s needs.  Yes, both of these systems are in their infancy when it comes to being full-fledged enterprise-ready platforms (see 2007 discussion of why Facebook isn’t ready for business users) but they give us the ability to design on the fly and adapt the systems as the groups and tasks evolve. 

Last week I built a prototype Google Sites platform for SCU’s Technology Entrepreneurship programs.  I spent 45 minutes talking with the leadership for the program, colleagues who will be teaching in the program, and administrators who work with students like those in the program.  We thought hard about building the first prototype on Facebook given its high level of adoption among the students.  However, the low level of adoption among faculty, and our limited understanding of its possible document and project management capabilities pushed us to Google for this first design.

It then took me 2.5 hours to build the initial site.  This included backtracking when I realized that I would need to build a separate “Site” for each program to manage the permissions such that some materials are available only to the specific program (e.g., the Fall 2008 group, the Winter 2009 group).  This is either a weakness in the Google Sites feature set, or in my conceptual understanding of what a “Site” should be.  Initially, I designed a single “Site” for the Technology Entrepreneurship overall program.  The idea was that access could be “provisioned” such that general materials would be available to all participants and faculty, but that specific readings, discussion forums, etc. would be available to only the individuals in a single program.  Instead, it seems that each program needs to have its own “Site,” those these sites can be linked via URLs.  Thus my backtrack.  I had to disassemble the overarching structure and put the separate parts into separate Sites.  What I have yet to formally test is whether there is a “single sign-on” capability such that once you have logged-in, you are in to all “Sites” in your “My Sites” section.  If so, the process of moving from one Site to another should work just as well as if there were a single Site with webpages provisioned to the individual user.  (Downside is that the Site map obviously only maps the single Site – so the overall architecture may need to be explained to the users – or we may need to draw our own general site map that covers the linked Sites. 

I’ll stop here and ask for advice. This prototype provides the ability for password protection, social networking, filesharing, discussion forums, calendaring, and announcements. Are there missing features that multi-organizational project teams are likely to need?

Footnote to the Title: Yes, I know Yahoo Groups was a later addition to the party that is “computer supported cooperative work,” but Yahoo Groups was the first major free tool I saw with mass adoption in the MBA student ranks.  These students often had access to more powerful systems at work (e.g., Lotus Notes), but they couldn’t use them with outsiders.  The students also had access to purpose-built systems provided by the university (in our case, Prometheus and now Angel).  However, the students never took to these systems in the way they did to Yahoo Groups (also possibly because each faculty member could configure the system differently, sometimes even turning off the ability for students to provide attachments or to start their own discussion threads).  Yes, Yahoo Groups went down one day when final papers were due, but the students soldiered on.