describe an integrated, process based, best practice framework for managing IT services. To date, these books are the only comprehensive, non-proprietary 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 better 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 support change management but also insist on it.
Another important aspect of operations is performance management. Performance 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 provided by the operations group are being properly met, the group must quantify 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 respond to user requests within four hours of receiving a request. Another example 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 metric dictated by the business. Often IT managers will implement a “dashboard” 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 component to providing good service.
The IT Operations area typically receives less attention than the applications 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 communication with the IT department for many corporate users. Therefore, an effective operations department is critical to good customer service, the perception of a well-run IT department, and a high level of customer satisfaction. By implementing standard operating procedures, service level agreements, 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.
Information Technology
449
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, services, 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 manageable chunks.
Project management is not as interesting as knowledge management. Project management is not as sexy as portal technology. Project management is not as fascinating as a new operating system. Yet, project management is necessary 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, project 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 certain rigor along the way. A good starting point for developing a framework is Microsoft’s web site, where it offers significant information on its recommended 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 ensures 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 prioritizing 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 process. Even for skilled project managers who write well, a standard document template can ensure best practices are followed and keep them on the essential points, shortening the documents delivered.
Documents should be well focused. They should be written for their intended 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 detailed 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 audiences 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.