Newsletter Sign-Up FaceBook del.icio.us Twitter Subscribe

Author Archive: Debra Schiff

Subscribe to Debra Schiff's RSS Feed.



Posts:


You would think that we have enough evidence by now to support the thinking that collaboration methodologies and tools are needed in the workplace, and that they improve efficiency and efficacy. But apparently, no, we don’t. Another recent study, this one from Cambridge’s Judge Business School and Nokia, says that using technology to collaborate improves worker morale.

The researchers asked 400 business leaders in both the United States and United Kingdom how they used mobile technology to communicate and collaborate. In their interviews, they found that 86 percent of the respondents said collaborations help "spark new ideas." Importantly, 75 percent of the interviewees said that when they’re looking for the best person to do the work needed, they will not be bound by geographical constraints in choosing that person. Additionally, 74 percent said that if they couldn’t seek help outside their immediate team, they would not be able to get their work done.

When they drilled down to the question of morale, the researchers found that 80 percent of their respondents said that "having the mobile applications and devices they need has had a positive impact on their morale." A little over three-quarters of those surveyed said that these items improved their company’s morale.   

Of course, if a non-Nokia (or any other technology company) sponsored study came forward with the same information, most people would view it a bit less suspiciously. However, the point is basic: If you give your staff the right tools to do the best work they can, they will be happier employees.

In this case, it’s mobile technology that enables collaboration. If you ask most workers who don’t currently use a laptop or have the ability to work remotely if they would prefer the option, you will hear a resounding "Yes!" Additionally, if you ask those same workers if they would like the ability to work with subject matter experts outside their team to get their work done, I’d bet you’d hear the same "Yes!"

Speaking of working outside the team, a group of researchers at the New Jersey Institute of Technology (NJIT) have rolled out a new project funded by the National Science Foundation designed to connect women researchers at the school. Currently, they find that female scientists and engineers are challenged with the problem of isolation. The NJIT project will build cross-disciplinary communities where female faculty can collaborate online and communicate in larger numbers. Then, after the communities are live for a while, the project heads will formally connect the communities using traditional face-to-face networking.

Echoing the sentiments in Nokia’s study, the NJIT folks will be using location-sensitive mobile communication systems to increase collaboration among non-collocated researchers. That portion is being developed as part of the school’s "Smart Campus" project, "a location-aware community cybersystem." NSF is funding that in a separate grant.

Probably the most interesting part of all this is what the project researchers are going to do with the data from the study. NJIT plans to use it to "create a dynamic computer map showing changes in social network complexity over time."

I’m going to keep an eye out for the results of that study.

 

If you use (or test) many different types of software made by many different companies, as most of us do, you’ve probably noticed that function, content and feature names vary from product to product. Not only that, but depending on your native (or even second) language, you may be trying to accomplish the same task in one country while your colleague in another struggles with the software to take the same action. This inconsistency in user interface vernacular can cripple distance collaboration as well as other organizational functions.

What happens when we don’t speak the same "language?"

Let’s look at a real-world example. I have a friend who rightly complains about a constraining implementation of his organization’s content management system (CMS). The CMS is comprised of multiple software products and is applied to the company’s Web site. For months, my friend battled with IT to have specific rules programmed that would support a large chunk of the site’s password-protected content. However, the rules were not created until he stopped emailing IT and sat down face to face with the tech who supports one of the CMS’s software products. Why did it take all that time and an in-person meeting to achieve what you’d think would be a simple task?

His vernacular didn’t match IT’s vernacular.

My friend explains:

"In this software, a ‘rule’ is actually a resource to protect. A resource would be a directory (folder) on a server somewhere, a file, etc.  How it is protected is defined by ‘policies’ which say who has access. The software calls it a rule because the resource + the policy that protects it = a rule. However, to most non-technical people, the rule is the policy since the policy is the thing that says only the restricted people can view it. Therefore, when non-technical people collaborated with technical people, the non-technical people were hearing ‘rule’ and answering with ‘policy,’ (among other communication issues)."

