After a few days of travel and other diversions, I’m back home and settling into the old routine. The last day of STC 2008 flew by pretty quickly. I saw two talks, plus the closing keynote. The first talk was Results of a Survey on the Usage and Impacts of Single-Sourcing and Content Management, by David Dayton of Towson University. Dayton’s objective was to see to what extent people actually realize the benefits of Content Management and Single-Sourcing (CMSS).

According to Dayton, there is a “meme” in Technical Communication literature:

“XML-enabled CMSS heralds a bright future for those willing to learn—

• Structured authoring
• More collaborative workflows
• New tools that break with WYSIWYG to enforce structural rules and use meta-information”

In his view, there is a “Strong current of technological determinism in the literature on this subject.”

However, there is very little good data on how widely these technologies are used or what their impact is on those who use them. His study, supported by STC, attempts to provide a “cross-sectional statistical view of SS and CM methods and tools.” The study, which is still underway, includes a survey of STC members, which is complete, but not completely analysed; interviews and site visits; and a Web 2.0 website to collect first-hand reports.

He will be publishing a full report early next year, but he did discuss some of the results, some of which are very interesting. Here are some highlights:

• The majority of IBM DITA users don’t use a Content Management System, but do single-source; I expected more users at IBM would use a CMS.
• About two out of five respondents use single sourcing, but only one in five uses single sourcing with content management.
• About one in three uses content management without single sourcing.
• Only 1/3 of respondents said that CMSS had made their work group more customer-centered.
• 18% said that their work group had been involved in an effort to switch to CM or SS that failed; seems lower than expected.
• Adoption appears to be in the “Early Majority” phase of the innovation adoption curve; i.e., still well ahead of a tipping point, and he can’t predict when that point will be reached.

I’m looking forward to his full report; it will be nice to have a more quantitative look at how these technologies work in the real world.

The second regular session I attended was Editing Modular Documentation: Some Best Practices by Michelle Corbin of IBM and Yoel Strimling of Comverse. This was an excellent presentation; the presenters had a clear sequence, good examples, and clearly stated conclusions. I went to this presentation because I’ve rarely had real editors on my staff, so I thought it would be interesting to see some, plus I was curious about what it’s like editing in a modular methodology.

To me the biggest surprise was the extent to which the presenters’ editing teams got involved with structure. In fact, it looks like the major value of editors in their environment is to ensure consistent chunking, labeling, and linking; i.e., the three basics of modular documentation. Issues of writing consistency and style are distinctly secondary, though not ignored. Given the propensity of organizations to undervalue editing and the tendency for technical communicators to rename roles every few months, I’m surprised that this particular role, which has evolved considerably from what I’ve always thought of as editing, hasn’t been renamed to something glitzier.

Regardless, the talk did give me a new appreciation of this role, and a better understanding of how it can add value in a modular methodology.

