Our latest webinar, “Managing Content Projects: What You Need To Know To Succeed” was a discussion between Scott Abel, The Content Wrangler and content strategist Joe Gollner. The two discussed some of the most important steps involved in managing a content project. Real project experiences were shared to set the stage for a discussion of what people should keep in mind when they are called upon to whiteboard a project plan or to review a project that is currently underway.

The webinar was an action-packed 60 minutes! The recording and Q&A are now available below. Enjoy!

Live Q&A:

How do you introduce tools gradually?

As we touched on during our session, the gradual introduction of new tools often does mean that they are being introduced in parallel with the old tools. Of course, some steps need to be taken to minimize the downside of running tools in parallel. Generally, I try to have business units cut over from one set of tools to another so they can overcome the impacts as a group and likewise provide feedback on the new tools based on their collective experiences. In deploying tools to a business unit it is also important to provide sufficient coverage for the end to end processes so that no one is asked to do anything goofy like manually channel content back into an old tool at some point along the way. This approach too can present some challenges in that it puts the onus on you to ensure that you have integrated a collection of new tools to provide end-to-end coverage. When you deploy a new set of tools to a business unit – it will usually mean an authoring tool, some measure of management support, and publishing processes (and perhaps a few more parts). The challenge here lies in needing to perform the integration that is needed for the business units to be effective – while keeping the integration approach lightweight and agile enough to be both affordable and adaptable as new business units are brought over.

There are other scenarios that come up as well. In one current project, which I mentioned during our online session, branches in a new publishing process are being incrementally introduced into a large production environment. Transformations have been added so that content prepared in the old way, using old tools, can be channelled into the new processes along with new content prepared using new tools. Under this scenario, backward channels are also introduced so that new content created using new tools can be published using old publishing processes. As you can probably tell, it can all get a little complicated – but sometimes complicated situations demand nothing less.

So how do you introduce new tools gradually? To summarize, I would suggest that the desire, or need, to introduce new tools gradually, so as to allow the business units to try them out and break them in, tells us a lot about what our new tools should be like. Most importantly they need to be adaptable and this should make it relatively easy for us to adapt to new or unforeseen needs or opportunities. If we have a tool set that resembles this description, then it will be possible to deploy those new tools in whatever way will best fit with the needs of the business. As I mentioned above, often the best fit will be a horizontal end-to-end business unit deployment. There will be special circumstances where other approaches to deployment will make more sense.

What tools do you use to do quick prototyping? What are the Pros and cons?

There are a range of options here. There are in fact a number of prototyping workbenches that can be leveraged, but I find that for the type of prototyping needed in “content projects” there is nothing better than transformations and interactions implemented using open standards (XSLT, XQuery, CSS, HTML 5) along with some JavaScript operating on open and extensible data structures (specifically XML). There are also a wide range of open source components that can accelerate the development effort.

In the prototyping efforts, I try to keep the amount of development effort to a minimum – and this requires a firm hand when it comes to scope management and the close supervision of the developers involved. It requires careful attention because implementing a minimum level of functionality is, for many developers, something of an unnatural act. If they can see some things that can be done better, or more completely, they will naturally want to do it. And bless their souls they will often pull all-nighters to do it. But this line of innovation, at this point in a project, can cause more trouble than good. For one, it can create impediments to changes in the prototype that are in fact called for in order to model new business activities. Or for another, this over-investment can cause some to see the prototype as more production-ready than it is. More than once I have heard “Why don’t we just put this out there? It’s working pretty well!”

So there are some Cons, or cautions, to be watched for when prototyping. One is that the technical investment escalates to levels higher than is prudent for a prototype. Another is that the presence of a prototype will lead some stakeholders to assume, wrongly, that a production system does not need to be designed and developed.

There are a variety of Pros, or benefits, associated with prototyping. If pursued in a broad way that is oriented to addressing complete business processes, or what I call “content scenarios”, prototyping can be absolutely invaluable in helping the stakeholder community to explore what the future state is going to be like. This type of exploration is more important than most of us will initially think – even though we already think it’s a pretty good idea. When introducing new tools and new techniques, as will be associated with any move to open standards and intelligent content technologies, we need to remember that “technologies are not neutral” and they carry with them a wide range of “potential” uses. When exploring prototype products and processes, stakeholders have a chance to hit those “ah ha” moments when they say “wow, this changes everything!” When you are prototyping and you hear this declaration you can celebrate. If you have built a complete system, and especially one in the older and more monumental style, and you hear this declaration, you have a big problem on your hands.

What criteria should a project lead look for in bringing in an outside consultant/trainer, and what is a typical Statement of Work for such projects?