When my friend approached the tech, he sketched a line drawing of what he needed to protect and how he wished it to happen. All of a sudden, the tech understood. Because this IT professional doesn’t have a background in Web site programming or engineering, he didn’t know what my friend meant when he said he needed "rules."

Of course, I agree with you that someone supporting a Web system should be more knowledgeable. But that’s a whole other kettle of fish.
 
When we think about this issue from the remote worker or non-collocated, collaborative partner angle, it becomes even more poignant. One big mistake I’ve made is assuming that my vernacular will be similar to those in other English-speaking organizations. The lesson is that no matter what software product or concept I’m teaching, I must ensure that I have the function, content and feature names correct. A discussion thread here may be a "topic" elsewhere. One program asks you to "add" a file, while another asks you to "upload" it.

Managing all this specific information is inconvenient at best. It would be infinitely useful for a standards organization to formulate a taxonomy of terms to describe features, functions and content items. There is already a library of universal signs and symbols. Why can’t we do this when it comes to software? From a usability standpoint, it seems to be a no-brainer.

I’ve spoken with a few companies about inconsistencies within their own products, and the reply is usually "It’s on our to-do list." Unfortunately, that often means that it’s at the bottom of the priority list.

Perhaps a larger problem is that software companies aren’t thinking about the end user as much as they think they are. If they collaborated with each other to agree on a common set of terms, they would flatten the user learning curve tremendously, and encourage faster new software adoption.

But, I think that numerous issues could be addressed by encouraging collaboration on different levels between competing organizations. There I go again, preaching to the choir…

 

Nov 2nd, 2006 | Debra Schiff

I Just Don’t Trust You

"If we are used to seeing knowledge as a scarce resource (and by owning it we have power), we are less inclined to engage in open idea exchange." — Guy Dugas, Professor, Red River College, Manitoba, Canada

When I use Google to search for "trust in collaboration" I find a host of PDFs and Web sites designed to help organizations either measure or try to foster trust in collaborative scenarios. While a good portion of these deals exclusively with inter-organizational partnerships, there are many that explore the challenges found within organizations.

Some are written from a human resources perspective — a light, band-aid approach to a pretty deep problem that stops organizations from becoming and/or staying leaders in their fields. Others are tomes that you’d be hard pressed to find anyone reading due to lack of time. Frankly, I’m amazed that professionals even have the time to read my blog entries on a regular basis, the demands on their time are so high. Thank you for that, by the way. I appreciate your time.

And, of course, there are the hundreds of companies and individual consultants who would be very happy to charge big bucks for spending a few days at an organization giving targeted workshops on developing trust within organizations in order to improve morale and collaboration. But do those workshops engender lasting change?

Many years ago, in college, I took an acting class. In this class, we were required to participate in trust-building exercises. One classic exercise had us standing on the edge of a table, facing away from our fellow students who were gathered around the table prepared to catch us one-by-one as we fell.

I had a tough time letting go of my preconceived notions that they would not catch me. Why wouldn’t they catch me? I would catch them. Eventually, I fell backward into the arms of my classmates and felt a rush of relief and a wave of embarrassment. How could I have doubted the group who only wanted me to succeed? I only wanted success for each of them, and I am hardly unique.

If we extend this thinking to collaborating within an organization, we may be able to persuade groups to more readily trust each other. They have a singular purpose, to help their ogranization succeed. If the organization succeeds, the employee succeeds.

Leading organizations exhibit many similar traits, but two of them are good communication within the organization and trust between employees. By continuous, open communication, they know that their coworkers are depending on them, and vice versa. Their human resources departments seek people with similar work ethics. They look for potential hires who have within them an optimism and an openness that leads to trustworthy behavior. Most importantly, they don’t require others to prove their trustworthiness before they share their knowledge. They don’t perceive others as potential threats.

Do these people actually exist? Yes, they do.

