CHAPTER 4
Scope of Maintenance
as Stephen R. Covey wrote in the Seven Habits of Highly Effective People, Habit Number 2 is, “Begin with the end in mind.” This is the basis for successful planning. Let’s begin maintenance with the end in mind. So, in the end, what does a maintenance team actually do, and what services should be included?
This chapter presents the very heart of IT maintenance, as depicted in the maintenance Process Groups Diagram in Figure 4-1. The Executing Processes are the core services of what maintenance performs (executes) and is represented in more detail later as the Maintenance Machine. The Maintenance Machine and the corresponding Controlling Processes depicted in Figure 4-1 represent the end point that we will strive to attain.
Figure 4-1: Maintenance Process Groups
You can think of the Maintenance Machine as something you build and improve over time. You, the manager, are not part of the machine, but you build, improve, and control it (Figure 4-2, Basic Model). You can expand the function of your machine by processing totally new inputs (e.g., supporting new IT systems) without much modification (modifying processes) of the machine itself (Figure 4-3, Expanded Scope Model). When your machine runs effectively and efficiently, you can duplicate the machine for other maintenance teams in your organization (Figure 4-4, IT-Wide Model).
Figure 4-5 presents the detailed diagram of the Maintenance Machine. Yes, it is a process flow diagram, but we use the analog of a machine since inputs (requests) are processed and converted to outputs (information or changes) with resources (people’s time) consumed in the process.
Figure 4-3: Expanded Scope Model
In project management terms, the activity boxes in the Maintenance Machine (Figure 4-5) represent the Executing Processes. This is what your team members will perform and deliver. Some of these activities are obvious to your customers and users, while others are more obscure. This chapter provides a brief description of these activities. Part III, “Executing Processes,” expands critical activities in greater detail.
The Controlling Processes are not represented in the Maintenance Machine figure. The Controlling Processes exist to ensure that the Executing Processes (Maintenance Machine) activities are effectively completed and continuously improved. This is an important distinction and similar to what’s done in new development projects. There is a separation between what is being delivered and the management layer. In projects, Executing Processes are the “doing” of what your project plan identified. In IT maintenance, Executing Processes are the “doing” of the steps to deliver quality service. In both projects and maintenance, Controlling Processes are the oversight that makes sure things stay on track.
The Maintenance Machine represents one view of the scope of IT maintenance. This is a generic view of the activities or services performed. The other view is the list of components supported—an important list that lets everyone know what is supported. Components can be whatever you define that is understandable to the business customer and can include stand-alone programs, modules of a software package, interfaces, reports, and other batch jobs. This second view is the list of what the Maintenance Machine’s generic steps work on and will be covered in more detail in Chapter 5, “Service Level Agreement.”
Figure 4-5: The Maintenance Machine
The large box of the Maintenance Machine (Figure 4-5) is the maintenance function. The arrows from the left are methods for users and stakeholders to input into the maintenance process. The arrows to the right are the outputs. The arrows from the bottom are the groups involved, while the arrows from the top are the policies, procedures, and other documents they utilize. The internal arrows show the process flows.
The following sections provide a brief description of the internal processes (activities), inputs, and outputs of the Maintenance Machine. In many cases, there are references to chapters that provide further details.
Process Boundaries
Process Inputs
The Maintenance Machine shows five possible input methods from users, customers, or stakeholders into the maintenance function (the big box). They are through a phone call, a pager, a help desk, in person, or an e-mail. All these methods may not apply in your situation, or there may be others. Whatever the methods, they should be documented and understood by your team and the customer. The best place to specify these methods is in the Service Level Agreement. See Chapter 5, “Service Level Agreement,” for more information.
At first glance, determining input methods seems straightforward, but consider the following questions:
• Will you provide users with your team’s office phone numbers?
• Will you provide users with your team’s home phone numbers?
• Will you provide a hot pager number that is rotated among your team?
• Will you use a company-wide help desk that routes calls to separate team queues?
• Will your users contact you by e-mail?
• What other methods can be used to start an inquiry?
• Are there methods that the users might employ but are not recommended?
The answers to these questions must be documented in the Service Level Agreement.
Process Resources
Your IT maintenance team will be the obvious resource to perform the tasks defined in the Maintenance Machine. Chapter 10, “Team Management,” covers the “care and feeding” of your team. There may also be others involved in delivering effective maintenance beyond just your team. Some resources may be from other IT teams, and some may be from the business owners of the systems. In some cases, the business team could be responsible for answering process questions and could even handle system administration issues like adding new users. There may even be a separate training department that trains new personnel on the computer system and business processes. You may have other resources to consider for your specific circumstances. In any case, all this should be clearly documented. The best place to document this is in the Service Level Agreement.
Policies, Procedures, and Other Documents
How your maintenance team operates should be consistent with the operations of other maintenance teams in your organization and, to a lesser extent, consistent with all IT teams in your organization as well, including project teams. Each team doing their own thing is less efficient than consistent best practices. Standard policies and procedures, written concisely and communicated to the teams, will provide this consistency. This book can provide the basis for consistent operating policies and procedures for your entire maintenance organization.
Definitions:
• Procedures are step-by-step instructions for completing a task.
• Policies are the accepted practices and boundaries for the actions of team members.
If you are developing policies and procedures from scratch, there is a big benefit from having the team and representatives from other teams determine the content of the policies and procedures. Doing this will help foster their buy-in and create better approaches than just one person could (assuming, of course, that the manager doesn’t know everything).
Over time, you most likely will continue to add to the team’s policies and procedures. Any specific situation where your team doesn’t perform effectively can be turned into an opportunity to improve policies and procedures. You can conduct a “lessons learned” session and document the conclusions by adding them to the policies or procedures so that a particular problem doesn’t occur again.
Process Outputs
A major output of the Maintenance Machine’s process is communication to stakeholders. This level of importance on communication makes sense considering that stakeholders don’t necessarily understand what the maintenance team does in the course of carrying out its normal function. Chapter 18, “Communication and Beyond,” will go into more detail about communication.
General communications to consider using are the status reports and metrics that are commonplace and sent out frequently. Other communications are related to specific requests: answering questions, system administration, data fixes, defect fixes, enhancements, new release migrations, and performance tuning.
Keeping the requestor updated is critical, but it is a highly appreciated art to consider what information is most important to the requestor and to deliver only that information. This art is part of developing a communications plan, which is covered in Chapter 18, “Communication and Beyond.”
Besides communications, software migrations are another major output, whether it is modified programs or totally new programs. Software migration is typically what most people think of when considering the maintenance function.
The last output is the non-programming changes made to the system that consist of data changes and system administration changes. These changes are less involved than programming changes; however, your policies should state whether or not the changes should be tested in a non-production environment first.
Inside the Process
Customer Care
The preceding process input section offers multiple methods for a user/customer to engage your team to start an inquiry. Regardless of how they engage, customers will enter the Customer Care box of the Maintenance Machine. This box focuses on the customer experience. You, as manager, are responsible for the way your team addresses customer contacts, including the response time to the user.
Consider the perception that you want the customer community to have about your team. There seems to be a basic distrust when a customer has a problem and he has to turn it over to someone he doesn’t know. When he doesn’t hear back from the maintenance person, his imagination kicks in and he sees the maintenance person with his feet on the desk playing video games.
Courteous responses, frequent status updates, and effective resolutions from your team will help foster trust among the customer community. A high trust level will be a major asset to you. You may leverage this trust level by not having to provide overly frequent status updates, and the customer may in fact be less demanding because he trusts you and knows he doesn’t have to demand attention. See Chapter 5, “Service Level Agreement,” for information about documenting your commitment to the customer base.
Work Tracking
Reporting all the requests, defects, and enhancements after the fact can be an overwhelming nightmare. Setting up one database to track everything is the solution. The database tool you use for tracking must be workable for the volume of data and the number of people accessing it, but beyond these requirements, any tool should work. A spreadsheet most likely would be too limiting, but a database system or even a test defect-tracking system could work.
What must be tracked?
• Calls with basic questions
• System admin changes
• Defects and their fixes
• Enhancement requests
With this information in one place, it will be easy for you to slice and dice the data to answer questions on how your Maintenance Machine is working and what improvements may be needed. The Work Tracking Tool will help you answer questions from your boss or key business contact that come to you in the future—questions that you have not even thought of yet. See Chapter 11, “Workflow Tracking,” for more information.
Status Tracking
Tracking outputs will include producing status reports on all of the maintenance functions and communicating the metrics. If set up appropriately (as depicted in the Maintenance Machine figure), much of the status report can be generated from the Work Tracking Tool to provide useful information to the customer and IT leadership. The recipients of all communications should be spelled out in the communication plan. See Chapter 18, “Communication and Beyond.”
Answering Questions
One of the simplest things your team will do is to just answer the straightforward questions that customers ask. This is a lot simpler than tracking defect fixes or enhancements. However, even simple questions should be tracked in the Work Tracking Tool to provide a full picture of the work your team performs. Without this record of your work, you and the business will ignore this part of the service provided by your team.
If certain questions are frequently asked, this may be indicate a lack of training of employees. Create easy-to-use job aids for employees. User manuals are great to have, but not everyone wants to read them. Develop frequently asked questions and answers; a one-page, double-sided sheet can be less intimidating to the user and will be more readily used. Help end users to utilize the full potential of the systems for the company’s and their own benefit.
All of this assumes that your team members are capable of answering the questions. Making sure your team is knowledgeable is not a trivial task, especially when there is high personnel turnover. Chapter 10, “Team Management,” provides more information on this subject.
System Administration
System administration involves using built-in system functionality to modify the system to meet a need. Some basic examples are to add users, remove users, and add values to option lists. These are the functions that a basic user cannot perform, but they can be performed by someone with the appropriate level of system rights.
IT team members or other employees can perform this function if they are granted the appropriate system rights. The key is to ensure that the correct authority approves any request.
Data Fixes
There are times when the customer uses the system but gets to a point where the system does not allow proceeding further. This situation is typically due to the workflow restrictions set up in the system. An example of this is when the user enters information and then cancels the entry. The user may want to recover what he or she first entered before canceling the entry, but the system may make that impossible. IT maintenance, with the appropriate system rights, could force the status change and thus resolve the problem. Sometimes these requests are just that simple; at other times they are complex, as in a data load where complex data is loaded into multiple tables.
Defect (Bug) Fixes
A major part of system maintenance is fixing software defects commonly known as bugs. Defects are defined as the circumstance when the software does not function as advertised. Some IT professionals use the term “undocumented feature” to describe functionality that is not defined, even though the customer considers it a bug. We will view this subject from the customer’s perspective.
Defects raise the anxiety level of customers, who may say, “Fix this bug now. How dare you give me a computer system that doesn’t work right?” Priority and business severity play an important role in determining your team response. Even though a low-level user may consider this a high priority, the defect may have no significant business impact, and if that’s the case, your team should work on other priorities.
Your team may fix the problem if you have the source code, or you may have the vendor who provides the system fix it. See Chapter 13, “Incidents, Defects, and Enhancements,” for more details.
Enhancement with Estimates
Enhancements are defined as modifications to the system that change the current functionality. Enhancements need a higher lever of scrutiny in order to determine if and when an enhancement should be made. Defect fixes, on the other hand, most likely will need to be resolved quickly.
There may occasionally be customer disagreement about whether a change is an enhancement or really a bug fix. This will have to be worked out on a case-by-case basis, but in general, if the system is performing the same as when the customer tested and accepted the system, then the change is an enhancement.
Similar to the defect fixes, the enhancement may be made by your team if you control the source code, or by a vendor if it controls it. The latter may involve negotiating the schedule and cost if a contract doesn’t already address this case.
Accurate estimates are needed for enhancements to help the business to determine which enhancements to proceed with based in part on return on investment (ROI). Chapter 13, “Incidents, Defects, and Enhancements,” provides further details on enhancement management and estimating.
Vendor New Releases
As if there wasn’t enough to do already, the maintenance team needs to keep track of what new releases the vendor is providing, if the vendor has that responsibility. The vendor’s release could provide additional functionality or fix defects that may or may not be adversely affecting your customers. In either case, this information should be tracked and communicated to the business to determine if the release should be tested and migrated to production.
Monitor Production
Monitoring the production systems is part of the unseen functions that the maintenance team performs without the stakeholders’ awareness. However, if your team isn’t doing an effective job of monitoring, the users will notice problems before your team does.
Monitoring should include making sure that each of the interfaces and batch jobs complete on time without errors. If an error occurs, appropriate actions should be taken. See Chapter 9, “Documentation,” for some of the items to monitor and document in a System Notebook.
Performance Tuning
As part of the monitoring of production, performance should be considered. Your company’s best minds may have implemented the system, but they did so based on assumptions of how many transactions would be handled and how large data tables would grow. Some of these assumptions may turn out to be false, and these assumptions may now adversely affect system performance. Ongoing tuning of the system will result in improved user access time and happier users.
Backup and Recovery
Creating backups of the systems is a basic system maintenance function—basic, but extremely important. The purpose of producing a backup of the system and data is not an end in itself, of course. The backups must be ready to be reloaded onto the system if required. To this end, you should practice recovering the backups to ensure that the backups produced are useful.
Disaster Planning
Disasters can strike without warning. Two potential disasters include a catastrophe on the IT system itself and a catastrophe affecting your IT team. Separate plans should be developed and tested for each.
The Disaster Recovery Plan should address how to recover system functionality if the supported systems are destroyed or unusable. The business need for these systems will drive the planning of the response; in some cases, a hot (currently running) backup system should be maintained at another location. In other cases where the business impact would be minimal, the system could be rebuilt with backup media on newly purchased hardware.
The Business Continuity Plan should address the risk of having your maintenance team unavailable to perform its function at its normal location and the loss of the tools used to perform the work. This situation can occur if your team’s work location is destroyed or if key team members are missing. Manually performing tasks that are normally automated might be necessary in some cases.
The customer (business) should also produce a Business Continuity Plan for its functions. The customer’s plan should include manual processing steps for cases in which a system catastrophe occurs and you are in the process of implementing your Disaster Recovery Plan.
Testing
Testing in maintenance is similar to testing in new development projects; the quality of the system or system components has to be confirmed. Test methods may be carried over from the development project, or you may have to establish them yourself. The customer should be deeply involved in the test process, since it is the owners of the system and knows how the software functions will fit into existing business processes. Chapter 14, “Testing,” provides a systematic approach to testing. This approach applies to fixes, enhancements, and mini-projects as well as large projects.
Migrations
Migration is the process for moving code changes into production. A major precursor of migration is the thorough testing and business sign-off of the testing. As the Maintenance Machine indicates, four processes cause or feed the migration: they are defect fixes, enhancements, performance tuning, and vendor new releases.
The migration process involves extensive coordination and communication with the business stakeholders. The migration may involve an outage of the system that could adversely affect business operations, so this should be minimized and performed after normal business hours if possible. Apply risk management techniques to increase the likelihood of success by developing a well thought-out migration schedule and setting rules for emergency migrations.
Configuration Management
Configuration management is the process for maintaining confidence that the system pieces are managed effectively and that they can be rebuilt to match production versions. Chapter 22, “Configuration Management,” provides more details on the subject.
Summary
This chapter outlined the core services of IT system maintenance and how these services interrelate. The intent was to provide you with insight on what the core services actually are—instead of using just the following three categories typically presented in a discussion of core services:
1. Keep it running.
2. Fix defects.
3. Enhance the system.
Taking too simplistic a view could limit your understanding of what could be improved. When you break down the overall maintenance function into its corresponding services, you begin to see interrelationships and possibilities of optimization that are not apparent when viewing the function at its highest level.
You will ultimately be judged on the success of the services you provide. Later in this book we cover Controlling Processes, but even those processes are focused on improving the success and effectiveness of the functions presented here as the Maintenance Machine.
Many of the functions are addressed in greater detail in Part III, “Executing Service Processes.” Let’s now further explore planning your maintenance team and documenting its scope in Chapter 5, “Service Level Agreement.”