I manage GartnerGroup's messaging environment, working from our IS&T department. I consider myself a service provider to the GartnerGroup business community. I'm not an analyst, so it is important to note that this article is not based on GartnerGroup research, rather, it's based on my experiences and those of my peers.

If you are in a similar position, you know that a clearly defined supporting technological or organizational infrastructure may not be in place. People "wear many hats." The network professional may also be the messaging expert, and PBX manager. One person, much less one department, rarely can focus on one area. Does it work? Usually not, but your organization may feel that it has no choice.

Take the opportunity of introducing a new messaging system to reevaluate old habits and engineer new methodologies. Regardless of your company's size, your users expect the new system to work, everything that touches it to work, and to work much better than the old system. You can no longer blame old technology, or old mentalities, as the excuse for not providing required services. We all know that no messaging solution will completely fit your business environment, but your users, and perhaps management, will expect it to. Messaging is ubiquitous. A successful deployment requires support from all Information Services and Technology (IS&T) departments, as well as the business units.

It ain't just e-mail anymore. If your management doesn't understand this yet, make them understand. Once the "meat and potatoes" of messaging and calendaring are in place, other applications and businessdrivers will start to become dependent on the messaging infrastructure. Implementation extends beyond providing your associates with an e-mail client on their desktops to developing a backbone that supports mission critical applications.

The key to a successful deployment involves participation of all of IS&T and your business community.

Early in the planning, tell people what you are doing. This comes way before you've initiated an RFI or RFP. Build excitement that a new system will soon arrive on their desktops. If your company has an intranet, publish an article on it. Better yet, start your own intranet website and keep it updated with plans and progress. Don't worry about giving people too much information too soon. Dispel grapevine gossip with early edition news. If writing isn't your forte, recruit assistance from other departments. Everyone wants to be associated with winners. People will find the time to lend a hand to projects they feel will be successful.

We used a variety of methods to build interest. We had the mailroom drop off a 3x5 postcard into each associate's mail slot—worldwide. We had T-shirts made that display the URL of our messaging website and we gave the shirts to anyone who worked on the project (or wanted to work on the project). I now see lots of people in the cafeteria "billboarding" advertising for us. The Help Desk gives out our intranet site as the place to get project information.

We began planning for a new messaging system in April 1997. Because GartnerGroup grows by acquisition, we inherit different messaging systems on different platforms. All GartnerGroup business units agreed that it was better to give up their disparate legacy systems for one enterprise-wide system. But which one? Each business unit has different business needs.

We developed a simple, two-page business needs assessment and sent it to about 30 associates representing all business units and functions, including small office/home office (SOHO) and local office associates. (We consider IS&T a business unit as well.) We analyzed it and sent our findings back to the people to whom we sent the survey—whether they responded or not. (By the way, we had a 75% response rate.)

By the summer of 1997, we had completed an RFI and were planning to pilot short-list candidate vendor solutions. We elicited participation across business units. During the pilot period, we conducted formal and informal surveys. Based on participant experiences, we worked with the candidate vendors. We responded to participants' feedback.

We started a business unit bible. The business unit bible is comprised of information we learned through what we called "in the trenches" meetings. We talked with associates such as those who staff the customer inquiry desk, handle sales and billing processing, and do research. We started to understand what makes GartnerGroup work and how messaging fits in. We learned what associates hated about their existing system and hoped for in the next. We also worked with GartnerGroup analysts in understanding industry trends. Most of all, we built confidence in the GartnerGroup community that we cared about deploying a solution that works for them.

In late August 1997, we made our decision. I wrote a business justification white paper and presented an executive overview to management. About a month later, an announcement presentation was made to a council of VPs of each business unit. Then we posted the business justification white paper to our website.

We had plenty of critics—those who felt that we'd made the wrong decision or felt that the project couldn't be pulled off. That's human nature. The most constructive criticism comes from critics. Listen to their concerns, act on their concerns, and they become your strongest allies.

We made sure that we communicated, directly or indirectly, with all GartnerGroup associates. We got buy-in by keeping everyone informed and involved.

By this time we had done our job well. Almost too well. People were so hyped that every business unit wanted the new messaging solution now. However, they also understood that it takes time to build a technology infrastructure. So for the next few months we developed our architectural backbone and started to understand how our new system worked. We recruited last summer's pilot testers and others to be users on the new system. We set expectations for admittance into this privileged club that one must have a high tolerance for pain and expect the worst.

Eventually, we began to understand our new system and opened admittance to include the average user. We're currently in the midst of rolling out the system—business unit by business unit. We asked each business unit to assign a point person to work with us. The point person is the primary liaison between the unit and the IS&T Messaging Team. As each business unit has unique needs, we run about a two to three week "beta" deployment with each before starting the real deployment. The point person sends out a user expectations document to each associate about two weeks before their planned migration. The document describes what IS&T will do and what the associate should do to prepare for the migration. The idea is to leave nothing to "but you didn't tell me."