The second part of this question might be a good place to start. What type of Statement of Work should be put into place for “content projects”? I would be inclined to ask “what types of Statement of Work” with the emphasis being placed on the plural. My point is that in many cases it is a good idea to plan on there being two or more Statements of Work and associated contracts for external support in a content project. While this might sound like twice as much aggravation and while many supply chain manager might oppose the suggestion at least initially, experience has shown that content projects work out best if a certain division of responsibilities is manifest in the contracts put in place for external support. Specifically, it is advisable to separate the work items associated with guidance, advice, strategy, requirements, architecture, acquisition oversight, quality assurance, and technology evaluation and to group these under one type of Statement of Work. In practice, this set of activities can account for as much as 30% of a content project’s budget for external support. A second set of work items are then grouped around another type of Statement of Work that will provide technology licenses, as well as development and implementation services. I recommend this division for the simple reason that in most organizations (indeed all but a select few) the level of in-house expertise in content management, open content standards, and intelligent content technologies is marginal at best. This will have the consequence that these organizations will struggle in being able to effectively manage the major providers of content technologies and integration services. Establishing this division has the benefit of equipping an organization with the knowledge and experience needed to forcefully engage the industry players and to ensure that it is the organizations’ long term interests that are being served in the selection and application of standards and tools. Now many organizations don’t really like this advice and I am not really sure why. I suppose the fact that the advice is coming from someone who provides the set of independent services is taken as reason enough to discount the advice. But I can say, without any reservation or fear of substantive contradiction, that projects that have adopted this division of responsibility in their approach to engaging external support have historically out-performed those that have not.

If this suggested division of responsibilities is adopted, then the first part of this question become germane. In selecting an external consultant to play the role of independent guide and counsel, organizations should probably look for consultants who fulfil a number of criteria. One such criterion is independence. The consultant may have good working relations with a number of suppliers of technology but they should not operate under any agreements that would prejudice their advice. For example, they should not have any agreements in place under which they receive commissions or other considerations for the referral of business or the sale of products. Another important criterion is that the consultant should have a substantial amount of experience actually implementing solutions and being responsible for those implementations. There are always consultants active who are exceedingly bright and have built up a lot of knowledge about different tools and standards by writing studies and market reports. However, in all too many cases these consulting analysts, as I prefer to term them, have never actually been responsible for a major implementation. As I have been overheard saying from time to time, when you are asking for directions it is a good idea to ask someone who has been down the road before. Going further, I would be inclined to say that an organization should look for someone who has a wide range of experience implementing different types of content technologies and standards in many different domains. Moving in a slightly different direction, I frequently encounter a selection criterion that places a high value on content management experience in exactly the business domain that a given organization works within. While there is some merit in this criterion it is far less important than many organizations seem to feel. In fact, there can be a lot of benefit realized from a consultant who has extensive experience in addressing content challenges in industries other than your own and who can therefore bring a fresh and unbiased perspective on your predicament. Peter Drucker used to famously say that the main thing he offered to his customers was ignorance – it allowed him to ask questions like “why do you do that?” Of course, he was being a little mischievous because he was, after all, only the founder of modern management thinking.

Are there apps you recommend for doing agile small projects in Content Management?

My answer to this question will change depending on the organization and the situation. A lot of factors come into play when establishing a prototyping and implementation plan. Depending on the organization, sometimes a significant emphasis should be placed on using technology infrastructure components that are supported and around which there are in-house capabilities. This is often a critically important consideration. This infrastructure can be augmented using the XML based tools referenced above. In other organizations, there is a growing interest in the use of open source platforms which in the domain of collaboration and content management are increasingly attractive. As we noted above, in many organizations the in-house technology groups do not have very much in the way of knowledge of collaboration and content management. In this case, these organizations will be attracted to commercially-supported open source tools that exhibit high levels of openness and extensibility. When coupled with competent professional services, these platforms can allow specialist teams within organizations to move very quickly with their content management initiatives. In all of these scenarios, I do tend stress the importance of prototyping and evolving the delivery capabilities – showcasing what new content processes can actually produce for users and customers.

Collaboration is a magic word but it seems that new available tools are currently not as mature as the tools from the past – WYSIWYG vs. WYSIOOO (What You See Is Only One Option), editing by using tags, etc.

There is a sense in which I do find that we have fewer tools for certain things than we did twenty years ago. I do find that this is particularly true at the heart of high end content management. This is ironic because with the appearance of XML as a more manageable successor to SGML we had collectively looked forward to an explosion in product choice. It was in fact one of the driving motivations behind the streamlining of SGML that came to be known as XML. The reality was something quite different for people working in sophisticated content management and publishing systems. In the broader marketplace however we have seen a proliferation products come and go and this process is slowly, but surely, producing some attractive choices.

Now the authoring product choices that have been available in the past and in the present have not really tackled the full range of challenges that confront content creators working in today’s world. On one hand, the creation and refinement of content assets is an activity that is fundamentally collaborative and we have been seeing the emergence of increasingly effective tools that help in this regard. On the other hand, the highly focused activity of actual composition is one that faces escalating challenges. For good reason, rhetorically speaking, authors prefer to work with tools that let them see how the content will appear or behave for the users. This is why WYSIWYG has had a persistent attraction. The problem however is that the content we are typically working on today will be delivered in two, three or more different forms. To complicate matters, some content will indeed be prepared for specific venues such as a print campaign or for an online support tool. What all this means is that we need a tool that helps authors envision and explore how content will be used in a variety of ways. Perhaps we will see a WYSIWYCWU (What You See Is What Your Customers Will Use). And when more and more of those uses actually exploit the semantics of the content the “tags” also become something that is important for reasons other than what someone will see.

