We are in the business of getting people the information they need and letting them get back to their life. Fundamentally, that’s what we do, whether we write user manuals, policies and procedures, create illustrations, videos, or any other thing.

And in this information rich world, this is an important thing to do.

No one reads the manuals

If I had a US dollar for every time I’ve heard “No one reads the manuals” I’d be retired in the tropics, playing with large dogs and writing crazy stories. While no one reads the instructions is a true statement, it’s a false statement.

People do read the instructions we provide. They do. But not like a novel – when was the last time you read your employers Policies and Procedures guide, start to finish? Probably never. It’s not that interesting.

But you may have read a part of it in the last month – perhaps when you completed your expense report for attending the STC Summit conference. Because you couldn’t remember what the per diem was and how to charge that properly. Because you don’t fill out expense reports often, you needed to be reminded of how to properly do that task. So you could get on with your life.

And that’s how it works

This is how our instructions are used – on demand. People rarely read our instructions from beginning to end, to see how it all turns out. Typically, people read what they need to know right now and then move on.

Perhaps they need to refresh their memory about how to run the month-end report, or how to rewire the speaker wiring for the home theater system the 3 year old gleefully pulled out. or they need to create an expense report.

So how can we help?

We can create short, to the point instructions for these user moments. I call them Job Aids, you may call them something else. But they are short overview instructions for important infrequent tasks.

Installation is a good job aid – typically called Getting Started guides. For most things, you install one time and then never again. You probably don’t reinstall your garage door opener – after it’s complete, you can happily throw away those instructions.

Other tasks that make good job aids are running end of month and end of year reporting. Not done often enough to remember exactly how to do it so a refresher is helpful. You probably don’t need to include how to run a report, because reports may be run at the end of every day. How to set up the end of year report and archive the data is similar but different.

Make them available to your users

OK, so if my users only need these infrequently, how do I get that information to them, you may be asking yourself.

You can ship them with the product, if you know ahead of time what is needed. But most of us don’t have the luxury of knowing ahead of time.

If you talk to your support people, they can give you ideas. Many of the questions they get are actually Job Aid questions. So talk to your support people and see if they get the same sorts of questions.

Then develop the job aid. Try to keep it to one sheet of paper, front and back.

Now you can post the job aid in the support area of your website. Ask support to tell callers about them. If you send a marketing thing to your users every month or so, include links to the newest job aids to get people to know they are there.

Job aids can impact the company’s bottom line

Consider tracking statistics to see how often the job aids are looked at/downloaded and if those sorts of questions are being asked less often in Support. That’s how you know you’re being effective. Take those numbers to management as clear evidence the docs group is making a bottom line impact on the business.

Clearly someone is reading them, you can say. As a matter of fact, this month, X people read them. And Y people didn’t call support to ask about that topic, as compared to 6 months ago.

Regardless of where you are in the world, we at Author-it would like to wish you a Happy Easter weekend.

For people in New Zealand and most of Europe, you have a 3 or 4 day holiday. It sounds like a great time to spend with your family, napping, or what ever makes you happy.

In the US, we don’t get any extra time off from work for Easter, but, as my Kiwi cohort mentioned yesterday, we do get Thanksgiving in November as a long holiday. For my cohort, the similarities are both long holidays are late Fall, early Winter for the local residents.

Something fun

As something fun, if you are attending the STC Summit in May, go to our Author-it Facebook page and Like us before May 17.  We’ll do a drawing in the booth at the Summit from the names who Like us and give something away.

Winner will be announced at the booth, on twitter, and Facebook. You don’t need to be present at the booth to win but if you are, you can take the prize with you right then.

Don’t forget the exciting webinar Monday the 25th

Don’t forget the exciting webinar next week: Content Development: Future Trends, Future Solutions Webinar, presented by Paul Trotter, Founder and CEO of Author-it Software Corporation. We have a lot of people signed up but we’ve got a little more room.

We will be recording this webinar. If you can’t attend because the date or time don’t work for you, sign up anyway. An email with a link to the recording will be sent to everyone the next day.

Whether it’s Spring or Fall where you are, enjoy the weekend and we’ll see you next week!

I was talking to a friend whose employer has merged with another company. My friend’s company spent the last 5 years clawing its way to supportable and repeatable processes throughout the company as they build software products. If you are familiar with the 5 levels of the Capability Maturity Model, they had finally reached something close to a level 4.

