Content Migration: the Iceberg of Intranet Projects

bryan| May 26th, 2010 11 Comments »

It lies there just over the horizon and just below the surface of any new intranet implementation. It is the factor that is most often forgotten or ignored as the intranet barrels toward launch. It is often left out of the project plan altogether but can take longer than the build itself. It is content migration.

It’s easy to understand why migrating content from your old system to a new intranet is overlooked:

Content migration is underestimated and misunderstood.

Many organizations moving to a new intranet have never been through a migration before and get blindsided by the amount of coordination and planning required to get through it

Content migration is hidden.

When some consultants are bidding on work, they don’t want to raise the issue because it may balloon the timeline or costs vs. their competitors.

Big intranet? Big migration issue.

Content migration is ugly.

Put simply, content migration is not attractive. Who wants to think about copying and pasting content or writing migration scripts when you can spend your time admiring your site’s new visual design or playing with the new features of a recently installed intranet software package?

For all the reasons to ignore the inevitable, the truth remains that failure to adequately strategize, plan, schedule, and budget for content migration can easily sink your intranet project. Failure to plan can lead to delays as the content migration drags past the launch date. Conflicts can occur as extra resources are called upon at the last minute to attempt to migrate mountains of web pages into the new system. After all of the hard work your team has put into designing and building the new system, content migration is the last hurdle — one that you don’t want to underestimate.

Here are some guidelines that ThoughtFarmer Professional Services uses to work with our clients to help ensure a smooth migration and an on-time launch.

Include content migration in the project plan.

Time is required to consider and draft a migration strategy and approach document and to modify it as the project progresses and decisions are made. Time is required for the migration itself. Because the project plan is written early in the process, it is necessary to be very conservative and even pessimistic in the amount of time required.

Determine if the migration approach is to be Automated vs. Manual vs. Hybrid.

Depending on the systems involved, it may be possible to automate the movement of content between systems. If the original intranet is a CMS or the original content is very structured and the content organization is to change little in the new site, then it may be possible to write a script that reformats the original content and populates the new content repository. Most scenarios, however, involve a manual copy/paste job into the new system. Scenarios where a single site has content physically residing in multiple environments may utilize a hybrid manual/automated approach for different sections of the site.

Resourcing for migration should be addressed early in the project.

The best case scenario has resources dedicated to the task until it is completed. To achieve this, resources need to be booked in advance so that regular duties can be cleared or reassigned for the period.

I have heard of some organizations outsourcing the content migration activity. I don’t recommend this because it distances the organization from taking ownership of its content and denies the opportunity for the content contributors to learn the new intranet inside and out prior to launch.

Reduce the scope of migration through ruthless pruning of the content inventory.

The simplest way to reduce the time required for content migration is to leave any outdated or unimportant content behind in the old system. Organizations should only migrate relevant content to the new CMS.

Only migrate relevant content.

Think about before, during, and after.

The Content Migration Approach document should address content transformations that need to take place before migration begins, during migration, and once the content is in the new system.

Pre-migration: Reduce the inventory, determine URLs to grandfather, do a final update of the content before migration. If automated scripts are to be used, these should be tested and put through a dry run before the real thing.

During migration: What needs to be done to get the content into the new system? Regardless, this should be done during a content freeze – more on this below.

Post migration: What type of clean-up needs to be done once it is migrated? Often hyperlinks fall into this category as frequently the final URL (or link variables that render a final URL at run time) are not known until all content is in the new system.

Negotiate and communicate the nature of the content freeze before migration begins.

Migration occurs best if the content on the “source” site is not being updated while content is being replicated in the new system. This entails a freeze or ban on updating the website for the migration period.

Every organization has different needs with respect to the ability to update their intranet. Highly collaborative organizations will find any content freeze painful, while a freeze at an institution or government department might pass by unnoticed. Any content freeze should be clear on the start and end times that apply, any exempt content to which updates are permitted, how exempt content will be “caught up” in the new intranet, and who should be consulted if a mission critical issue comes up that warrants an emergency intranet update.

Foster a focused, goal-oriented, teamwork-based culture for the migration team. Assuming you have a dedicated team to copy/paste content, likely seconded from their regular duties, you need to keep the team focused and motivated. I suggest the following tools:

The War Room

Have dedicated facilities where the migration team can work together free from distractions.

Set goals and chart progress

A thermometer on the wall charts should be used to chart progress as the team ploughs through the content. Daily goals should be set for the team and each person so that migration is paced for the entire period.

Have an issue resolution process in place

