Performing a Needs Assessment

A needs assessment is a two-part process. First, you must understand the current state of affairs in some detail. Then, using your knowledge about what is currently in place, you must come up with an analysis of need that focuses on both keeping the best of what is and developing new approaches where required. You should perform needs assessments in each of these categories:

• Users

• Geography

• Data networks

You'll probably find that assessing user needs will be the most difficult because you're dealing almost exclusively with people and their perceptions of their needs and those of your organization. You should focus on the fact that, in addition to being an e-mail system, Exchange is a platform for a range of collaborative applications. You also should remember that user needs and wants have significant costs in time, money, and computer and network capacity.

A geographical needs assessment focuses on discovery of network components, servers, and users and the buildings, cities, states, and countries in which they are located. You need to know what kind of computing capacity, networking hardware, and software you have. Then you need to determine what, if any, changes must be made to ensure that everyone in your organization can participate in your Exchange system at a reasonably optimal level.

Exchange is nothing without quality network links from workstation to server and from server to server. Your network needs assessment should deal with three key issues. The first is the location and nature of your network connections, the second relates to the bandwidth on your network, and the third relates to network reliability.

Assessing User Needs

Here you're interested in who needs what, when they need it, and how you'll provide it. You'll want to get a handle on the programming, software, hardware, management information services (MIS) systems, systems support, and training resources that will be required to satisfy user needs.

Remember that Exchange is an electronic messaging package, not just an e-mail product. Users might need specific electronic-messaging-enabled applications. Depending on what users have in mind, application development can be a real resource hog. Also remember that, in some cases, hardware and software might require new workstations, not just new servers.

Be prepared to give users a clear idea of what Exchange can do. You don't need to get technical with most users; just give them a view of Exchange from the end user's perspective. Take another look at Chapter 1, "Introducing Exchange Server 2007," and Chapter 2, "Exchange Server 2007 Architecture," to see how you might organize your presentation.

Keep in mind that one of the biggest mistakes that most people make when implementing a system is to ignore or give only passing attention to this step. Knowing as much as you can about what the users require up front means that you'll have an easier time during implementation. For example, imagine that you don't know from the get-go that your organization could benefit significantly from a particular custom-programmed electronic-messaging-enabled application. You go ahead and implement Exchange as an e-mail system with only the resources such an implementation requires. You get your Exchange system up and it's perking along just fine when, maybe three months later, some user comes up with this great idea for an electronic-messaging-enabled app. Boink! Suddenly you have to tell management that you need a few programmers and maybe more hardware to implement this idea that nobody thought of four or five months ago. I'll leave the rest to your imagination.

Note 

Regardless of what you find out in your user needs assessment, add a fudge factor in favor of more hardware and support personnel. Exchange has so many capabilities that you can be sure your users will find all kinds of ways to challenge whatever resources you make available. Depending on your users and their ability to get away with unplanned demands for resources, fudging by as much as 25 percent is reasonable. You can go with less fudge if your organization is particularly cost conscious and willing to adhere closely to plans.

Suffice it to say that a user needs assessment is the single most important part of the Exchange design process. Therefore, we'll cover it in more detail than the other Exchange design steps.

Questions to Ask

You'll want to answer a number of questions during your user needs assessment. Here are the major ones:

• What kinds of users (for example, managers, salespeople, clerical staff, lawyers, doctors) does your organization have, and what do they think they want from the new Exchange system?

• What sorts of electronic messaging services are different groups of users likely to need (for example, e-mail, calendars and scheduling, public folders, specially designed applications)?

• Is integration with other collaborative applications such as SharePoint required?

• In addition to LAN access, will users need wireless LAN and/or WAN access to your Exchange system? Will this access have to be secure?

• Which specially designed applications can be developed by users, and which must be developed by MIS personnel?

• Do all users need every capability from day one, or can implementation be phased in, perhaps based on user groupings? If you are migrating from an existing messaging system, can you start by simply replacing the users' existing functionality and then adding more functionality at later a time.

• What client applications will be used by the users? Outlook MAPI clients? Outlook Anywhere (RPC over HTTP)? Outlook Web Access? Outlook Voice Access? POP3? IMAP4? Windows Mobile and ActiveSync devices? Other mobile access technologies such as Blackberry and GoodMail?

• Is your organization affected by regulatory compliance such as laws that require specialized protection for some messages or mail retention for certain types of messages?