It was hard and they struggled but development, testing, and documentation had stable processes that supported consistently developing products.

Then the merger happened.

Post merger

As they bring the 2 companies together, they are also breaking the company into 2 parts, based on markets. The split is not based on previous company affiliation, but rather on the needs of each vertical market both companies sell into. It makes sense to break it up this way, because the products are related but the needs of each vertical are very different.

This could all be very good, except for one thing: the company they merged with has no actual product development processes.

And that could all work if Company A (my friend’s employer) consumed Company B. But that’s not what’s happening. As they break the companies apart and regroup into 2 separate business units, the processes of each company are staying in place. Those people who are moving into the business unit that was Company A get the existing and stable processes of Company A. Those who are moving into the business unit of what was Company B get all the processes of Company B, which is to say, none.

6 levels of the CMM

My friend and I have thought for years there are actually 6 levels of the CMM. We both discovered this level when we ran our own consulting companies. We also learned to identify and then run away when we first met with these potential clients because nothing good ever happened.

The 6th level is negative 1. Working with a negative 1 level will destroy your processes if you are a contracting company providing outsourcing services, like product documentation. Think of it as entropy.

There is a place for the negative 1 level – three people creating some wild new technology in a garage somewhere can actually benefit from this level because it strongly encourages crazy mad ideas that then get tried. These ideas would be shot down any other place because they are crazy mad ideas. But for these people in that garage, it’s a creative environment that works.

The moment these people move into any level of developing the crazy mad ideas into some actual products, level negative 1 will kill them. Perhaps slowly, perhaps quickly, but entropy will have it’s due.

And how do tools fit in here?

Very often, companies with few to no processes decide the problems they’re having are because they don’t have the right tools. If they got the right tools, they reason, this would all be better.

So they build a feature list.

And they buy new tools.

They don’t bother to train anyone, or set up any Best Practices for using the tools. They just buy them, install them, and then continue on the way they’ve been. And nothing changes, except some vendor somewhere got a nice fat check.

New tools are not feature lists

If you (or your company) are thinking about improving how you do the business of what you do, new tools can help a lot. But new tools also require that you look at your existing processes and be brave enough to change what isn’t working. And something isn’t working if you’re looking to get new tools.

Think of purchasing new tools as a time of reflection for your company. Identify what’s not working in your processes and then find tools that support your efforts to make it work better.

Don’t look for new tools based on a feature list – look for new tools based on the business problems you have and the business solutions you need. When you identify the business issues you need to solve, you’re going to be looking at processes as well. You can’t help it.

After a webinar the other day, I would up chatting in email with a fellow about useful books. So I thought I’d post a list of books I think should be on your bookshelf.

Listed in no particular order:

• Illustrating Computer Documentation: The Art of Presenting Information Graphically on Paper and Online by William Horton

Altho this book was published in 1991, it’s still very relevent today. He covers how to present information visually, especially important for us non-visual learners.

• DITA 101, 2nd edition. by Ann Rockley

Even if you’re not moving to DITA, this book is valuable because it makes you think about how to structure your information to be useful to your readers.

• Information Development: Managing Your Documentation Projects, Portfolio, and People by Joann T. Hackos

I cannot recommend this book enough. She clearly discusses why content is a business asset and how to manage it.

• Single Sourcing: Building Modular Documentation by Kurt Ament

Do you have any to add to the list? What have I missed?

If you didn’t go to the Intelligent Content conference in Palm Springs last week, you really missed out.

I was holding down the booth and talking to people so I didn’t get to much of the sessions but the ones I did attend were great.

And they made me think about where our field is heading.

Content as a business asset

Content is starting to be thought of as the business asset it always has been. It has the potential to inform and educate our customers. This includes our technical content, such as product instructions and knowledge bases.

Additionally, our users are creating content. Think forums, blogs, etc. Some of this content is fantastically useful to our users and needs to be included somehow into the “official” content. How to do that for your specific organization is an interesting question.

The future

Now, if you’re a content development professional, you may be panicking at the thought of your users writing the content and you become a line editor. I think that’s an over-reaction.

I think we are poised to move into part content creator and part community manager. And I think this is a good move. We are not the keepers of all things worth knowing – our users are also very smart people who figure out stuff we didn’t think of. And we should be open to this input.

Additionally, think of all the content you’d love to create if only you had the time. Perhaps your user community can do that for you.

Don’t be afraid

