Pages

01 August 2012

In content management, beware the 'Talker'

I've just read a HBR blog describing a customer profile that salespeople need to avoid: the "Talker". Talkers are people whom, despite being a friend of yours (or your product); despite strong connections with purchasing decision makers; despite repeated assurances of assistance, somehow fail to close the deal for you.

This passage, in particular, struck a chord:

There is a troubling paradox in the Talker. This profile embodies much of what sales leaders tell salespeople to seek out in the ideal stakeholder: they are accessible, they provide great information, they act as a hub for networking, they are pro-supplier — the list goes on and on.

In the end, however, these very traits ultimately harm their credibility inside the organization. The access they grant to the supplier and their energetic backing of that supplier results in doubt amongst their peers. Indeed, our data show that Talkers are anywhere from four to six times less able to build consensus for a purchase compared to Mobilizers.

This reminded me of the KM (knowledge management)/content management/Intranet projects I've been involved in before. For some reason, there was always at least one "Talker" leading the project.

The right person for the job?

I've mentioned before that I was involved in a few Intranet or knowledge management projects in the past–all of which failed to deliver on benefits for users. But it wasn't for want of a "right person for the job" that these projects failed.

  • The project leaders were all considered uniquely qualified for the job within the organisations. These weren't just self-appointed experts, or volunteers on a "cross-departmental" project; they had their names in the right boxes on the organisation chart. They were considered inhouse "champions" for innovation or KM.
  • All of them obtained early support for their projects from management. They got approval for both budget and time. And they made sure their organisations knew it: In all cases, the big bosses gave a speech at kick-off, and wrote a memo to all staff asking for cooperation.
  • They knew the right people. They managed communities of practice in the organisation. They also knew vendors who provided the right tools and consultant services.

On paper, there were all signs that things would go well. The projects were being done by the right people, doing the right things.

But on the ground, perceptions (and thus realities) were quite different. (Again, all examples are reconstituted from memory to obscure real persons and organisations.)

  • One project's leader was the anointed "champion" of organisational KM. He was a huge evangelist for KM and innovation within the organisation. He organised a lot of workshops. He also frequently invited colleagues to presentations by vendors and consultants–so frequent that we began to wonder if we were working on our existing project, or we were part of an RFP evaluation committee for the latest content management system or a social media listening tool.
  • Another project had a knowledge manager who found out the hard way that his "knowledge" was a double-edged sword. On the one hand, it made project planning with his retainer-hired information architect a lot easier. On the other hand, his knowledge wasn't matched by experience. He had unrealistic expections about the change management effort needed, and his vendor found it necessary to remind him that he was over-ambitious in terms of project scope.
  • Then there's this other KM "champion", whose "championship" was just a euphemism for "isolated". He's utterly alone in his perfectionist ideas about what his organisation needed. If you spent any time with this KM champion, you'd have heard his every idea about what direction to take the organisation. You'd also know there was no hope in hell he could execute it, because the only way he could do it was to do it alone. But his boss was kind enough to create a role where his dissatisfaction with the status quo would hopefully result in something useful–the role as Intranet revamp project lead.

In all these cases, knowing the practice of KM, and familiarity with vendors and products, worked against the project leaders. Management and team members alike didn't know enough about KM to challenge them, but that didn't stop them from having doubts. This created a lot of questioning, backtracking and strategy deviations along the way. That expertise would work against the expert seems paradoxical, but I've seen it enough to think there's a pattern here.

Dealing with 'Talkers'

In retrospect, I think it didn't really a matter of who was leading the project, or what qualifications he possessed. It was politics that guided the projects' trajectory–something that's not really within any project team's control.

But there are some strategies that both inhouse and external content strategists can deal with these unspoken, opaque obstacles.

1) Get facetime with the real stakeholders. Project leaders are never the big decision-makers. In fact, given that Intranets and KM are complex solutions, no single person will be able make all the decisions. You have to talk to all of them.

