Stuck in a system

by Tom Johnson on May 7, 2012
categories: technical-writing

I've been reading Sarah Maddox's new book, Confluence, Tech Comm, Chocolate, and have been impressed. I enjoy the energy and speed in Sarah's writing. If you've read her blog before, her book has the same tone.

This is not a book review, because I'm not yet finished with the book. But it doesn't take too many pages to come to some realizations worth noting. My primary realization: I wish I had a Confluence wiki rather than a Mediawiki wiki. I intend to explore Confluence some more. After reading the chapter on installation, it seemed easy enough, so I am uploading the bin file right now and will attempt to make it work with Linux commands on our team server (I don't know Linux, sorry, so I'm really relying on the Sarah's documentation here).

While that bin file is uploading, let me elaborate on what I think is a larger problem. I think vendors all too quickly forget how hard it is to change systems. I didn't choose Mediawiki. I didn't choose Joomla. I didn't choose SharePoint. I didn't choose Author-it. I didn't choose many of the help authoring tools that are at my disposal. What's on "the menu," what's "off the menu" -- many times decisions are made by others.

But regardless of how one gets saddled with a tool, the longer you use it, the more difficult it becomes to break free of it. For example, our blog for our tech group runs on Joomla. Why? Because the developer who initially set it up was familiar with Joomla, and it works well as a content management system, which was its initial purpose. Other developers coded a community framework into Joomla, adding a custom extension. This extension was integrated into other systems, such as JIRA. And then other developers hacked in some blogging features we needed, such as tags and comments.

The other week we discussed a redesign for the site, and several of us felt that if we wanted to switch from Joomla to WordPress, now would be the time. However, after some discussion, it was decided that the cost would be too high. Developers would need to almost reinvent a dozen customizations and integration points. It would be easier and cheaper just to stay with our existing platform.

One could say the same about our wiki platform. Mediawiki was free. Some helpful extensions integrated nicely with our user database. Others added a WAM (web-access-management) component to enable single-sign-on, and little by little, it was made to work well with our other systems. Now Tom comes along and tries to make it work for documentation, but alas, Mediawiki handles documentation poorly. Most notably, its lack of content spaces makes it highly problematic. I noted in a previous post -- Subpage Titles on Wikis -- Challenges, Conventions, and Compromises -- the problem of having all product information in the same space. If all of your product information lives in the same space, then page titles, search, and navigation all become problematic.

I won't go to the trouble of re-articulating all the issues here. My basic point is this: As I learned more about the way Confluence provides so much customization around spaces -- you can skin a space, you can provide different versions in different spaces, you can customize rights for different spaces, and so on -- I started to feel jealous and then eager to experiment with this other wiki platform.

But herein lies the problem, and it is a universal problem, not just with IT. Once you're stuck with a system, knee-deep integrated into your environment, how do you get out of it?

For example, suppose you decided to purchase a heavy-duty enterprise wide help authoring system, one that costs more than $100K. About a year into the solution, you start to feel that it's the wrong direction. But you've already spent all your money on that solution, and your manager won't be too happy to learn that all of this money was in vain, that another solution was better, cheaper, simpler, and easier. Do you keep going down the original path, because you're already so invested in it? Should you simply try to "make it work," because you're three-quarters of the way across the river, and it's silly to change horses mid-stream?

Or do you jump off that horse, swim back to the original side, and beg for money to buy a different horse, one that swims much better, and then attempt to re-cross the river? Further, suppose you're not the only rider on the horse. Instead of the main rider, you're a feeble child, dependent on a parent to influence for decisions? (That is often the case in an IT organization. The technical writers don't have the bank account information for their organization, nor the free will to spend it.)

This scenario reminds me of a conference presentation I once attended on project management. It was called The Abilene Paradox. Basically, it's a big analogy about why projects fail, and the collective mentality that supports failure. The Abilene Paradox was depicted in a video showing a group of people sitting around on a Sunday afternoon, trying to decide what to do for dinner. The father in the family says, "Well, we could go to that old diner in Abilene." Abilene, a small city in Texas, is about 50 miles away, so it's no small journey.

No one wants to go, but no one has a better idea, and before they know it, they all pile into a hot stuffy truck and travel 50 miles down an old highway toward Abilene. The whole way there, almost no one talks, because no one really wants to go there in the first place. When they reach the diner in Abilene, they order dinner and have a meager conversation, and then get back in the truck and drive home.

The trip takes most of the afternoon and evening, and later they start talking about why they decided to go to Abilene. It turns out the father suggested the trip in jest, not really thinking they would go. But when others agreed, he decided to agree as well. Everyone chimes in about how he or she never wanted to go but went along with it because he or she thought the others were behind the idea.

The paradox is that you have a group of people all behind a decision, working to see it through, when in fact none of them actually wants that decision.

How can you get out from under the Abilene paradox? How can you buck off ineffective systems and install what you really want, even when you've sunk so much money into an existing solution?

I'm not sure, but that is the crux. When you walk down vendor halls at conferences, and a salesman shows you how slick his or her tool works, it's not that I'm not open to the idea. The tool probably does work better than the tool I'm using. It's probably more efficient, more flexible, and better suited to the task. But the cost of switching, and moving in another direction is ... oh... so... hard.

In discussing the difficulty in switching solutions, my colleague pointed out to me the theory of "sunk costs." The basic idea of sunk costs is that however much money you've sunk into something, that money should not affect future decisions because the money is not recoverable. But the fact that you've already sunk money into a solution persuades you mentally to believe that it was the right solution, even when it wasn't.

The Wikipedia entry on sunk costs has a great story to elaborate. The idea is that if you've sunk a lot of money into a solution, you're more apt you are to believe it's the right solution:

In 1968 Knox and Inkster, in what is perhaps the classic sunk cost experiment, approached 141 horse bettors: 72 of the people had just finished placing a $2.00 bet within the past 30 seconds, and 69 people were about to place a $2.00 bet in the next 30 seconds. Their hypothesis was that people who had just committed themselves to a course of action (betting $2.00) would reduce post-decision dissonance by believing more strongly than ever that they had picked a winner. Knox and Inkster asked the bettors to rate their horse's chances of winning on a 7-point scale.

What they found was that people who were about to place a bet rated the chance that their horse would win at an average of 3.48 which corresponded to a "fair chance of winning" whereas people who had just finished betting gave an average rating of 4.81 which corresponded to a "good chance of winning". Their hypothesis was confirmed: after making a $2.00 commitment, people became more confident their bet would pay off. Knox and Inkster performed an ancillary test on the patrons of the horses themselves and managed (after normalization) to repeat their finding almost identically. (See Sunk Costs.)

Sunk costs present another challenge in getting out of a system. When you've sunk money into a solution, you're less likely to see the problem in an unbiased way. The sunk costs blind you with a myopia to see the solution you've purchased as the superior one.

Clearly the best way out of these situations is to avoid them in the first place. Before you agree to a tool or other system, evaluate it in depth. Do research, pilot tests, interview other people who have bought the product, and so on.

However, no matter how much research you do, chances are you won't fully understand the strengths and weaknesses of the system until you've actually used it in a real scenario. And to really put a system to the test, you need to use it against a real project, with real users. That kind of pilot testing may take months, maybe even a year. By that time, the tool landscape may well have changed so that your initial evaluation is no longer current. An entirely new set of variables may be in effect.