And I admit, this idea can be scary. We’ve worked hard as a profession to be smart and create good content. Some of us still work in organizations where they believe anyone can write so tech comm isn’t anything special. This sounds like that but worse.

That’s why I think our role is going to shift. We still add value – potentially a lot of value – but it’s going to be different value. And it’s up to us to create that new role.

Your thoughts? Do you agree that our role is changing or do you think this is another fad?

I’ve been in this industry a long time and I’ve seen a lot of workflows. I’ve been in the position of:

• Write like crazy, hoping for the best
• Plan every detail to the smallest step
• Not allowed to talk to the developers
• Easy reviews
• No reviews
  • A personal favorite reviewer who would not sign the docs off as accurate if the word “must” appeared any where in the 800 page mainframe manuals. “It sounds like we’re ordering them,” she said.
• And everything else you can imagine

My heroes have always been writers

Because I have no actual life, I was thinking about this as I was walking my tricolor Australian Shepherd over the weekend. During the 2.75 mile brisk walk, I was thinking about all the places where technical documentation goes wrong.

I was also thinking about my duckling engineering students. I’m trying to grow the engineers we all want to work with. This quarter, they seem very passive and helpless. I’m worried that if they don’t show more iniative that they are going to go in the box of “bad reviewers”. I’m worried about other things for them as well, but these were my thoughts.

And that made me start wondering why we get crazed bad reviewers in the first place.

• No one cares? I see such passion in other areas of the product development, so I don’t think that’s all of it.
• The reviewer finally has control over something? In the case of my “must” reviewer, I think that was the case.
• Engineers have a hard time understanding the different audience needs? I see this from some of my ducklings, so that’s part of it, I think.
• Institutional culture? I think sometimes this is the case. I worked at a place where one of the senior dev leads would stop my writers in the hall and spend 10 minutes talking about how what we did was stupid and a waste of company money and not needed. The VP of Dev didn’t think this was out of line. I wanted to do the same to his developers but I’m too nice.

What do you think?

Feel free to share your stories about bad reviewers and why you think it happened. What do you think are the motivations for bad reviewers and bad reviews?

One of the things that we tech comm people do is function in a business environment. That means we have a different audience internally with specific needs. We need to meet those needs if we want to function well.

If you have ever asked for a new tool or other “thing” from your boss and it didn’t happen, one of the ways around that is to make a business case. I asked a friend and business associate this week to write about this topic, as he has co-authored several articles about building a business case and has run several workshops on the topic.

Making the business case shows your company that there is a financial reason why you need a new tool, for example.

Here’s Jack.

How to Build a Business Case

The amount of money that is anticipated to be saved or generated as the direct result of an expenditure is known as Return on Investment (ROI).  ROI is usually measured in time and money: how long it will take to recoup the money spent, and how much money will be saved or generated.

When speaking of ROI on a new investment, one states how long it will take to recoup the initial investment via new sales—and then some (profit).

When speaking of ROI on a cost avoidance expenditure, one states how long it will take to recoup the initial expenditure via the money saved.

While it may take years to recoup a large investment, a client of mine in Alameda, CA localized their documentation into so many languages that they reported recouping the cost of purchasing Author-it (through reduced translation costs) in just one product release!

When you build your business case:

• State the problem
• Offer a solution
• State how much it will cost to implement the solution
• State the ROI that could be realized when the solution is implemented

Be sure to state what the problem is for the company, not just for you. The problem is not, “We need a content management system,” the problem is, “We are spending $XX per month more than we need to on translation costs!”

By finding ways to decrease costs and increase profits, you are also showing how you add to the company’s bottom line.

Which, BTW, is a business case for you getting bigger raise come review time, right?

When you get a group of professional writers – or programmers, or project managers, or any one else, really – we love to talk about the projects that went south and the craziness that ensued. There’s a certain Can you believe this? that needs to be shared.

I heard a story recently. Names are not disclosed to protect the guilty.

Process=good

We’ve all heard that having a stable, repeatable process is a good thing. I’ve taught that you need one to get quality documents. But I was told this story about a process:

