When to Wiki

Here’s what I think it’s important to think about when deploying a Wiki/Blog environment:

I think Wiki/Blog (let’s just say self-service publishing) can be very powerful where processes for publishing “formal” information channels to the Intranet are in place. That is to say, if the right people are publishing to the right place on the Intranet and have the right editorial flows/governance around that, then adding an open, less-structured layer to that is fine. If, on the other hand, if there are no good controls/process/tools in place, then handing everyone a Wiki is too loose a solution, in most cases.

Certainly there are models of total self-publishing which have worked well. Rational, for example, followed that model but this was a particularly techy and tight corporate culture (at least, before IBM acquired it ;) ). So overall, my advice would be to make sure they have their formal content publishing ducks in a row before introducing self-publishing, and I certainly would not advocate replacing a full-blown CMS with a Wiki.

The challenges of Intranet personalization

I couldn’t agree more with this take by Gerry McGovern on the current state of Intranet personalization. While at IBM I saw an immense amount of effort going into this concept of delivering the perfectly useful and customized experience for each employee. Even with teams of content authors pushing content into the Portal, use and overall satisfaction really remained sort of stagnant. I’ve found that most Intranet and Portal efforts fail to fully appreciate the amount of work and change required to support a truly valuable Portal experience. And, most companies will be pitched a Portal as the latest and greatest thing, without a word from the sales team about how to manage not only implementing the Portal experience appropriately, but how to mange the governance and management of content authoring into the Portal to make the experience relevant and useful.

Senior Management and Intranets

Just read a take on the age-old problem of conveying business value of good Intranet Management to senior leadership. Gerry McGovern’s article is a good, straightforward reminder of the importance of proving value to Senior Management.

I find that the challenge of proving the aggregated value of improved productivity is often hampered by the location of the management team involved. That is to say, unless you get to the very very top, it’s hard to get someone with a completely objective, cross-enterprise view of the value of Intranet management. Managers in lines of business will be happy to fund initiatives to solve their problems, but not necessarily those of the rest of the business.

This problem of silo’d financial thinking is a tough nut to crack, even as organizations talk about cross-functional collaboration and organic networking and teamwork. At the end of the day, the problem remains the same: Work goes where the money goes.

Offerings and deliverables

ThinkIntranet can provide consulting and deliverables in the following areas:

Taxonomy: Develop a corporate taxonomy and apply it as part of content authoring system. Create governance around taxonomy management: definition, maintenance, archiving. Application of taxonomy to end user via glossary/directories and also through Content authoring.

Content authoring: Define common content types and templates, ensuring consistent information elements for information reuse(multiple devices, RSS feeds, etc.) Also establish content authoring policies to prevent duplication of authoring, ensuring appropriate editorial workflows in the communicator role, and managing correct authoring authority into the Portal - i.e. who gets to publish what, where.

User Experience: Establish a common user experience across all Intranet sites and applications. Is the visual design of the Intranet expressing both the right message vis a vis company culture, AND is it usable and accessible? Create and manage processes for ensuring consistent user experience across multiple Intranet sites in a given company.

What is Intranet Management?

Here is what my definition of “Intranet Management” (IM) is: First of all, “Intranet” for me, concerns each and every experience the end-user (employee) has with any tool, content or application that is used to perform work. So “Intranet” in the traditional sense extends beyond the browser to include anything “on the glass” used by the employee as part of doing work at the company. At IBM we called this “Workplace,” but then a few people were confused and asked us about things like chairs and water coolers.

As far as the technical infrastructure of the Intranet/IT system, IM is concerned where the implementation impacts the end user. For example, the absence of a common authentication method will impact end-user productivity (multiple sticky-note passwords), and reduce satisfaction. So the IM role would be to check any technical implementation (firewall, proxies, routers, mail servers) for end-user impact. Another important area, helpdesk and support functions: Here the IM Management role ensures that a connection between the launch of a new employee tool and the right help and support is made.

Syndicate content