Studies of success rates in surgical theaters indicate there are fewer problems when the surgical staff explicitly follows written checklists of what is to be done, and in what order. Apparently, some surgeons resist this idea, stating they’re professionals and don’t need checklists. Does this sound like any systems programmers you may have known?
Do you know the areas of your operation with the most frequent problems? Do you know which areas of your operations have or don’t have detailed documentation of what they do, and how they do it properly? Do you know if there’s a correlation between the two?
A little comparison between the areas that cause you problems and the areas that do or don’t have good checklists will give you a possible answer. If the answer is yes, then you will want to develop more effective documentation.
Such documentation or checklists used to be called “desk instructions” or “baseline documents.” Whatever you call them, they’re the detailed procedures to be followed to complete a job correctly. Not having them where they’re needed is like not having a disaster recovery plan. A major question for you to answer is “what areas of my department need better desk instructions?”
Several trends turn these desk instructions into an interesting opportunity to develop needed in-house expertise. We need to cut costs, and experienced mainframe professionals are starting to retire in large numbers, often without clear successors in sight. IBM is providing Windows GUI-based applications to help systems programmers administer their systems. However, new staff who learn the GUI-based applications may not be learning the underlying details, since the GUI interface distances them from what’s actually being done. We’re all finding it necessary to consolidate servers and data centers.
These trends leave us needing to groom more experienced staff in certain areas. Consolidation of data centers and servers may make certain qualified staff available for cross-training. These might be, for example, systems administrators and programmers who have proved their worth, but who might otherwise become surplus. They’re already on your staff. They already know information processing on one platform. They’re perfect candidates to become the eventual replacements for retiring mainframe gurus. You should carefully select these staff to be groomed, and explain to them the financial and career security of knowing both mainframe and distributed systems. (Note that UNIX administrators already have expertise that will be valuable in administering UNIX System Services on your mainframe. TCP/IP and firewall administrators will have similar expertise that will be valuable once they know a little bit about mainframes, meet the VTAM systems programmer, and meet the RACF, ACF2, or TopSecret administrator.)
To cross-train such staff, you might consider having them develop detailed desk instructions as they work with more experienced staff. Having anyone document what he learns on the job, at his mentor’s knee, will improve the intensity of the learning.
Of course, the quality of the resulting documentation will vary, depending on the habits of the person creating it. To ensure the quality is sufficient, you will need to develop documentation standards, including both content and format.
This leads us to two additional staff positions you might want to develop: a standards developer and an analyst capable of identifying the root causes behind any problems in your department. These might be part-time positions. The standards position might shortly eliminate the need for itself. But both positions will save you money and make your operation run more smoothly. You probably already have a good idea of the best candidate for each. Ask the problem analyst what he thinks of these ideas and how he would go about implementing them.
A future column will address Big Data and the information you need to manage it.