Well, it’s important for a couple of reasons. One is that it gets everyone on the same page in terms of nomenclature and how we want to talk about our products, so that ultimately you get a consistent message across to the customer. As you plan to take products to market, multiple products with a similar information architecture will enable our regions and customer facing counterparts to look across the product lines to be able to better position and place our products with in our product portfolio and against our competition in the market place. For example, if you talk about one set of features and benefits for one product, and another set for another product, it becomes really hard for a customer to make a buying decision across the board. How we talk about our products becomes very important in enabling the whole select and buy process.

Process efficiency is our other reason. When you have an apples-to-oranges comparison across product lines, then a lot of re-work has to be done to provide consistency for a customer. When there is a predictable set of information or a predictable architecture, you can then build the processes, access and timing around the whole product introduction process.

Another piece in selecting a vendor had to do with learning. We often outsource work, yet we need/want to have that knowledge internally and not just with the consulting firm or vendor. A vendor that is willing to teach us and have us a part of the process was extremely important.

Finally, I would say it’s flexibility in solving problems. How a problem is solved shouldn’t just follow a cookie-cutter approach, but rather be flexible and adaptable to our environment.

We’ve approached information management in a 2-pronged activity structure with the activities running in parallel. One approach is to standardize some of the unstructured documents so that people start using the same framework at a high-level. Then you can get feedback based on that high-level framework and spend time to understand what needs to be taken to the next level and structured and what should remain unstructured. What you structure is based on opportunities for reuse, and the behavior of the different components with in a standard document. If you’re really going to get process efficiency – to the point where you take work out of the process – you need to put structure in place behind that unstructured space.

The next activity is diving into the content ownership and process models. You need to understand the process throughout the content value chain and start determining where and how you can improve timing, efficiency and ownership. A RACI model, the ownership model, needs clear definition and should be integrated each link in the value chain for the content.

Again, it’s about baby steps and accommodating the user community in a way that will encourage the new behavior. Management of change is at times overwhelming and often our toughest aspect of a project. It’s impossible in 6 months to talk to all the different downstream partners of the content, and the value chain is so complex in a large organization that you have to tweak behaviors slowly in order to get to that end state.

Work was also recently completed around navigating content within the content management system for our technical documentation. This has made it easier for people to find and author the content, thereby improving our time to market.