| Maintaining a system is seldom included in the same contract as the one to build the system. Often, the contractor that built the system is not the same organization as the one that maintains it. For both contractors and outsourcing organizations, it is important to clarify exactly what is meant by the term "maintenance." "Maintenance" is sometimes confused with "operations support." To help clarify the difference, the tasks and attributes associated with each are explained next. Even if your definition varies from what is stated here, it is important to verify and define this precisely so that no misunderstanding occurs between the contractor and the client. Operations Support Operations support is typically performed at the location (usually a data center) where the system is deployed. Most organizations have a staff dedicated to providing these services. To better understand the operations process, the goals of operations support should be identified. Operations Support Goals For most organizations, the goals of operations support are the following: Assist the business organizations that depend on the IT applications running smoothly. In other words, support the organization's business goals by keeping all IT systems functioning as they should. Help the organization get the most value out of its investment in technology, including both hardware and software. Provide a positive experience for users to help drive usage of the systems. IT systems are expensive, and return on investment is zero if the system isn't used. Most users recognize that no system is perfect. Many even tolerate a certain level of defects in the system provided that support is responsive to their needs and provides the proper answers to their questions.
These goals are straightforward. To achieve them, the organization generally forms a staff. Examples of operations support tasks are as follows: Performing backups and restores for system recovery or disaster preparedness Managing system logs Defining or managing user IDs and passwords Researching and answering typical Help Desk or usage questions General monitoring of system performance Increasing available disk space by archiving old records for long-term storage
Sometimes, operations support is referred to as "first-echelon" support. The operations support group is the first line of support users call when a problem arises. The support group probably is responsible for many systems. They may be part of the group often called a Help Desk. If you have the luxury of determining and controlling the staff for supporting a system your team has built, the following section explains key skills and attributes needed for these positions. Staffing Operations Support and Help Desks Help Desk and other operations support personnel have a difficult job. Like any customer support position, the only time they hear from users is when they are having a problem. In addition, users are often frustrated by the time they call for help, and this frustration is sometimes directed at the Help Desk staffers. Help Desk staffers have their own frustrations, such as users who never read manuals or follow recommended steps. Despite the challenges, working at a Help Desk can be a tremendous learning opportunity. When you're considering candidates to staff Help Desk and operations support, the following qualifications are key attributes: Quick learning ability. Typical Help Desk staffers support multiple systems concurrently. New systems come online frequently. Although proper training is vital for good Help Desk support, the reality is that this is not always possible. Accordingly, the ability to learn new systems quickly and to self-teach is important. The ability to handle pressure. Providing correct answers often requires some research by the Help Desk staff. During peak periods, questions are directed to the Help Desk faster than their ability to find the answers. Thus, successful support staff need to perform multiple tasks concurrently and manage their time wisely. A good demeanor over the phone. Most Help Desks handle the majority of requests via phone or e-mail. A calm, steady, friendly voice over the phone that inspires confidence goes a long way toward soothing users' frazzled nerves. Initiative. Although operating a Help Desk is a reactive task, it helps to have people staffing it who take the initiative to raise and solve issues that will make the Help Desk operate more efficiently. A strong desire to help people solve problems. Despite all the technology involved, as with many endeavors, a Help Desk is about people and information, not technology. The best Help Desk candidates are the ones who derive great job satisfaction from helping others.
It is interesting to note that turnover is high in these positions. One reason is by the time a Help Desk staffer acquires a great deal of knowledge, he finds other opportunities where he can apply his knowledge in an environment more amenable to him. Perhaps, a more common reason is simply the burnout factor. Yet another is opportunity for career advancement. A talented Help Desk staffer is highly prized. To reduce turnover and retain those who are talented, consider rotating Help Desk personnel into other tasks for periods of time. This reduces burnout and lets the staffers apply their talents in other areas. Equipping Help Desk Personnel Because the Help Desk is the first (and often the only) group users interact with after deployment, a system's ultimate success and acceptance depend on the quality of the Help Desk support. As the contractor who will build the new system, you may not be able to control the staffing of the Help Desk, because a different contractor may handle it, or the customer may staff it. But you can equip the Help Desk with everything that is needed to provide responsive technical support. Consider the following points: When eliciting requirements for a new system, be sure to ask the operations support personnel (such as the people staffing the Help Desk) for suggestions. Help Desk staffers are in a unique position to supply useful information on the sorts of difficulties the users experience when new systems are deployed. This information can be used to make operations support of the system easier. In addition, this information may help determine the capabilities of the user population. This information can then be factored into decisions that affect the system's usability. Often, these suggestions require little in the way of additional resources as long as the requirements are identified early. A complete set of reference materials should be provided to Help Desk personnel. This includes user manuals, installation guides, build instructions, maintenance instructions, and any other helpful documentation. An additional document that may help is a list of error messages the system may produce and suggested ways to respond to them that are within the scope of a Help Desk operation. If possible, try to anticipate questions users may have. Provide a list of these questions and their possible answers in the form of a Frequently Asked Questions (FAQ) document. You may get ideas for the FAQ document from the questions that arise during acceptance testing and other hands-on demonstrations for the users prior to deployment. For more complex systems, hands-on training is useful to get Help Desk support started. Consider supplementing Help Desk staff with a member of the development team for a period of time after the system is initially deployed. This will facilitate knowledge transfer and enable the Help Desk personnel to become self-sufficient. There will be occasions when an issue reported to the Help Desk appears to be a problem requiring attention by the maintenance team. The maintenance contractor should provide guidance to the Help Desk representatives on the information they should collect before reporting a problem to the maintenance team. This will help the maintenance team replicate the problem and provide corrective action quickly. If you're a contractor and your organization is providing maintenance but not Help Desk support, an extra investment of time to allow the Help Desk to run efficiently will ultimately benefit your organization. Most Help Desks are staffed with the minimum number of people needed to support the user community. As a result, Help Desk staffers are under great stress to provide solutions quickly and then move on to the next problem. If a problem cannot be solved swiftly at the Help Desk level, it will quickly be escalated to the maintenance team.
Other Useful Items for Operations and Help Desk Support If you are setting up a support organization for the first time, other useful tools can help the operations organization (including the Help Desk staffers) immensely. The majority of these tools help you manage and disseminate information. Some of these suggestions are practical only for large shops with a significant IT budget. However, consider these options when equipping any Help Desk: Call management systems. For Help Desks with enough call volume to have multiple staffers working simultaneously, a call management system that can automatically route calls to the next open representative is helpful. For very large organizations, they can be used to route calls to representatives who specialize in certain products or have certain skills. Trying to manage multiple phone lines manually, without a call management system, does not work for high call volumes. This means users become even more frustrated by the time they finally reach a representative. Web sites. Most organizations already have intranet Web sites available for employees to which pages for a support organization could be added. You could include a simple statement of the current status of the various IT systems. You also could include elaborate knowledge management systems that make it easy for users to find information they need without contacting the Help Desk directly. Problem tracking software. This is essential for all Help Desk operations, no matter how large or small. This is discussed further in the next section. License utilization software. Some companies offer license utilization software that tracks usage patterns of Commercial Off-The-Shelf (COTS) products. These tools can create graphs showing peak usage, whether anyone was denied a license due to maximum utilization, and so on. These tools can pinpoint the usage pattern of systems over time so that Help Desk staffing can be made more efficient. It also helps organizations manage their software products more efficiently so that they can achieve maximum utilization of the products before having to spend additional funds on more licenses.
Call Tracking/Problem Tracking Software Call tracking software is the most important tool in a Help Desk's arsenal. The primary need for call tracking software is to enable the Help Desk representative to document the details of each call. During peak periods, it is difficult to remember all the various details of every call that is not immediately resolved. Hence, call tracking software is needed to effectively support multiple problem resolution efforts concurrently. Call tracking software has another important purpose. As the call tracking database becomes populated with the details of problem solving sessions over time, it serves as a knowledge base. Help Desk personnel can search this knowledge base for previous occurrences of a problem. They can review and apply prior solutions to the problem to a new instance of the problem. This not only saves time but also accelerates the learning curve for newer Help Desk representatives. They will be able to learn solutions to problems without affecting other staff. To facilitate use of call tracking software as a knowledge base, representatives should be certain to describe problems completely and fully, listing all the symptoms of the problem and the various solutions applied. They should strive to describe the information to the point where a review of the call log a month later, or a review by a different representative, provides enough information to understand the problem and the solution, along with the final resolution. Another use for call tracking software is to provide historical information on call volume and trends. This can be used to anticipate future call levels and adjust staffing accordingly. Finally, if possible, the maintenance team should have access to the call tracking system. If this is not possible, at the very least they should have the information from the logs from the reported problem that is being escalated to the maintenance team. This will facilitate replicating the problem so that the issue can be corrected quickly. Other Best Practices for Operations Support Hiring the right people for operations support and equipping them with the right tools to manage the job will put you on the path to success. For other best practices, consider the following: Try to identify peak usage periods in the user community, and adjust staffing on the Help Desk accordingly. For example, some organizations have certain times when the users must run certain reports or perform certain activities using their IT systems. Some organizations do this once a month or once a quarter. Near the end of these periods, you can expect the Help Desk to have higher-than-normal call levels. The problems reported in these calls will have a greater level of urgency, because the reports may need to be completed by a certain deadline. Make sure that sufficient staff is available during these peak periods. If not, both the Help Desk staff and users will become frustrated quickly. Try to view problems from the customer's perspective. Many customers are uninterested in computer systems and view them simply as a tool they must use to achieve some goal or purpose. For this reason, you need to be patient with users who may be struggling in their use of the system, even with things that are seemingly simple. Do not consider the support call complete until you are certain the client is satisfied with the response. Despite the best efforts of even the most talented support staff, some users will be disgruntled. Other users, perhaps through no fault of their own, will try to use the Help Desk as their own personal training tool. For these situations, have an escalation path. Someone other than the Help Desk staffers should manage users who are unhappy with the support or who continually make out-of-scope requests. The focus of the Help Desk staffer should always be on solving the specific problem reported to the Help Desk. Separating the management of these concerns preserves the Help Desk staffer's credibility. For issues that require several days to research and solve, contact the client periodically with an update. Do this regularly, even if you have nothing new to report or you're still waiting for something else to happen to solve the problem. Users always appreciate getting updates. During periods of low Help Desk activity, proactively call selected users for whom you have solved problems in the past. Ask them if the solution you provided was helpful. If this is not practical due to continual activity, have a manager perform this activity. One situation that happens occasionally is that the Help Desk staffer must provide support for systems of which they have a low opinion. If you're tempted to state this opinion to a Help Desk client, you should refrain from doing so. In fact, the Help Desk staff should be a proponent of all the IT systems they support. To do otherwise invites trouble. I have seen situations where a Help Desk staffer offered his true opinion to a caller. After the caller hung up, the client ran around his office stating that "Even the Help Desk thinks our IT systems are of poor quality." Don't get caught up in these situations!
Maintenance Support Maintenance support (sometimes called second-echelon support) comes into play as a response to a specific event, as with operations support. But maintenance requires expertise and resources beyond the scope of operations support. Simply stated, the role of maintenance is to determine the cause of functionality that is failing to operate properly and then provide a solution that corrects the problem. This simple definition is technically correct, but most organizations require much more. The following tasks are typical needs of an outsourcing organization for its maintenance provider: Adjustments needed to software resulting from operating system upgrades Modifications and adjustments needed to software from a change in COTS software vendors, such as a change in databases Modifications and adjustments to software to take advantage of hardware improvements Training for new Help Desk personnel Assistance in relocating servers due to data center moves Changes in functionality to support Continuity of Operations (COOP) Changes or additions to functionality to support changes in business processes
I have seen all these issues arise at actual customer sites. In every case, the only source of expertise available to assist with these tasks was the maintenance team. All contractors engaging a client site for maintenance contracts should consider these items and ask whether these services may be required. If so, they should be factored into the Statement of Work and any pricing information that could be affected. In general, fixed-price contracts for maintenance are a bad idea. They are risky to the contractor and a poor value for the client. Can you imagine an automobile dealer selling fixed-price maintenance contracts? Even with extended warranties, many things are specifically excluded. It is difficult to predict what, if anything, will go wrong with software. A Cost Plus Fixed Fee or even a Time and Materials contract is more appropriate. When the Maintenance Contractor Is Different from the Development Contractor When a new contractor takes over maintenance on code that was not developed by that contractor, a large amount of knowledge transfer must take place. Each of the following areas should be examined and considered when accepting responsibility for software maintenance: What tools did the developing contractor use to develop the code originally? Are these tools needed to maintain the code? If so, how will licenses be acquired for the tools, and who will pay for them? If some of the original tools must be reacquired for maintenance, find out which versions of the tools the developing contractor used. If possible, the same versions should be used for maintenance. When the maintenance team is successful in maintaining the code, the tool versions can be upgraded if needed. If this is done too soon, and problems occur, it will be difficult to tell whether the problems are caused by the new versions of the tools or by some unrelated aspect not understood. Also find out any special configuration settings that were used or any other information that is needed to set up the tools correctly for maintenance. Obtain from the development contractor a complete set of design documentation, and any other documentation needed, such as build instructions. Have the maintenance team review this documentation and identify any questions they may have. Have the developers of the new maintenance team meet with the original development team. The goal is to answer any questions the maintenance developers have. A second goal is to allow the maintenance developers to perform a build without input from the original developers, following the documented build procedures. Any difficulties should be investigated and the build procedures corrected. Just as with the software build procedures, any test suites should be documented with instructions on running the test suites and properly interpreting the results. The testers on the maintenance team should try running these while the expertise from the development team is still available. If possible, try to arrange the periods of performance of the development contract and the maintenance contract to overlap for a periodperhaps 30 days. If that is not possible, at least arrange for the original development team to be available for consultation if the maintenance team runs into difficulty getting the software to build properly or if other questions arise.
Corrections in Software There have been many horror stories relating to software maintenance. Many of these errors can be attributed to insufficient testing following a seemingly minor change. When a small change is made to correct a single problem, the temptation to skip thorough testing is great. For this reason, this type of change should be attempted only in emergency situationswhen the disruption of a system being out of service unexpectedly overrules the risk of introducing bugs through making a quick change. For some other best practices that should be employed when performing maintenance, consider the following: Group changes, defects, and enhancement requests that do not constitute emergency fixes into a single release. This makes it more practical to perform thorough testing on the release before it is released. Never send a changed release into the field, no matter how small the change is, without changing the version number in the release. This sounds like common sense not worthy of attention, but I have seen it happen. The problem, of course, is when a defect is detected in the "new" release. Is the bug in the "old" version 5.0 or the "new" version 5.0? This causes tremendous confusion and wasted effort. Never do this. A robust configuration management system is vital during maintenance. It should be capable of permitting work on a maintenance release while allowing independent work on newer versions (containing new features) if needed. Refer to Chapter 6, "Establishing the Software Development Environment," for more information.
When delivering a maintenance release for deployment, remember to keep the operations group "in the loop" and informed of the expected date of delivery. Installation and deployment of a new release of software is a significant event and requires resources from the operations group. This is seldom an issue, unless the operations group was not informed of the date of delivery. |