• What sorts of demands will users (or groups of users) put on your Exchange servers? Much of the information in this category can be used with Microsoft's Exchange server load simulation program to predict expected server load and project server hardware and networking requirements.

  • How many mailboxes will you create per server?

  • How many messages will the typical user send per day?

  • How many messages will the typical user receive per day?

  • How frequently will users send messages to others on their server? In their own site? In each of the sites in your organization? Outside your organization? (Be sure to break this down by the different kinds of external connections you'll have.)

  • How often will users read messages in their mailboxes?

  • How often will users read messages in public folders?

  • How often will users move messages to personal folders stored locally and on the network?

  • How often will users move messages to public folders?

  • How big will the messages be? What percentage will be 1KB, 2KB, 4KB, 10KB, 40KB, 60KB, 80KB, 100KB, 200KB, and so on?

• What level of message delivery service will users want and need? This should be stated in hours or minutes between the time a message is sent and received. You'll need to specify this for both internal and external communications. Do you have a service level agreement that specifies expected response and message delivery times.

• What sorts of hardware and software resources (for example, computers, mobile phones, operating systems, Exchange client access licenses) will different groups of users need to implement Exchange on the client side?

• What kinds of training will be required for users or groups of users? Remember to consider training for administrators as well as training for anything that affects users.

• What sorts of MIS resources will be required to support user needs?

Studying Your Organization's Geographic Profile

You need a list of all the geographical locations in your organization. Here you should think not only in terms of cities, states, and countries, but also in-city and even in-building locations. Start at the top and work your way down. At this point, diagrams are important. Draw maps and building layouts.

This is the time to gather information on the workstations and servers you have in each location. You'll want to know how many run each of the different kinds of operating systems in your organization. Operating systems to watch for include these:

• Windows Server 2003

• Windows 2000 Server

• Windows 95/98/ME/2000/XP/Vista desktop operating systems

• Windows CE, Windows Mobile, and ActiveSync-enabled devices

• Apple Macintosh

• Unix workstations by type of operating system

• Workstations used remotely

If you have hardware and software inventories for these machines, including CPU type, RAM, and free disk space, your job will be a lot easier. You can use all the information that you collect about workstations and servers to determine who's ready for Exchange and how many client access licenses you'll have to buy. Don't forget that you need to determine how many standard client access licenses you will need versus enterprise client access licenses.

As you gather information in other steps, begin to look at it in the context of your geographic profile. For example, you'll want to meld geographic information with what you find out about user needs and user groupings.

More on User Workstations

Most user workstations are underpowered. That's a pretty strong statement, but I, Barry Gerber, stand by it. I limped along for quite some time running Windows 2000 Professional on a substandard 400MHz Pentium II workstation with 128MB of memory. Then I moved up to a 1GHz dual Pentium III processor and 768MB of RAM. When I ran Windows 2000 on my old, underpowered sleepwalker, it was all I could do to keep my word processor, a spreadsheet, and my e-mail software open at the same time. If I opened anything else, the machine started thrashing around so much between RAM and virtual memory that it slowed to a nearly useless crawl.

With my new system and Windows XP Pro, I can run word-processing programs, spreadsheet programs, and Outlook together without wasting precious time to switch among them. And I still have plenty of horsepower left for all those tasks that I used to do with paper because I couldn't bring up the applications fast enough when I needed them. At will, I can now simultaneously open - and keep open - such apps as an accounting package and Microsoft Word, Excel, Project, and PowerPoint. With all that computer power, I'm also no longer reluctant to run other key programs - say, web browsers or Control Panel applets - at the drop of a hat.

Here's the bottom line: I've had my new system for less than a year. By my estimates, the productivity increase that I've experienced in that time has already paid back the cost of the system's purchase.

May be all your users don't need a dual 1GHz Pentium system with Windows XP Pro and 768MB of RAM. However, as you start assessing user needs, don't let the dismal state of your organization's stable of workstations stop you and your users from reaching for the stars as you think about potential applications for Exchange.

Assessing Your Organization's Network

In this step, you just want to know what your network looks like now. This isn't the place to get into what kinds of networking you'll need; that comes later. You need to answer three key questions here:

• What's connected to what, and how? (Okay, if you're counting, that's two questions.)

• How much bandwidth do you have on each network?

• How reliable are your networks?

What's Connected to What, and How?

Generally, in answering these questions, you should start at the top of your organization and work down to the domain or server level. For each link, name the following:

• Physical connection

• Networking topology

• Networking protocols running on the connection

For example, physical connection = local hardwire, networking topology = 100BaseT Ethernet, networking protocols = NetBEUI, TCP/IP, IPX/SPX, SNA. This information, especially when combined with the information you collected in steps 1, 2, and 3, will prove valuable as you start to plan for the Exchange connectivity that you'll need.

In looking at your organization's network, don't forget about connections to the outside world. Do you have connections to the Internet or trading partners?

How Much Bandwidth Do You Have on Each Network?

Although bandwidth begins with network topology (type of connection), such as 100BaseT, T1, and DSL, it doesn't stop there. You need to know how much of your network topology's theoretical bandwidth is actually available.

To assess the actual bandwidth on each of your networks, you need some help from a network monitoring tool. If your networks are Windows 2003, you can try using the performance monitoring tools that come with the operating system to get a handle on traffic. For Windows 2000 and 2003, select Start Menu Ø Programs Ø Asministrative Tools Ø Performance.

Tip 

Microsoft's built-in tools will tell you only so much about the usage of your network. Consider third-party tools when doing network assessments.

What you want here is a chart that tells you, on average, how much of a network's bandwidth is available during each of the 24 hours in a day. You'll have to take several samples to get reliable data, but it's worth it. A warning light should go on in your head if you're already using more than, say, 60 to 70 percent of the available bandwidth on any network during daytime hours and you're not already running a heavy-duty messaging system such as Exchange. With that kind of scenario, you just might have to make some changes in the network before installing Exchange. We'll talk about those changes later; for now, be sure to collect this data on available bandwidth and incorporate it into your organizational maps.

How Reliable Are Your Networks?

Having a reliable network is an important issue. Increasingly in corporate America, there is strong pressure to centralize network servers. Centralization makes good economic sense. If all network servers are in one place, one set of staff members can support and monitor them, ensuring 24-hours-a-day, 7-days-a-week uptime.

Of course, 24/7 server availability is useless if the networks that people use to get to the servers are unreliable. We've seen this scenario play itself out in several organizations: They centralize the servers, the network fails, users can't get to their now mission-critical e-mail and other data, responsible IS planners are roundly criticized, and lower-level IS personnel are even more heavily criticized or fired. Grrr!

Here's the bottom line: Don't make your users work on unreliable networks. If your networks can't come close to matching the reliability of your servers, put the servers closer to their users. The little extra that it costs to manage decentralized servers is worth the access insurance that it buys. Sure, get those networks up to par, but don't risk your Exchange implementation on centralized servers before a reliable network is in place to support them.