They understand that shared knowledge is much more powerful than if it is kept from the larger group. Seems like common sense, doesn’t it? Well, not to everyone.

When more organizations communicate effectively to their employees that they are trustworthy at all levels, and that sharing knowledge within their safe environment is highly valued, they will experience more solidarity and consequently, more success. However, lasting change takes time and repeated effort. So, if you are charged with the massive task of improving trust within the organization, you are in it for the long haul.

Oct 18th, 2006 | Debra Schiff

It’s Not the Technology, It’s the Culture

One of the biggest roadblocks to the adoption of a distributed work scenario has little to do with technology or infrastructure. It’s the culture.

In this case I’m am referring to the external, international culture, rather than internal, organizational culture. (That will be the topic of another blog item in the future.) Ignorance of differences within international cultures causes a host of challenges that can, in fact, drive companies away from using a "follow-the-sun" model. Earlier this year, fellow Collaboration Loop blogger David Coleman and I had a conversation about this topic and the types of issues that make many managers fearful of using workers around the globe to get the job done and speed time to market.

David’s experience is that international culture clashes supply the biggest issues. "Often when you’re working on a team, it may be with people outside the company," Coleman said. "Your company is here doing the design and someone outside your firewall is doing the manufacturing. Often what happens is that cultural issues get in the way. They’re not used to your corporate culture. You’re a western culture and they’re an eastern culture. You end up making assumptions that often get in the way. When I used to work in Japan, I found that the Japanese avoid conflict, they may say yes when they mean no. That also comes up in India, where they say you’ll have it on Friday, but they don’t really mean you’ll have it on Friday. As someone from the US, we just assume that people mean what they say. It doesn’t always work that way, and all the technology does in this case is exacerbate things."

To be successful on a large scale, you must be flexible enough to change your thinking and behavior to fit within many diverse cultures, especially ones you don’t know well. What this means is that you now have to be very clear with your language. No colloquialisms. And, more importantly, make no assumptions.

In a time when nearly all our distributed work "conversations" happen either within a collaborative platform or via email, it is even more important to clarify exactly what you mean. David explains, "The cues that you would normally get if you were in front of that person, you’re not getting. If you’re using IM or another online tool, your bandwidth is less. We get about 70% of our cues from body language and things like that, which you’re obviously not getting."

There are numerous books and twice as many sites on the Web that deal with cultural diversity and how to work with international colleagues and customers. As it becomes increasingly more important to work in a global way, I strongly suggest visiting a few of those sites and investing in a book or two.

If you are an American reading these words of advice, please also remember why we have been called "The Ugly American" in so many places around the world. William Lederer and Eugene Burdick wrote their landmark book of the same name to point out not only American policy errors in Southeast Asia, but the general arrogance of Americans who enter and try to take over a culture they know nothing about. If you haven’t yet read the classic (published in 1958), you should. It was required reading in my high school.

 

Oct 4th, 2006 | Debra Schiff

Is there a Generation Gap in Collaboration?

An ever-widening gap exists between the young people just entering the workforce who are accustomed to adopting new ways of communicating and collaborating, and the two top levels of workers, boomers and, well, let’s just call them "elders."

However, some of my favorite researchers say (based on Spherion’s latest study, now two years old) that the "emergent worker" has attitudes and behaviors not tied to demographics. Charlie Grantham of The Future of Work concurs, explaining that "…you have baby boomers out there that are using MySpace, IPods and webcams and living on the Internet with equal frequency as the younger folks. You can be a hip 60-year-old or you can be a fuddy-duddy 30-year-old. It’s not just an age factor, there’s something bigger going on here."

That may be true, but let’s look at a practical example regarding work within an online collaboration environment.

Last year, I worked for an organization that set up many online communities according to fields of technical interest. One of the top reasons why many of the older participants chose not to share research was that they did not trust the other community users. On the other hand, the younger members posted research and enabled collaborative relationships much more readily.

