Career Counseling One Interviewee's Lament News & Views Feature Article

By David Calloway Most recently, David Calloway was a Y2K certification consultant on contract at Smith-Kline Beecham. Originally published in News & Views January 2000 issue. Copyright 2000 STC-Philadelphia Metro Chapter. For permission to reprint this article, contact the Managing Editor.

The VP of IT had appealed, "We want the benefit of your experience. You're all senior people, and we need you to get the ball rolling right away. We need this job done yesterday, so please tell us how you'll do it." The Interview Four IT managers vented their thinly-veiled frustration with the firm's current situation to the three candidates facing them across the broad table. Eight senior people in one room, with no written agenda. Discomfort with this situation chased basic principles of analysis, normally second nature to me, right out the window. By the end of the two-hour interview, three consultants blinked their bewilderment in the bright sunlight, asking as one, "How can we get the ball rolling, if we don't even know what the ball is?" I was not surprised the next day when the consultancy rep reported the client's feed-back: "You just want to rewrite the plan, and we barely have time to get the job done." No, my mind argued. You won't get the job done. If this attitude were any indication, a follow-up letter explaining my recommendations would be as futile as the interview had been. Nonetheless, I needed the debriefing exercise. Thinking through the issues at leisure only served to solidify my assurance that my recommendations were sound. The client was a service firm that had, in twenty-five years, become a regional powerhouse by acquiring dozens of mom-and-pop operations like it. The founder's hands-on, entrepreneurial culture had left little room for extravagances like structured methodologies and systematic documentation. The result was a hodge-podge of small, barely-communicating systems and networks that quite accurately represented an underlying chaotic business reality. The firm had recently been acquired by a multinational communications giant. The VP of IT hoped that the magic of Systems Documentation could make this roiling stew of adopted sibling rivalries appear to the new parent as a coherent, logical whole. "Which, by the way, needs to include Y2K verification, and be completed in the next two months. Got that?" And now, the Letter Dear Ms. X: I appreciate your time for our meeting yesterday. I apologize for not being as prepared as I should have been. I neglected to bring a resume, assuming that either you or Sharon (the rep) would have a copy. I did not bring writing samples because they tend to become the focus of the interview, rather than an illustration of how certain problems were solved, at a certain time, under certain circumstances. Preoccupied as I was with the unusual interview arrangement, my presentation may have lacked focus on your requirements. Although I am apparently out of the picture, I'm sending this memo in hope that some of my "20-20 hindsight" might be useful to you. First I'll define recommendations for handling interviews, then expand on the suggestions that I made in the meeting. First, I'd like to introduce something called a Gap Analysis. Like a before-and-after view of the problem space, a gap analysis defines what you want, subtracts what you have, and shows the remainder to be your requirements. Doing this beforehand may help make your interviews more productive. Had time been available to study the new owner's requirements outline that you circulated, the impromptu presentation of my experience might have been better targeted on your needs. Without first defining the gap between Have and Want, it was impossible for me to articulate how I have closed similar gaps in the past. Confusion could also be avoided by ensuring that your management team focuses their presentations on the task at hand: what we have vs. what we need. While I can certainly sympathize with their feelings about the current situation, I found their exhaustive inventory of problematic issues-well, exhausting, as well as distracting. It simply added to our bewilderment, as outsiders trying to understand what we are being asked to do. Wisely, you identified the key mission: to document current systems and processes. Your people are clearly dedicated and competent, with all the skills and tools they need to be effective. A development or documentation solution will not align their activity with corporate goals that are undefined and conflicting, nor replace poorly nurtured business relationships with healthy ones. To illustrate this point: I recently participated in a re-engineering project intended to bring logic to a fractured cross- departmental function. Mysterious data flow problems had stalled development of an interface between the mainframe host and a new client-server system. Mapping the complex, undocumented system and process interfaces, I discovered several undocumented data feeds. The client department assured me that these had been used by a small group in another department, but were now obsolete. Tracing the system further, however, I found that they were in fact still used for a process on which the client department's activity hinged. The stronger group had to recognize the weaker group's contribution and bring it into the project as an equal, or suffer severe damage. After your head of Marketing Systems mentioned Visio as a common tool used, I decided to check out the vendor's web site to refresh my Visio knowledge. You might find Visio to be helpful in charting your company's relationships and processes, linking each chart shape to an entry in the Y2K tracking database. As I heard it, your plan is to use Visio to map the physical and logical locations of the information entities and who they support, and a massive set of written, narrative-based printed documents to capture development, Y2K remediation, and other status information. While a detailed map and up-to-date documents will be a vast improvement over the currently inconsistent and dated documentation, they are not the most effective approach. So, I will try to present my recommendation again, hopefully in a way that makes sense to you. You said that you already have an extensive database product for tracking development status information, although it has become out-of-date because it demands a lot of detail, and you couldn't justify the expense of maintaining it. Wasn't this tool de-signed to capture exactly the kind of system information you're asking writers to document, namely, Y2K remediation status, interdependent interfaces, business rules, and the like? This information does not need to be easily read; it needs to be easily located, and 100% accurate... ...The data-centric nature of this information... (something about bypassing the print phase, cutting out a very labor-intensive step and adding these functions to the existing database) You asked for the benefit of my experience, and that's what I gave you. When your situation blatantly cried out for an analyst, I was baffled by your disappointment that I didn't present myself as a writer, a scribe, a simple chronicler of what is. Good senior technical writers with plenty of systems experience are qualified to wear many hats. We excel at locating and documenting system, process, and business information. We do this by interviewing users and programmers; learning, operating, and often debug-ging applications; digging into vendor documentation; and bird-dogging mysterious processes. We do whatever it takes to create and communicate the most complete picture possible. Systems documentation is not literature, nor training material, nor proposals. As an artist, I may delight in the wonders of language and expressive words. As an instructional designer, I may appreciate an inviting introduction. But as an analyst, I know from experience that computer-enabled business relationships can be most clearly and precisely defined as tables, graphs, and pictures, while narrative prose is inherently subjective and open to interpretation. Systems documentation is reference data carefully organized for easy navigation. It will be referenced rather than read, and that by technicians, who tend to skip over long blocks of text anyway. In whatever format your corporate parent wishes to see your Y2K documentation, its content should be just a series of reports from the tracking database, linked for ease of navigation to a set of Visio charts. The real value of documentation is not in the clarity of the writing, but in the confidence one can place in its accuracy. Bring the tracking database up to date, then work on feeding the data in it through meaningful reports, and forget about the documents. Do you see now what I was getting at yesterday? It was to build on your existing infrastructure, not create a new one. Sorry some of my presentation left you with the wrong impression. Best wishes for success in this difficult transition, and that of your career beyond it.

Return to . . .

[News & Views] [STC-PMC Home] [STC Home Page]
Last updated: April 22, 2000 (mvh)