Essentially, organizational maturity is determined by the level to which an organization has developed its internal policies and procedures. For example, an organization with very few defined procedures for managing the messaging environment and that has no standard operating procedures for server configuration may experience more incidents and outages than another organization that has carefully documented policies about driver updates, patch installation, and server configuration.

However, organizational maturity is not restricted to the use of policies. It also includes the means by which administrators manage an environment. For example, an administrator can apply hotfixes to 10 servers by logging into each server, and then downloading and installing the hotfixes on each one in turn. This process is extremely inefficient. By contrast, one administrator using an automated patch deployment system could easily deploy hotfixes to 100 servers in a few minutes, exponentially increasing efficiency. However, that patch management solution would, itself, have to be actively managed. This requirement would demand more resources, and would have to follow specific policies and procedures to ensure a healthy, accurate solution.

Organizational maturity is built on the following principles:

• Operational process maturity:  Typically, if you have created well-documented and repeatable operational practices, the need for constant or reactive maintenance is reduced because most tasks will be automated.
  
  
• Experience:   The level of knowledge and relevant work experience possessed by the operations team members has a positive impact on the team’s ability to manage an enterprise messaging solution.
  
  
• Hardware:   Efficient systems and good storage practices help maintain a high degree of user satisfaction and can greatly reduce the number of support calls or outages.
  
  
• Reliability:   Related to hardware, reliability is a function of the combination of hardware, software, features that are in use, and the demands on the system. Often, a reliable solution is one that is chosen specifically to meet the full demands of a given workload.
  
  

  Note:
  Reliability is not a synonym for clustering. A clustering solution introduces additional complexity that may be unsuitable for organizations that don’t have experience.

• Design:   An appropriate design of the Exchange environment increases the effectiveness of all the aforementioned principles. Conversely, a poor design can cause the hardware or staff experience to be less effective.
  
  

The principles of organizational maturity are organized into organizational profiles that are known as the Infrastructure Optimization model, as shown in the following table.

Infrastructure Optimization model

For more information about Infrastructure Optimization, see Microsoft Infrastructure Optimization.

The key differentiator among the levels of the Infrastructure Optimization model is how technology is used and the standardization of systems across many levels and groups. Generally, the higher the organizational maturity level, the lower the required staffing level for managing the environment. However, technology by itself doesn’t increase an organization’s maturity level. All solutions must be managed to successfully support accuracy, efficiency, reliability, and stability. An organization’s policies should be driven by business need, and the technology should support or facilitate those policies.

Staffing levels are also heavily dependent upon the demands placed on the enterprise messaging team. These demands can vary greatly from organization to organization. An organization that asks its messaging administrators to deploy, configure, manage, and maintain only the Exchange Server 2010 systems will require fewer staff than one which asks administrators to manage Exchange, backups, messaging hygiene, mobile devices, network, storage, and virtualization technologies.

The following list includes some of the critical questions to consider when you evaluate the role of the messaging administrator in your organization:

• Does your Exchange team have primary responsibility for the underlying Windows operating system on the servers that are running Exchange?
  
  
• Is your Exchange team responsible for other technologies, such as Active Directory Domain Services, Microsoft SharePoint Foundation 2010, or Microsoft SQL Server?
  
  
• Does your Exchange team manage the physical hardware of the Exchange environment, such as servers, network, and storage? Or, if your Exchange servers are virtualized, do the Exchange administrators manage the virtualization solution?
  
  
• Does your Exchange team manage backups (tape-based or disk-based) for the Exchange servers?
  
  
• Does your Exchange team manage the messaging hygiene infrastructure? Does your Exchange team manage non-Exchange software or hardware?
  
  
• Does your organization separate the roles of operations and design/architecture for messaging?
  
  
• Does your Exchange team manage network or perimeter security for messaging?
  
  
• Does your Exchange team perform direct end-user support? If so, does the team receive all messaging-related tickets or only those that have been escalated from tier 1 and tier 2?
  
  
• Do Exchange team members perform standard daily, weekly, monthly, quarterly, or yearly tasks? If so, what are those tasks? What additional tasks should be added to the list?
  
  
• Are Exchange team members responsible for responding to security issues involving messaging resources?
  
  
• Are Exchange team members asked to perform discovery searches and handle other compliance-related matters?
  
  
• Do Exchange team members perform capacity management?
  
  