The team should take advantage of each other to solve any problems that arise. If issues cannot be resolved in this way, tools should be in place to track minor bugs and a contact should be designated if a show stopper issue comes up.

Have little rewards and thank you prizes on hand

The migration team leader should give out little prizes to people who exceed their target, are really helpful at helping others solve problems or are great leaders. Keeping morale high will be important if a lengthy migration period is required.

Through careful planning and preparation and closely tracking progress during the migration itself, you can keep your intranet migration on track by navigating around the content migration iceberg.

This is a modified version of a post that originally appeared on the OpenRoad blog.

“Our intranet is like underwater ballet: kinda lovely, mostly useless.”

Chris| April 7th, 2010 1 Comment »

Enjoy this slideshow of the best postcards from our viral marketing campaign, Intranet Secrets.

The thorny issue of archival content on the intranet

Gord| March 30th, 2010 2 Comments »

So by now you may have seen our site Intranet Secrets. I hope you’re enjoying it. We’ve had some great feedback and some very, very funny submissions through our form. Who knew the intranet could be such a dark and troubling place.

There are quite a few secrets, which while they look made up, are in fact totally true. Like this one:

Yes, it’s true. Those are almost verbatim the words that were uttered by an intranet manager I once met. I’ve used it many times in conversations with clients about slimming down their intranets.

Now, you’re thinking, I’d love to delete a lot of old content on my intranet, but I just can’t. I know that Chris told me to blow it up, but I’ve got some pretty big reasons as to why I can’t. Like regulatory. Or records management. Or just plain old paranoia.

And now that’s disk space is so cheap, there’s really no cost to simply keep a copy of everything my organization has published to the intranet for the past 15 years. Besides, someone might need it one day. And then it will be here for them.

Right?

Of course, we know that there’s issues with that. While disk space is cheap, the cognitive load experienced by intranet users is high. Ever tried finding a particular document or collection of documents amongst 100,000 others on an intranet with a sub-par search engine, questionable information design, and highly varying degrees of reliable content? And our time is precious and expensive. Managing and maintaining 100,000 and growing pages on the intranet can cost lots.

A noble goal for many of our customers is a smaller, more relevant intranet. People like James Robertson have been calling for this for years. But it too is hard to do.

What help is there?

Recognizing the characteristics of your content is a great first step. This classic from Paul Chin in the Intranet Journal from 2004 is one of the few articles I’ve ever found that tackles the time-based dimensions of your content. What’s your content’s lifespan?

Once you recognize the short-term / long-term orientation of your content, how do you design your site for it? One of the best metaphors that comes to my mind is the IA community’s adapation of Stewart Brand’s notion of scaffolding in his book How Buildings Learn. Peter Merholz and Jesse James Garrett blogged about this in 2002. I still think it’s a powerful concept. And reminds me a great deal of how we deal with each other through physical space (which I’ve blogged about before via Edward T Hall’s notion of proxemics).

What’s the “stuff” of your intranet? The “skin” or the “structure” — how do you assemble your content based on its temporality or permanence?

And finally, what patterns can we use from the wiki body of knowledge to help re-enforce editorial activities that will keep the intranet a cleaner and tidier place?

Stewart Mader’s WikiPatterns site has a great example with Built-in obsolescence. If you know your content has a shelf life, why don’t you design for the future audience with that in mind now? It’s like a content time capsule.

Mike Briggs of Sun had this important point in his post on stale content: keep the authors tied to their content as much as possible. The publish-and-forget anti-pattern of intranet publishing, combined with the “orphaned content” anti-pattern are harder to have happen if you keep the connection alive between content and author. You created this page, it’s your responsibility to keep tabs on it, remove it when you see fit, or pass the ownership onto someone who will. That’s a design pattern that we baked into ThoughtFarmer from the start: there is no anonymous page ownership. Page and author are always coupled together.

Archiving is tricky. How have you dealt with it on your intranet? Have you ever preformed a giant web harvest snapshot and backup of your intranet, like the US government did with their federal sites in the past few years?

Has anyone ever come asking for one of those 70,000 deleted pages? What will your intranet look like if you could time travel to the future?

6 Guiding Principles for Building the Ultimate Intranet

Chris| March 24th, 2010 1 Comment »

When we started planning ThoughtFarmer back in 2004, we established these 6 guiding principles that we felt would lead to the ultimate intranet. They’re as valid today as they were when we started, so I’d like to share them with you here.

1. Include a Killer App

Bring your users back every day

A critical ingredient for a successful intranet is the ‘killer app’—the feature that brings users back to the intranet every day, or several times a day.