1. A person in the company wants content created (perhaps a customer has expressed a need) and enters the request in DatabaseA. That request is sent to Writer, who analyzes the need, and agrees. Writer changes the status of the request, adds his comments and sends it to Editor.
2. Editor evaluates the request, agrees with Writer, updates the request with the location(s) Editor wants to see the new content in the existing content organization.
3. The request is sent back to Writer. Writer agrees with the location and number of topics. Or Writer changes and sends back to Editor for further discussion.
4. Writer creates the shell topics one by one, by hand.
5. Then Writer enters these topic names in DatabaseB, including suggested index words, meta tags, and so on. Writer send the new structure to Editor for review.
6. Editor agrees or not, and approves or not.
7. Assuming it is finally approved, Writer starts writing. When writer is ready with a topic, he updates databaseB with the status of the topic and send it to Editor.
8. Editor reviews for language, conforming to standards, etc, and suggests or demands changes. No technical content is reviewed at this time.
9. The change request is logged in DatabaseB and sent back to Writer. Rinse and repeat until Writer and Editor finally agree.
10. In DatabaseA, Writer now marks that the content is ready for first technical review, including the location and name of the topic. This information is sent to the initial requestor for First Technical Review.
11. A process similar to, but slightly different from, the Writer/Editor thing happens until Requestor is happy.
12. Then Writer updates DatabaseB and sends the topic back to Editor. Because the topic changed and has to be approved by Editor.
13. You know what happens next, as it’s similar to what happened before.

Continue on, adding databases and reviewers until the content is considered “ready.” It can take months for 100 new words to appear out of this group. Months.

You don’t even want to know how this group goes about publishing content but I think we can all guess that it involves a lot of homegrown scripts no one understands anymore and a lot of machine time in some magical process that involves elves weaving straw into gold.

Did I mention they then probably localize the content? What are the odds that process goes any better than this one?

Bad process=Bad

When I was told this story over a beer, I shook my head and declared this to be the most broken process I’ve seen in a long career of broken processes. As a process, it’s certainly repeatable and has steps and all the other stuff we expect in a process. The most important point was missed, tho.

It’s a bad process.

Content that takes months to get in the customer hands is a broken process. It doesn’t matter that we have a process if it ignores the reason we have the group in the first place – to support the users. This process seems to exist for the sake of a process, which I think is wrong. It’s focusing on the wrong stuff.

It’s your turn

Pull up a chair and share your best bad process story. Don’t name names, just share the fun. Tell the story so we can all share in the head shaking. I may give away a t-shirt or something to the best story.

Let me give you an example: In one of my first projects I had to organize the relocation of the company to a new, much larger building. As part of the process, we needed to clarify a couple of issues regarding the alarm and security.

I duly summarized our questions in an email and sent it to the contractor responsible for the fit-out. Not that I expected an answer within a week (by the way: that’s what I’d expect sending this email to a German company), but after 10 days I would have been really happy to receive at least a mail saying “received – we will get back to you”. But the CEO of this company did not contact me, messages on his mobile box remained unanswered, as well as my “friendly reminder” e-mails.

Anyway, about two weeks later of complete “communication silence” I finally managed to reach him by phone. His reaction was a very friendly “it’s no problem at all, no worries”. We clarified our questions and just minutes later all the issues were sorted out, task boxes were ticked. I was happy, but couldn’t help thinking “why on earth didn’t this happen sooner?”.

Not, that I am feeling peeved, I am just a bit bemused. All I wanted to do was get a response in a timely and organized way, but without ‘nagging’ my partners or upsetting them.
This, by the way, is far from the end of the story: A couple of weeks later we have finally moved into the new building. My understanding of the role of a Project Manager includes cross-checking the initial quote and PO with the services and installations delivered to us.

And guess, what was the result? A quick look at what we asked – and paid for, and what was actually carried out revealed some inconsistencies, to say the least.

The response from the contractor: “Oh, my goodness, we have forgotten to install the temperature sensor in the server room.” And once again, in the friendliest of tones he added “it’s no problem at all, no worries”.

I am sure, by the time we were finished they would have wished I was anywhere else rather than on the project: This “smart project manager” is really checking everything and he does not give up until all is done … And I have since had heaps of other very similar bits of feedback, all about me following up, sticking to schedules and chasing deadlines.

I realize that my style of working is pretty pedantic (I’ve been told I won’t ever starve in hell…) but surely it’s not too much to ask for a project to be carried out, as agreed, on time?

I am still working hard on finding my very own German/Kiwi balance: So far it seems to be “stay relaxed, but not too relaxed”. So, does anyone else have similar experiences about working in another country? Is it a cultural issue, or more about the character of the individual?