Getting in the Groove
Groove is the best implementation of a new group of products that are designed to bring people and resources together. Think of it as an "instant messenger" with the added strength of instant documents.
That said, this situation reminds me of the earliest days of desktop computing—before IBM came in and standardized the whole industry with its XT system. IBM wasn't the best, and they never became the biggest in the desktop industry. In the days before standardization, Atari, Apple, Billings, Radio Shack's TRS-80, Commodore, and CPM machines each had its own software and hardware. IBM announced an "open architecture" that allowed everyone to build a system that met its standards. To this day, I don't think IBM was the best architecture to have followed—others were superior (at the time.) But the sheer expected mass of the IBM PC—and the open architectural standards—made it the system to develop on. For we IT folks, it meant we could trust the new PCs on our networks.
Well, Groove is probably the best implementation for this decade of the communication tools your firm will probably use. If you do an audit of the machines on your system now, you'll find that many of your clients have downloaded such tools as AOL's Instant Messenger, Microsoft's Chat, or some other peer-to-peer communication tool. We both know that if these items are loaded on anyone's machine in your network, they are probably being used for less than office communication, and more likely to have a running love affair between two people tantalized by the possibility of after-work activities together. What it should tell you is that your system is being used in ways you didn't expect, and that the creative talents of your office want! It means you can either wait until standards are set by default, or you can set them.
It is my suggestion that you get in the Groove and set your own company standards. However, you'll want to do it on a tool with significantly more "open architecture" than Instant Messenger. (This isn't to say that some future release of IM would not be able to incorporate many of the design features of Groove, just that Groove offers the open architecture you will one day want TODAY.) I see this as giving me two choices: I can spend time running around deleting IM and Chat from folks' computers, or I can implement Groove across the network, and support a new tool that will become my office standard (whether it becomes an international standard or not).
Why Groove? (And why not IM or Chat?) Simply because of the open architecture. The feature that you'll want to use—and want to have available in the future—are the "tools." Groove already does things IM or Chat don't do. But more importantly, Groove has the communication tools that are the equivalent of "expansion ports." The tools of Groove will allow us to add new components and new features that may be unique to our office—but more likely will be used by most people at many offices.
I can't even imagine what new tools I'll want to implement on a glorified chat box. If I had my druthers, I'd probably tell everyone to just meet weekly and save the bandwidth for the really important stuff. But it's not my computer system. The company I work for still believes it belongs to them. And some of those folks will want the tools to do stuff that I think could be done more efficiently in a fixed set of meetings at a fixed set of times. Besides, I'll miss the frequent flyer miles.
But the point is that time will provide new tools. Fortunately, you won't have to develop them. Someone else will, and Groove, Inc. will facilitate you getting the new tools. I didn't write Windows, or WordPerfect, or Quattro Pro, or Civilization, either. I didn't extend their capabilities. My job was just to get them to work on our computer system. (Okay, I chose to put Civilization on the system, and no one asked me to.) When our office decided that Microsoft's Outlook would do our facilities management, scheduling, and calendaring program, I dutifully made it work across the network. Frankly, the network is doing things now that I hadn't prepared for it to do. I think it shows my expertise in building a complete system that had so many possibilities. In reality, it meant that I was able to stay just ahead of the curve because typically I was leading the curve. (In my office, we don't have a lot of technophiles, so I get to keep my job because no one knows more than me, still.) I'm going to need to lead again—and once again, I have a chance to look particularly brilliant. I'll actually buy another license for software that no one yet knows how to use, and I'll relax in the comfort that a few folks will figure it out. I'll let them figure it out as they need to.
Although my clients still don't use Outlook correctly, they're learning it (slowly.) And they didn't have to go through many different iterations. They'll learn to get in the Groove, too. And they'll learn it because they'll find it useful, not because I told them they needed to use it.
What I will do is provide Groove as a tool. One day, my clients will come into work, and they'll have a new icon on their desktops. I'll force an upload on some forthcoming weekend, and "Poof!" Everyone will have Groove on their machines. No one will know what to do with it, so I'll send out a little email message that says: "You may have noticed that a new program was downloaded on your system over the weekend. This new tool, called 'Groove,' will allow instant communications with everyone in the company, and with those outside of the company who install the software." I'll then tell everyone to update their vCards (which they don't know they have), and wait until a few managers come back and tell me how they're using Groove.
Of course, I could train them how to use it right up front. But that would make it seem like they have to use it, and they don't. Many will not, in fact. Those who do will find it to be tremendously helpful, and I'll just keep installing more bandwidth to accommodate our ever-growing need for sending more information to more people than could possibly be able to use it. And, when the office gets real quiet, I'll use the computer for its intended purpose (playing the newest version of Civilization.)
I'll write a few more articles about Groove to tell you how to use it. You'll want to read them because the documentation sent by the company spends much more time telling you how to install it (installation is easier than most programs—it really does all the configuration you need), and no one in your company ever needs to know that it was simple to install. (It runs around your firewall by going through Port 80—which you kindly leave open for your Web browser.) You don't have to configure anything.
Groove won't change how YOU use the computer, but it will definitely change the way your clients use the system. Ultimately, it will cut down on expenses—particularly travel. Groove is really a neat way to communicate. It will become a very useful tool in your enterprise. And, if you don't implement it, your company will end up cluttering your network with 10 similar products, each fighting for support. The cost of using Groove will be around $40.00 per machine.
Before I end this article let me reiterate one item I mentioned a paragraph back. Don't distribute Groove's documentation to your clients. More than half of the 12-page manual is devoted to items such as "How to install Groove," "System Requirements," and stuff that should be invisible to the users. Someone will one day write a friendly user manual for Groove. It will never mention the system requirements or that the software needs to be installed. Instead, the correct user manual will just tell your clients how to chat with it, or how to send a document to someone else already "In the Groove." It will also talk about some security issues (such as the irritating use of "passphrase" instead of "password" in all Groove literature and, frustratingly, on the actual implementation.) Then, you will find ways in which you, too, can use the new Groove software to play games (with other humans).