The last talk I went to was the closing keynote, by Richard Saul Wurman, who was best known to me as the originator of the Access travel guides. This was a relaxed, informal talk that almost went off the rails a couple of times, but kept me engaged. Wurman has a strong pragmatic streak and is someone who is able to get to the heart of an issue. His current focus is on a project called 192021 (http://192012.org), which looks at 19 cities in the world with over 20 million in population in the 21st century.

In his view, the “rise of supercities is the megatrend of the 21st century.” As of last year, more than half of the world’s population lives in cities, and by 2050, 2/3 of the world’s population will live in cities. 192021 is a five-year comparative study of these cities, looking at things like health, education, demographics, infrastructure, and culture. By using a consistent methodology, it will be possible to compare various aspects of these population centers and track trends. Like his other projects, 192021 strives to make complex information consistent and understandable, and sounds like it will be a worthy project.

While I would have liked to see a little more about how he thinks and how he approaches a topic, I thought the talk was a nice cap to the program and left me with a lot to think about.

Today for me was mostly split between two types of events, talks about Agile development techniques, in particular Scrum, and two “progressions.” To take the latter first, progressions were a new concept to me. A progression is held in a room with several large tables, each of which has a moderator with a particular topic. Over the course of a one to two hour progression, participants cycle through 1-4 tables, and have a short conversation with the moderator and other participants. It’s a bit like the conference version of “speed dating,” without the fear of rejection.

I ended up at three tables over two progressions, covering topics from Marketing yourself as an independent consultant, to Managing in-country translation reviews, to Managing Virtual Teams. I found the progressions a good way to network with experienced pros, though there was less prepared material than I expected. Still, I made some good contacts and got some good ideas.

The two Scrum talks, Scrum: An Agile Approach to Managing Content Projects, by Julie MacAller of Microsoft, and Agile Development: Challenges in Transforming TechComm Departments, by Mike Wethington of Troux Technology, provided a nice overview of Scrum. There’s no space here for (nor are you likely to have the patience for) a full description of Agile methodologies or Scrum, but here is my best understanding of the Cliff Notes version based on a grand total of two hours of talks. Skip ahead if you’re familiar with Scrum.

The base of the methodology is the Roadmap, which is a high level, long term, multi-release plan; the sample Mike Wethington showed was just one page. Releases are implemented through a series of Sprints, each of which is a 2-4 week cycle. The planning process generates a backlog, which is the list of all the work being done on the project. The granularity is such that any writer will implement around 10-12 backlog items over the course of a 2 week sprint.

There is an initial planning session for each sprint that selects the backlog items that will be implemented during that sprint. The items may be design, implementation, documentation, or testing; in short, if it’s not on the backlog, it doesn’t exist. Over the course of the sprint, the full team meets every day for a short (15 minute max) meeting (called a scrum) to discuss: 1) what was accomplished in the last day, 2) what’s next, and 3) what’s standing in the way. When the team gets big, these meetings may be split, with a representative from each scrum attending another (still only 15 minute) scrum with other representatives.

Sprints continue until the release is complete.

The basic idea is to build a visible, inspected, and adaptable process. Key to making the process work is quick turnaround and resolution of issues, plus open communication among all committed parties.

Unlike some methodologies, Scrum gives documentation a full seat at the table. In Scrum terminology, there are Pigs and Chickens, as in “when you make ham and eggs, chickens are interested, but pigs are committed.” The committed (pigs) are the core of the team and are all central players. Technical communicators are considered pigs, along with developers and QA (quality assurance).

Some of the keys to making scrum work, according to Julie and Mike, are:

• Make sprint goals customer focused, grouping detailed topics into customer “stories”
• Pick the right moment to start writing. There’s a tendency to get started too early, which can be a real problem with a fluid process.
• Get every work item on the backlog, including reviews and SME interviews.
• Keep processes lightweight; since you report status daily, formal tracking can be lightweight.
• Make sure daily scrum meetings are with development, and not separate.

Overall, I found scrum to be an intriguing methodology. I’ve managed writers who have used earlier incarnations of Agile methodologies, including spiral development, which is similar, but with longer cycles (more on the order of 6 months), but this is the first time I saw this kind of methodology as offering a significantly better way of doing things.

One final note. The second talk, by Mike Wethington, resembled a scrum. There were constant questions, and the talk evolved based on the questions. In a sense, each slide was a sprint, with frequent questions and discussion. I think this was not by design, though Mike was receptive to questions. Rather, it was just a result of participation by several folks who resonated with the ideas, and were assertive. In fact, I wonder whether a side benefit of this methodology is to encourage more assertive behavior on the part of technical communicators.

The one talk that didn’t fall into these categories was Creating Task-based Navigation with DITA, with Mike Priestley of IBM and Amber Swope of Just Systems. They gave a good combination talk/demo on creating task-based navigation using an application called Task Modeler, which is beta software available from IBM. This application uses a GUI to let you build a DITA application, including the ditamap, relationship tables, and topic groups. It was nice to see these two skillful presenters put together a nicely integrated and interactive presentation.

My only reservation was a claim that DITA is “ridiculously cheaper” to customize than a custom schema. One company (Nokia) found that changes took 50% less time for DITA, and would have been even better if you didn’t count the planning time. While I’m sure the difference is significant between DITA and a custom schema, the comparison I’d like to see is DITA vs. DocBook. I would not expect to see nearly the difference. However, this demo did show that the tool support for DITA is improving quickly; the Task Modeler is a very nice application that I expect will become very popular.

