I had a fascinating conversation with a CIO the other day. He was complaining about how users at his company were running roughshod over corporate systems and networks.
The most recent problems came to light when a network failure cut off e-mail and Web access throughout the company's far-flung operations.
Instead of simply calling it a day, creative employees quickly implemented workarounds. One group installed a quick and dirty Wiki to enable team communications.
Another took advantage of America Online Inc.'s Instant Messenger application to route files and messages between geographically remote employees. Others used Web e-mail and wireless networking to keep the company's business flowing.
The CIO's response was predictable: He moved quickly to lock down corporate desktops and laptops to prohibit users from installing unapproved software or accessing unsupported Web services.
I am still not aware how much of blogging happens internal to an organization i.e. it is necessarily access controlled, and more specific to internal needs such as projects related info, internal news etc.
If you are new to blogs, then it is a good link to understand what you can expect in a blog site.
Note: This is very nice table, so worth the visit.
-Vinod
From their blurb from Mobcall for example:
Thinmail's newest service, Mobcall, provides instant push-button teleconferencing. It is triggered by sending an email message to any number of phones. They ring and whoever answers pushes a button and joins your conference call.
the real value of the new mail, though, will be attention management rather than content management. In an iterative process based on explicit user instructions and watching of user behavior, mail will start to know what you want to see now, what you want to see later (and when), and what you want to see never.
I'm eager to hear about actual examples of these kinds of tools, and I hope to see a lot of them at Inbox. More when I know more.
Likewise, e-mail suffers when you have lots of people collaborating and different attachments that are going back and forth. And the creation of this idea that, whenever you want to work with somebody, you just create a Web site -- called a SharePoint Web site -- that's been very explosive in the last year as we've built that more into Office. Office, even if you have the latest, will make a hint that when you send an e-mailed attachment that, do you really just want to click here and we'll just make a Web site that everybody can go to and see what's going on there?
What happens very quickly when a company adopts that is you get all different templates for these shared Web sites for starting a project, for doing a meeting, for discussing what's going on with a customer. It's phenomenal to see how quickly that takes place. So, the next generation of collaboration really is about bottoms-up creation of Web sites where the IT department doesn't have to get involved. In fact, you can just have a few people administering 50,000 different sites and those sites get staged out and everything in a simple way.
For mailing lists, there are some solutions:
Browses are essentially categories / sitemap layer on top of variety of documents / material that gets accumulated from various people. For examplt, Open directory project is a group-based browsing system created to capture the most useful links out there.
The information accumulation may happen under wiki systems, forums, weblogs, newsgroups and sometimes through emails.
While most people submit information, very few people create browsable interfaces for that information. Browses take the user to specific information, unlike searches and news (i.e. tracking changes) interfaces to the same information.
Creating "browsing" on the information will work for specific use cases - such as "What a new person joining the project should learn". In essence, this is a context. Some contexts have long-time validity (like in project-induction process) and some others have short time (such as proposal making).
Since browses are for specific activity/context, the overhead in creating a browse in advance needs to be carefully examined. For example, if a group starts to collaborate on a new process, members should probably put browses to identify "must-read" information by all members, to give context to the work, and to identify relevant documents within and outside of organization.
So it doesn't make sense to have "master browse" for information within organization, the people can browse through a list of activities, and then access the browsable information within that context. It also helps in why that information was relevant to that activity.
When a specific activity is started, how quickly you can let other people (not formally part of activity) to reach you with helpful content? Obviously, you would also like to filter the incoming information - typically this is based on relative expertise of the person is giving the information. In large organizations it would be very difficult to know real expertise levels. That is when you go look at the weblogs maintained by those people.
But it also helps to know "What is happening in organization now"; that is the only way the connections are made. (And that also explains why a canteen or coffee corner is strategically essential to any organization!). You require news like interface her: Which people are in news? What events are happening? What topics are being discussed? Here is an interesting tool: k-collector from evectors.com. It is an interesting approach for presenting information from weblogs (and possibly, from wikis as well): In terms of "What", "Where", "Who" and "when" boxes that give overview of what is happening in your organization (or in a community where the server is hosted). This is probably achieved by tagging appropriate information with weblog entries: such as people, places, events and so on.
The "optimality" of social-expertise and experience exchange tools will continue to be refined, and I hope some set patterns emerge giving a clear idea of what tools will result in better ROI.
-Vinod
In summary: Get involvement and complete backing from the senior management (at least 2 levels up!), make sure goals and objectives are understood, make sure you establish processes which are actually understood and followed by people, check out inertia effects and so on.
In a small group, things work fine because everyone is involved, and it is group effort, and things are likey to succeed. But the moment it is an effort where the audience is not personally in touch with you (i.e. you are doing it for much wider group), then you need to handle it in much more different way (heeding to suggestions such as ones from above link). People come from variety of background; they won't have visibility towards objectives and goals the way you do. Or perhaps, they have some suggestions to give from their experience... In essence, the success factors are not in your hands alone, and you have to take help from senior mentors, and so on.
Needless to say, wiki systems are moving towards this. Twiki is actually well placed to handle many such requirements in organizational settings.
-vinod