Medium 9781523096022

IT Maintenance

Views: 197
Ratings: (0)
IT Maintenance: Applied Project Management modifies project management best practices to improve how IT system maintenance is managed. By taking a fresh look at increasing value and quality of system maintenance in a straightforward and practical way, this book helps readers understand how to apply modified project management best practices. From IT maintenance managers, project managers, and team members to CIOs, readers will:
• Discover cost savings associated with reducing staff Improve reporting status and metrics
•Build greater customer satisfaction Learn how to perform work consistently
• Decrease staff stress level by stabilizing expectations
•Streamline team operations
•Decrease the manager's ongoing workload

PLUS! This practical reference is organized by process groups similar to the PMBOK® — providing you with applied step-by-step guidance.

List price: $49.95

Your Price: $37.46

You Save: 25%

Remix
Remove

22 Chapters

Format Buy Remix

Chapter 1 Introduction

ePub

Information technology (IT) professionals worldwide are searching for the “next solution” that can save money and improve quality. Applying standardized project management tools and techniques is resulting in handsome dividends on new development projects, yet new projects account for only half of IT professionals’ responsibilities. The other half is running system maintenance. It has been years since we saw the maintenance hype for the Year 2000 cleanup effort. Now is therefore an appropriate time to modify project management tools and techniques so they can serve the business of IT maintenance—the next solution!

Maintenance delivers a service, while projects deliver a product. Basic project management thus does not apply to maintenance. IT Maintenance: Applied Project Management modifies basic project management tools and techniques so they can be used to manage systems maintenance. This book demonstrates proven modified tools and techniques, reasons for using them, and ways to use the concepts presented in the book to lower costs while increasing customer satisfaction. Many Project Management Professionals (PMP®) will recognize the book’s concepts as extensions of PMI®-tested best practices in project management.

 

Chapter 2 Project Management Versus IT System Maintenance

ePub

applying the tools and techniques of project management to systems maintenance is not a straightforward process. Why not? The IT industry benefits greatly from project management best practices when managing projects. Can’t we apply these best practices to other endeavors in IT, such as maintenance? This chapter compares project management to IT system maintenance and answers these questions.

According to the PMBOK® Guide, a project is “a temporary endeavor undertaken to create a unique product, service, or result.” In IT terms, a project is established to deliver a new system, a major software revision, or a new hardware platform. Key project attributes are a unique deliverable and project start and project end dates. A project typically provides one major deliverable. Minor deliverables may also be included, but everyone focuses on the one major deliverable.

Contrast this with maintenance. Maintenance is not unique and has no clear end date. Just ask a manager running maintenance year after year. But the major difference is the deliverables. Maintenance is set up to deliver a service. No one major deliverable dominates everyone’s focus. The service consists of keeping things running the way they have been running and implementing enhancements to the system when requested.

 

Chapter 3 Outsourcing: The New Challenge

ePub

The growing subject of outsourcing entices executives with the promise of phenomenal cost savings and scares directors—and everyone else—with the prospect of job loss. In the news, the debate about whether outsourcing is an appropriate option continues. But from the boardroom, there is no debate; the only remaining question is how much will be outsourced and when.

The outsourcing market has matured over the last decade, during which the primary driver was the promise of extraordinary cost savings. The market today has many anecdotal stories of expectations falling far short of targets, however. The reality is that clients need additional resources to manage the relationship with the service provider, and some of the cost savings are lost. Clients of outsourcing have matured, and they now know these realities. The cost savings still exist and are still enticing, but realistic expectations are now in place.

For companies, the decision is a sourcing decision about what is appropriate to keep in-house and what could/should be outsourced. If companies do outsource, the location needs to be decided. Assuming your company is U.S.-based, choices of location include on-site (your company location), on-shore (U.S.), near-shore (Mexico, Canada), or off-shore (India, China). The service providers are also experiencing changes. Many of them have experienced the India market as having too much competition for the limited number of workers. What once seemed like a country with an unlimited amount of technically competent, English-speaking potential employees has become a place with high turnover and ever-increasing pay rates.

 

Chapter 4 Scope of Maintenance

ePub

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

Figure 4-2: Basic Model

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).

 

Chapter 5 Service Level Agreement

ePub

Let’s assume you are setting up the maintenance of an IT system currently being implemented by a separate development project team. If the project team uses project management’s best practices, it would have a scope statement, project charter, and project requirements. But don’t be confused; the development project’s project charter authorizes only the work for the development of the system. It does not authorize ongoing maintenance. The project charter and other scope documents can be retained by the maintenance team, but only for historical purposes. A different document is needed to authorize the maintenance team to proceed.