Setting expectations goes beyond the user level. I routinely compile a risk assessment document for management identifying problems and problems waiting to happen, as well as how to mitigate them. Never be shy about owning up to problems or asking for help. Expect that no project will run as expected.

Sure, everyone thought they were ready, but when you start to plan your deployment you'll find that is not the case.

Can the business unit PC support your new system? Does it have adequate RAM and available hard drive space? Is there money in the budget to pay for upgrades if required? Whose budget will pay for it? Come to agreement with the business unit on who pays for what before deployment. Will your business unit point person take an active or passive role in the deployment planning? If you need to do several business unit rollouts in tandem, you'll need strong and committed point people. We developed a "point person roles & responsibilities" sheet that we review with each point person during the planning phase. If they can't do the job, we ask for someone who can. Do you have messaging-specific monitoring tools and processes that enforce accountability when "things go bump in the night"? Develop a Service Level Agreement (SLA) with your operations group. If your company doesn't use internal SLAs, this is a good time to start. Have you developed user documentation to supplement off-the-shelf manuals where required? We keep hard copy for training classes and an electronic copy on our website. Do you have a software distribution utility? In the absence of such a utility, how do you plan to install the client for mobile or SOHO users? One method is allowing self-installation. If you go this route, ensure that your self-install instructions have been tested and re-tested. Configure as much post configuration settings as possible in the "master" copy. Prepare your Technical Support Center for the expected support calls.

Recognize that users have needs that extend beyond differences in business units or job functions. At GartnerGroup, we have four basic types of users: hub office worker (where the user connects across the LAN to local networking and mail servers); satellite office worker (where the user connects across the WAN to networking and mail servers resident in hub sites); SOHO worker (where the user connects to a hub site across an ISDN or analog line); and Mobile or Roving worker (where the user connects to different hub sites across analog lines). From a systems perspective, we need uniformity, but most organizations are not homogeneous. If, for example, your business supports SOHO users, then so should your application.

Keep your administrative and system polices, procedures, and processes documented. Most people hate to document, but without it your system is victim to the "hit by the bus" syndrome. If the system administrators don't document, then hire a consultant or college student to do so for you. Distribute the documentation to all system administrators so everyone is doing the same thing.

Do you have a disaster recovery plan? There are many levels of disaster recovery. At a minimum, you need to understand your points of failure. Mostly importantly, document and rehearse. No one will be sympathetic when your system fails and you aren't prepared.

Be sure that your network can handle the increased traffic that the messaging solution brings. Have your networking administrators offer suggestions to ease the load. Make sure that desktop images are updated with the new messaging client. How embarrassing would it be if a new hire is given an image with the old messaging client? Ensure that your Technical Support Center understands how to support the new messaging solution. Work on proper hand-off of second-tier support calls. Use a good call tracking system and analyze the types of calls that come in.

If your messaging solution supports application development, who will do it? Develop system naming standards and procedures. Define what type of applications should be available for public consumption.

We understood that this was much more than our tiny planning group could or should do on its own. So, a core group was formed soon after we made the decision of which messaging solution to use. The group is made up of participants from many IS&T areas: Messaging, Training, Technical Support, Networking, Operations, with international representation. We started meeting for one hour twice a week, but have since cut our meetings down to weekly. Minutes with action items come from each meeting. In this manner, we uncover deficiencies and get everyone ready.

What will you be asked to do tomorrow? Your company's business needs will dictate what is considered a messaging stable—integrated faxing, workflow, document management—each bringing a new definition to routine messaging. Every step forward has a taxing effect on all your information systems and messaging architectures, which you must account for today. Design for the present, while planning for the future.

How will you support true ubiquity? Access to your e-mail anywhere, anytime, such as two-way pagers, with filtering to only accept the first few lines of a new message, web kiosks through which associates can access their mailbox from a hotel lobby or trade show across the Internet and secured through your firewall, voicemail that includes telephony hooks into the messaging system. Users listen and respond to e-mail through their voicemail and the recipients receive their "e-mail" response in traditional e-mail and/or via voice—the choice is up to the user.

Is secured messaging of concern? If you're not sure, ask your legal department. Does your company use Electronic Data Interchange (EDI)? You may find a shift from traditional EDI to messaging-enabled electronic commerce using initiatives like Business Quality Messaging (BQM). The term messaging has already evolved to collaborative technologies that enable multiple people to work together. Desktop audio and video conferencing and application sharing allows multiple conference participants to work together by having other conference participants see the same information on their screens—reducing travel costs, shortening project cycles, and developing relationships between associates who would never have had the opportunity for face-to-face communication otherwise.

Continue to work with your point people. Understand how your messaging system will need to change to meet their future needs. The crystal ball exists within your company and your reach.

About this time, you may be thinking that this advice wouldn't work in your environment. It's too big, small, bureaucratic, or autonomous. There's no time. No structure. Business frameworks are based on myopic views of the world.