Technology and Organizations

…“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 

I’ve been getting questions from students about quick and easy ways to run their team projects. They correctly believe that they could do better than Yahoo Groups and/or Google Groups. In August I wrote a basic post about designing communication and workflow infrastructure for multi-organizational project teams. More recently I created a short “audit” to help people think about their requirements and options. Today my research assistant said she’d be interested in a “how to” about how I created the Google Sites project site she and I are using to work together.  This approach combines a useful technology tool (Google Sites) with basic ideas of team and project management - including some implementation tips.  Here it is:

Disclaimer – Limited QA here – I may have left out a click or two – be sure to save your work at each stage.

Simple (using a student project as an example) — See bottom for a more sophisticated version.

Three basic components – To Do list, Discussion Tool, and a File Repository. Here’s the demo site.

Create a Google Site for your project (you do need a Google account – free):
Go to http://sites.google.com
Click on Create New Site
Give it a Name and a URL (they don’t have to be the same, e.g., Primo Project for Name and http://sites.google.com/site/primoprojectsite for the URL)
Click appropriately for adult content
Click on whether sharing is with the world, or just with people you will specify
Pick a theme
Enter the funny text that proves you’re human

Presto! Now you have a site.

Immediately “Create a New Page” and choose Dashboard as the format. Click that you want this page created at the “Top Level.” I like to name my Dashboards –ok, Primo Project Dashboard. Very creative. Click on “Save.”

---

{This section is my kludged way of getting the Dashboard as the home page – Google Sites automatically creates a “Home” page – but I want a Dashboard at the top of the site and I can’t figure out how to do that initially. I’ll edit this section if I ever figure out how to do it more simply.}

Click on Site Settings (top right of page)
Click on the “Other Stuff” tab
Change the “Landing page” to your dashboard page. Click “OK” then “Save Changes”.

Return to the site and delete the page with the title “Home” (go to the site, click on the link called Home, click on the “More actions menu” then “delete”). Now your dashboard page is your home page.

Create another new page. Choose the “List” format. Call the page “To Dos” and have it put underneath the Dashboard page in the site structure (this is an option you have to pick). I like the “Action Item” style, though you are given other choices.

Create another new page. Choose the “File Cabinet” format. Call the page “Files and Documents.” Put it under the Dashboard in the site structure.

Create yet another page. Choose the “Announcements” format. Call the page “Comments and Questions” and put it also under the Dashboard in the site structure.

Now for the fun. We need to link these pages to the Dashboard. You can’t create the dashboard links until you’ve created the pages to link to. Makes sense.

Go to the Dashboard page. Click Edit. You should see four place-holders for “gadgets.” These gadgets are the tools of the dashboard – they keep track of changes in the other pages you created. Click on the first gadget – use the dropdown box to insert the “Recent List Items” gadget – this will now keep track of and provide a link to your To Do page. Click on Save. Click on the next place-holder and link to “Recent Files.” Click on Save. Click on the third place-holder and link to “Recent Posts” (links to your Comments and Questions page). Click on Save. Go crazy. Use the fourth place-holder to add a link to an existing shared Google calendar (you’ll need the URL from the calendar’s site. For more info click here).

Click on the save tab near the top of your page and you will see your dashboard page with its three gadgets (four if you added the calendar). The site map will let you go directly to the underlying pages – or click on the links provided by the gadgets. (I like to put in a test “comment” so people know how to use the comments and questions section).

Click on the Files page and add any files you already have. Decide as a group whether you want to post separate files (e.g., stand-alone Microsoft Word or Excel files), or whether you want to use Google Documents – see this education focused discussion on Google documents.

Take on the hard but critical task of deciding as a group how to do the work. If possible, do this over a beer or coffee in a place with wireless.

• Bring a laptop and do some group design on the site.
• Ask people to bring their resumes so you can get to know their strengths.
• Convince everyone to “subscribe” to changes to the site – this means that they will get an email each time a change is made (under the “more actions” tab, click on “subscribe to site changes”.
• Add any other gadgets to your dashboard that the team thinks will help you get the work done. (I added the Santa Clara logo by using the “Insert” tab and then uploading the image from my desktop.)

Dylan Salisbury (SCU http://www.Scu.edu MBA student and author of a thoughtful blog) http://blog.dylansalisbury.com/ had some additional suggestions after he read a draft of this post (he’s also suggested a post on team roles, I’ll do that next):

For an actual MBA class project, I think that e-mails directly to the project mailing list is the best format for all group discussion — announcements and discussion boards are not as useful (but you knew I was going to say that!). It’s very common to see an e-mail from somebody that comments on all the three current open issues and expresses an opinion about what to do next, which is good. The quarter moves so quickly that I *want* multiple discussion threads to be consolidated whenever it’s appropriate, and I want a linear view of all the communications at the potential expense of not seeing the threads so clearly. I don’t want any chance that I update a discussion but only 3 of the 5 team members sees it right away. Also, each of us has our own e-mail client that we can use to create a threaded view — we own our tools! {TG asks: Dylan (or anyone else), do you still feel this way if you are getting email announcements of changes to the page?}

Announcements and Q&A pages are really helpful for some of my real-world projects where we have a team of 4-5 people but 20 or 30 possible stakeholders who occasionally want to browse the web site to understand what’s going on.

But it may be good to start some wiki pages for various ideas and things that need to be collected during the project, outside of the discussion format (List of URLs of relevant articles, list of open questions, ideas for the paper, etc). {TG notes: To create a basic wiki page in your team’s Google Site, create a new page and choose the “web page” as the format. This format has the ability to “see earlier versions” and then the possibility of reverting to an earlier form if you need to}

Get an “A” on the project because you have an excellent collaboration process.

More sophisticated version (includes project status, background on project, background on team members – site example provided by www.enterprise-dashboard.com)

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.

Yesterday, David F. Gallagher wrote “I’m in Your Google Docs, Reading Your Spreadsheets” for the NY Times Bits blog. He describes how he was mistakenly sent a sharing invitation to a set of Google Docs by an employee of Community Newspapers Holdings Inc. — based on his email being similar to that of a CNHI employee. This gave him access to spreadsheets (among other things) with detailed financial data.

This highlighted for me the true but mundane statement that “Security is human,” and the role that security needs to play in our current discussion of the design of communication and workflow infrastructure for multi-organizational project teams. While I mentioned yesterday how I redesigned my prototype site based on specific needs for password controls, I haven’t yet broached the issue of how when you self-design for collaboration, you also need to self-design the technical and human aspects of security for your collaborative systems. We make decisions in face-to-face settings about whether to leave the conference room door open or closed, and we need to make similar decisions in more virtual settings.

Many of the current 35 comments to Mr. Gallagher’s post focus on bringing the collaboration tools behind the organization’s firewall. That works for some collaborations, but not for any of the ones I work with as they are all multi-organizational. Ultimately, security is human. Yes, it would be nice if Google Docs would do a check and ask you if you really mean to share with someone you’ve never shared with before – a suggestion Mr. Gallagher provides. (Google Sites does query your intentions when you add someone from outside your own domain.) However, as he notes,

in the end, security requires careful typing — and perhaps some careful decisions about whether some documents would be better left behind the corporate firewall.

I’ll add that careful consideration of permissions, access controls, version tracking, and the like are all part of the human/technology system that must be carefully intertwined in modern environments. We need to actively consider our security just as we should actively think about what to write on the white board, how the tables and chairs should be arranged, and who should be involved. When we make the decision to use teams, we take on the responsibility of proactively designing them as well.

Email is selfish. If we are working on a team project and I send a message only to you, only you have access to it. I might have meant for only you to have the info (maybe I was griping about another team member), but more likely I just didn’t think the others would be interested and I was trying to keep their in-box clutter to a minimum. On the other hand, maybe I just didn’t know that the other team members were actually just then wondering about that information, or I didn’t know that you were about to quit the team and now the person taking over your role won’t have access to the info unless I figure out that I need to resend to them. Email requires a lot of forethought – and when was the last time you seriously thought about the information architecture of your team project as you were popping off that message? True, systems like those available from Tacit can mine email for content, but does your team have access to such tools?

Email is unwieldy. To file or not to file. Do you structure your email in well-considered folders, or actively label/tag as GMail would suggest you do? Do you save every single email you send and receive? Can you easily search your archived email? (As an Apple Mail user I don’t believe I can – though I could if I bought add-on tools.)

As Wired magazine might put it: email is tired, pages are wired. Pages are the structure of Facebook and Google Sites. Portals may be the enterprise version (e.g., w3 from IBM). Pages and portals push us to think of content as content, rather than as a fleeting message. Communication within pages is persistent and searchable – as people change roles, the material stays put. (July 2008 Wired has an article by Clive Thompson about email management tools — describing current email use as “The Great American Timesuck.”)

I don’t yet have a clear-cut platform/page structure to suggest for a project team (would be great if people would post possible examples in the comments). I am thinking hard about how to best structure the content for my upcoming EMBA Managing Innovation and Change course. We use Angel as our course management platform and it has some blog/wiki capability (and needs to be private in some areas), but maybe I should be thinking about Facebook instead. If this were an undergraduate course I expect I’d make the leap as that would give them more of a one-stop shopping experience for their on-line activities. (I’ve heard from more than one place that email is just for old fogies.) In an earlier post I talked about using freely available tools to handle complex tasks. Please comment if you have found a way to move your group away from email using freely available platforms. Clearly there is still a place for point to point communication, but is switching over to your separate email application going to be as attractive if the rest of your workday is taking place on a more full function platform?