Upgrading Documents in a Slower Economy – It just makes good sense.

PlantStacks

With many industrial projects either complete or temporarily paused, my local landscape of technical writing opportunities is looking a bit parched. Several of the local potash mines have completed expansion projects in recent years, at the same time as a couple of greenfield mines have started construction. One of these is nearing completion and the other seems to be in a slow mode. With potash prices weaker than a few years ago, the industry appears to be heading for retrenchment.

Other industries appear to be exhibiting similar trends. SaskPower’s carbon capture project is essentially complete. Recent news indicates they still have some work to on increasing its efficiency, but so far as I can tell, their technical writing needs are covered, for now. Local upgrades to power generation facilities also appear to be winding down. Oil and gas is “in the tank”, so to speak, and oil companies are pulling back significantly. Based on my research not a lot is happening in other industries either.

That doesn’t mean nobody needs technical writing services. Based on the work I’ve done for many different clients over the years, all process industries should have an ongoing strategy for document maintenance and updating. And there are good reasons to continue that through the slow times as well as when business is booming.

Nothing remains constant in the operation of process plants. Whether slow or busy, operations and maintenance personnel are always finding new, better and safer ways to operate their plants. Equipment maintenance is even more important when capital expenditures have been curtailed, and this often reveals gaps and inadequacies in procedures and training materials. During slow times hiring staff to write and edit these documents may be difficult to justify, but contracting out for these services is more affordable.

When things are slow it is also tempting to lay people off. But when things get busy again it may not be as easy to replace them. Focusing operations personnel on updating procedures and training materials is a productive way to keep them busy and ensure future efficiency. A competent technical writer/editor contracted to work with your personnel will focus those efforts and ensure quality and consistency.

In the current conditions it may seem counter-intuitive to spend money on maintaining resources such as procedures, training materials and other documentation. But anyone who has managed through slow periods knows differently. Good managers make the tough decisions that pay off over the long term. Maintaining documentation is a perfect example of that.

Give me a call. I’m here to help.

Sphere: Related Content

Technical Writer meets Client – Exploring Expectations

At the beginning of a new project the initial discussions between myself and a new client are always interesting.  It’s usually a cautious exploration by both parties to determine what the other needs, wants, knows, and is capable of delivering.

What the technical writer needs to know…

The technical writer needs to know what the client’s expectations are, and how much the client knows about the process of creating quality documentation.

Are there enough resources to do this right? Are there existing standards? How many and what kinds of documents are required? What kinds of content are required? Text only? Graphics and diagrams? Print? Web? Help? Is all the expertise available? Will I get enough support from subject matter experts?

What the client needs to know…

The client usually wants to know how well the writer understands the industry, product or process that needs to be documented, and how much support the technical writer will need.

Can this writer deliver everything I need? How quickly? Will there need to be several people involved? How many and what kinds of subject matter experts will have to be made available for the duration of the project? Do we both have clear and accurate ideas of the project scope? Are they the same? What is the bottom line?

These are all valid questions. And both parties need answers to proceed.

A team effort

Producing quality documentation is a team effort. The larger the project, the more it must be broken into component parts. Also, on larger projects it may be necessary to have multiple people on the team, with specialized expertise.

With that in mind, it’s important to know what the technical writer brings to the table. This tends to be pretty subjective since technical writers come into the field from many backgrounds.

Share information ahead of the meeting

Before the initial meeting I like to do some research on the client and his/her business, products, and processes. Besides just being good marketing practice, this can tell me a lot about what to expect, and how good a fit the project will be. These days, with Google, clients’ websites, Linked In, Facebook, and so many other resources, you can learn a lot before you ever meet face to face.

In the same vein, I provide the client with my resume in advance, and encourage him/her to go to my website where I keep additional information, blog articles, and references. I also keep samples of my work there so the client can see real examples of what I have produced. I assume the client will probably follow up by checking me out on Linked In, Facebook and other online resources.

At the initial meeting

When we do meet I try to continue the learning process. Obviously, it’s important to know the scope of the project in broad strokes. But I also want to know as much as possible about the client’s concept of what technical writing is, what he or she thinks is possible, and (often more importantly) what is impossible.

I also try to share as much information as I can about my background, training, and experience, as well as how I approach the document development process. More than just information, I want the client to understand how I plan to drive toward the goal of completing the project. That may include tools, techniques, and processes I use to ensure success, but also a sense of commitment and passion that I bring to the work.

