The Case Against Collaboration, Part III
In my last two posts, I described some of the reasons that all projects and endeavors do not lend themselves to effective collaboration. Whether they deal with people or with innovation, some projects or products are best conducted with the fewest number of people possible–at least initially. In this post, I’ll discuss some of the cultural and geographic challenges associated with collaboration on IT projects.
I have worked on international IT projects and have personally seen some of the issues described in this post. Also, I have watched with great interest the rise of wikis, VOIP, instant messaging (IM), screen sharing, greatly enhanced video conferencing technologies such as Telepresence from Cisco, and other tools. Collectively, they have made collaboration easier. Never mistake easier with easy, though.
Despite the recent technological advents and improvements mentioned above, international projects are still face formidable challenges. They include differences vis-à-vis:
- time zones
Each one of these differences could be a deal breaker on a specific project. If you talk to a true expert on the subject like my friend Jason Horowitz, you’ll realize that there are simply limits to what technology can effectively overcome. Consider the following:
- While wikis may be better than long, drawn out email chains for exchanging ideas, neither captures the energy of an in-person brainstorming session.
- Being able to stop by a colleague’s cubicle to run through a scenario isn’t the same as sending her an instant message.
- Even those who speak the same language may not be able to pick up on non-verbal cues. Consider that upwards of 90 percent of all communication is non-verbal.
- While banal, sometimes the very act of scheduling a conference call can be a struggle with workers strewn all across the globe.
I could continue, but the fact remains: there are still major hurdles to overcome on multinational, multi-party information management (IM) projects. These hurdles can become insurmountable factoring in two additional obstacles.
Incomplete Specifications and the Limitations of Outsourcing
Those who cite the benefits of outsourcing are quick to talk about money. Yes, organizations can ostensibly save considerable funds by utilizing high-tech workers in countries such as Brazil, Russia, Vietnam, and India. In some cases, compared to workers “high wage” countries such as the US, the savings can be upwards of 70 percent. But what about the drawbacks?
There can be many, as most seasoned IT practitioners know. But perhaps the most vexing on IT-related projects is the tendency for outsourced workers to “write to spec.” This is tech-speak for writing code, reports, or software exactly as detailed in the specification. This problem wouldn’t be as inimical if specs were bullet-proof. At least in my experience, this is rarely the case. Precious time is wasted as developers and “business folks” go round and round debating the ins and outs of individual work products. In many cases, the outsourced worker does not have sufficient “business” or product knowledge to make the logical leaps of faith required on a deficient spec. For their part, those requesting the work typically cannot communicate in a language that the techies can fully understand.
And let’s not forget the elephant in the room:
Sometimes proper specs are completely missing altogether.
I’ve worked for months at client sites on development projects without receiving a single proper spec. I’ve been able to muddle my way though, but I’d be lying if I claimed to be a mind reader. My batting average was certainly not 1.000.
For a more robust description of the issues related to outsourcing, click here.
Look, no one is saying that international projects and collaboration are mutually exclusive. They’re not. Nor am I implying that organizations should never outsource. My only point is that all of the wikis, teleconferences, and meetings in the world can necessarily overcome many of the challenges associated with different time zones, languages, and cultures. Know this going in to your next IM project.
What do you think?
You must log in to post a comment.