In keeping with the overall goals of the Microsoft Operations Framework (MOF) to support and guide distributed computing through best practice on the Microsoft platform, it is important to note that the Team Model in this environment looks and operates very differently from traditional centralized computing and hierarchical data-center operations teams.

An important concept that is unique to the MOF Team Model is the mapping of process ownership to organization functional models. For example, change management process ownership was much easier to delegate to a person in a centralized (mainframe) environment, where that person likely owned end-to-end change control for the system. Today, change management ownership crosses geographical, business unit, time zone, and even company boundaries and is therefore much more difficult to assign to any one person or group.

Organization functional models are closely tied to the processes used within them. The process responsibilities must be shared, which is why it is key to promote the use of standard best practices-such as the Information Technology Infrastructure Library (ITIL) and MOF-across the industry as the means to accomplishing such processes.

The extent and manner to which an organization adopts the MOF Team Model may vary depending on whether it is implementing a new data center or seeking to change an existing IT operations group. There may be additional considerations relating to geographical locations of staff, historical context of the organization, the willingness or readiness to change, reward systems, goals and hierarchical structure of the operations group, and any future changes to the business that may affect such a change. Organizational change is not to be undertaken lightly; it takes time to accomplish.

One possible approach in applying the MOF Team Model is to first identify the issues present within the existing IT operations group that are obstacles in achieving the business vision. For example, start by asking these questions:

• Are we covering all of the quality goals or missions of service?
  
• Are roles and responsibilities clear to everybody?
  
• Are we fulfilling business objectives?
  
• Is our organization healthy and able to quickly respond to business changes?
  

By determining the activities being performed by specific groups or teams and identifying the objectives that you have established, you can then begin to determine which functions may be missing, duplicated, or unnecessary, and what activities may be causing direct conflicts or breakdowns in communication. You can then develop a set of activities or wish-list of things that need to be corrected and which will form the basis of activities for a corrective action project plan.

You might consider amending job descriptions for particular staff, thereby realigning different staff to the role cluster they work within so that individuals have a single quality goal or mission of service to work toward. An individual's activities can then be focused on working toward a particular quality goal.

Another option might be to design a new organizational structure around processes, procedures, and work instructions. This top-down approach identifies roles and responsibilities from the processes and then creates job descriptions from them.

Several matrix management techniques are also available. These include:

• RACI (a list of activities in which the job description is Responsible, Accountable, Consulted, or Informed about that activity).
  
• RATE (that the job description has the Responsibility, Authority, Time, and Expertise to do the task).
  

Due to inherent staffing limitations and/or to achieve efficiency, smaller organizations will typically combine role clusters within their organization's functional structure. The following table illustrates role cluster combinations that are risky (as indicated by "N (Not Recommended)" or "U (Unlikely)" symbols) and synergistic (as indicated by "P (Possible)" symbols).

Table: Cluster Combination Risks and Synergies

The rows and columns that intersect with an "N" identify roles that should not be combined because of conflicting interests. The rows and columns that intersect with a "U" identify roles that are unlikely to be combined because the skills required for each role are quite different. The rows and columns that intersect with a "P" identify roles that are possible to combine because they have compatible interests.

These combinations are not absolutes. Some groups successfully share roles that the chart indicates are risky. But as with any teaming exercise, successful role sharing comes down to the actual members themselves and what experience and skills they bring with them to the role-sharing activity.