At the same time I need to communicate my expectations: what resources will be required and what the client must ensure to achieve his goals. I don’t want to overpromise and then not be able to deliver.

A good start

It’s my belief that projects that get off to a good start usually end well too. Establishing a strong foundation of expectations that are understood, shared and agreed on is one of the keys ensuring a successful beginning.

Sphere: Related Content

Finding Paths to Success in Documentation Projects

During the initial stages of my last project, my team came up with the idea of organizing a “Lunch and Learn” for team members, as well as for our subject matter experts. The idea was to introduce the SMEs to the new document formats, naming conventions and stylistic standards we had developed. We also wanted them to learn how to use our SharePoint site, which contained our document library, and our wiki.

We ran several of these lunch hour meetings, provided dessert (which ensured most of the SMEs would show up), and facilitated some good learning experiences. The experience built rapport with our SMEs and helped us learn more about their capabilities.

The team member who suggested the L&L got the job of organizing the events, and I decided to add a modest contest to the mix. I called it the “Find the Gold Coin on the Wiki” contest, hoping that a search for the coin would help them learn to navigate and see what was available on the wiki.

The contest rules were simple: The first person to find the small graphic of a gold coin embedded somewhere on a page in the wiki would win a “fabulous prize” (although what the prize would be was not specified). The contest and rules were announced during one of the Lunch and Learn sessions and a notice posted on the wiki home page.

At that point in time our wiki, (set up on our SharePoint site) was not large. It included about thirty pages of information on how to create new documents, set up headings, write procedural steps, create graphics and insert callouts, as well as other information. Granted, this information may not have been as interesting to our SMEs as it was to the technical writing team, but since the SMEs were expected to create initial, rough drafts of documents, we thought it would save them time and frustration if they knew what was expected.

It may not come as a surprise to anyone that several months went by before anyone found the “gold coin” and only then by a newer member of the technical writing team.

So, what did I learn from the fabulous “Find the Gold Coin on the Wiki” contest?

First, I chose not to conclude that the SMEs had failed; if anything, I had failed in my expectations. The SMEs, who had many tasks to accomplish, couldn’t assign a high priority to surfing through wiki pages in search of a gold coin. And expecting them to spend time on the wiki in a self-directed learning quest was even more unrealistic.

The SMEs did eventually learn how to use the document library, because it addressed an immediate need they had to access documents. But the wiki became a reference—a source of information that they went to only when necessary.

Over the duration of the project SMEs did learn a lot about standards and formats, but it became clear to me that they learned best when a technical writer worked one-on-one with them. Over time we learned to review drafts with them, showing them where we had made changes and explaining why. Sometimes it required a few iterations of this process but eventually we developed effective work processes. Also, the one-on-one approach allowed us to adapt those processes to each individual, ensuring we got the best results from each.

For me, our Lunch and Learn meetings, and the “Find the Gold Coin” contest, reinforced my belief that every documentation project is different, and that it takes time to develop effective processes. I haven’t found a “perfect path” to making a project work, but I have learned that some creativity and flexibility goes a long way toward finding a “successful path” to completion of a project.

Sphere: Related Content

Who Wrote the Book on Industrial Tech Writing?

I’ve always found that my best clients are the ones who already have a basic understanding of the challenges of creating great documentation. So I believe it’s in all of our best interests to help potential clients learn as much as they can about technical writing and the issues associated with a documentation project. One way to accomplish that is to share some of the resources that I have found useful.

Technical communication covers a lot of ground, and although the basics are similar for any industry, there are differences from one to the next. When I started out it seemed as if technical writing was primarily focused on the information technology and software fields. At that point my focus was on teaching electronics, instrumentation and industrial data communications. Still, there was enough overlap that I could see some potential for using my knowledge and experience as a foothold to build a technical writing business.

To assist with that I made a point to go looking for existing resources that would help me understand the unique challenges of writing materials for industrial clients. It soon became apparent that resources related to the process industries were especially difficult to find. There just weren’t many books, articles or training resources available that would prepare me for technical writing in those areas.

I embarked on a learning quest that spanned a number of years (and, of course, continues today). In the interest of helping potential clients see the value of good documentation, here is a short list of general, and specific, resources that I’m happy to share…