This list isn’t exhaustive. There may be critical tasks for messaging administrators in your organization that are not listed above. Additionally, there are other positions, such as operations manager, whose job description and required tasks are markedly different from those of messaging administrator. It’s important to consider all positions in the context of the entire team rather than focus on individual positions.

The following list describes the potential responsibilities assigned to roles and functions that are common to many large and medium enterprise messaging deployments. In many cases, the listed role is a subset of an existing role (for example, Director) instead of a specific position. For example, this is the case of Operations Engineers.

• Director
  
  
  • Provides messaging technology vision based technology capabilities and business need.
    
    
  • Coordinates activities of messaging operations and messaging system engineering.
    
    
  • Represents all aspects of the enterprise’s messaging system to internal and external sources.
    
    
• Manager, Messaging Operations
  
  
  • Makes sure that the messaging system is functioning at peak performance.
    
    
  • Makes sure that the messaging operations team is aware of system slowdowns and performance degradation before these problems affect users.
    
    
  • Makes sure that all messaging operations technicians and all operations analysts have the tools they need to do their jobs.
    
    
  • Represents messaging operations to users.
    
    
• Manager, Messaging System Engineering
  
  
  • Drives the messaging team towards constant analysis and design review with the goal of improving the messaging system’s performance.
    
    
  • Makes sure that the messaging team has the necessary tools and training to do their jobs.
    
    
  • Responds to appropriate escalations from the operations team and allocates resources to those escalations.
    
    
• Associate Operations Analyst
  
  
  • Installs, configures, and documents new production servers in the messaging environment.
    
    
  • Performs rudimentary troubleshooting of messaging system problems.
    
    
• Operations Analyst
  
  
  • Installs, configures, and documents new production servers in the messaging environment.
    
    
  • Performs all troubleshooting of messaging system problems.
    
    
  • Ensures that problems are correctly documented in the daily log.
    
    
• Senior Operations Analyst
  
  
  • Assists with mentoring new Operations Analysts; performs duties of the Operations Analyst when required.
    
    
  • Handles escalation issues not resolved by Operations Analyst and Technicians.
    
    
  • Makes sure that the daily log remains a useful repository of system troubleshooting information.
    
    
• Associate Operations Engineer
  
  
  • Works with Operations Analysts and Technicians to perform rudimentary analysis and design.
    
    
  • Brings ideas and recommendations to other members of the engineering team for further discussion.
    
    
• Operations Engineer
  
  
  • Works with Operations Analysts and Technicians to perform detailed analysis and design.
    
    
  • Handles initial escalations from the operations side
    
    
  • Troubleshoots and follows up on all escalations from operations team.
    
    
  • Evaluates features of released products for usability in the enterprise messaging system.
    
    
• Senior Operations Engineer
  
  
  • Evaluates released and unreleased messaging systems.
    
    
  • Provides detailed test plans for features to be implemented.
    
    
  • Attempts to minimize all impacts of next generation releases of message product.
    
    
  • Handles extreme escalations and interfaces with Microsoft Technical Support, if necessary.
    
    
• Messaging Operations Technician
  
  
  • Handles day-to-day monitoring and reporting on the messaging system.
    
    
  • Ensures that events are properly recorded in the daily log.
    
    
  • Ensures that all events that transpired during his or her shift have been recorded and reported to appropriate personnel.
    
    
  • Also handles escalation requests from standard “PC Helpdesk” department.
    
    

