TEAM PORTAL AUDIT
/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.
- 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?
- 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)?
- 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?
- 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.
- What capabilities do you need for your site?
- File storage
- Versioning of files
- 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.
- 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.
- Threaded discussions
- To-do lists
- Gnatt-charts
- Calendars
- 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.
- How long-term is this team? Are any learning curve issues acceptable given a longer view?
- 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.