The Service Level Agreement (SLA) is the controlling document that addresses maintenance scope and authorizes the effort. The SLA serves as a contract between the IT maintenance team and the business owner of the system. This document must address all the services to be provided by the IT maintenance team in terms that the business will understand. Two ways to provide clarity and eliminate confusion in the SLA are to:

 

Chapter 6 Service Breakdown Structure

ePub

Chapter 4, “Scope of Maintenance,” introduced the Maintenance Machine, which represents all the services needed to run maintenance. This chapter provides a list of all of the services as well as a breakdown of the activities, which further clarifies the scope of maintenance. This list can be used as a checklist for a new manager who’s just taken over a maintenance team or as a refresher for an experienced manager.

The format of the list of services and activities is called the Service Breakdown Structure (SBS). The SBS is a modification of the classic project management Work Breakdown Structure (WBS). The WBS can’t be used for maintenance because its lowest level represents work packages that can be assigned to individuals. That level is inapplicable to the IT maintenance team.

In the SBS, the lowest level represents a distinct type of work to be performed, but the quantity, duration, and effort level will not be known ahead of time. Unlike development projects, most of these maintenance activities will run in parallel, with few predecessor (start to finish) relationships. You will be able to make assumptions from the breakdown in the lowest level about how many items you will get of each type of work so that you can predict effort and staffing needs, which will be helpful in your estimating the cost of maintenance. The next chapter (Chapter 7, “Cost Estimate”) will present additional methods for estimating maintenance cost.

 

Chapter 7 Cost Estimate

ePub

How much will your maintenance effort cost annually? That’s not an easy question to answer. But the answer is needed for several purposes:

•   To communicate needs to IT leadership. IT leadership needs accurate information about how much of its overall budget is needed for each maintenance area.

•   To communicate to the business customer. An accurate maintenance costs estimate will be important to the business customer during discussions about the SLA and the cost. The cost estimate will give the business detailed information about the services so that, if it wishes to, the business can easily revise its service request to reduce the cost.

•   To validate your current cost level. Current maintenance teams will already have a track record of costs. But are those costs still valid? Maybe the cost should be lower because of past improvements. Maybe the cost should be higher to fund improvements to service levels or cover new scope.

 

Chapter 8 Transition Planning

ePub

In general, after IT systems are developed (or purchased) and deployed to meet the business’s needs, they must be maintained in order to ensure continued benefits. A typical development approach is to set up a project team to transform business requirements into a system solution. Then the project team disbands and a maintenance team takes over to ensure that the system continues to deliver the expected business value.

For you hard-core project managers, transition planning will offer you an opportunity to perform some real project management. A transition plan for new systems moving into maintenance has a definite scope, is unique, and has a start day and an end day. Thus, a transition plan meets the definition of a real project, but you can think of it as a mini-project. If you are not a hard-core project manager, consider this step another planning activity that you will want to do correctly.

The transition plan should outline the approach to moving the ownership of the project team’s products, support material, and knowledge—as well as accountability for the system—to the maintenance team. The deliverable of this plan is a maintenance team that is already both effectively and efficiently maintaining the system for the business according to the specifications in the SLA. The goal is to make the maintenance team as effective as possible as soon as possible.

 

Chapter 9 Documentation

ePub

Documentation of the systems is one of the least exciting subjects for any team. If a vendor provides it, the documents are just there to be reviewed as needed. But if it is for interfaces or customized code developed in-house, someone has to write the documentation. This is a task that is frequently pushed off to the end of the project and often never completely finished before time on the project runs out. The pervasive mentality that documentation is low-priority work drives this situation. But have you considered documentation as an effective risk mitigation tool?

Effective project management teaches us that we need to manage risk. Chapter 19, “Risk Management,” covers the subject as it relates to maintenance risk in greater detail. The following four processes relate to maintenance documentation risks.

•   Risk Identification

•   Risk Analysis

•   Risk Response Planning

•   Risk Monitoring and Control

So we will approach documentation assuming it is an effective risk mitigation tool. If that assumption is true, what risks are we trying to mitigate? The remainder of this section presents five maintenance risks along with the analysis and response/quality standard for each. This approach changes the focus of Risk Response Planning by including a “quality standard” for the documentation. Each risk is related to the others, but each is broken down for greater insight into the potential problem. Risk Monitoring and Control is addressed later in the chapter.

 

