Business Systems Analysis: Maintenance and Help
We hear a lot of talk about how maintenance has become the majority job description for IT. But they never discuss why. I submit (in my best Capt. Kirk voice) that the reason is that almost all companies are now computerized, and the applications are almost all in place. So creation from scratch is not as needed as it was 5-10 years ago; granted, new operating systems and processors and trends (networking, intranets, etc.) have required constant upgrading of software and hardware – but that’s what it is – upgrading – which requires less development and more maintenance.
OK, let’s face the ubiquitous Change Management Committee. The main purpose of such a committee is to oversee the environmental (that is, business environment, not trees and lakes) impact of the many projects that are in progress, especially in a large company where thousands of users could be affected. This committee oversees any plans which might require a user reboot, or take down a server temporarily (such as when updating an application that taps into a server-based database), or install on a huge number of machines at once (as in a new version of an application software), the committee is supposed to ‘choreograph’ the changes so that they don’t all happen at once unless they should. An example of the latter situation would be if there are several databases on one Unix box, and three of them need to be down for a couple of hours – schedule them all for the same night. The committee might stall one deployment because there is a major deployment planned. For instance, B-MS usually deploys 8-12 applications a night, with 200-800 intended users for each app. But when they were going to deploy Acrobat to all 6000 users the CM committee ordered all other deployments to be put on hold – such a large target with such a large app will take all night. The committee has the right to ask any questions it deems necessary, and then it approves or rejects the proposed deployment. This is strictly limited to the environmental impact, not on other constraints such as budget. After deployment, the proposer must report in to the CM committee of the success of the ‘mission’ so it can be closed – this is usually done up to a week after deployment, to handle the evaluation phase first.
Corrective maintenance is the bulk of the work. Users/requesters realize that they forgot to ask for certain functions; use of a new system brings other ideas to mind for new functions that are needed (as opposed to a wish list); the system doesn’t work as planned. Some clients go into coronary arrest with this – but the reality is that any of these can happen in a very complex system. As systems get older and older, maintenance becomes a big issue, because users don’t want to let go (“It’s worked for me for 10 years…”). Change is the hardest thing to accept. Companies keep holding on to established systems. As a result, people like my friend become rare commodities – Carl is the only one who knows a particular language (I forget what it’s called), and a large insurance company in Boston has been using it for customer support for ten years or more. So they fly Carl into Boston for 2 weeks of every month and gave him an apartment – and yearly substantial raises!
In large companies, the CM process usually requires a minimum of one scheduled notification to all impacted users, usually by e-mail.
To monitor maintenance and determine when changes need to be made, a great source of information is the Help Desk. There are so many good uses for metrics based on Help Calls:
- How many calls indicate inadequate training?
- Which applications are having a high frequency of problems? Perhaps they should schedule further training.
- Number of incidences of the same problem with the same application? Perhaps they need to do corrections on the application.
Versions and their meaning. A full-blown, 60%-or-so, change requires a full version number. Little patches are in the hundredths. Major fixes (like the MS Service Packs, lord help them) require a marking of a tenth. So they come out with version 1.0. Then they find that the printer drivers are out of date – version 1.01. Then they discover that they needed to add a better-working Help function – version 1.10. A year later, they want to add more functionality to the product – version 2.0.
Validated systems require special handling; changes must be within authorized parameters (usually defined by regulations, such as the government or the FCC, or the FDA). When a company is using validated systems, there is usually a person or group which determines if the change is within the parameters.
In every large company I’ve been in – large enough to have its own developers – the developer ‘owns’ the application; it is the developer who is involved from the get go. And it is the developer that does the maintenance. This is only logical – who else could find the places to make the changes faster? Pfizer unfortunately hires contract developers per project and then they disappear, so any updates or maintenance requires a developer to relearn the code.
Training has to be the most neglected part of maintenance, especially in small companies. Tech support people who are worth their weight in gold are those who teach their users how to handle the system. At B-MS, unless it is a system-wide application (like MSOffice), the department requesting a system or upgrade pays for the system AND the training. If users are already computerized, it’s difficult to convince the management to pay for training on use of the system and computer/system concepts; they don’t see it as a need (yet often it is). Classroom training is difficult unless a corporation has dedicated computer classrooms. Some companies get around this by renting classrooms (there are companies out there that supply computer classrooms for training); and there are companies that make a living teaching at their own facilities – even custom software. Computer-aided instruction is a good thing for a vendor (outsource) to offer – it’s well-received, and cheaper than formal training. And it is convenient for new users for an established application. Software help components should be designed only for on-going support – not as a training device.
People often assume that developers live in an ivory tower (ah, would that it were…). A good developer is well-versed in his/her users’ needs. I’ve learned a great deal about how a company runs by talking to the developer of the company’s software.
How many people do you know that turn off that MS ‘office assistant’ as soon as they figure out how? It’s more of an imposition than a help. Better to have question-making a feature of the Help online, just as contents and the index are.
Most software-related surveys include asking the user what are the deciding factors in selecting an application. They always get a resounding call for free, live support. I have been submitting my taxes electronically since 1994 (my return is very complicated). Support is awful – not online, unless you want to accept a truckload of faxes; phone numbers are not toll-free. But eventually you can get hold of someone on the phone, and if your question is a technical one (as opposed to one about tax laws), the call becomes ‘free’. And after about 3 years, they actually called me up and spent about an hour with me on the phone asking my likes and dislikes about the package – I saw some of my complaints corrected!
Microsoft charges for any and all technical support, as does IBM. This makes it hopeless for the private user. I always go through the FAQs first – what I think is unique often turns out to be a known glitch (grrrr). B-MS pays for Microsoft support, and the IT department is notified of the username and password for access. Lately, Microsoft has opened this up – people like me, registered developers of MS products, now get free help.
The forums (message boards) are great; I worked on an AOL message board about the Internet for a couple of years. Other users often had great solutions to problems, so you don’t have to rely on the resident expert. But you need time to use a message board – it’s not an instantaneous response.
Don’t get me started on Help Desks. There are now certifications available on Help Desk management. A couple of years ago I was part of a team that created a SmartDesk for Pfizer. As I used to tell clients, it was manned by overeducated, overqualified and overpaid analysts. The result….65% of calls were resolved by the person answering the phone! Pfizer is well aware of the payoff (ROI) to good technical support, and they trained the analysts on managing all types of passwords, remote access, the infrastructure, and the software being used. Unfortunately this is the exception. Most Help Desks are manned by people who know little about the work – they are just supposed to hand it off to the right support person/group. The result is that people find out how to call the technicians directly, and the techs don’t get credit for the support they give their clients.