To increase the accuracy of any workforce staffing level calculations, it helps if you clearly define the roles of the various messaging team members and then objectively assess the demands of those roles.

After your organization has defined the various roles and responsibilities, the next step is to assess the technology, and then map the desired tasks to the technical components of the solution. Often, improvements in the software may let administrators complete specific tasks much quicker than in previous versions, may enable administrators to automate common workflows, or may enable administrators to delegate specific tasks to other individuals or other teams.

Consider this example. Woodgrove Bank administrators often receive requests to restore mailboxes to retrieve mistakenly deleted items. These requests require the involvement of a messaging engineer (who has the necessary permissions to access the Exchange Server 2003 systems), as well as a backup engineer (who handles the actual restore operation). The requirement to restore deleted content will still be present after Woodgrove Bank deploys Exchange Server 2010, but if they choose to enable single item recovery for all users, the actual restoration work could be performed by a messaging administrator (who was granted the appropriate permissions via Role Based Access Control) or by a compliance administrator in the Human Resources department. Because the backup engineer is no longer involved in the restoration operation, the overall process is simpler and presumably can be completed in less time.

Exchange Server 2010 includes several features that could potentially let management reassign tasks at different levels, to different teams, or eliminate the need for the task completely. The following table describes several major features in Exchange Server 2010, together with the changes to tasks that these features may support. The features described in this table aren’t an exhaustive list. Of course, you may choose to employ these features at your discretion.

While the above list is specific to Exchange Server 2010, the principle of matching task to technology holds true no matter which version is in use. Using the technology to its fullest lets administrators perform their duties in the most efficient manner possible, freeing their time for other tasks and reducing the demands on other teams as well.

As stated at the beginning of this topic, there is no simple formula to provide a specific recommended number of staff to manage a given Exchange organization. The range of factors is too complex and too varied. Two organizations of similar size and scope may require vastly different staffing levels based on the required duties of the administrators, the administrators’ experience managing Exchange, and the degree of automation in the environment.

The most important factor to consider when calculating staffing levels is the amount of time that is needed to perform all required tasks given the current infrastructure. It may also be appropriate to calculate the amount of time that is required to perform all desired tasks given an idealized infrastructure, if significant changes will be made to the environment which would increase the operational maturity level. The sum total of hours is then translated into a recommended staffing level, taking into account other factors including the length of the work day, the length of the work week, and the average number of vacation and sick days. The staffing level should always be rounded up to the next integer value to ensure that staffing levels exceed the required time rather than fall short.

The following sample Exchange Operations task checklist indicates the level to which tasks should be detailed before staffing levels are calculated.

SAMPLE - Exchange Operations Task Checklist (per location)

In this example, the organization determined that the total number of tasks requires 9,792 hours. Given that a full-time employee works 1,635 hours, this analysis suggests that the organization requires 600 percent of a single individual—or, more appropriately, six FTEs—to manage their Exchange organization. Note that this sample task list is for the operations team only. The customer has to perform the same analysis for the engineering and help desk teams, as well.

The number of positions also depends on the complexity and size of the organization. Small organizations may combine roles or omit them entirely, while large organizations may have multiple individuals in certain roles. For example, one large financial services corporation has a messaging team which manages resources for 45,000 users on a 24 hours a day, seven days a week basis. Their messaging services staff typically includes 30-32 individuals in the positions shown in the following table (whose roles and responsibilities are defined in “Defining Roles and Assigning Tasks” earlier in this topic).

To determine the number of engineers, administrators, and other support personnel that are required to manage a specific Exchange environment, you must carefully gather business requirements, consider a variety of factors, and, above all, plan. You can determine your required staffing level only after you determine the needs of the user community, define the roles to fulfill those needs, assess the technology, match the technology to the roles, and then, finally, calculate the time required to perform the desired tasks. It’s an involved process, but the ultimate results should closely align the capabilities of the messaging team to the needs of the business (and users) without unnecessarily encumbering either organization or team with superfluous head count.