Exhibit 17.4 Typical IT Operations Resources Required for Small- and Mid-Sized IT Departments (single location)

on a common cause. To fully build these teams, however, it is important for them to meet regularly. Consider having these teams meet at least once a month by conference call. Team members should be assigned action items and expected to move those action items to resolution and report on them regularly. Key members of the team should meet at least annually, in person, to discuss the more critical issues, plan for future development of the team, and build stronger interpersonal relationships. The relatively minor cost of these in-person gatherings is well offset by the benefits gained in system stability and overall technology expenditure.

One challenge with professional services companies is that sometimes offices are small. Even a small office, however, may need on-site support staff. This situation can cause the number of support staff compared to billable professional to increase, which, in turn, increases costs. This situation, however, can be mitigated with proper planning. First, the firm could simply decide that proper service to professional staff requires the extra cost. Even if a firm decides that in the first instance, its likely that the firm will put extreme cost of pressures in other areas of technology. Therefore, technology leadership must find a way to get the most benefit out of the local asset.

One way to accomplish this is to recognize that a local office IT person will be doing things other than support. Certain support aspects must be provided locally. It is not possible for a remote call center to change a hard drive or a monitor. Rather, it takes hands on, feet on the street in the local office. The local office IT person, however, may not spend 100 percent of his or her time conducting the support. Rather, he or she may also spend some time monitoring the servers, planning and executing upgrades, testing software, and performing various other projects. Significant cost savings can be

obtained by focusing on these ancillary tasks. Each IT person likely has strengths and weaknesses. If you can organize the tasks such that a local IT person is responsible for all of a regions efforts in a particular area, or potentially even the global firms effort in a particular area, then that person can take his or her nonsupport time and spend it in that area. By using other local IT support to fill in the other areas that are needed in that local office, all aspects of technology can be covered. The benefit of proceeding this way is that you are minimizing redundant tasks, such as each office creating its own intranet system, or setting its own standards.

For example, if left to fill its own needs, each local office would likely create a document repository. This system would have features unique to that office and would likely have a unique platform. Electronic document sharing between the offices would be more difficult because the disparate systems would be difficult to integrate. Minimizing redundant tasks is likely the single biggest way that a large organization with multiple offices, especially smaller offices, can control costs and improve services.

Standards

The nicest thing about standards is that there are so many of them to choose from.

-Ken Olsen, founder of Digital Equipment Corp., 1977

Everything in life thats easy is made easy because of standards. Standards and difficulty are inversely proportional. Plugging in your notebook computer is easy because we have a standard voltage and connector. Visit a different country and your life might be a bit more difficult. Your connector might not fit in the receptacle on the wall, so you would need an adaptor. Luckily, there is a standard adaptor to bridge between two conflicting standards. Even then, the power supplied may be a different voltage, requiring you to use a transformer. If you did not have the adaptor or the transformer, you would not be able to connect. Your life would have been made more difficult as a result of lack of standardization. You should pay close attention to this simple concept throughout your technology enterprise.

That is not to say that everything should be standardized on a global basis. Many standards simply do not lend themselves to global application, perhaps because they address local or regional issues or because they themselves depend on other standards that conflict between geographic locations.

With standards comes a loss of control. For example, a program that deals specifically with U.S. taxes may not need to be a global standard, but rather a U.S.-based standard. Also, when rolling out a system globally, standards between locations may differ based on particular building codes or power configurations.

How do you determine where to set a standard? Exhibit 17.5 illustrates a process to use for determining and setting standards by area. Standards should be set at the highest level in the organizational structure at which they make sense. A wide area-networking standard, designed to connect all offices together, should be set at a global level. An accounting standard designed to ensure that data from all offices is compatible should also be set at a global level. Likewise, an application that has only local utility should be set at a local level.

The real difficulty or a special difficulty comes when setting a standard at a regional level. Many times the regional distinction is more a matter of convenience than logical necessity. Support regions are often set up to provide local time zone and local language technology support. There is not necessarily a user difference or a system difference between the regions.

Some distinctions may exist, however, where regional business management is attempting to meet different strategic objectives. Because technology should align to the business strategies, and not vice versa, differences between regional standards may result.

Another reason for differing standards, the reason that should be sparingly applied, is the difference in the maturity of a region in a particular matter or in a particular area. For example, if one region is significantly mature in its support structure, that region may require a standard call center software and approach. That same approach may not be practical in the other regions based on maturity. In such a case, that standard may not be set for the other regions. The standard could be set once the regions are ready to adopt call center technology.

Standards dont have to be perfect. A cubit is an ancient unit of linear measure. It was equal to the length of the forearm from the tip of the middle finger to the elbow. While this was a handy unit of measurement as people always had their arms with them, it was not particularly precise. Depending on who applied the measuring, the cubit would be of different lengths. Yet, it provided an important way to measure. With modern need for extreme precision, distances are much more precisely defined. For example, a meter is defined as the international standard unit of length, approximately equivalent to 39.37 inches. It was redefined in 1983 as the distance traveled by light in a vacuum in 1/299,792,458 of a second. 6

When setting a standard, you must determine the reason that the standard is needed. Standards for standards sake do not advance the enterprise. In fact, they can do the opposite by limiting creativity. Also, you should communicate broadly when setting a standard. Every person in an enterprise who may be interested in considering the standard or to whom the standard would be applied should have the opportunity, at least indirectly, to comment.

This opportunity can be provided by an e-mail setting forth the projected standard or, better yet, an e-mail identifying the fact that a standard would