<<

. 76
( 92 .)



>>



Scope of Operations
Operations incorporates the following processes and areas as shown in
Exhibit 17.6:

• Problem management (help desk)
• LAN/ WAN infrastructure and services management
• Systems and network security management
• Systems administration (patches, upgrades, tuning)
• E-mail administration
• User login and profile management.




Asset
Management Problem
Management
Demand
Management
LAN/WAN
Management
Disaster
Recovery
Security

Change
Control
Systems
Administration
Telecom
Equipment
Support &
E-mail
Administration
Administration

Operators




Exhibit 17.6 IT Operations
447
Information Technology

• Operators”daily systems operations (cost recovery, facilities, job
scheduling, output management performance, production control, and
quality assurance)
• Telecom equipment support and administration
• Change control (change requests, analysis of impact of changes, and
test plans)
• Disaster recovery (business continuity and contingency planning,
backup and restore procedures, and test plans)
• Demand management (service level management, service request man-
agement, and workload monitoring)
• Asset management (configuration management, contract and software
distribution management, and inventory)
• Systems and infrastructure uptime monitoring
• Systems and network capacity measurement and management
• Vendor management (infrastructure, hardware, and systems software)

It all comes down to how well you do operations. You can implement the best
systems, but if they don™t work consistently, they have little value. You can
develop processes, and if they are not followed, they might as well not have
been developed. If your operations are not smooth, if your downtime is not
kept under control, and if you don™t do a good job supporting your users, your
technology will be seen as a failure.
As with projects, operations™ needs a framework, a set of standard
processes. A good example can be found from Microsoft or the ITIL. Mi-
crosoft has developed its Microsoft Solutions Framework (MSF) to guide
technology operation projects such as an Exchange deployment project or
an infrastructure upgrade project. The Information Technology Infrastruc-
ture Library (ITIL) on the other hand is a set of books developed by the
United Kingdom™s Office Of Government Commerce (OGC). The books
describe an integrated, process based, best practice framework for manag-
ing IT services. To date, these books are the only comprehensive, non-pro-
prietary guidance for IT service management.
Change management. Change management is a process that controls
changes in the technology environment. Its goal is to minimize downtime and
surprises by proper planning, analysis, and communication.
Change management may slow down implementation in some instances,
but this should be supported by firm management, not resisted. It™s far bet-
ter to fully plan a change than to implement it on short notice and wreak
havoc on a production environment. The latter approach all too often results
in more downtime. For this reason, firm management should not only sup-
port change management but also insist on it.
Another important aspect of operations is performance management. Per-
formance management of the operations area is important because of the
448 The Back Office: Efficient Firm Operations

business critical to the nature of the services provided. Most companies have
a high reliance on operations infrastructures that they have created. Outage
of telephones, e-mail, and file and print capabilities can cripple a company.
This heav y reliance means that extremely high reliability is required of the
assets managed by the operations group. To ensure that the services pro-
vided by the operations group are being properly met, the group must quan-
tify metrics for measuring their performance. The process for establishing
these metrics begins with setting objectives based on business requirements,
determining targets, creating a service level agreement, and specifying the
targets. Once each service level has been defined and quantified each area
in operations, the CIO, and the business should sign-off on the agreed terms.
After the service levels have been defined and approved, the operations
team will track and analyze their performance and make adjustments in each
area depending on the analysis.
Each operations area should be managed on an ongoing basis according to
the performance criteria summarized in the service level agreement (SLA).
The SLA documents the expected tolerance levels that a particular process
should operate within. For example, it may state that the Help Desk must re-
spond to user requests within four hours of receiving a request. Another ex-
ample is the Wide Area Network must be available and operating 99.8
percent of the time.
The SLA spells out processes, procedures, policies, and targets for each
area. It dictates the metrics the IT groups will track. The SLA is essentially
the document that defines the acceptable ranges for each performance met-
ric dictated by the business. Often IT managers will implement a “dash-
board” as a mechanism of reporting the actual performance results against
those metrics in a simplified manner. The dashboard is created by selecting
one to two key metrics from the SLA for each IT process. The IT director
can also effectively manage each area by giving them a one-page dashboard
with appropriate SLA metrics.
For the SLA to be effective is must be created in cooperation between the
IT department and the business units. Operations departments that do not
have an SLA established with their business users are missing a critical com-
ponent to providing good service.
The IT Operations area typically receives less attention than the applica-
tions portion of the IT department. Yet, it often accounts for more than half
of the spending in the department and provides the tools and infrastructure
that users see most often. The help desk is the only interaction and commu-
nication with the IT department for many corporate users. Therefore, an ef-
fective operations department is critical to good customer service, the
perception of a well-run IT department, and a high level of customer satis-
faction. By implementing standard operating procedures, service level agree-
ments, process control, root cause analysis, and infrastructure investment
assessment methodologies, you can greatly improve the performance of the
operation team and the infrastructure they manage.
449
Information Technology

Projects
Weiler™s Law: Nothing is impossible for the man who doesn™t have to do it himself.
”Anonymous.

