It’s Time To Get Professional: Using Metrics To Select Software And Make Smart Business Decisions
In a blog post on MonkeyPi—RoboHelp 6 Arrives, And It’s Craptastic—several technical communicators (and a few software marketing folk) are having a discussion about the Adobe RoboHelp, the popular online help / single-sourcing software used by many technical writers. The blog posting has yielded several tangential discussions, but what’s not being discussed is why professional technical documentation teams don’t use metrics when making software purchasing decisions. Scott Abel of TheContentWrangler.com left the following comment on the blog and is in the process of authoring several articles (and a presentation or two) on the topic. Here’s what he had to say…
Vendors of software know that most technical communicators have no idea how to shop for tools. They know that we ask the wrong first question (What’s the best authoring tool?) and that we often rely on listserv and blog posts to guide our buying decisions (Hey, that MonkeyPi guy likes it so we ought to throw out our old tools and buy that new thing he says is way cool.)
Smart software vendors capitalize on this. They customize their advertisements to address our lack of knowledge (The RoboHelp Replacement) and they sprinkle in — for good measure — a spice packet of industry jargon and flavor-boosting keywords (XML, DITA, reuse). They can stretch the truth because they know we don’t understand the subtle, yet important differences between various software products (e.g. XML is not the same as XHTML). And, they also realize we don’t know much more about our own industry standards (They say the new version doesn’t support DITA, but it does support topic-based authoring, so it will work just the same).
They also bank on the fact that we are unlikely to follow the guidance of our best and brightest industry gurus (analyze existing content, identify needs, make changes in processes, develop content models, select tools that best match our needs – Rockley, Hackos, etc.) because it’s faster to skip those steps and hope things will work out fine. After all, we’ve skipped these steps for years and look how much better we do today than in the past.
While some software vendors are smart to target our weakness in the tools and technology arenas, they miss the mark when they create campaigns designed to sell “return on investment” to documentation managers who can’t/don’t/won’t/aren’t made to collect any metrics. How on earth can you make an accurate business case for changing tools (who cares which ones or who used to work at the companies that make them) if you don’t know what it costs to do business at your company today? How will you know which tool has the best chance of helping you speed up your processes, reduce expenses, and eliminate manual tasks that can be automated, if all you know about your own environment is how you feel about what you’re doing and what you think might make good improvements. It’s about time we introduced a little science (and math) to the field of technical communication.
Buying the right software for the right reasons can provide your organization with a strategic advantage. As such, software purchasing decisions ought to be done with a strategy in mind and based on real, actionable data about your environment, your authors, your customers, and your organizational needs and goals. And, the decisions should be metrics-based (quantifiable).
Features are nice, but they have little to do with the true cost of adopting software.
As a profession, we ought to seek ways to become smart software shoppers. Once tech docs managers adopt tools that can aid them in collecting metrics (No, Excel is not a technical publications management metrics gathering tool) we may be able to select products that actually provide us with both an excellent return on our investment and a long-term strategic advantage over the competition.
We at TheContentWrangler.com expect the issue of software tool selection — and metrics gathering — to become an increasingly important topic as organizations look for ways to save money through process improvements. We’re planning a special Management Summit at the upcoming Documentation and Training East 2007 Conference (October 16-20, 2007) that will provide managers with the skills needed to understand how to collect, maintain and utilize metrics to make smart business decisions. And, we’ll provide guidance on shopping for and selecting the right tools (content component management, web content, and XML authoring). Learn more: http://www.doctrain.com.
Similar Posts:
- DITA Test Drive Challenge: A Great Deal If You Ask Us
- Most Documentation Managers Don’t Use Metrics As Performance Measure
- HyperSTE: An STE Plug-In For Word, Frame, Arbortext and XMetaL
At the recent X-Pubs conference in Reading (England) a lot of the speakers stressed the fact that a tool was not a solution, and that properly understanding the technological requirements, and the requirement to manage changes to working practises, was the most important aspect of embarking on a single source solution.
I’d say the same holds true for any ‘tool’.
Mind you, I think there is a need for more technical writers/authors to gain more business savvy, relating what we do in a business context is a fair more effective way of showing our worth, and quantifiable data is the best method of all.
Metric on!
In my field of practice – performance management – the saying goes: “What gets measured, gets done”. By the same token: “What gets measured, gets valued”. Since nobody seems to care which tools a mechanic uses to fix your car – why would it matter which tools you use to fix your documentation challenges? Another saying: “A poor carpenter blames his tools …” I’m one of the ‘industry experts’ speaking at X-Pubs and other conferences, and I constantly repeat the mantra: “CMS: It’s a process, not a product”.
And I’ll just confirm that Emma gave a great presentation on this at X-Pubs, it was good to get a non-technical approach as well. There are so many factors to a successful CMS implementation (and usage).
Ohh and Emma also knows several dirty jokes… but not as many as Bernard Aschwanden, I had the pleasure of sharing their company at dinner on the Sunday night after the conference.