How much does “good” cost?

Recently, Ben Minson stated that “Good Enough” Really Isn’t. It’s an interesting post, and I wanted to expand on the comment I left on his blog.

Ben suggests that:

If I find myself thinking “It’s good enough” on a regular basis, I—and my users—am probably not getting all that’s possible out of my work

Before I go any further, perhaps we need to clarify what “good enough” means?

My fear is that many people take “good enough” to mean, “yeah, I’m done with that and it’ll have to be good enough”. If that is the case then yes, you are selling your users, and yourself, short. However there is a perfectly valid scenario around which the phrase “good enough” could, and should, be used.

There is a classic business situation that drives the use of the phrase, it is one with which we are all familiar and which will never ever change, and that is the age old issue of high quality deliverables versus cost of delivery. It is sometimes stated in terms of Return On Investment but the bottom line is that, at a certain point, regardless of your deliverable, there comes a point where the amount you are spending on something has reached the maximum value you can expect to gain.

Finding the balance of that will, without doubt, mean that you disappoint some users. The Pareto principle is typically offered as a rule of thumb at this point (wrongly as it happens) with the presumption that “good enough” means meeting the needs of 80% of your audience, knowing that 20% will not be as well served. The reality probably that 20% of your documentation will be used but that’s for another blog post.

Ultimately whilst we would all love to provide better information, both in quantity and quality, projects have deadlines, budgets have limits and it is there we find the true definition of “good enough”. It’s up to us, as professionals, to make the most of these situations so that when we say something is “good enough”, we mean exactly that.

Comments

  1. “Before I go any further, perhaps we need to clarify what “good enough” means?”

    Meets the requirements? You have requirements, right?

  2. For the documentation? More than “please document this, thanks?”… sometimes. But rarely would I expect anyone bar the technical writer to be able to accurately set acceptance criteria for documentation and, and this is my point, we, as a profession, tend to be completists which can lead you away from achieving a positive ROI.

  3. “Good enough” exists because there is never enough time to do it right the first time, but there is always time to do it over.

  4. Good article.

    It might also be worth considering the opportunity cost of continuing to work on something past the point where it’s “good enough.” There are probably other projects a writer can turn their attention to at that point that would produce more value for the time spent.

  5. @Gordon says:

    “But rarely would I expect anyone bar the technical writer to be able to accurately set acceptance criteria for documentation and, and this is my point, we, as a profession, tend to be completists which can lead you away from achieving a positive ROI.”

    Unfortunately, top quality documentation seldom, if ever, is able to achieve a positive ROI unless you define “positive ROI” as on time and within budget constraints.

    I’ll confess to being a “completist”. It’s always been my objective to provide the best possible documentation for the user… to provide documentation that will enable the user to answer any question they might have about the product without having to involve the support staff. If I do my job well enough, inbound support contacts will be reduced dramatically. *There* is what I consider positive ROI in a documentation project.

    However, many times the bar for “good enough” is set by project managers or others who have little or no understanding of what we technical writers do, let alone what we as professionals in the field would consider top quality documentation. In many cases, their sole objective is to be able to check that checkbox labeled “Documentation” without any consideration of any sort of standards whatsoever. When we, as technical communicators, encounter this kind of thinking, we usually have little choice but to choke back the bile and start the next project.

  6. Mike – Spot on, the lowering of Support calls is a measurable ROI although it takes a lot of effort to get measurements in place. I’ve often stated (deliberately to provoke) that the job of my team is to put our Support team out of business! 🙂

    As for the project manager setting the bar, I’ve not experienced that and would fight tooth and nail to have a say in it. Never easy, that battle, but it is winnable on occasion.

Comments are closed.