There will be many types of stakeholders: some who do the content publishing; some who are the domain experts writing or vetting the content; and some who do no content work, but make the big decisions anyway.

Don't think of this task as an obstacle to progress. You need stakeholders on your side, and as soon as possible.

If you don't, you can be sure they will emerge later in the project, challenging all the design decisions the team has accummulated along the way.

But if you do miss a stakeholder during earlier project phases, (or in some cases, they absent themselves until late in the project) you can still remedy the situation. Ask your project leader to arrange a face-to-face with them, to take them through the design process and to understand their concerns.

(By the way, identifying the stakeholders is itself a huge subject; I'm still a student myself, so I've to leave this topic for a future time.)

2) Business needs and facts first; features and content later. In any digital project, both clients and stakeholders will focus on features. They will suggest additional features based on something they have seen or read somewhere else, without consideration for whether additions are relevant or helpful.

The solution is two-fold.

First, always focus on business needs. Not just at initial planning meetings, but even when you have progressed far enough to present mock-ups. Keep referring to business needs, even ad nauseum, and what each feature is meant to address.

Second, back up your design choices with data and best practices. You should have accummulated white papers, style guides, case studies early on in your project. When questioned, dust these off and present them again.

3) Manage your clients' and stakeholders' expectations. As mentioned, KM/content project leaders are often appointed the project because they are considered the most knowledgable within the organisation. If you are an external KM or content strategist, don't assume the client is on your side, sympathetic to the way "things are done in the industry". Knowledge does not equal experience, and they may have strong but mistaken ideas about what can and cannot be delivered. (I know I still do.)

Do this by clarifying clients' thinking in their requests. For every feature requested, ask about their goals.

Suppose they want a wiki. Ask them why they want a wiki. If they answer that "everyone should have the ability to edit the pages," but "ease of publishing" is the stated business goal, you should check if he has a content team that is experienced in editing and managing wikis.

4) Document your process, and then some. This is an obvious point, but one that we all need to be reminded.

Content architects sometimes cave to clients' request to simplify the content process, even when they know it will affect the content's quality. For some reason, the requirement for IT documentation (such as functional specifications) is so taken for granted that we'd question the client's sanity if they didn't want it; yet no one blinks when content documentation is skimped on.

This is a mistake. Just because your client or stakeholder thinks content maintenance is less esoteric than IT and doesn't need to be documented, doesn't mean that they understand how content works. Even within the industry, the terms "taxonomy", "content strategy" and "style guide" all mean different things. I had a colleague once who thought a section on common grammar mistakes was unnecessary in a style guide because he thought "common mistakes" was the "ones everyone already knew about."

Unless your client is in the publishing business, they won't understand the process and labour cost of content management. Make sure your methodology and process is documented. Clearly define what your deliverables are, and make sure this list of deliverables is signed off.

5) Do a content inventory. If you are working on a large website, assume no single person will know where all the content is–even when some person claims that he does.

There are many reasons for this. Poor information architecture (lots of orphan documents). Distributed publishing responsibilities. Content that is not even on the web, e.g. print brochures. The list is long.

Make the case for a content inventory, and make it early in the project. An inventory is very helpful for many things–identifying gaps between business needs and customers, content planning, and identifying content domain experts.

A conceit

You may have noticed by now that this problem of "Talker" project leadership is really a conceit--whether or not the project leader is a "Talker", you'll always need a robust process to guide a content or knowledge management project. Content and knowledge management is a complex task, requiring both high-level management support–and a person/team who knows how to pull stakeholders together.

Compared with user interface and visual design, information architecture and content strategy is much more political in nature. This is because, unlike visual design, stakeholders's involvement in content management continues long after the product is launched.

2 comments:

Lisa said...

I was lucky enough to have the opportunity to read this article! Enhanced my skills.Project Proposals

Kok Hong Poh said...

Glad you found it helpful.