What does this mean? Charlie’s partner at The Future of Work program, Jim Ware, may have an idea. He thinks that "in the younger generation just entering the workforce, there is this sense of connection with people all over the country, if not all over the world through email and instant messaging, as well as this familiarity and comfort with multitasking. There is a difference and a comfort with relationships at a distance."

In Jim and Charlie’s October newsletter, they talk about why there’s still resistance to distributed work. They give six very clear reasons why organizations should be adopting this strategy, but the bigger question is why most won’t embrace the change. They write in-depth about the eight reasons why organizations refuse to use a collaborative and distributed strategy to move forward.

These are their eight reasons:

   1. Inherent human inertia against externally imposed change
   2. Organizational inertia
   3. Management habits and Industrial-Age thinking
   4. Fear on the part of middle managers
   5. Fear on the part of front-line workers
   6. Uncertainty about communication and relationships in a distributed environment
   7. The CEO "Edifice Complex" that leads to visible corporate facilities
   8. Plain old complexity — Distributed Work is truly a Big Change
  
To debate Jim and Charlie online a bit here (and I know they would welcome the discussion because they are open-minded fellows), most of these are generational differences.

Take point 1, "Inherent human inertia against externally imposed change." The younger worker (and I’m going to peg that person in their 20s for the sake of this discussion) has experienced a great deal of externally imposed change. They were the first generation to experience metal detectors in their schools. They were probably using instant messaging before we were (and I like to think of myself as an early adopter). They have been working with technology much longer than their teachers and have been using it to assert change for most of their lives.

Regarding point 2, "organizational inertia" is going to be tough for these new workers to address because most of the baby boomers lost a big chunk of their 401(k) savings when the tech bubble burst. Consequently, these folks will be working much longer and will be holding more of the jobs that the "middle agers" have been targeting. Meanwhile, there is an exodus of workers in their 30s and 40s are leaving organizations to freelance, consult or start their own companies because there are few growth opportunities available. Thus, we have a giant gap between the new workers and the boomers planning for retirement. No wonder there’s organizational inertia. It would be the rare organization that set up a mentoring system to match the boomers with the new workers to avert the inertia, but that would be one of my first suggestions.

Jim and Charlie point out the generation gap without precisely naming it in their point 3, so I won’t address it here. Instead, I will take on points 4 and 5 together since they deal specifically with fear. Ever hear of the X Games? The younger generation has little fear about most things. Of course, I didn’t either in my 20s, but my point is that they grew up in the world of X-treme everything. They’re not afraid to take risks in any part of their lives, including their careers. They will tell you how it is without mincing words. They didn’t know what it was like to lose job security. They never had it, therefore, these younger people will be more willing to try collaborating in a distributed way because they don’t have anything to lose unlike the middle managers and older front-line workers. I predict there will emerge a generation of innovators out of these young guns, but then again, I’m an optimist.

Point 6, "Uncertainty about communication and relationships in a distributed environment", is one of the things that doesn’t exist to the younger worker. These folks grew up communicating with online community users from all over the world. They did not grow up without "call waiting," the cell phone or computers. They embraced the communal nature of blogging very quickly and developed online friends whom they share interests. As I mentioned earlier, this younger generation collaborates easily and realizes the value of sharing work. There’s an interesting balance here since they are also fiercely independent as workers. Just don’t get in the way when they are trying to get something done.

Skipping to point 8, "Plain old complexity — Distributed Work is truly a Big Change", this is essentially the merging of all the points together, so I won’t rehash what I’ve already written here. On the other hand, I can recommend my friend Peter DeJager, who is always willing to come in and work with groups on change management. If his name sounds familiar, you are probably an "older" worker, since he rose quickly to fame during the pre-Y2K hysteria as the dominant voice of change.

Please let me know your inter-generational experiences with collaboration. I’d like to hear them.

Sep 9th, 2006 | Debra Schiff

The $60,000 Question

