Job Search Management Tools

WIND (Wednesday Is Networking Day) is a professional networking group in the greater Boston area, with meetings on different days north, west, and south of the city.  I typically attend the WIND North meeting, which is facilitated by WIND Executive Director Fred Nothnagel.

At WIND North last week, Fred Nothnagel gave a presentation on using the CRM capabilities in Microsoft Outlook to manage the job search. One question that came up was alternatives to Outlook for those of us that do not have MS Office. I said I would investigate these alternatives.

CRM is an abbreviation for “Customer Relationship Managment”, also known as “Client Relationship Management” or “Contact Relationship Management”. It is the practice of “using technology [usually software] to organize, automate, and synchronize business processes—principally sales activities, but also those for marketing, customer service, and technical support.” (source).

I looked at two commonly-available open-source CRM tools: SugarCRM and vtiger. If you have a web site, these tools may be available from your web host. My web host, for example, makes SugarCRM available. If you do not have web hosting, I recommend using an alternative tool, as these tools require both a web server and a database. (I’ll discuss alternatives below.) Even if you do have web hosting, I’m not sure these are the best tools, as they have more capabilities than you really need to manage a job search, such as tracking for marketing campaigns, tech support tickets, and sales orders.

Two more practical options are available: Personal Information Management (PIM) systems and job search management web sites.

One job search management web site has been mentioned at recent WIND North meetings, JibberJobber (www.jibberjobber.com). A second one I discovered is CleverCareerist (www.clevercareerist.com). Both offer the ability to manage:

  • networking contacts
  • job search tasks
  • target companies
  • job board searches
  • resumes and conver letters

CleverCareerist offers a free 7-day trial. After that, it is a paid service, with three levels of plans: Basic ($9.95 per month), Professional ($29.95 per month) and Ultimate ($59.95 per month).

JibberJobber has a free basic service, which allows you to manage up to 75 target companies, recruiters, and job boards, and 250 networking contacts. Silver service ($5 per month) expands that to 1000 companies, recruiters, and job boards, and 1000 networking contacts. Premium Service ($9.95 per month) allows unlimited contacts, companies, recruiters, and job boards.

I have played with both sites a little in the past few days, and I don’t see that CleverCareerist offers any significant benefit over JibberJobber, especially considering the price. You get Premium service from JibberJobber for the same price as basic service from CleverCareerist, making JibberJobber a much better value.

These are the only two job search management sites I found,. If anyone knows of others I missed, I’d be more than happy to hear about them.

Personal Information Management (PIM) software are bascially computerized personal organizers. They can manage:

  • Personal notes/journal
  • Address books
  • Lists (including task lists)
  • Significant calendar dates
  • Birthdays
  • Anniversaries
  • Email, instant message archives
  • Appointments and meetings
  • Reminders
  • Fax communications, voicemail
  • Project management
  • and so forth.

A variety of PIM products are available, many of them have free editions. Here are three I downloaded and played with:

EssenialPIM and EfficientPIM bear a very strong resemblence to current versions of Outlook. PIM XP uses a tree motif for its interface. EssentialPIM, like Outlook, can act as an email client.  You can add and manage contacts, tasks, and other calendar entries in all of these products.

Personally, I’m likely to start using EfficientPIM, since I don’t need the email client (I use Mozilla Thunderbird for e-mail). I might use JibberJobber since it’s basic plan is free and can help me manage target companies and recruiters.

Content Strategy: Enterprise Content Management Redux?

Reading tech writing blogs recently, I can’t help but notice that “content strategy” is currently a very popular topic.  But the more I read about it, the more I am reminded about “enterprise content management” (ECM), a term that was in vogue around 2004 to 2007.  Indeed, Ann Rockley uses the term “unified content strategy” frequently in her book on Enterprise Content Management.  I see a lot of the same concepts and phrases being thrown around ( “content silos”) that Rockley uses in her book.    And it’s difficult not to notice that some of the articles most frequently cited when defining content strategy (such as The Discipline of Content Strategy by Kristina Halvorson and Content Strategy: The Philosophy of Data by Rachel Lovinger) were written as even as ECM was going out of vogue.

What I saw at the ECM Revolution

When ECM was in vogue, I was working for a company that produced a content management system (CMS).  Most CMSs at the time had been developed to manage and deliver web content.  Most CM systems did this well.