That’s all for now.

Three out of four ain’t bad, and the fourth wasn’t awful, just not excellent. Rather that drag you through all four sessions, I’ll summarize the highlights from the three I got the most from.

The opening Keynote speaker was Howard Rheingold, who gave an interesting talk that centered on the way mobile communication (texting, cell phones, etc.) is changing human interaction. In addition to being an interesting speech, I found his use of graphics compelling. Instead of the usual bullet points that echo what the speaker is saying, he used graphics that reinforced his points, along with a video sequence, which was nicely synchronized with the speech despite some minor technical problems.

In the afternoon, I attended two panel discussions, the first was titled Content Management Systems Why Can’t I just Pick One. Participants included Steve Manning of the Rockley Group, Rahel Bailie of Intentional Systems, Nancy Kotkin of Independence Blue Cross, and the moderator, Alan Houser of Group Wellesley.

They spent some time talking about different kinds of Content Management Systems, including Document Management Systems, which primarily store completed documents; Web Content Management Systems, which support web sites; Component Content Management Systems, which support authoring of components. The latter was until recently a niche market that didn’t even have an industry standard name.

The rub for technical communicators is that IT departments typically think of the “big gun” Document or Web Content Management Systems when they think about CMS’s. This leads the IT folks to think they’ve solved the content management problem, even though these two types of CMS’s typically are not set up for editing, storage, and retrieval of components.

Alan then asked the participants some questions, starting with, “How do you assess a customer’s needs?” He further honed this to, “what’s your first question”? The clearest answer to that came from Steve, who asks, “what’s the problem you’re trying to solve?” As I heard at DocTrain, and have heard elsewhere this week, customers typically put the cart before the horse here, asking questions like, “what’s the best CMS?” before they even have the slightest idea what they’re trying to do. Steve estimated that as many as two out of five CMS projects fail, for exactly this reason, though he hastened to add that his company’s failure rate is “nil.”

The next question came from an audience member, who asked about granularity. This caused a fair amount of discussion, with a couple of interesting points: Nancy commented that she’s seen projects hit serious problems because they could not agree on the degree of granularity needed. She also said that she’s found that technical writers have an easier time working with fine-grained structures than training developers. The latter tend to see their output as more of a narrative than the former.

Most of the remaining discussion centered around what you should do if your company is starting the search for a CMS, or in a worse case, has already chosen a CMS. Consensus was that you must get involved with the acquisition and help make sure a sound business decision is made. Since IT departments have different needs from technical communication, it’s important to be part of the decision as early as possible. If you get in after a decision gets made, you need to do the same analysis, then see how well the chosen system meets your needs.

Bottom line all around is to look at the problem you’re solving, evaluate needs, and make sure you’re part of the decision making team when/if a CMS selection is occurring.

The second panel was Evangelizing, Proselytizing, and Preaching: Strategies for Marketing Yourself and Your Expertice to Others. The moderator was Scott Abel, with panelists Ann Rockley, Rahel Bailie, Chris Hester, and Tom Johnson. Scott ran a tight, well organized panel. He began by asking each panelist for a favorite marketing tactic. Chris and Tom, who are employees, both suggested “inserting” yourself into meetings and taking the user’s perspective in those meetings.

Ann and Rahel, who are independent consultants, suggested being active with STC and to share knowledge. Early in her career, Ann was a member of STC and an active networker. When she was laid off from her job, she was quickly able to find contracting employment because of her contacts. Now, she doesn’t do “traditional” marketing. She continues to share information, attend conferences, and network. She has been able to build a strong reputation through those means.

Rahel is a prolific writer who uses blog and forum posts, conference attendance, and her web site as outreach. However, she doesn’t see the web site as an ad. Instead, she sees it as providing information that can give prospective customers a taste of what she does and how she does it. Someone looking at her site can get a good idea of whether her company will be a good fit for their needs.

