IT Management Reference Guide

One of the primary characteristics of a world-class IT environment is that its key processes are well-developed and robust. These processes include those that are part of the infrastructure such as change management and problem management. They could also include application development processes such as production acceptance and the software development life cycle. These processes could also include business continuity and information security. This section prescribes how to develop robust processes, regardless of their placement in IT.

Robust processes have a direct tie-in to customer satisfaction in the following manner. We can satisfy our customers by meeting or exceeding their reasonable expectations. To do this, we need to deliver quality services consistently. The quality and consistency of our services are a direct result of the robustness of our processes. The customer/supplier matrix shown below can demonstrate the importance of processes that produce the key services that key customers require.

The first segment of this section describes 24 characteristics associated with a robust process. The second part explains how to differentiate a formal process from that of an informal one, and the importance of doing so.

Characteristics of a Robust Process

The following is a fairly exhaustive list of attributes that characterize the robustness of a process. In this sense, robustness refers to the resiliency and durability of a process to withstand abuse, enforce compliance, and be able to measure its effectiveness. In the common vernacular of IT, it refers to a process as being bulletproof. The intent of these attributes is not to categorize the robustness of a process as all or nothing. As with many items associated with technology, the robustness of a process comes in degrees. Missing a few of these characteristics doesn't mean that a process is weakly designed or poorly executed. In general, the more of these attributes that are present, the more robust a process is.

1. The objective is identified. An early step in creating a robust process is to state its overall objective, document it, share it with all appropriate parties, and ensure that all process-design participants agree to it and clearly understand it. The objective should answer the questions of what problem the process solves, which issues it addresses, and how the process adds value and quality to the environment.

2. The executive sponsor is identified and involved. Each process needs to have an executive sponsor who is passionate about the successful design and ongoing execution of the process. This person provides support, resources, insight, and executive leadership. The executive sponsor arranges for any required participation or communication with other groups, either inside or outside the infrastructure. This individual is often the manager of the process owner.

3. The process owner is identified and given responsibility for and authority over the process. This person leads the team that designs the process, identifies its key customers and suppliers, and documents its use. The process owner executes, communicates, and measures the effectiveness of the process on an ongoing basis.

4. Key customers are identified and involved. Key customers are those individuals who are the immediate users and direct beneficiaries of the process. For example, suppose you're designing processes to request the restoration of a file or the resetting of a password. Key customers for these processes may be users who are most likely to request these services on a regular basis. Their involvement in developing the process is important to ensure practical design and ease of use.

5. Secondary customers are identified and consulted. Secondary customers are those that may use a process less frequently than primary customers or who may be the eventual rather than immediate beneficiaries of the process. Using the example in item 4 above, if administrative assistants are making the original requests for file restorations, then their managers are likely to be the secondary customers of the process. Their consultation can be helpful because they may be the ultimate users of the process.

6. Process outputs are identified. These are the specific deliverables or services that the process provides to the primary and secondary customers. Service metrics usually measure the quality of the delivery and the content of these outputs.

7. Process inputs are identified. These are the specific input entities that the process requires. They may take the form of soft inputs such as data, information, or requests, or they may be hard inputs such as floppy disks, tapes, or other physical entities.

8. Process suppliers are identified and involved. Process suppliers are the individuals who provide the specific inputs to a process. These suppliers may be

• internal to an IT infrastructure (for example, data entry departments)

• external to an IT infrastructure but internal to IT (such as a development group entering change requests)

• external to IT but internal to a company (for instance, an outside user group supplying report modification information)

• external to a company (such as hardware and software vendors who may provide details about how an upgrade is to be performed)

9. The process is described by a sound business model. In simple terms, a robust process should make common business sense. The benefits of using the process should exceed the cost and efforts expended to design, execute, and maintain the process. The business side of a robust process sometimes involves leasing agreements, maintenance agreements, and service-level agreements.

10. Process hierarchy is understood. Some processes have secondary processes or subprocesses underneath them. Individuals who are developing well-designed robust processes know and understand the relationships between the primary and secondary processes.