When ECM came into vogue, CMS companies began driving to do several things:

  • Develop compatibility and interfaces to  other products subsumed under the ECM rubric, such as digital asset management (DAM) and records management.  Companies began negotiating alliances and development teams dedicated time and resources to developing these interfaces.
  • Add functionality to address missing capability in the product.  In particular, CMS developers began to add print document management capability to their CMS.  When developers with a web mindset tried to develop interfaces to manage print documents (where order is as important as hierarchy), the result could be…interesting.  Indeed, in some cases, the results were practically unusable.

Then, suddenly, around 2007, ECM went out of vogue.  Most CMS developers began emphasizing their web bona fides, sometimes labeling their products specifically as web content management (WCM) in a specific effort to distance themselves from ECM.

What Happened to ECM?

Like the revolutions of 1848, the ECM vogue was “a turning point at which history failed to turn”.  It failed to turn for two reasons, one obvious and not uncommon, the other more subtle and potentially troubling.

The ECM vogue, as is so often the case, was driven by market analysts, who were telling the vendors of CMS, DAM, and other types of software, that customers were demanding enterprise content management capability, while telling customers that they needed this capability and that it would solve all of their problems.  (I’d love to see a study of the role that market analysts play in creating and driving trends like this; I’m sure it would be very informative.  Perhaps it’s already been written and I don’t know about it.  If so, I’d love to find out.)

It did not take customers long to realize they had been oversold, that the ECM tools they were buying were not solving all of their problems (and often created new and different set of headaches in and of themselves).  Once customers began realizing ECM tools have been oversold, the whole concept lost credibility, and customers no longer wanted to hear the term.

Which leads to the second reason “history failed to turn”.  ECM is not simply a set of capabilities and tools.  You couldn’t get ECM simply buying the right tools because ECM required a cultural change more than a change of tools.  Content silos do not exist simply because of incompatible tools (although incompatible tools  aggravate the problem).  Content silos exist because different organizations in a company compete as often as they cooperate, sometimes more often than they cooperate.  Organizations compete for resources, control, political capital; competition is a fundamental characteristic of the corporate milieu.

The Upshot

ECM, content strategy, call it what you will, can only work, can only be successful, in an atmosphere of cooperation, not competition.  Engendering this atmosphere requires a radical change in corporate culture, a change that is alien to corporate culture and can only be driven from the top.  Only when executive leadership sees the value in cooperating to create and maintain content will they foster and enforce the cooperative culture fundamental to the very function of ECM or content strategy.

As I see it, the advocates of content strategy (or ECM) face a threefold challenge:

  • The first, and possibly easiest, is to themselves recognize  the shift in corporate culture inherent in the very concept of content strategy/ECM.  Only when they recognize the need for a cultural shift can they begin develop strategies to bring about the cultural change, and begin to generate real value from a coherent strategy for managing content across an organization.
  • Develop strategies strategies to bring about the changes in corporate culture required to implement content strategy/ECM, and thus return real value from the practice.
  • Execute those strategies to convince corporate executives that content strategy/ECM has real value, enough value that it’s worth their effort, often the hassle and headache, to make and enforce the cultural changes required to implement content strategy/ECM successfully.  This is the most tricky of the three to realize, but without it, I don’t see content strategy/ECM going anywhere.

Decisions, Decisions! Choosing Wiki Software

Once you make the decision to start using a wiki, whether to foster internal collaboration or for external delivery, you need to pick your wiki software. Selecting a wiki platform is no easy task, as literally dozens of options are available.

