Collaboration “in the Wild”: Some Observations
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 24×7. I wasn’t a big fan of this one, primarily because I’m the guy paying the long-distance bill …
- 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 close-minded? 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:
Prioritizing “Improvements”: 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.
New Collaboration Tools need Lead Time & Practice: 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.
You must log in to post a comment.