Other good suggestions for “self” marketing, both inside and outside you company, included:

• Make sure the engineers you work with understand what you do and what value you add.
• Blog internally and use other internal communication vehicles to establish your credentials as a communicator and user advocate.
• Chris regularly meets with senior staff and shows them the work her team is doing. She also has one-on-one meetings with senior staff where her objective is to make sure she 1) understands their needs and 2) is meeting them.
• Tom has had great success with podcasting, and commented that there are very few technical communicators doing podcasts. There’s an opportunity to establish a niche using podcasting, and few people are taking advantage of that opportunity. (I’ll be starting my podcast shortly

While these communication techniques are powerful, each of the panelists conceded that you need to prioritize your efforts; doing everything they suggest would leave no time for “real work.” Ann tends to limit blogging, using twitter, etc. She also drops “optional” activities she doesn’t enjoy. Rahel has stopped detailed filing of information (she keeps material unfiled; she finds that locating material when she infrequently needs it takes less time that filing it carefully). Chris compartmentalizes and batches activity (TIVO helps). Tom doesn’t consider most of this to be work; he clearly enjoys the podcasting and other “marketing” activities.

The final question was how they put together their “elevator” pitch. The conclusion was that it takes time, practice, lots of metaphors, more time, and more practice. No one found this easy, though all found it essential.

That’s all for now. Another good day, though with all the available activities, it’s easy to feel like you’re missing something important, regardless of how valuable the sessions you attend turn out to be.

I’m at the STC 2008 conference this week and will be posting my comments here each day. This is my first STC conference, and so far I’m impressed. Registration was smooth, in part because our badges were mailed in advance. We just needed to pick up the obligatory tote bag, badge holder, program, and marketing material from the sponsors.

I was pleased and surprised that there was a session right off the bat; a panel titled, Is What You’re Doing Today Enough to Remain Competitive Tomorrow? The panelists were Jack Molisani, Andrea Ames, Bogo Vatovec, and Barbara Giammona (I think that is her name, she was a replacement for Bill See, who was not there), with moderator Paula Berger.

The panel turned out to be a lively crowd that enjoyed mixing it up. They started off with a few random thoughts before getting up a head of steam. Among the random comments, I particularly liked Andrea’s four word slogan, Think More, Write Less. Not only would that make a great book title, it also captures the essence of the panel’s discussion.

The issue the group settled in on was how to avoid being “commoditized.” A commodity product is one where the only real differentiation is in the pricing. If you are “just” a technical writer, you run the risk of becoming a commodity that can be easily replaced with a lower price alternative. Andrea, with the concurrence of the rest of the panel, suggested that technical communicators should be asking why instead of what, and should be thinking in terms of solving business problems, rather than documenting products.

She then asked how many people were involved with deciding what their deliverables would be. She was surprised (and I was shocked) at how few people had a hand in deliverable design or even input into the process. As a quick digression, I consider deliverable design to be a core technical communication task, and I’m surprised at how many folks indicated they are in a situation where their deliverables are dictated to them.

The moderator then asked each participant to recommend courses/training that could help communicators avoid becoming a “commodity.” Here are their responses:

Molisani: He recommends Toastmasters, and suggested improving domain knowledge.

Giammona: She recommended project management training. She told a story about Morgan Stanley, her previous employer. Within the centralized doc group, there was a group of people who expanded their communications skills and found jobs in other areas, and another group of people who stayed as pure technical writers. As Morgan went through a series of re-organizations and downsizing, the people in the first group kept their jobs, but those in the second didn’t.

Vatovec: He suggested learning Project Management skills, Information Architecture, and Object Oriented methodologies; anything but pure technical writing.

Andrea: She suggested learning about DITA, but focusing on the methodology behind it, rather than just the markup. She also suggested honing negotiating and influencing skills.

At this point, someone commented that the consensus recommendation seemed to be to get out of technical writing.

The best response to this came, I think, from Andrea, who said that writers shouldn’t change their careers, but rather should change the way they think about their careers. Jack added that you should think along the lines for being Technical Writer/something else (information architect, interface designer, etc) rather than simply “Technical Writer.”

Beyond the obvious point that broader skills will make you more employable, it’s also the case, fair or unfair, that “Technical Writer” as a job category has less value in the marketplace than other skills.

They wrapped things up with two discussions; first about off-shoring. Beyond the usual questions of reducing costs, Bogo made the important point that some off-shoring is necessary because the market for products has expanded well beyond the U.S. and companies need to go where market knowledge is, regardless of the location.

The final point that I found interesting was a point Bogo made about task oriented writing. He decried documentation that described how to do isolated, and often trivial, tasks without context. The interface should make it obvious how to do simple tasks, like printing, without additional documentation. Where the technical communicator can add value is through context and a deeper understanding of how to solve problems.

Overall, a wide ranging, sometimes disjoint, but thought-provoking panel that I think got things off to a good start.

I spent the last four days scheduling volunteers for an organization supporting the disaster relief after last week’s tornado in Colorado. When I came home each evening, I would find another installment of a lively discussion about motivation on the mailing list for the Society for Technical Communication’s (STC) Management Special Interest Group (SIG). It wasn’t until the fourth day that I realized that my “day job” as a volunteer was also a lesson on motivation.

So, what did I learn?

• For the right cause, people will do pretty much anything.

  For example, I found out at 6pm on Friday night that I needed to assemble a crew of 10 to unload a supply truck at 5am the next morning. Hard work at an insane hour, but I got commitments from everyone I needed within 3 hours. And, for every activity I needed to schedule, we had more volunteers than we needed. This response didn’t happen because I have some magical skill as a motivator; it happened because the need was critical.

  Most business objectives are not as clearly “right” as feeding disaster victims, but if your objectives make sense, are clearly communicated, and can be seen as productive for the organization, you’ve got a much better chance of having motivated people.

• A strong group helps keep people motivated.

  Nearly everyone who volunteered came as part of a group, and not just groups like Red Cross and Salvation Army that exist specifically for disaster relief. Churches and other community groups were a big part of the effort. While there were a few stalwart folks who volunteered independently, they were in the minority. The reason is pretty clear; if you’re a member of a strong group, you have a motive to serve the group as well as a motive to serve the group’s objectives. The two reinforce each other.

  Given today’s highly outsourced, geographically diverse projects, most of which operate in an environment where downsizing is the flavor of the decade, it’s difficult to build a strong team, but if you can pull it off, it becomes really difficult for team members to remain unmotivated. They either get with the program or leave.

All of that said, motivation is internal. You can identify clear objectives, communicate them vigorously, create a strong team, and build a supportive environment, but they have to drink the Kool Aid, you can’t do it for them.

I believe that most people will be motivated if you do these things, but some won’t; they may be in the wrong place, be going through problems outside of work, or simply be one of those folks who never gets motivated by anything. When that happens, you can coerce them and get some results, but almost always the best thing you can do is find them a better job fit or get them out of the environment.

Today was the last “official” day of the conference. Tomorrow (Friday) is a post-conference day of workshops. Unfortunately, I need to leave early Friday, so I’ll miss the workshops.

Today started with 3 keynote talks. The first was from Joshua Duhl of Quark and titled, Once Content is in XML, Now What? He introduced the idea of dynamic publishing. While the talk was mostly a pitch for Quark, it was interesting because Quark is not normally thought of as an XML company. I think it’s encouraging that companies that have mostly been in other parts of the technical documentation world are seriously working with XML.

The second keynote was Document Engineering in User Experience Design, by Robert Glushko of the University of California, Berkeley. Bob has a new book titled, Document Engineering: Analyzing and Designing Documents for Business Informatics and Web Services.

He spoke about the idea of Document Engineering as a methodology that is a synthesis of information and system analysis, and business process engineering. In an e-commerce environment, customer satisfaction is more than the User Interface. We tend to think of the customer experience as being a “front stage” function; that is, the immediately visible parts of a system. But, in fact, the “back stage” functions, the plumbing that makes everything happen matters as much to customer satisfaction.

Glushko says that we need designs that cut across back and front stage operations. He described the “Moment of Truth,” which is the point where a problem or other critical event becomes clear to the customer. Moments of Truth are often the intrusion of a back stage problem (supply chain problems or other failures in plumbing) onto the front stage. The design needs to encompass both the front and back stage to be fully successful.

The third keynote was Social Media 101, presented by Darren Barefoot of Capulet Communications. Darren was probably the most skillful presenter I saw this week in the use of presentation materials. He used very few words; large portions of the talk were accompanied by pictures that alluded to what he was discussing, but rarely, if ever, repeated what he was saying.

He discussed characteristics of social media, which include conversation, collaboration, sharing, broadening of scope, community, transparency, and authenticity. To me the critical point is that all manner of web communications have become multi-way. There are few areas where a pure, one way broadcast of information makes sense. For example, users are now part of the product support cycle, having input into every part of the support cycle.

The second critical message is that resistance is not only futile, it’s counterproductive. Companies will gain more by giving up some control and taking full advantage of social media. This means empowering your most passionate users, giving users the tools they need to help each other, and going to the places your users go. If they use youtube, you need to be there; if they use twitter, go there.

The first regular session of the day I attended was DocBook vs DITA: Will the Real Standard Please Stand Up, presented by Teresa Mulvihill. Since I’m on the DocBook TC, I was particularly interested in this talk. In general, I think Mulvihill’s views are close to mine (see my article titled, Choosing an XML Schema: DocBook or DITA). However, as someone who has worked with customers on both DocBook and DITA, she sees more difference between the two tool chains than I’ve seen (I’ve done extensive work with DocBook, but much less with DITA, so I don’t have her perspective). She strongly favors DocBook in smaller, turnkey environments; a sentiment I share, though possibly not as strongly.

We were fortunate to have people who use both DocBook and DITA in the audience and had a good discussion after the formal talk.

The next talk was a short talk by David Ashton, of SDL (the company that offers the TRADOS translation support tool), titled 24 Ways to Shut Down the Application and other Apocryphal Stories. He gave a nice high level introduction to some of the trials and tribulations of translation, tying it into the publication process.

I then snuck into the second half of Joe Gollner’s last talk of the conference, Extreme Content Makeover: Migrating Content to DITA. While the talk focused on DITA, the basic principles would apply to any data conversion. In addition to the expected exhortations to plan carefully, Joe covered some less obvious, but important points, including:

• Establish Control Collections, which means to look for groupings of files that have similar features, and therefore are likely to need the same kinds of conversions.
• Define the target end state, which goes beyond simply selecting a target schema; that’s just the bare minimum. You also need to consider linking, metadata, and other details of the target.
• Prepare a conversion specification, which defines the end state, naming conventions, mappings, and so forth.
• Establish a representative example set, which is a group of files that cover the range of the control collections and gives you a set of content for testing.
• Build a conversion plan, which is a project plan for the conversion itself.

Overall, Gollner provided an excellent overview of what it takes to do a successful conversion, whether it be a conversion to DITA, or a conversion to some other XML format.

The last regular session I saw was Using Task Modeler to Streamline DITA Content Development, by Mark Wallis of IBM. This was a demonstration of IBM’s Task Modeler. In addition to demonstrating the software, Wallis described the methodology his team uses to structure content. They design “Task Support Clusters,” which provide conceptual, task, and reference information as a self-contained cluster of DITA topics. They use a minimalist approach, but try to keep each cluster independent, to the extent of avoiding links outside the cluster.

The software helps with the mechanics of setting up a cluster by helping authors visually build ditamaps, develop initial topics, build relation tables, and build a skeleton cluster. The interface looked straightforward, and I’ll be trying it out.

The closing keynote was titled Living Multiple Lives: The New Technical Communicator, and was presented by Noz Urbina. He talked about findings from techdoc evaluations his company has done for several companies, but the main focus was on distilling those ideas into suggestions on “What to do on Monday”? In other words, what can participants do when they get back to work next week to improve their environments.

He did what a closing keynote speaker should do; he summed up the main points of the conference, which I take as the following:

• Moving to XML can gain significant productivity. He cites the potential for 15-30% reductions in localization costs, and another 15-30% savings from reuse.
• You don’t get these benefits by buying some tool; in fact, selecting tools should be one of the last things you do.
• You need to understand your needs and use cases first.
• The job of technical communicators is rapidly changing, mostly for the better. But, to take advantage of those changes, communicators need break out of the “manual box,” establish a business-driven strategy, and work closely with other parts of their organizations.
• Agile methodologies can be a good thing for communicators because they pull communicators into the process early on, and the methodology takes documentation seriously.

Overall, I found the conference to be useful, both through the talks and through interactions with other attendees. There was a manageable number of people, and I had the good fortune to speak with many of them, including several of the speakers. There was a casual atmosphere that encouraged discussion with the speakers and other attendees. The facility was excellent and the logistics were handled cleanly and efficiently. Overall an excellent conference.

Today was the first “official” day of the DocTrain conference. Yesterday was a “pre-conference” workshop day.

Things started with 2 keynotes. I was a bit late and only caught the secoind half of RJ Jacquez’s keynote: Bringing the Video Revolution to Technical Communication. This was primarily a demonstration of Adobe’s latest products, in particular, Adobe AIR. While it looks cool, I didn’t see enough to get a sense of how well it would fit in with an XML environment.

The second keynote was XML in the Wilderness by Joe Gollner. This was an interesting look at the history of XML and Content Management, which if nothing else has pushed me to check out Ted Nelson, Vannevar Bush, and Douglas Engelbart, three of the “fathers” of XML and content management. Gollner is an entertaining speaker, who has obviously spent a lot of time thinking about SGML, XML, and Content Engineering. The main points of his talk echoed his workshop, with the addition of some nice historical points.

The first conference session I saw was Ann Rockley’s Component Content Management. She defines Component Content Management (CCM) as managing content on a granular level with each component having its own life cycle. In her view, CCM is not well supported by most tools. Since terminology is still vague, this can case problems, especially when an IT organization buys a CMS and assumes it will work as a CCM. The problem is that most Web CM, Enterprise CM (ECM), and Digital CM systems don’t deal with chunks of information that aren’d documents or webpages.

Rockley then spoke about evaluating CMS software, highlighting a new publication, developed in conjunction with CMS Review, titled XML Component Content Management Report 2008, which evaluates CCM systems. She also spoke about the importance of going beyond tools. In her view, which I heartily agree with, “Successful CCM is about:

• Understanding your content
• Understanding your user requirements
• A solid reuse governance plan
• Information Architecture (taxonomy, UI, workflow)”

While tools are important, they are not the most important question. Yet, tools considerations often dominate the discussion and distort evaluation.

The next session was Single Sourcing House, by Heidi Sandler of Siemens. She used the analogy of building a house, which while occasionally strained, was an apt analogy for building a single sourcing system. I was mostly impressed with some of her quantitative measures, which showed a significant (3-4x) improvement in productivity with the introduction of an XML based single sourcing system. The other item of note was a suggestion to keep a written history about decisions. Given how quickly things change in most organizations, this could be very useful.

I got a third dose of Joe Gollner in the next talk, which was titled, Putting Everything Back Together Again: Delivering Effective Information Products. This talk expanded on his earlier discussion. He made the point that while preparation and design are important, a more flexible planning approach may be a better way to deal with the “Uncontrolled growth” that characterizes content management these days.

Gollner presented a few case studies that served to illustrate the wide variety of content applications out there and to emphasize the point that old style waterfall style planning is not necessarily the best way to approach content management design.

The last talk I attended was Rahel Bailie’s Content Management Successes: Separating Fact from Fantasy. In a continuation of what is becoming a theme of this conference, she pointed out the common fallacy that leads people to think that “Tools are the engine,” when in fact, “Tools are the caboose.” I know from hard experience that organizations tend to select tools too early, and often without any idea of what their needs really are.

She also gave a cogent description of how to look at the blizzard of features offered by most tools. Her suggestion on evaluatiing features is to go beyond the “what” questions, like “do you have version control,” to more open questions like, “How do you handle version control.”

The other point that stood out for me was a discussion of “governance,” which emphasized the importance of understanding who owns processes and the budget, and understanding the depth of support, or political will, behind decisions. She suggest being wary of support below the “C-Level,” i.e., CIO, CTO, or CEO. And, she suggests using the tools of audience analysis on the people governing projects.

Again, an interesting day.

This week I’m in Vancouver at the DocTrain West Conference. I’ll be posting each day on the sessions I attended that day. I’ll cover the highlights and add comments.

Day one offered four pre-conference workshops. I chose Content Engineering: Workshop, presented by Joe Gollner of Stilo International. Joe is an excellent speaker, who kept us engaged for 3.5 hours. It’s impossible to summarize the full seminar in a blog entry, so I’ll hit the high points and add a few comments of my own.

The workshop was a comprehensive introduction to Content Engineering, which Gollner defines as the “application of rigorous engineering discipline to the design and deployment of content management and content processing systems.” He sees Content Engineering as a necessary means for controlling the explosion of both the volume and complexity of the content that organizations must deal with.

Gollner divides Content Engineering into two major activities: Content Management and Content Processing. While many CMS vendors see Content Management as the overriding discipline, and other activities, like Content Processing, as subordinate, Gollner sees Content Processing as an equal, and in many ways more complex, discipline. He also sees Content Processing as a weak link in many CMS offerings.

Following from an engineering approach, Gollner made some other important points:

• Metadata and link information must be treated as “first class” content; no different from any other content.
• This means that metadata and links must be “detachable” from any CMS; i.e., you must be able to export this information in usable, non-proprietary form, something that not all CMS’s support.
• Technology components must be “loosely coupled,” which means that interfaces must depend on the exchange of validated content, rather than depending on component to component interfaces like proprietary APIs.
• Processing rules aka business rules must be treated like content and therefore be expressed independent of any particular technology component.
• In general, must be able to export everything (content, links, metadata, processing rules, etc.) as processable content.

He concluded with some general comments and a “Top Ten” list of guidelines. The general comments centered around the importance of recognizing the content is inherently complex and getting more complex all the time. Effectively processing content requires engineering discipline that covers the entire life cycle. Doing this well is an elusive goal.

In the Top Ten list, without a doubt the most important point was “Don’t invest in Content Management technology too early.” Gollner has seen many projects get “bogged down in molasses” by committing to CM technology to early. Instead, he suggests focusing on Content Architecture and Content Processing first. Having seen exactly the same thing happen, I heartily endorse this recommendation.

Another notable item in the Top Ten was: Take a “Customer Service” focus in delivering tangible benefits to real users. All too often, the people who should be receiving new features and benefits from Content Engineering are forgotten and see little or no direct benefit. It’s important to keep delivering benefits to real users and not just “cool toys” for internal users.

Overall, I found the session valuable and hope it is a harbinger of how the rest of the conference will go.

I’ve just published a new article, titled Seven Tips for Living with Technology, on The Content Wrangler.

The article looks at some basic strategies for keeping your sanity as you acquire and work with technology. It is a significant re-write of a draft section of my book. That draft section can be found at: Living With Technology.

If you’re visiting this site for the first time after reading one of my articles, welcome. Stay for a while and check out other draft sections of the book. The place to start is the Note to Participants, which describes what I’m up to and how best to view the site.

If you haven’t visited The Content Wrangler, it’s worth a look. It’s frequently updated, has a lot of good information, and has a large and growing community of people interested in content management and content management systems.

Scott Abel, who runs The Content Wrangler, a website that focuses on content management, has posted an article of mine titled, Choosing an XML Schema: Docbook or DITA.

The article talks about how to choose the right XML schema for your needs, and despite my DocBook bias, I think it gives a “fair and balanced” treatment of the subject. While you’re over at the site, you may want to consider joining The Content Wrangler Community, which calls itself, “The social network for content professionals.” It has subgroups for everything from Blogging to Wikis. Certainly worth checking out.