On Triangles

      Comments Off on On Triangles

This post is directly prompted by a discussion on TechWR which, whilst it occasionally frustrates, continues to provide plenty of scope for thought.

Sylvia Braunstein asked about “Avoiding documentation bottlenecks whilst maintaining quality” and a couple of emails later the responses headed into a familiar territory. I call it the “management choice triangle” (or sometimes just the “pick two”) but you’ll all know the triangle, in one format or another, and under various guises, the premise is largely the same.

“Good, fast or cheap, pick two.”

However, as much as I prefer and encourage a minimalist writing style I think that summation is damaging. This particular triangle has been discussed, at length, by others but it’s always been something that perplexed me. I’ve always understood the basic presumptions being made and also that, despiting being sold by some as a hard and fast rule, it most certainly wasn’t as black and white as was being depicted. But then, what ever is?

Of course the basic (extracted) statements do seem to contain, and be entrenched in, some rather ineffable logic. Namely that you can have:

  • something good, quickly, but it will cost you (in resource)
  • something quickly and at low cost, but it won’t be any good
  • something cheap and good, but it will take a long time

All of which, of course, is utter tosh.

Without stepping on the toes of others, I’d suggest that “good” really should read “good enough”, that “fast” is meant in terms of “good enough within a given timescale” and that “cheap” really means “at some cost which we’ll do our best to minimise”. Thus we now have “Good enough within a given timescale, and at a cost which we’ll do our best to minimise”. There is no “pick two” of course, what kind of manager would abide by such a rule?

Deciding what is good enough for your organisation requires an understanding of who the audience is, budgets are set although can be influenced with some discussion, and timescales are things which need to be agreed. Money and time will always be constrained by senior management – everyone wants things faster and cheaper these days – so maybe, as technical writers, we need to concentrate harder on figuring out how we decide what we consider, and how we can measure, “good enough” documentation.

Previously that was largely the job of audience analysis but, perhaps, today there is another tack we can take.

If you work in software development, you are probably used to discussions around the prioritisation of functionality. The old “must have, should have, would like to have” type thing for example, and you may do the same with your documentation but, and here’s the twist, if you DO have a list of “would like to have” documentation features then why not publish it? Better still, create a Wiki, create empty pages for those areas and see what happens.

It may just turn out that those fringe areas of the documentation, which should match fringe areas of the product, are BETTER documented by the specialist users out on that fringe. Most products have users like this, the ones who know more about a specific area of your product than you do (because they’ve used your product for years whilst the developer who created it has long since left the building, perhaps) and they are usually more than keen to share (ok, to display) their knowledge.

So, maybe, good enough means we can publish documentation that is incomplete in certain fringe areas, making sure we make everyone know that is what we are doing. Maybe good enough starts with the creation of a living, user-contributed document, that very quickly becomes something better than it’s original. Maybe then “good, fast or cheap” can then be negated completely? OK, it is a bit of a leap but as different ways of accessing information continue to gain popularity, we, as a profession, need to be aware of this because if that “triangle” comes up in discussions with a project manager, then they may already be thinking of OTHER ways to provide information that is FAR cheaper than you can manage, and no, I don’t think that (overall) the quality of information provided by user-generated content will be all that far from “good enough” for that senior manager who is desperate to cut costs and timescales.

I’ll close with a couple of pertinent quotes from the mailing list, both of which can be found in the archives. First up, Beth Agnew points out the real value of the triangle:

I think the triangle, with its humorous variations, is meant to be more an aphorism than an axiom, a general rather than absolute truth. It’s a good way to help people understand the factors involved in quality projects. We could just as easily hang our hats on scope/risk/resources, or any other threesome that makes sense for our situation. I’ve found the good/cheap/fast idea to be very useful in educating clients who don’t seem to think a documentation or marketing project is an actual project where multiple factors must be managed. Once they realize that change in one area prompts changes in the other two areas, they start to understand the relationships among the variables and why some of their great ideas show up on their bill as an additional charge. 🙂

And Chris Borokowski makes a valid point when he says that:

It’s important to remember the triangle isn’t created like a three-position switch. It’s a slider switch. If you want anything done faster, there are going to be tradeoffs. If you want it done more> thoroughly (“better”) there will be more time requirements. If you want good, cheap and fast, it will be possible, but material will by the nature of time be left out.

It’ll be interesting to see how the triangle stacks up in the future, as it certainly seems as if some of the points are starting to fragment.