11. Execution is enforceable. Almost any process, regardless of design, needs to be enforceable to be effective. Whenever possible and practical, software techniques such as passwords, authorizations, audit trails, or locks should enforce compliance with a process. When technical enforcement is not practical, management support, review boards, metrics, or other procedural techniques should ensure enforcement.

12. The process is designed to provide service metrics. Most processes measure something associated with their output. Often this involves a quantitative measure such as transaction processes per second or jobs completed per hour. In addition, a robust process focuses on qualitative measures that are oriented toward the end user. These metrics show the relative quality of the service being provided.

For example, service metrics involving a report-delivery process may include not only how often the report is delivered on time, but whether it was delivered to the right individual, in the correct format, with accurate content, and on the proper media. Service metrics should measure the benefits of the process to the end users in their own terms. Designers should orient the metrics toward the customer and should focus on measuring the right thing; that is, these metrics should exhibit effectiveness.

1. Service metrics are compiled and analyzed, not just collected. Mediocre infrastructures often invest a fair amount of time, money, and energy to collect and compile metrics; then they do little to analyze them. The real value of meaningful measurements comes from thoroughly and consistently examining these metrics for trends, patterns, and relationships and then applying the results of the analysis to improve the effectiveness of the particular service being measured.

2. The process is designed to provide process metrics. Robust processes include not only service metrics but process metrics. The key difference between a service metric and a process metric is that a service metric focuses on how effective a process is with regard to a customer, and a process metric focuses on how efficient a process is with regard to a supplier.

3. Process metrics are compiled and analyzed, not just collected. We need to compile and analyze process metrics, just as we do with service metrics. Analysts sometimes overlook the importance of analyzing missed process metrics when the associated service metrics are met. This could be the case in terms of a service metric involving output delivery being met, even though the job and its output had to be reprocessed numerous times. As with service metrics, the real value of meaningful process metrics comes from thoroughly and consistently examining them for trends, patterns, and relationships and then applying the results of the analysis to improve the efficiency of the particular service being measured.

4. Documentation is thorough, accurate, and easily understood. Documentation is one of the fundamentals that clearly separate mediocre infrastructures from those that are truly world-class. Well-written documentation facilitates the training, maintenance, and marketing of key processes. Progressive shops hold appropriate staffs accountable for reading and understanding key documentation by making it part of the performance review. These shops also have their new employees test the clarity and readability of the writing while ensuring that senior analysts and technical leads have validated the accuracy of the material.

Thorough documentation eases the tasks of removing all non–value-added steps and verifying that all required value-added steps are present. Effective documentation can come in various forms, including online and hardcopy narrative procedures, diagrammed illustrations such as flowcharts or bubble charts, and web-enabled help menus. IT analysts and technical writers can evaluate documentation in a variety of ways. Future sections of this guide will explain some of these methods to evaluate documentation more formally.

1. The process contains all required value-added steps. To use a legal analogy, value-added steps are to a robust process what the truth is to the testimony of a credible witness: The process should contain the value-added steps, all of the value-added steps, and nothing but the value-added steps. Two key attributes of a robust process are effectiveness and efficiency. Process effectiveness means that all existing steps are adding value to the end result. Key customers, suppliers, and process owners should meet prior to and after development of the documentation to identify all the value-added steps. This group should also ensure that they have inserted all value-added steps into the final process.

2. The process eliminates all non–value-added steps. If a step is not directly contributing value to the overall objective of the process, process designers should eliminate that step. This procedure is critical to eventually automating the process. Designers need to perform two activities to completely eliminate all non–value-added steps. First, they need to identify all the steps in a process, regardless of how small, even if previously undocumented. This comprehensive list of the exact steps of a procedure is commonly referred to as the informal process. Second, they need to evaluate each of these steps closely with an eye toward eliminating any steps that don't directly contribute to the desired outcome of a process.

3. The process guarantees accountability. Analysts should use process metrics, performance charts, and trending reports to quickly identify when a department or an individual is not following the prescribed procedure, with direct feedback to and consequences from management. For this design to work, process designers and owners need to give management sufficient tools to carry out enforcement. In turn, management needs to follow up with fair, timely, and appropriate actions to ensure process compliance in the future.

