Technology and Organizations

In September I posted about forest firefighters using portals (my definition of portal: one-stop web shopping for information and/or working space on a project or topic – often updated from multiple sources).  In October, Wired’s Damon Tabor wrote about the LAFD’s 23-year veteran Brian Humphrey – calling him a one-man geek squad. 

The article talks about how Firefighter Humphrey is building resources for the LAFD and the public using Twitter (microblogging, see related posts here & here), Yahoo Pipes 
(free data aggregating tool – you can build a custom pipe, or subscribe to ones built by others), mobile alerts 
(subscription to get messages on your mobile phone when something happens), and map mashups (they already use a Google Maps mashup, he wants to link to more detailed info like USGS topographical maps.)  LAFD’s portal.  LAist article with even more examples of LAFD’s efforts.

Clearly real-time data is crucial for firefighters.  But given all the firefighting I hear about in business organizations, perhaps there is something to be learned here.  What data could you be accessing, mashing up, aggregating, or just tapping into that would enhance your work?  Situational awareness has to be balanced against information overload, but if done well may support immersive performance.  Always looking for examples…  

…“I’m working on the Acme revision” …versus microblogging, say, at a party: “I’m so drunk.” Microblogging is blogging, but posts are limited in length (say 140 characters). Twitter is one of the most famous microblogging platforms. The key question for me is whether (and how), microblogging can help with coordination at work. In prior posts I’ve discussed the value of situational awareness amongst team members and the possible value of Twitter, but there hasn’t been a serious push for microblogging in work organizations – until recently.

Claire Cain Miller’s article in the WSJ Business Innovation Technology Society (BITS) section focuses on Yammer and the possible value of microblogging in organizations. Yammer is similar but different from Twitter in that Yammer’s key questions are “What’s happening at your company?,” “What’s happening on the project” versus the less formal Twitter “What are you doing?” (“Thinking about what’s for lunch”).

Miller’s article touches on the value of short updates and speaks to Yammer’s founder, David Sacks, about microblogging versus email and IM:

E-mail no longer serves its proper purpose, which is to request an active response, Mr. Sacks said. All the rest of the stuff that clogs in-boxes — mass e-mails sharing a link to an article, for example, or notifications of company events — makes e-mail less efficient. He wants to move all that to Yammer.

I certainly agree with the idea that email is broken for many of our organizational and team coordination needs, but I’m not sure if a stand alone microblogging platform is the solution. I’m still thinking about how we can support collaboration and work performance more as a symphony and perhaps less as jazz improvisation. Even with jazz, collaborators understand the possible instruments and how they best intertwine. We aren’t there yet with our understanding of work collaboration and its support. We do need to support situational awareness within teams – especially in virtual work situations.

Knowing when and how to communicate, document, and discuss are key to team performance. Tools like Yammer are an additional method, but the value will be in how the tool is interconnected with the team’s process.

Further reading:

Whitepaper on microblogging and Twitter 

Discussion of Twitter for enterprise use

Twitter hall of shame 

In my post “First there was Yahoo Groups” I promised an audit as a starting point for building a team or project “information architecture.”  I’ve had both on-line and face-to-face conversations with readers offering that email with distribution lists is still the best option for short-term teams.  I’ll try and respond to some of those points below.

Disclaimer: This is not an overview of the full space of available tools.  These are questions to ask as you think about the design of your team’s portal architecture.

1. Who are the participants?  Key to this is whether they are all inside your organization or not.  This matters first because it determines whether or not they will have access to platforms provided by your organization.  For example, are they included under your Microsoft Sharepoint license?  Are they allowed to make design changes to a Sharepoint site you set up?  What happens if you leave the group? Will the group lose access to the site? 
2. What tools do you have access to?  Will your company allow company work to sit on external servers (e.g., Google Sites)?  Will your company allow non-company work to sit on their servers (e.g., you have access to Sharepoint and/or Basecamp, can you put your grad-school team’s work on the company servers)?
3. Cost.  If you are using a fee-based tool, who pays? Is it your account and you can bring others in as you choose (see my concern about what happens if you leave the team)? Is it by the team member or by the project?
4. Who do you want to be able to redesign the site? Different wikis have different features around how you can free up or close down permissions.
5. What capabilities do you need for your site? 
   1. File storage
   2. Versioning of files
   3. File syncing – systems that are passive are more likely to be up to date as the system is managing the uploading of the most current version.  Right now I’m running several team projects via Google Sites, but I have yet to enact the part that would manage syncing.  This means that team members have to remember to upload the current versions of the files to the site. 
   4. Notification of changes to the materials on the site – I may wish email dead for moving information in collaborations, but it’s perfect for being notified when new work has been done, or a question has been asked.
   5. Threaded discussions
   6. To-do lists
   7. Gnatt-charts
   8. Calendars
   9. Personal blogs.  Socialtext keeps team members up to date by having members blog about the work they are doing.  Think of this as stopping by a team member’s office and saying “what’s up?”  This gives needed unstructured visualization into member’s work, and helps the rest of the team coordinate.
6. How long-term is this team? Are any learning curve issues acceptable given a longer view?
7. Ease of design.  I’m having good luck with modular/Lego-like sites.  Google Sites, Facebook, web-versions of Blogger, WordPress, etc. don’t assume you have a personal website, know how to program, etc.

Why not just use email with a distribution list? Besides the issues raised in my Kill Email post, who maintains the distribution list?  With a portal strategy people are having to go look at the portal and are actively involved in their own account maintenance.  How do you know that your version of the file is really the latest version? You may have a date on the file you have, but your spam filter may have eaten the version that came after (I speak from experience).  Discussions around the material are piecemeal and may be distracting to other work you’re trying to do.  You don’t have control (or even awareness) of how the material looks to other parties (do they read from the top down, bottom up, or via Gmail and so in a full conversation?)  How much email do your team members get a day – will they even see yours?  When they are ready to work on the project, do they have the skills to track down all the different related emails that have come through since they last took action?  Email is asynchronous with little control over permanence of the materials.  You’re relying on the skills and attention of your team members, and that may or may not be a good idea.

Yes, there are start up costs to a “portal” versus email approach.  But I’ve gotten it down to about 15 minutes per Google Site.  In a following post I’ll describe the basic format I’m using and talk about plusses and minuses.

What have I forgotten in this audit?  I see this as a starting list, please help us build it out.

Really.  Not the kind of firefighting we generally talk about in organizations, but really fighting fires.  I’ve been following the “Gnarl Ridge Fire” updates since my cousin Daniel is part of the fire crew.  It occurred to me today that their InciWeb interagency information portal does in fact provide consistent, timely information (its stated goal) — and that less exciting organizational projects could benefit from this approach.  The system is basically a blog of the fire.

Credit: Graig Edberg

I’ve written about the value of using portals, pages, and applications rather than email for project management.  I am still working on the promised “audit” strategy to help guide possible implementations, but I found value in this simple example.  This is a one stop shop for information transfer.  Interested parties can find the data they need and coordinate their own efforts as a result.  I’m going to try and find out how the system is perceived by the insiders and will post if I do.  I expect they have more detailed and integrated systems for internal parties.

I wish a safe night to the multi-state crews working on this fire.

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.