For many companies, the killer app is the employee directory. For others, it is payroll information, news headlines, or vacation requests. Whatever the killer app, it’s crucial that it’s visible, easy to find, and quick and easy to use.

2. Create Serendipity

Create an environment where random, profitable events take place

The biggest reason to deploy a great intranet at any company cannot be known in advance. By creating an environment where knowledge flows uninhibited, something unexpected will take place that will pay for the entire project. A salesperson will come across a piece of information that will give him what he needs to close an important deal. A designer will encounter something that inspires her to create a brilliant, winning concept. After reading a post on a discussion board, a director will come up with The Next Big Thing that transforms the business.

Networked people, or Connectors, are critical to any large enterprise. A great intranet should be the Ultimate Connector. It can create a hyperlinked organization, where knowledge flows freely and serendipitous events lead to breakthrough thinking.

3. Create community

Good intranets create a sense of community in a company. Strong community increases employee satisfaction and encourages knowledge transfer. Community-building intranet features include:

• Discussion forums—must be seeded, moderated and led by example to be successful
• Blogging—online journals by individual authors, usually link-intensive. Readers can attach their comments to journal entries.
• Photo albums
• Recognition articles—information on achievements, promotions, top performances
• News articles that are authentic, honest, and have a personal voice
• Bulletin boards—areas supporting non-work announcements, like birthdays, engagements, garage sales, etc.

4. Keep it Open

For an intranet to truly succeed, it has to be as open and accessible as possible.

24×7 anywhere access for everyone

Every single employee should be able to access the intranet, at any time, from any location.

Everyone can contribute

Every single employee should be empowered to contribute content to the intranet.

Invite partners

A company’s trusted partners should be given a window into the intranet. Information increases in value as more people access it. Sharing data invokes Metcalfe’s law and generates new value.

5. Focus on the user

If it’s not easy to use, don’t even bother

Users have precious little tolerance for confusing or difficult-to-navigate interfaces. Your intranet is judged on the quality of the user experience. If it’s not extremely usable, it will fail.

Perform expert usability analysis

A usability expert should review the site at regular intervals and make recommendations based on usability best practices.

Perform regular usability testing

Every new feature on the intranet should be tested on 4 or 5 users to uncover usability problems. Usability testing adds time and expense to the development cycle, but it always pays off in increased user satisfaction.

Expert usability analysis is not a substitute for actual user testing.

6. Keep it Agile

Use an agile software development methodology

Agile software development is people-oriented rather than process-oriented—it tries to work with people’s nature rather than against it. It is adaptive rather than predictive—it allows for change, instead of trying to predict everything in advance. It focuses on returning business value as early as possible.

Close collaboration

Agile development emphasizes close communication between the developer and the business customer, to make sure the product being built is exactly the product needed.

Rapid iterations

The software will be developed in iterations, each lasting 1 to 4 weeks. Every iteration will end with a tangible delivery that returns value to the business. There is always an opportunity to readjust course before continuing.

Frequent planning meetings

At the beginning of each iteration, there will be a meeting to discuss the results of the last iteration and plan the features and tasks for the next iteration.

—

Almost 6 years after writing this, I’m proud that we can look back and feel that each of these principles is still vital. They did indeed lead to what our ThoughtFarmer clients feel is the ultimate intranet.

What would you add to this list that’s led to the success of your intranet?

3 Potential Benefits of a Social Intranet

Chris| March 9th, 2010 1 Comment »

1. Realize the power of the network

Metcalfe’s Law states that the value of a network is equal to the square of its number of users*.

Information shared on a social intranet increases in value as more people access it. Sharing information in this way invokes Metcalfe’s law, generating new value.

2. Create an environment where lucky foresight appears

Gary Hamel, visiting Professor of Strategic Management at London Business School, says that truly innovative strategies “are always, and I mean always, the result of lucky foresight.” The task of the entire organization then becomes communicating on as open and wide a channel as technology will permit, creating an environment where lucky foresight is more likely to make an appearance. A social intranet facilitates this wide communication channel.

3. Unleash the power of individual minds

Bob Buckman, former president of Buckman Laboratories, says:

“If the greatest database in the company is housed in the individual minds of the associates of the organization, then that is where the power of the organization resides. These individual knowledge bases are continually changing and adapting to the real world in front of them. We have to connect these individual knowledge bases together so that they can do whatever they do best in the shortest possible time.”

A social intranet becomes the Great Connector, hyperlinking these individual knowledge bases together.

*Our senior consultant Bryan Robertson reviews Metcalfe’s Law and other formulas for calculating ROI in his piece, “The New Laws of Intranet ROI.”