Primary Tools Used: SnagIt, MS SharePoint, MS Office, MS Teams,

Dates: July 2023 to October 2023

Deliverables: MS Word files with screenshots to be printed out and used for training end users

Wrote printable docs for training end users on Infor/M3 Enterprise Resource Planning (ERP) software. This new system would handle all the sales, accounting, inventory and order fulfillment for branches of a national company selling construction supplies and services.

This project was still in the early stages of testing before being rolled out. My role was to document how typical tasks in one division would be handled in the new system. To do this, I:

• watched screencasts of previous software demos by Subject Matter Experts (SME) and the Implementation Team
• Re-created these steps using beta versions of the Infor software
• Created screenshots with SnagIt to capture the various steps of completing a certain task.
• Wrote instruction sets for these tasks — accompanied by relevant screenshots.

Also: prepared an early draft of a style guide to be used by other technical writers and occasionally proofed other people’s docs for accuracy and consistency.

Technologies Used: MS Office 2013, Visio, SnagIt, XML Oxygen Editor, Docbook

Samples: (Confidential;  screenshots )

Dates: 5/2014 to 7/2014

An enterprise cloud hosting service wanted to standardize the way it set up data centers overseas.  It needed me to do two things: 1)prepare a detailed deployment doc for “Remote Hands” at IT centers in one country (Singapore), and  2)prepare a  template to make it easier to append documents in this manual and edit things easily.

The employer didn’t want to use MS Word because it is difficult to do version control and manage the document (and template) over time. Also, MS Word was unwieldy for handling lots of tables and information heavy with data and graphics.  It was decided to produce the document in Docbook XML and use the Docbook XSLT stylesheet to produce a simple-but-functional PDF. Because the remote hands were likely to know English as a second language, the information had to emphasize  illustrations and use very basic vocabulary. It had to have comprehensive instructions but also be easy to find things.

The deployment document needed to show the correct layout of a server rack and the proper cabling and network connections to ensure a perfect configuration. It was not necessary to document the application layer (or even the networking layer) because once the cabling was correctly set up and connected, network engineers from Houston could start and manage the devices (and the apps running on them). Remote hands would be unboxing new devices and configuring them quickly.  Therefore, the most important things to document were:

1. identifying hardware and their proper position on the server rack (by using grid numbers and letters).
2. identifying the ports on each piece of hardware on both the front and back.
3. identify the function of different  cables and which ports they needed to be associated with
4.  how to look up which cable needed to be connected to a specific source port, and where its destination port ought to be.
5. Identifying the optimal sequence of cabling and how to check your work.

To find the information, I had to interview 2 network engineers (luckily in Houston) and look up specs for each network appliance on the web. Also, I had to choose photos of hardware which were easy to understand and in some cases create original graphics when none were available. I imported  premade  graphic elements of server components into my Visio diagrams and labeled everything correctly.

The biggest challenges of this contract were

1. documenting cabling of devices which I never had physical access to. Each component  cost $10,000+ and up, so I relied mainly  on product specs and photographs taken of server racks from previous deployment.
2. verifying the accuracy of all instructions. It was easy for a hired hand to plug a cable in the wrong place, and also it was easy for a technical writer to type in a wrong number (especially when the network engineers changed the deployment instructions several times). Therefore, I had to use various methods to doublecheck the data and ensure that the final data tables were consistent with what the engineers wanted.
3. Understanding what kind of information the remote hands needed and how they would be viewing the manual. I had to consider the various possible ways the pages could be read and what kinds of presentation would be easier for remote hands to understand. In many cases, eliminating unnecessary verbiage was essential in favor of  tabular data and graphics.
4. Using advanced features of  Docbook XML. I had to use informative captions, width-appropriate tables, and size graphics appropriately. I also used sidebars for warnings and long numbered lists. I already was an expert on using Docbook. But I had to optimize and customize  the XML, graphics and XSLT for this specific project.
5. Because this was a one-time contract project, I also prepared a guide for adding/editing Docbook documents and projects for anyone editing the document in the future.

The resulting 48 page manual was succinct, thorough and easy to read. I provided easy- to-read multicolored  labels for both photographs and diagrams.

Technologies Used: Visio, SnagIt, Personal Brain mind-mapping software, Exchange 2003 & 2010, Remote Desktop, Google Postini, Active Directory, ActiveSync, Outlook Web Application (OWA), Sharepoint, Windows Server 2003

Dates: 9/2012 to 11/2012

Samples:  (Confidential, but I might be able to reveal short excerpts of these docs in person).

An IT company hired me to document email architecture for a major international media company.  This media company had three administrative groups for running Exchange in 3 different data centers. Two were running Exchange 2010, and  one was running Exchange 2003. But  all administrative groups shared Active Directory  Resource to allow all users and distribution lists. The media company used public folders, ActiveSync and OWA; the Exchange 2003 data center (which I documented most thoroughly) used clusters and Storage Groups on Storage Area Networks (SANs); it also ran servers for  message archiving, web proxying, faxing, Blackberry,  business continuity and antivirus. It also used Postini (a Google Enterprise app) for  email security.

The Exchange 2003 data center  was constantly experiencing  outages and needing to implement stopgap fixes. Also, the media company lacked any documentation of what the current system was like (because a key Administrator had recently left).  My job was to talk to  current Exchange administrators and outside Exchange experts to write a 12 page technical white paper recommending short and long term solutions to upper management. I also wrote a 25 page Technical Design Document which documented all major system components of the 2003 data center plus all the configuration settings for the Exchange bridgehead/frontend/servers, system policies, connectors and message formats.

An important part of my job was producing system architecture diagrams  to illustrate the ways that different components interacted with one another. These diagrams  could be used as quick references by management and support staff to understand the implications of any proposed action.