Let’s say you have a worst-case scenario where a project team: 1. has never met, 2. probably won’t meet, 3. are distributed all over the globe, and 4. are scheduled to work together for approximately 18 months to develop and deliver a new product. Aside from the fact that they are all being paid well to do the work, how do you get them to work together and gel as a team? That, my dear readers, is the $60,000 question.This being the second article in my interview series of long-time collaboration experts and founders of The Future of Work program, Jim Ware and Charlie Grantham, I thought I’d share with you the portion of the interview where they spoke about ways to handle that worst case scenario.

Deb: So, if for a variety of reasons, you can’t have an in-person kick-off meeting with this team, how do you get them to work together?

Charlie: I would spend about $80 a person and buy every person a little web cam. I’d use collaborative meeting software that lets us literally see each other, and I’d schedule an opening half-day meeting where we’re all sitting in front of those web cams telling each other about each other and getting to know each other, and getting to know the task. It would be like any group kick-off meeting where you’re going through what needs to be done, who will be doing it, agreeing on commitments and times, and that sort of thing. But I’d do it with web cams so that the people would have a sense of who they’re talking to.

Jim: I think a sense of who the people are is worth something. In collaborative software that lets you do file sharing and keep repositories, you might have a stream of instant messaging that’s more personal than task-oriented. You might have a place where people can put up their resumes or a picture and a bio. Those things are important.

Charlie. In that worst-case scenario, the manager of the group has to realize that one of their responsibilities is managing the social relationships and communication of group members. Most [people] don’t put that on their to-do list. They just assume it’s going to happen. But that task needs to be a goal of the project manager.

DS: What can you suggest to managers who don’t have those social relationship and communications skills?

Jim: People who rise through the ranks of managing other people without any preparation are not going to be very successful. A team is basically a group of people, none of whom can do the work all by themselves. You’re going to have to deal with the human side of these things otherwise the team isn’t going to be successful. As people come out of purely technical training and technical work into some beginnings of managerial responsibilities, or they’ve been members of a team, they begin to learn just by being around it just how important that stuff is.

Charlie: I’d be very cautious in a worst-case scenario situation of putting an inexperienced manager in charge of managing a distributed work team. That is not where you want folks to cut their teeth on management skills because there’s an extra degree of complexity around this issue of communication. It really comes down to making sure there’s a leadership development process in place with these folks. It’s absolutely critical, which means you’re going to have to spend bucks. What are the tradeoffs, if you spend money on training or some money on travel, what can you expect that to do in terms of productivity and effectiveness of the team? And, you can do the tradeoff analysis and clearly you need to invest something in developing those competencies and skill sets, or it’s going to cost you big time. You don’t want to be 9 months into an 18 month project and your three key people quit because they can’t stand the team interaction pattern anymore.


It’s been a few months since the interview, but just reading that last comment by Charlie again really drives home the point that good supervisors manage the interpersonal relationships within their teams. Next time, we tackle the generation gap.

While we like to talk about the advantages of working remotely or in a distributed scenario, nothing can replace the magic that happens during the face-to-face interactions among colleagues or other collaborators. In recent discussions with collaboration industry pundits as well as professional engineers working in distributed environments, the unanimous sentiment was that projects must start with a face-to-face meeting.

Two long-time collaboration experts and founders of The Future of Work program, Jim Ware and Charlie Grantham, were kind enough to talk with me about the value of face-to-face meetings in conjunction with distributed teams. Below are excerpts of my interview with Jim and Charlie.

Deb: When people don’t know each other are placed on a team, how do you get them to work together?

Jim: The manager needs to begin the process with a face-to-face interaction. I know people don’t like to hear that because it means that a lot of people will have to get on airplanes and go to one place at the same time. But, it’s our experience and what we know from our research, that if you don’t start that team interaction off with intense face-to-face interaction, you’re going to have a lot of problems later on down the line in terms of communication, misunderstanding of goals and handoffs.

