This is an old link ... let me redirect you ...
(... or click here if the page does not automatically redirect)
New Collaboration Tools need Lead Time & Practice
Collaboration "in the Wild": Some Observations
An Enterprise 2.0 dream scenario: implementing a complex project across
multiple sites, in two different time zones, with a large team (well
over 100). The team was reasonably savvy with collaboration tools; core
team members were quite comfortable with Instant Messaging, and we have
been relying on SharePoint for many months. A centralized, coordinated
document repository; a single source, very public bugs/issues list - the
foundation was in place for some time, so our "go-live weekend"
experience was pleasantly predictable.
During this critical time, we had to coordinate with the multitude, and
we did that with a highly structured "hour-by-hour plan", regularly
scheduled "all-hands" conference calls, and web-based meeting places so
all could review Completed, In Process, and Coming Soon tasks. After a
successful weekend, we received plenty of positive feedback, and some
interesting suggestions for improvements:
- Conference calls were regularly scheduled, and featured
tight agendas - which tended to limit individuals' ability to connect
with the right person (until afterward). Since each location had a
"war room" where the team gathered for the status calls, some
suggested we leave the conference call open 24x7. I wasn't a big fan
of this one, primarily because I'm the guy paying the long-distance
- Few on the team are actively using Twitter, but one of the
project leads noted that IM was quite popular, and imagined a
Tweetdeck-like ability to see instant messages and responses that
have gone out previously; "threaded conversations" that could be
visible to all, helping collaborative problem-solving and knowledge
transfer. I congratulated him on inventing Google Wave ...
- Like most decent-sized companies, we have a highly
structured Process for approving code changes into production - and
like most decent-sized projects, we noted a few instances where
promotions to resolve problems were delayed (while they worked their
way through the Process). Might there be some streamlining
opportunities here, since we are working on a high profile project
with lots of oversight?
Of course, #3 was a non-starter, but the first two generated some good
discussion, Yes, it's conceivable that we could augment our SharePoint
site with a few new extensions or plug-ins to address the first two -
but I'm actively working against any changes to our collaboration
environments for a very simple reason -
we're not finished with the big project
. Phase 2 of 2 is coming in just a few weeks.
Am I being
? Not really, I'm a huge driver of collaboration tools in the company.
But, I'm also a realist - and I know two significant factors that argue
against change at the time:
: We are implementing ERP and other highly intrusive / foundational
systems, and there's a lot of change that comes along with that. I
understand that an organization can only take so much change at once -
so why not focus on the stuff that's bringing real (ie. quantifiable,
bottom-line, significant) business value.
: Eight months ago, sharing files by e-mail and ad-hoc, unstructured
meetings were the norm. To be fair, we were working smaller projects
with teams of 10-20, and usually in no more than two locations. Over the
past few months, as we were teeing up for Big Go-Live #1, we've been
introducing the newer tools in small bits. For Go-Live Weekend, the team
was already familiar with going to SharePoint for status updates, or
recording a new Issue in the SharePoint list. The mechanics were old
hat, and folks didn't need to think about it - which was nice, since we
need them thinking about their Tasks. If we introduce new collaboration
tools with little lead time before the Big Go-Live #2, Tasks will be
interrupted with people struggling to remember how to communicate.
In the right setting, collaboration tools can clearly add value - even
for the most conservative jaded technology users. However, you can't
introduce something so new and expect people to "get it" in the short
term. Better approach is to introduce the new tools early in the
process, when there is no pressure. This lets the team build
familiarity, understanding, and skills by the time you need to rely on
these tools for critical communication.