4. The process provides incentives for compliance and penalties for avoidance or circumvention. One of the most effective incentives for compliance is efficiency. If it takes more time and effort to go around a process than to go through it, most employees choose to go through it; that is, use the process. The challenge is to remove the obstacles normally associated with using a process and to insert roadblocks for circumvention. Properly streamlining and then automating a process can encourage its use. Security measures such as passwords and locks, as well as management measures such as exception reports and accountability, can discourage circumvention.

5. The process is standardized across all appropriate departments and remote sites. Designers may develop some processes at different remote sites at different times. This may cause the processes to have slightly different standards of implementation. For example, one of my clients had an older change-management process at a remote site based on an email system and a newer version at the central site based on an Access database system. Before optimizing either process, analysts had to agree on a standard. Nonstandard processes often come into play as a result of acquisitions, mergers, or takeovers. The technical challenge of implementing an agreed-upon standard is often much easier than the political challenge of actually reaching that consensus in the first place. This is because resolving a technical issue, for most IT professionals, is far easier and more desirable than resolving a political issue.

6. The process is streamlined as much as possible. Streamlining a process involves removing all non–value-added steps, eliminating redundant steps, placing the steps in the most efficient sequence, and streamlining individual steps as much as possible. For long-established processes, this goal may be difficult to achieve because users have employed inefficient practices for so long. Here are three of the most common responses that IT professionals get about why a particular process cannot or should not be changed:

• "We've always done it that way."

• "It seems to work most of the time, so why bother changing it?"

• "Analyst X designed this process, and only he can change it."

This last response can occur even after analyst X has left the department.

These explanations are not adequate justifications for keeping a process the same when improvements through streamlining are clearly warranted. Once we remove non–value-added steps, streamlining proceeds in this order: eliminate redundant steps, place the steps in the most efficient sequence possible, and streamline individual steps as much as possible.

7. The process is automated wherever practical, but only after streamlining. Automation can end up being either beneficial or detrimental, depending on how the automation is designed and implemented. Automating a poorly designed manual process results in a poorly designed automated process.

8. The process integrates with all other appropriate processes. Several processes within systems management naturally complement each other. For example, problem and change management are separate processes, but they often rely on each other for optimum effectiveness. Similarly, performance tuning and capacity planning are almost always closely related.

Formal Versus Informal Processes

Most IT professionals are familiar with the concept of a formal process. By this we mean a procedure or methodology in which all of the major steps are explained and documented. The write-up is normally signed by a manager in authority, disseminated to appropriate members of the staff, and made accessible for future reference in either electronic or hardcopy form. Written procedures on how to reboot servers, initiate online systems, or back up and restore data are common examples of formal processes.

An informal process is a far more detailed account of its corresponding formal process. An analogy from the culinary arts serves to illustrate this difference. Suppose you decide to duplicate a specialty of a gourmet cook by following her published recipe. You adhere precisely to each of the prescribed steps and create a dish that looks exactly like the original. But after the first bite, you know immediately that something just doesn't seem right. It's close but just a bit off the mark. Soon afterward you have the opportunity to watch this chef prepare the same dish in person. With her recipe in your hand, you note how she follows the steps in the same order as you did. But occasionally she swirls the pan briefly or adds a pinch of this and a dash of that—steps so seemingly insignificant as to almost be ignored. In this case, the recipe listing the steps is the formal process, but if the small, seemingly innocuous steps that make the dish taste just right are included in the directions, you have the informal process—the sum of all the actual detailed steps involved.

Documenting the small, critical steps of a process, little known and almost rarely recorded, is a prerequisite to effective process improvement, streamlining, and eventual automation. Shops unaware of the complete informal procedure associated with a systems management process often fail in their attempts to redesign it into a robust process due to tiny but significant steps being left out.

References

A Practical Guide to Information Systems Process Improvement (CRC Press, 2000), by Anita Cassidy and Keith Guggenberger.

IT Systems Management: Designing, Implementing, and Managing World-Class Infrastructures (Prentice Hall PTR, 2002, ISBN 013087678X), by Rich Schiesser.