The second point to that is that folks are well-advised in that face-to-face interaction to go through some sort of process where they can begin to appreciate the relative approaches to everyone on the team. There are several ways to do that — Meyers-Briggs, Strengthfinders, etc., but some process to get an idea of who Sally or Joe really is before they get out there and try to deal with things over the Internet or telephone.

Charlie: There are a couple of key points in a project team when meeting face-to-face is important. It’s not just for getting to know Joe and Sally, it’s also for the depth of conversation and the breadth of meaning. The kickoff is certainly one of those points.

There’s also a key design point later on in a project where it might be worth bringing the team back together. Recognize the need that people have to socialize. When you’re having group conference calls, a team leader should be willing to spend a few minutes up front, say checking in with people, asking "what’s happening in your life?" It’s not really task-oriented relative to what you’re trying to accomplish, but it connects us with each other, gives each other a sense of context. The evidence we have is that colocated teams (people all on the same team on the same campus) meet face-to-face just slightly more often than teams that are spread all over the world. It’s surprising.

Jim: One of our advisors is a professor at Santa Clara University named Terri Griffith, and she’s done quite a bit of research on what she calls the value of presence (of being in the same room together). Her research suggests that colocated teams meet as a full team, face-to-face, something like 17-20% of the time — whereas distributed teams meet face-to-face over an extended period of time an average of about 12% of the time. It’s a bit of a myth that people who are colocated meet as a team significantly more often.


I will be sharing more from my conversation with Jim and Charlie in upcoming blog entries.

 

Aug 17th, 2006 | Debra Schiff

Catching Up

Yes, it’s true. Four months is too long to go without posting a blog entry. And, being beyond busy is no excuse. Just look at all the professionals in our field who fill the pages of this site with their thoughts and experiences. They can manage it just fine! So, to get back into the swing of things, I’ll spend this entry catching you up a bit with the role collaborative technologies and collaboration in general have played in my life from the last entry until now.

First, did I say I was busy? Well, back in January, I parted ways with IEEE to try consulting and freelance writing. I’ve published three articles since then in EE Times (will say more about the third article later in this entry) and several in IEEE-USA’s Today’s Engineer. The first two articles had very little to say about collaboration. The first two EE Times stories were on the political implications of the H1-B program and its violators, and on the differences between the brain of someone who is ideally suited to become an engineer and someone who is not.

While the stories themselves did not deal directly with the concept of collaboration, they did require a lot of collaboration between the reporter  (me) and the many experts in their fields who were interviewed. The interviewee must be able to trust that the journalist will not misquote them or emphasize a point incorrectly. The journalist must have respect for the interviewee and research his or her work prior to the interview so as not to talk "blindly" with that person and waste his or her time. In most cases, I  have great admiration for the people I interview, and wind up reading reams of research in order to better understand their work as well as my article’s subject.

For the third story on distributed engineering, I again sought leaders in the field as well as in the field of collaboration itself. I hit up some of our  fellow Collaboration Loop bloggers, and had the pleasure of interviewing Jonathan Spira and David Coleman. In fact, I asked Jonathan if he would write the sidebar on collaborative engineering tools because contractually speaking, I can’t at the moment. I can write about the concept of collaboration, but tools are off my agenda due to a non-compete agreement with one of my clients.

But that worked out very well and you can read my article, "Global Teams Rock Around the Clock" at EE Times site.

Please let me know what you think.

Not to sway you in any way, but one of my favorite quotes is the one that closes the article by David Coleman. I hope you enjoy reading it as much as I did writing it.

Apr 26th, 2006 | Debra Schiff

No One Wants To Reinvent The Wheel

It’s not enough to know a collaborative technology inside and out when teaching someone how to use it. The key is context. A really useful recent posting here by Steven Tedjamulia gives some solid instruction on how to take user requirements and map out a collaboration architecture. But what happens if the key stakeholders don’t know what they don’t know?

