CollabPlace

This Place is for discussing Collaboration software, systems, tools, theory, practice, and behavior.

Name:
Location: Gahanna, Ohio, United States

I've been designing, building, implementing, integrating, and supporting Collaboration Systems for over a decade. Prior to that, I've worked with business process reengineering, project management, IT R&D, industrial engineering, account management, legal contract drafting, and general management. I have degrees in Economics and Finance, which don't seem to apply directly to any job position I have. However, I've found the background gained applicable in some way almost daily.

Friday, December 11, 2009

Where to Collaborate

I've had several eMail accounts for years. I have different purposes for each, and keep up to date with each of them. Over the last couple years, I've ended up with accounts in several different collaboration environments. How to figure out where to "be active," or what to use each for?

Facebook is the "Kleenex" or "Xerox" of public social networking -- the "brand" that is practically synonymous with the category. Several tools allow cross-posting or simultaneous posting to public sites like Facebook, Twitter, LinkedIn, etc. - For example, see ping.fm. While these help with posting, I still have to manually deal with other aspects - like managing connections to people and working with longer postings or attachment data.

There's also a disconnect or gap between Internal Corporate collaboration tools and public tools. The more detailed collaboration like shared document authoring/editing, wikis, forums, etc. are more frequently used internally, and don't necessarily create the quandry of posting or sharing in multiple locations. Data confidentiality alone drives much of this. In the "status updates" or micro-blogging realm, though, it frequently would make sense to post the same info internally and externally.

One of the options I've considered is an Eclipse PlugIn for Notes that would allow posting updates to internal sites (e.g., Lotus Connections, Sametime IM status), and external sites like Facebook, Twitter, etc. simultaneously. I think a key feature, though, would be the ability to easily, on a post-by-post basis, select which tools are updated.

As I've spent a few paragraphs jotting down these thoughts, it occurs to me that simultaneous posting of blog entries would be helpful, as well. It would have saved me from copying and pasting this post.

Saturday, October 11, 2008

Integrity in the Collaboration Business?

I've typically joked about the value of "consulting research" firms - who typically ask me and several others what we think, then charge us for a report to tell us what we said... Some seem even less authentic in their efforts.

I became especially disappointed with one particular firm that goes by the last name of the female head of the firm a few years ago. They conducted a survey to report on the relative cost of operating Lotus Notes/Domino or Microsoft Outlook/Exchange environments. I was asked to participate in the fairly detailed survey, responded, and had my response acknowledged with a complimentary copy of their report.

In reading the report, it was clear that my input had been distorted. There were only 5 responding firms in my "size" category who were running Lotus Notes/Domino. There report indicated that no one was hosting more than 1,000 users on a Domino server. However, I had clearly responded (correctly) that we were running 4,000 users per Windows Domino server.

This seemed suspiciously like an attempt to make Microsoft appear better in the study. I began watching this firm's reports and studies more closely. They seem to consistently rate Microsoft more highly than seems reasonable - and in comparison to similar studies performed by other research organizations.

What's the harm? Is all fair in business? Why do I care since I don't think very highly of such reports anyway? -- I value integrity. I strive to adhere to the utmost standards of integrity myself, and look for the same in others. I have no problem with people who honestly disagree with my opinions, analysis, and conclusions. I respect people who are trying to make a living producing and selling a product that I don't wnat need or like. I have no respect or tolerance, though, for people who are willing to sacrifice truth for a buck.

  • The research analysis firm who shades a report to favor a company they think will provide more business, or
  • The software vendor who tells my company we'll be able to run their product on half the number of servers it will reall take,
  • are no different from the used car salesman who swears the salvaged vehicle has never been in an accident.

Saturday, May 27, 2006

Collaboration Systems

I currently work with Collaboration Systems (eMail, Calendaring & Scheduling, Instant Messaging, Web Conferencing, Team Workspaces, etc.). I didn't take a straightforward path into an "IT" career, but while updating my resume recently, a common thread through my career did strike me. Much of my work prior to IT was in management consulting and business process reengineering. Although both sometimes generated negative connotations among the "subjects" of projects, the goal was to help people work together better. The goal with collaboration systems is the same thing - just using systems to do so.

With the business process reengineering work, we found that the more we involved the people doing the "processes" we were trying to improve, the better the results. Not only were they better from an analytical perspective, but because of the involvement, the people were more willing to accept and implement the changes, which meant the intended benefits were actually gained.

The corrolary to collaboration systems should be classic IT project management of getting the requirements well defined from not just the product owner or project sponsor, but with input from the actual users. This can be challenging as most users are not aware of what features, functions, and benefits are actually available. On the other hand, we have potential influencers (IT executives reading too many trade rags) who think bleeding edge tools are ready for prime-time. The best approach I've found to addressing these both (so far) is a manner of "iterative requirements development." This includes some demos and discussions to generate thought and input around what potential exists today... and what is coming, but not ready, yet.