You could turn to a site such as WikMatrix (www.wikimatrix.org). This site not only lists a variety of available wikis, with a brief assessments of their features, but includes a Wiki Choice Wizard (http://www.wikimatrix.org/wizard.php) to help you select a wiki. Unfortunately, this wizard is not very useful, as it asks such questions as your preferred backend (database, text file, or revision comparison system), language, hosting options, and preferred programming language.

These issues are all important to a wiki programmer, but they’re not the important questions facing a technical writer or documentation manager, who has a very different set of concerns. When I began working with wikis, I worked out a different set of questions, based on my needs as someone that develops and delivers product documentation:

Scalability

A small product may only require a few dozen pages, but even a moderately complex product could require hundreds of pages. Depending on the number of products you support, the complexity of those products, and the number of versions of each product you support, you can easily generate and manage several thousand pages. Not all wikis scale to thousands of pages effectively.

Multiple Layers of Security

When delivering documentation for a product, in particular for a proprietary product, you will want to provide multiple layers of access. At a minimum, you want to ensure that members of your documentation team can add and modify the content but that the general public cannot. But you may want to consider even more complex model. For example, you may want to allow anyone to read your content, but only allow customers to comment on it. Alternatively, you may want to open edit rights to a select group of customers, or to section off a portion of the wiki where customers can contribute their own documentation. Not all wikis support such complex security models. Others say they can support such models, but implementing the security model turns out to be challenging even to technically sophisticated users.

Tables of Contents

Tables of contents are a major avenue for navigating a wiki. Tables of contents provide navigation for multiple headings on a single page, or for a group of pages. Ideally, your wiki provides both.

Sectioning Wiki Content

Depending on the number and complexity of the products you are supporting, and the number of versions you want to support, you may want to section off different portions of your wiki. You may want to section off information within one wiki (such as creating different “spaces” or “categories”), or you may prefer to use different wiki instances to maintain and deliver different content.

Comments and Moderation

A key benefit of wikis is the ability of users to interact with your content, either by modifying it directly or by adding comments. Most wiki platforms support comments, but some require edit access to add comments, potentially opening content modification too broadly. Moreover, the Web is notorious for content that exceeds the bounds of decorum and professionalism. Comment moderation is a key capability for ensuring that the content on your wiki remains professional and projects a positive image of your organization.

Workflow or Approval Process

Most technical writers work in environments where content goes through at least a minimal cycle of review and evaluation before public distribution. This is one area that is weak to non-existent in most wiki software, as “wiki culture” favors more open access and modification rights. The theory in wiki culture is that open modification rights gradually evolve more accurate content. Anyone with more than a passing familiarity with Wikipedia is aware that certain topics have become such notorious battlegrounds that they have locked down and administer carefully. Wikis have so far resisted workflow or approval processes, so you will have to work around this limitation.

Export to .pdf and Online Help Formats

Users often like to print out pages for frequent reference. Some wiki products allow you to create printer-friendly pages, but others provide even more robust options for creating organized manuals as .pdf files.

If you use a wiki for internal collaboration, you may have a need to provide online Help for your user interfaces, in formats such as Microsoft compiled HTMLHelp (.chm format), JavaHelp, the Eclipse Help format, or even plain HTML. For most wiki products, you will likely need to port the content into a Help-authoring tool (HAT) such as RoboHelp, Flare, Doc-to-Help, or Author-IT to output these formats. For one or two tools, plugins or other addons are available that provide the ability to output to online Help formats. These addons often include the ability to output to .pdf as well.

Sidenote: Analytics

Especially when you begin delivering your documentation externally via wiki, some stakeholders in your organization may want to track and report on analytics data. Analytics is not a capability inherent in most wikis, but many can include addons that can plugin to analytics sites, tools, and packages.

Good Service Keeps Me Coming Back

Saturday morning, my wife and I took our son out for breakfast.  We went to a little, local hole in the wall place, not open a year yet.  But I bet they’ll stay open a while, and here’s why.

Taking our drink order, the waitress, one of the owners, told us that morning special, stuffed French toast with a berry topping.  She had my wife until the berries; my wife’s aversion to berries is notorious.

Returning with the drinks, the waitress brought a small bowl of the berry topping with two spoons.  “I thought I’d let you have a try.  It’s not a compote, no sugar, just a nice berry reduction.”  We tried it and she was right, the mixture had a nice balance of sweet and tart.
So we got the special, which was both tasty and filling.  “Wait until you see next weekend’s special,” declared when she brought the check.  “Breakfast pizzas!”.

Later in the day, I went to Men’s Warehouse for a few items I need.  I’m not a fan of clothes shopping, and it’s been several years since I added to my wardrobe.  But I need to update for a few events coming up.  I had hardly begun looking when one of the staff asked if I needed help.  I replied that I needed a couple of new ties, and maybe one or two new shirts.  The salesman took some measurements, and picked out a few different shirts.  After discussing the upcoming occasions, we narrowed down the choice of shirts, and a nice selection of ties.

“You picked the right day, sir”, he said.  “We’re having a 2-for-1 sale.”  I glanced at the suit rack.  I had been considering purchasing an additional suit.  “That includes suits?” I asked.
“Everything we have except shoes,” he replied.  I don’t typically drop several hundred dollars without a lot of forethought and investigation.  But the opportunity to get two suits, and accessories, for the price of one was, after a few minutes thought, too good to pass up.
We discussed colors, and he selected a couple of suits for me to try.  When the fitting was finished and I had changed back into my street clothes, he brought me to a table where he had prepared a set of accessories (suspenders, socks, etc.) to go with each suit.  I liked most of the choices, but made a few changes.   At the register, the hit to my credit card was short of four figures, but not by too much.

Was I upsold?  Absolutely.  Was it worth it?  Definitely.  Surprisingly, given how little I care for shopping, I was a little reluctant to leave.  The last time I shopped for a suit was at Men’s Warehouse, and I was similarly impressed then.  That previous service made them my first choice.

That’s especially true after I had a much worse experience with one of their competitors, Joseph A. Bank, a while ago.  Needing a couple of accessories for a wake and funeral, I stopped at one of these stores along my way home from work.   Unlike Men’s Warehouse, no one ever asked if I needed any help.  Indeed, I stood waiting at the register for several minutes waiting for someone to check me out.  They were much too busy, let’s just say “discussing” something, to help me.  And in the end, the prices were much higher.  A couple of accessories wound up costing close to a hundred dollars.

So Men’s Warehouse has won my business.

As for that diner?  “We’re coming here for breakfast next weekend, aren’t we?” I said to my wife after the waitress dropped the check.  I know that look in her eyes.  We’ll be there, too.

Update:  Alas, we did not make it to the diner for the breakfast pizzas.  I friend of mine died early in the week, and that Saturday morning was devoted to the funeral.  -RLJII

Additional thoughts on wikis

I’ve had a couple of encounters this week that have me thinking a bit more about wikis and their place in technical documentation.

The first was a post I came across on Tom Johnson’s blog, I’d Rather Be Writing, “Findablity and The Information Paradox“.  Here’s the key statement:

The more information you add to a help file, the more informative it becomes because it contains more information. However, as you add more information to your help file, it also becomes less informative because it’s harder for users to find that information.

Writing for an enterprise product, as I do, I definitely appreciate the concern expressed here.  And I’ve certainly experienced the problem first-hand:  users, even experienced internal users, often have difficulty finding the information they need in the volume of documentation we provide.  As often as not, the (imperfect) solution is to use the “tech writer search engine”; the writers wrote it, so they probably know where to find it.  (That assumption usually turns out correct, BTW.)  One major part of the problem, especially for customers, is that the user often doesn’t know what they need, so they don’t know how to search for it.

At first glance, opening the wiki to user contributions, as I’ve recommended, would seem to exacerbate this problem; more users contributing more content only adds to the clutter and makes finding the information even harder.  But if the 90/9/1 rule described by Anne Gentle in Conversation and Community is correct, this is not very likely to be a problem.  The 90/9/1 rule states that 90 percent of users lurk, 9 percent comment, and only one percent actually contribute.  It would take a very large community indeed before 1 percent contributed sufficient content to create a true problem.  Moreover, in Tom Johnson’s case, he was adding the documentation he thought was necessary, while in the community zone of the wiki, the users themselves are contributing the content, giving them more of a stake in it.

This user stake is enhanced if the wiki is part of a community infrastructure, including a robust forum.  The community itself is likely to build an “institutional memory” that will help address the findability problem.  Most contributors will let the community know when they’ve contributed something (whether out of ego or altruism); others are likely to remember and when the information, or similar information is requested, they can point to the original contribution.  So if Tae-min contributes a topic he thought was needed, and later Somnath asked about something similar, Igor might remember Tae-min’s contribution and suggest it to Somnath.

The second encounter I had was with someone involved in producing documentation for products related to health care and medicine.  When the conversation turned to wikis, she expressed doubts about her users would embrace a wiki, or at least the more communal aspects of wikis, due to concerns over proprietary information.   As I’ve thought about it, I wonder if the heavy regulation of the health-care industry might also play a role inhibiting adoption and embrace of wikis, forums, and other community approaches to documentation delivery.

Here, I’m on less certain ground, partly because I’m not in the health care industry (though, like all of us, I’m definitely a consumer!).  Still, it seems like community approaches to documentation have benefits that are worth investigating, and certainly the generation currently entering the workforce is much more accustomed to robust communities, and will bring their preferences and experiences with them.  It seems like a area ripe for investigation and experimentation.

The documentation “trilemma”

Most of us are familiar with the business truism “Good, fast, cheap:  pick two”.  A few years ago the documentation team I led discussed documentation quality and settled on another trio.  Documentation, we agreed should be

  • accurate
  • complete
  • accessible

This isn’t quite the same dilemma (or trilemma?).  Accuracy exists independent of completeness and accessibility.  Moreover, accuracy isn’t optional; inaccurate documentation makes a product as whole less usable, and less trustworthy.

Completeness and accessibility are more of a true dilemma, though, and involve trade-offs.  The more we make documentation complete, the less accessible it becomes (more detail means more irrelevant chaff for the reader to search through trying to glean the kernel of useful information).  Excessive completeness was long the bane of users, as technical documentation provided reams of technical detail about features and options available in each software product, with little real guidance to completing whatever particular task the user had in hand at the moment.

Conversely, the more accessible we make the documentation, the less complete it may become, as we remove detail to focus on more common, important, and relevant matters.  For example, Microsoft already documents Windows, and browsers have their own documentation.  We do not need to document either of these products, as their producers already document them more effectively than we could.  Another common approach to filtering detail is the “80/20 rule”:  eighty percent of users use twenty percent of features.  So we ensure that we focus our attention on those features.  A major portion of the documentation work when designing new features is identifying that twenty percent and ensuring that we document them correctly.  A side-effect, unfortunately, is that some features are not as well documented as we, our our users would like.

One way around this problem is to implement an open documentation or community-oriented documentation approach, delivering  documentation on a wiki platform, coordinated with a support forum and blogs.   This approach helps improve accuracy by making it easier for users to report errors, and easier for employees  to correct them on the fly.  In fact, edit rights on a wiki should be open to development and tech support teams as well as the documentation team specifically so they can correct trivial errors quickly.  The search and tagging features of wiki enhance the accessibility of the documentation, allowing the documentation team to add more content.

Moreover, you can provide users with the ability to help guide you in determining the right content to provide by opening a “sandbox” on the wiki, an area where they can contribute documentation they see as needed or useful.  A sandbox hands some of the power of documentation design over to the very users of that documentation.  The documentation team can, and should, keep an eye on the content contributed to this sandbox, ensuring that it is accurate, and evaluating whether customer-contributed content should be incorporated into the official documentation.

Kids and Writing

On my way out the door the other morning, I paused to join a conversation my wife and daughter were having.  My daughter had decided she wanted to enter our school district’s annual writing contest, in which she placed third last year.  She had been working on a draft for her entry the night before, when I thought she was working on a school assignment.

Moreover, the story she was working on was only one idea she had for the contest.  She has at least a couple of others she wants to draft.  She has plenty of time.  The deadline for the contest is in March.  And she’s already showing a fair bit of maturity as a writer in her approach to the contest, starting early, starting a few different pieces, and planning to write at least a couple of drafts.

So it looks like the writing bug has bitten her.  It’s not all that surprising, given that both my wife and I studied writing in college (I as a historian, she as a journalism major), and that we have both worked as technical writers.  And I can’t help but be proud that my daughter wants to write, too. In the end, it’s far too early to tell if she will make a profession of writing, and if she does what type of writing she will pursue.  But she’s started on the path, and I’m proud and gratified.

A very useful document

This summer I had surgery at Lahey Clinic in Burlington, Massachusetts.  During the prep, I had to change from my street clothes into a pair of hospital johnnies, one opening in back, the other opening in front, like a robe.  On the wall of the changing stalls was a nice little document with clear step-by-step instructions for putting on the two garments.  Each step was accompanied by a picture of a patient putting the gowns on.

It was a great, very useful document.  It was concise, clear, and told me all I needed to know about how to don these garments for my procedure.   It was  great piece of technical communication.

A few weeks later after I was released, I experienced some side-effects of the surgery, and one of the diagnostics was an x-ray.  As for the surgery, the radiology department asked me to change into a pair of johnnies.  I was disappointed to see that radiology did not have a copy of the instruction document from the surgical suite.

It’s a shame radiology doesn’t have a copy of the document.  It’s a great piece of technical communication, and it left me with a great impression, as a patient and as a technical writer.  And I was disappointed not to see it shared by other departments of the hospital.