I’ll tell you. It gets messy, but you can avoid the mess and help the process enormously by demonstrating the collaboration environment to the prospective users. If you’ve gotten to the architecture point, you already have an idea of at least one environment that would probably fit the company’s scheme. What you’ll need to do is have a demo available to show the people who will be using the environment and a way to show them how other organizations are using it as well.

With each new client, I am always asked "How does so-and-so use this platform to do such-and-such?" And, again, I explain with a short demonstration without exposing so-and-so’s proprietary data to the new client. It is usually sufficient to start the client’s wheels turning.

It’s important to note that before I walk in the door, I really should have done my homework about the client’s work so that the context for their use of the collaborative environment is crystal clear and easily demonstrated.

What I’m really after is the "Aha!" moment where people who don’t normally communicate and collaborate in a highly efficient and collegial way become converts. OK, I usually settle for buy in, but watching the light bulbs go on is pretty inspiring.

Either way, my goal is to try to prevent a disastrous rollout of a platform that people might be unwilling to use based on a number of factors.

To that end, I’d like to address one complaint in particular. First, my caveat is that each person is unique and has his or her own approach to technology. That said, I’ve sat with users who have complained loudly that one platform or another was too difficult to learn or not intuitive to them. These are often the same users who talk through the entire instruction time and/or tend to have difficulty with most applications (the latter is more often true than the former).

The expression "To each his own," comes to mind at these times. I’ve experienced my share of collaborative tools and platforms, and some of them work for me while others are thorns in my side. For that reason, I have a lot of sympathy for the person who has genuinely been trying to learn the platform on his or her own and is simply frustrated because it doesn’t mesh with they way they think about things or process information.

But, it’s my job to help people learn how to use something that might not like, but will need to use to achieve their organization’s goals. In that case, I get a little personal. I do something similar to what Steven suggests – I interview the user and ask him or her precisely what they do at work. Who do they serve, and so on. The better I can contextualize the work within the platform, the closer I’ll get to seeing that person’s light bulb go on.

It often takes more time than I’d like, but it’s worth the up-front time investment to prevent the high cost of re-engineering a whole set-up down the line.

Mar 16th, 2006 | Debra Schiff

The Elephant in the Board Room

Time was when the elephant was in the living room. Then, it represented any number of things that a family member didn’t want to face. Now, that it’s moved into the board rooms of collaboration environment purveyors, the elephant has become a woolly mammoth with enormous tusks.If you read Melanie Turek’s blog, you’ll know what I mean when I say that this situation reminds me of “Waiting for Godot.” First, I’m naming the woolly mammoth – it’s Microsoft. There is a palpable weight to the air when discussing the possibilities of Microsoft’s collaboration environment offerings to come.

In the backs of everyone’s minds at collaboration tool vendors around the world is a handful of sizeable questions: “What will the Microsoft solution be? Will it be a lightweight, completely integrated Groove-like solution? When does it hit the market? How do we differentiate ourselves before this happens? How can we preserve our niche?”

What makes your solution special now may not be special whenever Microsoft unleashes the mammoth. Furthermore, if your solution does not integrate seamlessly with what basically most of the free world uses to do their work, you may find yourself looking for work in another field. The integration piece is what will give Microsoft the green light from IT directors and other decision makers. It’s a huge time saver.

On the other side of the coin, the big question in the back of my mind is how secure will the Microsoft solution be? Although they are relatively quick to respond to security threats, Microsoft tools are such easy targets for hackers.

Another, slightly smaller, question that pops up in my consciousness now and then is what happens when Google does what it continues to do best – surprise us with interesting, new, mostly free ways to do things? What happens if Google makes a concerted effort and throws its hat into the ring for collaboration environments? Google is already making leaps and bounds with Gmail and Google Talk. Who’s to say that Google won’t beat Microsoft to the punch?

It certainly wouldn’t surprise me.

Time will tell, but it seems that the longer we all wait, the more questions arise in my mind. In the meantime, I’ll do a Google search for Mammoth Chow. The thing in the board room is getting hungry.

Next »