Chapter 10 Team Management

ePub

A team that understands what needs to be done and knows how to do it is an incredible asset to the manager of a maintenance team. If you did not take over an existing team that is at this level, then it is your job to develop the team to this level. This chapter is designed to help you and your teams get to that high level of performance. Figure 10-1 shows the progression that we will follow in developing an effective team. We will assume that there is no existing maintenance team.

I have led several different maintenance teams throughout my IT career. Some teams were outstanding, seeming as though they couldn’t do anything wrong. Things just ran smoothly, even when system issues arose. Of course, I attributed this to my management skills, but I really felt that the team managed itself. But then there were the other teams that required more time to manage and develop. Managing those teams was slow and had a fair number of glitches. This chapter provides an approach to developing your newly created team into a smoothly running group that almost manages itself.

 

Chapter 11 Work Tracking

ePub

In a project, you plan and track your work using tools like the WBS and the project schedule. It is straightforward to track the work performed, because it is simply a matter of checking off tasks as completed in your WBS. As time goes on, you may be adding additional tasks due to new knowledge, but overall you know what remains to complete in order to finish the project.

Maintenance is different, as this book has demonstrated. When you start the maintenance effort, you can categorize the activities to be performed in an SBS, but you can neither quantify how many activities there will be nor determine when they will need to be completed. You will need a different approach than using a WBS or even an SBS for tracking work completed.

But first, why is it important to track work in a maintenance team environment? Isn’t a satisfied customer good enough?

Many years ago, when I took over my first maintenance team, I thought I was proactively competent. After figuring out what services the team delivered for a variety of systems, I contacted my boss, customers, and the IT financial tracking team to see what information they would need on a routine basis. Then we instituted a manual process for tracking just this needed information. Everything was covered—until my boss asked for some data that I wasn’t tracking, which was time spent on a specific activity. He wasn’t interested in hearing about how proactive I had been previously. He just wanted the data. So the team dug through multiple sources to come up with generally correct information. We delivered what the boss wanted but at the expense of not performing other work for the customer.

 

Chapter 12 Customer Care

ePub

When discussing customer care, a good place to start is with an example of a company that does it right. The Walt Disney Corporation is a great example of such a company. In its customer care and service, Disney strives to delight its customers. First, it refers to its customers as “guests,” which sets the tone Disney wants. People are inclined to treat a guest with care and courtesy.

The second thing that Disney does is to refer to all of its employees as “cast members.” This creates a sense of being on stage. Employees are playing parts or roles as cast members. They can focus on playing their roles well and also benefit from being able to separate themselves from the roles. Being able to do this is a benefit, because the employees may not like to think of themselves in the roles they play. As an example, there are no people who are garbage collectors, but there are people who play that role. This may be a subtle difference, but it affects the attitudes of the team members involved.

 

Chapter 13 Incidents, Defects, and Enhancements

ePub

This chapter addresses emergency incidents, production defects, and enhancement requests. Defect fixes and enhancements are addressed together in this chapter because they both cause a change in production. Their priorities and the level of scrutiny involved in obtaining approvals will differ, but the overall process of migrating the change into production will be the same.

We will start by defining incidents, defects, and enhancements, and we will distinguish defects from enhancements. Then we will delve into the two processes for handling defects and enhancements. The enhancement process is more complicated, since there is more discretion on approvals and prioritizations.

The IT maintenance manager doesn’t have full authority to make all the decisions identified in this chapter. The system owner should be consulted about how priorities are set and how the process for seeking approvals is carried out. The business customer may include a large number of people, but the system owner is the specific person or the small group of people that have the final say on system changes.

 

Chapter 14 Testing

ePub

The manager of the maintenance team is accountable for the quality of the system after it is transferred to the maintenance team. The initial quality is a reflection on the project team responsible for the implementation; but as time goes on, the quality will be a reflection of the maintenance team, and rightfully so. The maintenance team will continue to apply enhancements and defect fixes to the systems in order to improve the systems. But there is also the possibility of inadvertently introducing new defects into production along with the enhancements and defect fixes. Though any given enhancement may be small, the quality and integrity of the entire system must be the concern of the maintenance team, and any coding change requires rigorous testing.

This chapter focuses on testing, but there are other aspects of quality than just testing. These other aspects are addressed throughout this book and include:

•   Accurate and usable documentation

•   Adherence to procedures

 

Chapter 15 Metrics—Overall Control

ePub