Professional services technology staff must consistently deliver systems, ser-
vices, process improvements, and capabilities to meet the firm™s needs and
support its strategic objectives. These must be done fast, right, and cheap,
with success as the only benchmark. To achieve this success, a firm cannot
allow project teams to continuously reinvent the wheel. A firm should have a
preset project framework to guide project teams from inception of an idea to
the closing celebration. It should work to follow project management best
practices. It should provide form project documents with standard processes
to follow. It should divide its projects into “quick wins” (described later in
the chapter) to deliver consistent and incremental improvements in manage-
able chunks.
Project management is not as interesting as knowledge management. Proj-
ect management is not as sexy as portal technology. Project management is
not as fascinating as a new operating system. Yet, project management is nec-
essary for any of these systems to be delivered successfully.
BASF Corporation, a major chemical company, had a well-advertised
motto: “ We don™t make the products you buy, we make the products you
buy better.” The same can be said of project management. Most often, proj-
ect management does not make the products you use at your firm, but
properly run projects make your use successful. So, project management
is about properly implementing knowledge management technology. It is
about creating valuable portal technology. It is about implementing new
operating systems. In fact, project management is about any incremental
change made.
Accomplishing this requires a project framework. This is a process that
helps project managers evaluate and execute their projects and ensures cer-
tain rigor along the way. A good starting point for developing a framework is
Microsoft™s web site, where it offers significant information on its recom-
mended MSF. While the complete MSF is likely too extensively documented
and too rigorous a process for most professional team projects, it is an ideal
starting point for developing a more streamlined process to fit a particular
firm™s culture and needs.
A framework formalizes a project management process and jargon. MSF
includes five phases: (1) envisioning, (2) planning, (3) developing, (4) stabi-
lizing, and (5) deploying. Being told that a project is in the envisioning stage
tells you a lot as long as the definition of envisioning and the processes in
that stage do not change from project to project. MSF has predefined “roles”
that project team members fill and that have predefined responsibilities.
This helps to ensure that team members know what they are to do, and it en-
sures that all needed responsibilities are covered in each project.
450 The Back Office: Efficient Firm Operations

For example, an IT department may be tasked with rolling out an accounts
payable system. If it just considers the technology aspects of that rollout, it
could easily overlook usability-related issues. A framework, however, should
require assignment of a product management role. This person is responsible
to ensure that the project satisfies its customers. The role could include a
focus on marketing, developing, and measuring business value, and prioritiz-
ing requirements. A framework might provide that the project manager
should never be the product manager, as the roles oftentimes are at odds with
one another. The project manager is oftentimes motivated by schedule,
whereas delivering features motivates the product manager.
A firm should define not only a framework and standard process but also
standard documentation. When drafting an agreement, a lawyer seldom
starts from a blank Word file. Most lawyers use prepared precedents, or past
agreements, as a starting point. These provide structure and key terms. They
keep the lawyer from reinventing the wheel at the client™s expense. The same
should be true for project managers.
Especially on smaller projects, it may be the first time a person has acted
as a project manager. The person may be a skilled technician, but not a
skilled writer. A standard document template can speed up the planning pro-
cess. Even for skilled project managers who write well, a standard document
template can ensure best practices are followed and keep them on the essen-
tial points, shortening the documents delivered.
Documents should be well focused. They should be written for their in-
tended audience. A document that describes the project™s objectives, scope,
business justification, and budget, and is intended for steering groups and
partners to read before the project is approved should be jargon free. A de-
tailed design specification may be jargon rich.
Documents should be short. The goal is to communicate. If you e-mail a
document to someone, who sees that it is 67 pages long, it is likely he or she
will either simply scan it or put it aside for later. If, however, it is 5 pages
long, it is much more likely to be read. If your documents never exceed 5
pages, reviewers will become accustomed to this, and you will receive better
feedback. Break longer documents apart to focus on issues for particular au-
diences if need be, but always keep them short.
Speed of implementation can be critical in a competitive market (e.g.,
whether to meet a client™s standard billing requirements, to provide an ex-
tranet, or to make an existing process more efficient), but it can be difficult
to balance speed against the need to select the right system and establish
clear user requirements and buy-in around the firm.
A firm should phase and structure projects to deliver substantial value
quickly and then follow up by providing the remaining requirements in a
later phase. This approach is referred to as “quick wins.” Phasing and struc-
turing allows projects and baseline efforts to deliver key requirements
quickly to meet the stated business demand. Requirements that are less
451
Information Technology

critical or simply harder to deliver will be scheduled for later phases of the
project to allow progress on the immediate requirements. The quick win
strategy, as a part of your project methodology, can increase customer satis-
faction and reduce the project™s exposure to risk.
A project framework, form documents, and a quick win philosophy pro-
vide certain economies. They keep project teams from reinventing the wheel.
They allow you to identify, coordinate, and control project interdependen-
cies. They help you move quickly to deliver value. But, perhaps most impor-
tantly, they allow the project teams to focus on the real issue, delivering the
project, and improve the chances that the project will be on time, within
budget, and deliver the expected value.
Project teams want to succeed. A project, however, is a minefield where
ignoring principals of change management or working to the wrong require-
ments or underestimating the effort can make even a project that delivers
what it promised look to its customers like a failure. A project framework
rigorously applied can help avoid these mines. It also provides the project
team comfort that it is proceeding properly and, as a result, instills an atti-
tude of success.
A valid business justification should support every project undertaken at a
law firm. This concept is easy to understand but oftentimes is hard to put
into practice. Since projects cost money, it is best to justify them with money
arguments. That approach is not, however, always feasible. A project might
be justified because the firm™s biggest client demands it. A project might be
justified because it fits the firm™s strategy. A project might be justified in
that it makes life easier for the firm™s attorneys, even if there is no direct fi-
nancial gain. In short, there is no one-size-fits-all solution to determining
business justification. There are, however, some accepted and customary ap-
proaches that should be considered.
For projects that will provide a direct and readily measurable income
stream or cost savings, a financial analysis may be appropriate. This analysis
can take many forms, but usually it includes a spreadsheet of project and on-
going operating costs set against income and cost savings over time. The proj-
ect may be justified from a business perspective if this analysis shows the
project breaks even or shows gain within a reasonable time period. This does
not mean, however, that other nonfinancial issues should be ignored; this fi-
nancial analysis is one justification, not necessarily the whole story.
For example, assume a mid-size office is considering whether to implement

<<

. 76
( 92 .)



>>