It’s fair to say that style guides tend to be dry reading, but I have found great reference information in having a few key style guides at my disposal, as well as bookmarks to online style guides and other resources. One of the key style guides if you are documenting computer and online interfaces is the Microsoft Manual of Style. It clarifies the differences between “screens”, “windows”, “dialog boxes”, “menus”, etc. as well as how to refer to them in print. Another computer-related style guide, Read Me First! from Sun Microsystems is also useful. For general writing style, word use, grammar, etc. the Associated Press Stylebook and The Canadian Style guides are great resources. There is also a variety of style guides online.

Early in my learning process I worked my way through JoAnn Hackos’ Managing Your Documentation Projects, the quintessential and authoritative manual on managing documentation projects. It may not be the ideal book for a client to plow through but as a reference it can’t be beat.

For the client who wants a practical, succinct (and even entertaining) explanation of why tech writers organize and express information the way they do, Spring into Technical Writing for Engineers and Scientists is perfect. Another useful and accessible one is Alan S. Pringle’s Technical Writing 101.

Obviously there are lots of other general books and resources on technical writing. These are just a few that I have found useful. These days there are countless online resources, the trick being to find reliable materials that are useful to you.

The one resource that I found that does focus specifically on developing procedures and other documents for the process industries is a somewhat obscure ebook called Procedures and Training in the Process Industries by Ian Sutton. Sutton is an American engineer with experience in a number of process industries. He has created extensive training materials and written resources related to process control. This book, which is directly marketed by the author, is only found on a couple of sites online. (One of them is here.) Adding some confusion is the fact that the book was originally titled Operating Procedures for Process Industries before being expanded and updated. It includes information on developing document structures, project management, the differences between standard operating procedures and other types, and several other useful topics. While I don’t agree with all his ideas, I recommend the book for its overall approach.

Finally, since the list of focused resources was limited, I put together my own short ebook, called Building Procedures with the SOP Toolkit, with a couple of associated workshops that I occasionally deliver to clients and industry organizations. I provide more information in my blog article Revisiting the SOP Toolkit on www.roncjohnson.net

Sphere: Related Content

Hello…? Technical Writer ≠ Administrative Assistant

Lately I’ve been thinking about job titles, and how they relate to the actual tasks involved. And then I noticed an online job ad today that got me a bit steamed up.

A large company had posted a job board advertisement for an “Administrative Assistant (Technical Writer)”. I read that and alarm bells started going off in my head. That is just SO wrong.

Now, before I say anything else, just let me state that my comments here in no way disrespect administrative assistants. I’ve been known to say that admins are the key role that keeps an organization from grinding to a halt. A good admin is worth his/her weight in gold. I know because I’ve had some good ones, and I’ve also…well, let’s just say I’ve had some good ones.

Let me also say that the skill set of an administrative assistant overlaps with some of the skills of a technical writer at several points. I consider myself a fairly accomplished MSWord user, but when I run into something that stumps me (and if I can’t find the answer quickly online) I contact the best admin I can find. Nine times out of ten they will have the answer.

On one of my recent projects I hired a young guy as an administrative assistant (knowing he had some skills that went beyond that role) and later promoted him to technical writer. Although he didn’t have formal training in either role, he did a great job in both. So there is some commonality between the roles.

Having said all that, let’s get back to this job ad. It was interesting to see the description of the job duties. They included leading teams, writing a variety of documents, project management, time management, organization skills, and office software skills. True, some of these can be found in an (exceptional) admin, but the admin who took that position would probably rather be classified as a technical writer (and be compensated accordingly).

I don’t know what the company was offering to pay for the position, but I couldn’t help but wonder why they listed the position this way. Was it truly an administrative position? Or was it a tech writer position but they didn’t want to compensate the person as a tech writer? Or was it just an uninformed person who didn’t understand what a technical writer does, or is worth?

I run into that a lot—undervaluing and misunderstanding the role and worth of good technical writing services. To a great extent people just don’t know what a technical writer can do, or the value of their work product. So it’s an ongoing task: educating people and organizations about the role of technical writers, their range of skills and capabilities, and what they can accomplish. I keep trying, and hope that the message will eventually get through.

Hmm…maybe I should have a new job title. How does “technical writing evangelist” sound?  :)

Sphere: Related Content