We start this book’s Controlling Processes part with this chapter on metrics. To effectively control the maintenance effort, the manager must really know what is going on. Of course, some level of control can be exerted on the maintenance effort without metrics. There will be anecdotal events that dictate what needs to be addressed, and the manager can assume total knowledge of everything that is happening is available. But that is just an illusion.

There are three kinds of people in the world: those who “know what happened,” those who “think they know what happened,” and those who say, “What happened?” People who think they know what happened are less effective as leaders than the people who know what happened. Metrics are what makes the difference. We won’t even talk about the “What happened?” people.

Single-engine aircraft pilots can fly across the country through clouds and rain using only the plane’s instruments and avionics. It is an exhilarating experience, after flying for several hours without seeing anything outside the cockpit, to suddenly break out of the clouds at only 200 feet above the ground with beckoning runway lights in front of you. For maintenance, metrics provide the same indicators as the aircraft’s instruments and avionics—they permit a safe arrival at your destination.

 

Chapter 16 Configuration Management

ePub

Configuration Management includes the control processes that allow managers to have confidence that all system components are managed effectively. The components include source code, production hardware, and the production environment itself. Whether vendor packages or internally customized systems, effective configuration management lays out well-defined, disciplined processes that identify who is accountable for each step.

Decades ago, this subject was demanding, but now the subject is daunting. Highly complex and sophisticated development of source code components leads to increasing confusion and chaos. Systems can run on multiple platform types. Many versions of a system can be in production at any given time, and all of them need to be supported. The growing trend in server consolidation drives multiple systems to run on a single server with shared common components (database drive), and so one system change affects many unsuspecting system owners.

This chapter presents concepts that will allow you to diligently control the systems and the production infrastructure on which the systems run. Without clear control, system integrity is lost. We will not attempt to evaluate the use of automated tools because new automated Configuration Management tools appear continuously in the marketplace and any product evaluations are soon outdated. But you will be able to evaluate vendor-supplied tools yourself when you have understood the concepts presented in this chapter and know how to implement an overall Configuration Management process.

 

Chapter 17 Cost Control

ePub

Cost control is nothing new for project management. With any project, it is important to accurately track and control the actual project’s expenditures in accordance with the approved budget. In this regard, there is not that much of a difference with maintenance.

However, at the lower level, maintenance has some specific characteristics. While a project’s expenditures are combined in order to produce one price for the customer, maintenance costs should be associated back to the types of services the customer is receiving and what customer the service was for (assuming multiple budget authority customers). Chapter 7, “Cost Estimate,” provided several methods for estimating how much the maintenance effort should cost. Now we will look at how to track the actual costs and analyze the results.

With effective tracking, you will be able to better control the process for delivering basic keep-it-running maintenance and enhancements. You will also have better control over the process for managing external contracts, contractors, licenses, and purchases (including conferences and training). Tracking allows the mining of a wealth of information to use for improving processes, communicating a clear picture to the customer, and decreasing staff when possible and necessary.

 

Chapter 18 Communication and Beyond

ePub

Effective communication in new development projects is important, and it is made slightly easier because of the fact that the project is delivering a tangible product. Maintenance, on the other hand, delivers an intangible service, which makes effective communication even more important. The customer of a project wants to know the project status and to be assured that the delivery dates are met at the agreed-upon cost. But customers of maintenance want more. They want:

•   Assurances that production systems are stable and available for business purposes

•   Assurances that the maintenance team is diligently working on a problem if it is not resolved immediately

•   Assurances that Service Level Agreement (SLA) metrics are being met

•   Statuses that reflect that approved enhancements are being worked

When the business customer trusts the maintenance team, the customer will start to demand less frequent updates. But if there is no trust, the customer will constantly want to know the status to ensure that the maintenance team is being “managed.” This is one of the stresses of maintenance and should motivate us to constantly improve trust levels. The only way to do so is through building relationships with all the business players by delivering results and communicating the results effectively. Establishing effective communication with the stakeholders and consistently delivering on business needs are the keys to building relationships based on trust. The sooner this happens, the sooner the stress level of your team members will decrease.

 

Load more


Details

Print Book
E-Books
Chapters

Format name
ePub
Encrypted
No
Sku
BPE0000250078
Isbn
9781523096022
File size
6.4 MB
Printing
Allowed
Copying
Allowed
Read aloud
Allowed
Format name
ePub
Encrypted
No
Printing
Allowed
Copying
Allowed
Read aloud
Allowed
Sku
In metadata
Isbn
In metadata
File size
In metadata