Tom Henderson on March 5, 2013
Many IT executives like to imagine that everything in the department is so streamlined that the business can continue indefinitely when the boss isn’t there. Most of us live in the real world, in which the staff realizes how much knowledge is stored in your head and nowhere else. Here’s the information you should document before you must disappear from the office for a while.
You’ll be away. Your documentation needs to be in order. Someone will be thankful you took the time.
Perhaps your sister broke her leg hiking. In Nepal. With no insurance. Your regiment gets called up to support relief efforts after Hurricane Dammit. Your lakeside cabin needs hanta virus eradication. Perhaps your branch office in the Ukraine burnt to the ground – because of mortar fire.
Your personal outage reason can be varied. Whatever the reason for your absence, your IT staff needs working docs to do their jobs, and all or parts of yours. Some people put off this task as a retirement insurance plan. Nothing could be sillier. Often, what happens if you’re suddenly (and perhaps permanently) away is that there will be pain and suffering on the part of your colleagues and staff. You’ll feel the pricks of the pins that they push into a kewpie doll that looks just like you.
Or, in a fit of forethought, you can easily and methodically document not only what needs to be done, but who does what, where the information that’s needed is located, and perhaps guidance for exception handling — or at least directions on where to turn should things go awry. Once done, the documentation needs only periodic maintenance and upkeep to be a useful working document.
There has to be an agreement on where the docs are located, and how they might be accessed, and by what applications. There’s nothing like docs in a bizarre ancient format, such as pre-historic WordPerfect. International offices have an additional onus: choosing the written language.
Documents, instructions, and resources must be in an accessible location. If they’re password protected, and only you know the password, then wait for the war stories about how someone (probably an expensive someone) had to crack your password to find the docs or resources. They’ll be the heroes, not you.
The documentation needs a table of contents. This alone can save hours of potential problems, by allowing your replacement(s) rapid access to what they need to get their jobs done, the crisis dealt with, the fire put out. It should be in a language that everyone agrees on. This goes for you, English speakers in Montreal, Yunanese in Taipei, and Catalunyans working in Madrid. Standard Language. No fights.
The final step in accessibility is ensuring that accessibility, meaning passwords and other authentication mechanisms your organization uses for accessibility, are available through whatever mechanism is your policy and documentation. No printing passwords in a folder that goes into your top center drawer, marked “Emergencies.”
The main instruction sets need to be divided into these elements:
Emergencies: Who is to be contacted for fire, emergency medical, building or logistics support, utilities, contractor main contacts, HR/Personnel contacts, salient reporting agencies, upper management, union representatives, insurance companies, loss-prevention contacts, legal department contacts, and local public safety officials for reach responsible location. The usual format is Agency, Contact Name, Phone, Address, email/website, Account or Addressing Method, listed alphabetically.
Personnel: These are departmental leads, their scope of authority and responsibilities, their contact information. Also provide a list of employees, their shifts and/or projects, basic responsibilities, ADA needs or necessary considerations (with hints like: Please coax them to turn up that hearing aid), contact information (best or preferred method) and vacation/unavailability zones, preferred or best correspondence language where applicable.
Production Online Commitments and SLAs: What work is production, where it’s accessed, who is responsible, how each production unit relates to other units, applications used (including version and patch levels), vendors and contact info, contractors and contact info, hosting/ISP/MSP and contact info. Use one “page” for each project. Divide into persistent versus non-persistent/aperiodic applications with schedule for EOM/EOP processing.
Assets and Licenses: What are the assets, where are they, how are they insured, where are the license docs, who are the contacts for tech support, sales support? When do licenses or support contracts expire? Who are the principal internal and vendor liaison contacts? Service procedure method for each salient asset and product. Tired so far?
Emergency Procedures: What to do in an emergency. Where to go, who is contacted, chains of command, dependencies, priorities established by management and department, safety procedures, authentication chain of command, notification steps. All need documentation or pointers to other documents or procedures. This is not the Army, but it might feel like it by now.
Culture: How things get done. How fun is accomplished. Policies regarding birthdays and other non-HR events, and perhaps what are events covered by HR policy. Where to find information regarding interpersonal and intervendor relationships, ethics policies as implemented, domain and “jurisdiction” of organizational departments. If sandals aren’t allowed because of OSHA regulations, say or point to the apparel policy. You know the drill: gaining cooperation. Add: travel procurement and implemented policies. (How many to a room? Really?)
Security and Audit: Security procedures, including authentication and access control, who-are-the-gatekeepers and how does one contact them, location and accessibility of the last audit, when the next audit occurs, who performs the audit, what the audit covers, and notes about what’s expected both in terms of the audit and its report. Also see Compliance.
Vendors: Who they are, what they should charge, contacts, pointers to purchasing history or practices, budget allocations, unencumbered budget and policy controls for it and by whom. Authorization processes, materials procured but not delivered (flow control and materials control schedule lookups). Mil-Specs or other compliance standards must be documented or referenced. Add to this: Who’s good in a pinch, ethical controls, and where to track purchases.
Continuum: Include a quick history of key events and milestones for the IT organization, and perhaps the history of the company itself available for the uninitiated. Highlight major events, key current personnel, and the org chart.
Legal: Current and pending litigation, along with other legal encumbrances, need to be listed along with liaisons for each of the captions, work in progress, security for eDocuments and document production and work-in-progress status or pointers to status(es), communications policy location, any current court or arbitrator orders, and legal department general contact information.
Compliance: Compliance and regulatory reporting and documentation needs, where reports are located, who is responsible, what document storage and backup/archival needs are mandated and how they’re fulfilled, and who generates them and logs the generation.
You: How and if you can be contacted, under what circumstances to contact you, your hours of availability in what time zones, who is trained or functions in your various capacities in your absence over what duration of time given what availability — as they do other jobs, too, in all likelihood.
Now you see why I recommend you have a table of contents, and specific locations of where the salient documents are located, and if you’re unsure, who would know. Exercise a revision of this file every calendar quarter, perhaps on a full moon, when your howls will be mistaken for the usual werewolves.
Then, take a copy of the document, and put it in another building or safe location, in case the first building or server or other location also becomes unavailable for whatever reason. Having an alternate copy (with its all-important table of contents) helps your organization carry on without you, so that you can do whatever is necessary, or just kind.
Sound like a lot of work or hard to keep up? Well, the best and most efficient way to reduce overhead and ensure real-time and accurate documentation is building it right into your regular tools and routine. You can’t always manage that – you really do need to follow the guidelines above – but in some instances, software can keep track of details for you.
For example, if you are building business applications and you need to document business logic, make sure your tools allow you to document that logic right where you build the application, not in an external document. If you use an app platform such as the one from Mendix, you also support your applications’ development, deployment, and documentation in a standard way that is understandable by multiple developers, IT managers, and business experts. This way, documentation is not an additional burden, but inherently is built into the processes and tooling. That makes it easy for the staff to fall back on in an emergency, no matter if it is a broken leg in Nepal or the Sarbanes-Oxley compliance auditor showing up unexpectedly.
Receive Mendix platform tips, tricks, and other resources straight to your inbox every two weeks.