Content is the king, but who is going to provide it if the state of the “art” is as-is?

In the increasingly complex environment where content will find its way into many venues, the importance of content continues to grow. But picking up on the previous answer, we also need to consider how these trends will change who contributes to the design and creation  of content and how these people will collaborate. One of the things that seems clear to me is that in a WYSIWYCWU (What You See Is What Your Customers Will Use) world the level of semantic precision in content can only go up. And this will drive the need for enhanced collaboration because different people to have the ability to apply their specialized knowledge to the enrichment of the high-value content assets. I have seen it on several projects where the authoring baton needs to pass between hyper-specialists so that each can add highly complex markup and this calls for some very careful design because the prospect for one group of specialist messing up the work of others is a very real problem. In these environments, which will probably sound terrifying to many authors, one of the things that becomes important is the presence of an effective feedback system – providing reports and renditions that help authors to test and trial these complex markup structures. So I guess the answer to this question is complicated but one thing is very clear – we are definitely not looking at tools and techniques that have served us in the past.

If you’re on a large marketing dept (100 people) and 15 content creators (design, 3rd party content, webinars, analyst reports, etc.) — how do you coordinate the creation process and campaign alignment?

To an earlier question, I suggested that domain knowledge is not necessarily the most important criteria when selecting a consultant for your content initiative. This question poses something of a counter-example and highlights the types of questions that do come up that are very much rooted within a specific business context. I am not someone with a great deal of experience in this particular area. But perhaps it is not as much of a counter-example as it might have appeared. My answer would likely be “let’s find out” and then we would use the exploratory prototyping approach that we touched on in this session to try out different possibilities. There might be many responses to this question and a consultant with a background in supporting marketing groups might have a quick answer. I don’t think that this quick answer will be as good as an answer that emerged from the prototyping efforts of the people who are part of this team and who understand its stakeholders.

Do you need a director to manage all creators to ensure alignment, optimization, etc.? Is this what you are seeing in larger marketing departments?

In my previous answer, I confessed to a limited background in the “marketing” business (and people who have seen my 40 page “brochures” will confirm this). That said, I have participated in a disturbingly large number of content projects in an equally unsettling range of industries, and in all of these I have found that the alignment, consistency and optimization that is increasingly called for is not a result of centralized control. The heightened demands for “quality”, shall we say, in our content is becoming something that is increasingly a collaborative undertaking – amongst expanding groups of participants and stakeholders and even application components.

Hi Joe, what is your recommendation for a small financial software firm who plans to move on to XML? What tools, CMS and workflow? Is there something that is light weight, not an involved CMS like Documentum?

Based on the thread that is emerging in my not-so-brief answers to these questions, I would have to say that my answer once again settles on a frustrating “it depends”. I immediately think about the technology support and capabilities that exist in your organization and recalling that it is important to align with these in-house capabilities (or how these capabilities might evolve in the near future). If there is minimal in-house capability to work with, or around, then our eyes would move onto things like commercially supported open source tools that provide an attractive mix of affordability, capability and reliability. In the field of content management and collaboration there are, fortunately, a number of excellent choices in this area. And finally an answer will also depend on what you are seeking to do. Depending on what that is, it may be that a commercial product may provide the best fit. My emphasis on open source tools and iterative prototyping is largely based on the benefits that organizations can realize by exploring future states. It often turns out that once an organization determines what they really need to do, they can undertake a technology selection process that may well identify one or two commercial products as having a “product trajectory” that intersects with their needs. When evaluating technologies (or standards for that matter) it is in fact most important to establish where products come from and what route they have followed. This is what I call “product trajectories” and this is far more informative than “feature check lists”. My point here is that if there are commercial products that intersect with your requirements they can be a very credible, and ultimately affordable, option.

What is the relationship between reference info and concept/task, that is, technical How-to? Is it common to publish product reference info in the form of white paper in e-book format, and the concept/task info in online help format?

When leveraging the Darwin Information Typing Architecture (DITA), or perhaps in simply applying some of the more common models for “topic-based authoring”, we find ourselves asking these very questions. What content fits best where and how will that content be delivered most effectively? In my experience, what we might call the technical reference material will exhibit a complex mix of what in DITA would be called Concept and Reference topics. The Reference topic in this model is supposed to be used to provide collections of reference details, such as specification tables and so on. With the Concept you are encouraged to build the elaborations that can make those details understandable. And this type of background reference material has a habit of being useful at unexpected times. Yes, this material is well suited to e-Book delivery so people participating in training courses can read their material while on the train to work. However, I have seen plenty of troubleshooting scenarios, including on ships veering from side to side in a rough sea, where the real answer to the problem only appeared when the investigation made its way back to the background reference material and we determined what it was the original system designers were thinking might be a possible situation. So based on these types of experiences, I would be inclined to have a help system that allowed people to dig all the way back into the supporting reference information.

Interested in attending our next webinar?

Tune in with Scott Abel and Cheryl Landes Friday, September 30, 2011 in “Is search the solution for findability?”. Sign up Now!