When Tom Rossi, director of the Innovation Lab at the Naval War College in Newport, R.I., began a knowledge management initiative in 1999, he thought he knew everything. Rossi and his team were charged with creating a futuristic environment for computerized war games. The games, held annually for more than 20 years, have about 500 senior military and civilian players who need to share real-time information about troop deployments, battle readiness and the battlefield environment. Prior to Rossi's KM project, the gamer commanders had to gather information via phone calls, memos, e-mails and game books none of which encouraged the kind of instantaneous decision-making necessary in combat situations. Rossi and his team put together a KM system that integrated a collaborative software suite, a naval war games software tool and Microsoft Corp. Exchange's Conferencing Server for Internet video and chat capabilities. In the year between games, Rossi worked with engineers and a metrics team to fine-tune the system. They tailored the command and control databases so that various commanders had access to the same information; as one group of officers plotted troop positions and battle tactics, other participants lower down the chain of command could see the plans as they formed and anticipate what their own tasks would be.
In theory, Rossi's project sounded great. But by 2001, the technology bogged down. "We had gadgets and tools, but when we brought the gamers together, it became clear that we'd given them too much IT," Rossi says. "By the time we brought them up to speed on the new tools, the game was well underway and they got frustrated fast."
As a result, the 2002 war games were canceled.
Rossi's misstep is a common one. While KM is a sound field with real benefits such as reduced training time for new employees, improved decision making and better operational efficiency, it's difficult to get it right. "The biggest misconception that IT leaders make is that knowledge management is about technology," says Shir Nir, managing partner at Knowledge Transformation Partners (KTP), a KM consultancy based in New York City. "Usually people begin a KM project by focusing on the technology needs, whether they want a database or a portal. But the key is people and process."
It's natural for CIOs to focus on technology, and many vendors are happy to oblige them by marketing so-called off-the-shelf KM systems. Yet as Rossi and countless others have learned, there's no cookie-cutter approach to adopting knowledge management. Every organization and company has its own definition of knowledge and how it should be gathered, categorized and made available to employees. What works for one company won't work for another because organizational knowledge is so subjective.
The one-size-fits-all mentality, coupled with the tendency to focus on technology rather than people and process, has obscured the real benefits that KM can bring, according to Nir. It doesn't help that knowledge management means different things and often involves different kinds of technologies at different organizations.
In terms of technology, KM often covers some of the same territory as CRM and sales-force automation, each of which gather information in an effort to increase efficiency and quality of service. Because KM usually requires changes in work patterns, there is also some crossover with change management and HR. The sticking point for many KM initiatives: Knowledge deemed valuable to the organization is often tied to individual experiences, attitudes and behaviors. For example, what makes one salesman better than another may be his individual contact lists. But as most salespeople are loathe to share any of their inside customer information, an organization must provide motivation for them to do so, such as offering them compensation or encouraging them to close sales collaboratively rather than individually. That is why paying attention to people and process is so important.
Defined broadly, knowledge management is the process through which organizations extract value from their intellectual assets. To get KM initiatives off to a good start, executives must evaluate whether their organization has a strategic need for knowledge management in the first place. Then it's necessary to decide whether the current process of dealing with corporate knowledge is effective and if the culture is ready for procedural changes. Once executives have resolved those issues, the CIO can evaluate the existing technology infrastructure to determine whether it's adequate for KM or whether new systems are needed.
The first step toward a successful KM project is to look closely at your organization and define the strategic business need. If KM isn't tied to a business goal, the organization could end up with an expensive system that takes up server space but has no real purpose or ROI. Unfortunately, this first step is one many organizations fail to take. In a recent study by The Conference Board, 82 percent of participating companies indicated they were involved in a KM project, but only 15 percent of them said they had specific, stated objectives for the project.
Often companies link a need for KM with an event. During mergers, for example, information about intellectual assets, processes and potential collaboration should be collected for use in the new organization. Some people also view layoffs as a good time to look at KM. But Gene Wright, director of the manufacturing practice at Born, a Minneapolis-based technology consultancy, says companies shouldn't wait for a major shake-up. "When you look up and notice a redundant process or an example of repeated inefficiency where you realize you're spending all your time searching for information online instead of communicating with your clients or customers, that's a good time to think about KM," he says. "It's when you reach the point of pain, when you realize you can do things better."
For Brad Sidwell, CIO of Ice Miller, a law firm in Indianapolis, the need for KM became painfully apparent during a meeting with a prospective client that wanted to know whether the firm had worked with any of its competitors and, if so, what kind of work was done. "We discovered that we had no clue," Sidwell says.
To get started on a KM project, Sidwell defined the scope of the data he wanted to collect and organize information on past and current clients, what work had been done for them, and their legal preferences. Each lawyer's knowledge and expertise had to be gathered and stored for others to access. Sidwell chose a product from Interface Software Inc. called InterAction to help set up a database for collecting client information. From a technology standpoint, the project is a success, Sidwell says, though he admits that the firm still struggles with motivating lawyers to contribute personal knowledge about old clients. (They are more willing to contribute information about new clients.)
By taking a proactive approach to KM, Sidwell's firm is in the minority, says Skip Boettger, chief knowledge architect at software company PTC Corp.'s global services division, which is based in Needham, Mass. Usually it takes some kind of disaster to jolt a company into understanding the business benefits of KM. "Whether it's low profit margins or overspending, it takes a lot to get a CEO's attention," Boettger says. "But it doesn't take much for a business to realize it can improve the whole process of gathering and organizing knowledge. The key is that you have to focus on the business need, whether it's a problem you want to solve or a process you want to improve upon."
Once companies determine the business need, they can get a handle on the nature and scope of the intellectual assets they want to manage. Then they can determine how KM will affect the work routines of employees, Boettger says, which is an essential step to moving forward.
Show and Tell
How executives introduce a KM project to their company and how those executives help the employees adjust to changes in their work routine can make or break the project. "It's not a system solution, it's a people solution," says KTP's Nir. "It's about sharing as a whole organization, not just about the knowledge itself."
In spring 2000, when Paul McKeon, a former partner and chief e-business officer at Ketchum, a New York City-based public relations company, planned the rollout of his company's new knowledge management system, he knew changing the staff's work routine and culture to incorporate the sharing of relevant knowledge would be a challenge.
At the time, Ketchum was experiencing a high rate of turnover. McKeon and other executives realized that incalculable amounts of expertise and knowledge were walking out the door every time an employee moved on. "In a professional services business, all your investment is in your people," says McKeon (now president of Chamber Edit, a company that provides portal software to chambers of commerce).
Ketchum's system has three parts, which all require the participation of every employee: A document management system catalogs documents that previously existed on servers and hard drives at the company's 29 offices; an expertise database contains an employee directory that lists staff biographies and photographs, areas of expertise, and client experience; and the client database lists past and present clients, and the work the firm has done for them.
Instead of gradually introducing the staff to the process of contributing information, McKeon worked with Ketchum's workplace practices group to create a campaign similar to what the firm does to gear up for a new client. During what Ketchum dubbed Reboot Week, McKeon taught the staff how to use the new system through webcasts and conference calls. Employees spent the week going through files, documents and e-mails, and entering all relevant information into the document database, as well as creating and updating their personal pages in the employee directory.
Reboot Week helped staff members overcome their hesitancy about sharing client information. To reinforce that message, McKeon made sharing mandatory; each employee's contribution to the KM system has become part of their performance review.
Pick the Right Tool for the Job
One of the biggest mistakes a company or CIO makes at the outset of a KM initiative is to get carried away with the technology. "If KM is just handed over to IT, it ensures failure. The CIO's role is to make sure the technology end of a KM initiative does what the company needs it to," according to Born's Wright.
Before the Federal Highway Administration (FHWA) in Washington, D.C., went forward with plans for a knowledge management system, officials took a look at their technology and realized something new was needed. The FHWA ran primarily on an Oracle platform, which worked well for database management but didn't deal well with the kind of unstructured, research-based data targeted for organization, says Mike Burk, the FHWA's chief knowledge officer.
The FHWA's employees worked primarily within Novell Inc.'s GroupWise system and did most of their business via e-mail. Burk knew that employees wouldn't constantly monitor the site for new information updates, but they did check their e-mail regularly. He worked with the FHWA's CIO to link the existing Oracle-based system with the agency's website; they set up automatic e-mail updates that notified employees whenever new information had been placed in the website's knowledge base.
Burk's approach is uncommon, says Mark Horwitch, head of Bain & Co.'s knowledge management practice in Chicago. "The danger with KM is that most companies jump in without thinking through major questions," Horwitch says. "Look at the processes and information requirements that you need to succeed. Is the solution really a complex IT tool, or are you just underusing tools you already have? It's a lot easier and cheaper if you look from the top down."
In addition to a top-down view, organizations need to select KM tools that will complement how employees work rather than distract them. During the games at the Naval War College, participants defaulted to tools they were comfortable with such as Microsoft NetMeeting and Instant Messenger instead of using the collaborative KM tools Rossi implemented. The Naval War College skipped the 2002 war games in order to put more analytical rigor into its KM program. "We are clearing the slate and looking at tools we know we need instead of tools we'd like to use," Rossi says.
To make sure next year's participants don't get overwhelmed by the technology, Rossi plans to get the participant list early and involve all the players in building the game program. When they come to play next summer, he hopes everyone will be up to speed.
According to Born's Wright, a key role for CIOs is to make sure every employee gets hands-on training with KM systems. If no one knows how to use new tools, even the best KM project will fall flat on its face, he says. CIOs can also integrate change management efforts into a KM project by recruiting thought leaders within each department. The thought leaders can ferret out frustrations, resistance and department-specific needs for a KM system, which will help IT make the system as user-friendly as possible.
At California Casualty Management Corp., a San Mateo-based insurance company, CIO Vasu Kadambi is looking into starting the IT rollout of a KM portal that will deliver sales, underwriting and claims information quickly to customer service representatives. Although he'll be immersed in the technology rollout, Kadambi is not in charge of the overall KM project. In his view, the CIO's job in KM is to ensure that the technology doesn't derail employees so that effective information sharing can take place. "My role is to help people get the information they need," he says. "Technology just helps the process of gathering information."
Those who have successfully tackled KM projects have taken a systematic approach. "Knowledge management is not a walk in the park," Nir says. "It can be overwhelming, so make sure you look at it one step at a time." That's not to say you have to be a business genius in order for your KM project to succeed. To ensure the best odds, take a big-picture view by first defining KM in terms of a business objective. Once that challenge is met, your company will be in a much better position to determine which of its intellectual assets are worth organizing, managing and sharing. Take a look at the people and processes that will be affected by KM and address any relevant issues accordingly. And then it's up to the CIO to evaluate current technology and recommend and implement new systems as needed.
While there's no way to guarantee the ultimate success of any knowledge management project, organizations will have a better chance of maximizing their investment if they take projects one step at a time.
GETTING READY FOR KM
Mark Youman, a principal at American Management Systems Inc., a government and private systems integrator in Fairfax, Va., is an expert on project and knowledge management as well as IT strategy. We asked Youman what steps a CIO should take to help prepare his company for a major knowledge management initiative.
Before tackling a KM initiative, Youman says, CIOs should take a close look at the project's business objectives. Some common objectives include:
- Improve returns on customer information. Consolidate and leverage information about customers and potential customers to tailor offerings, improve customer service and increase revenue.
- Improve efficiency and effectiveness. Connect similar functions across geography to reduce redundancy and share practices.
- Enable a mobile workforce. Connect mobile workers with information and with each other to create a virtual workplace that, like the physical one, derives its value primarily from the capabilities of its staff working together not from access to the right data.
- Integrate with business partners. Share knowledge and collaborate outside the firewall to enable efficient business networks or intergovernmental coordination.
One of the most common pitfalls of KM is when project leaders lose sight of objectives like those. These kinds of mistakes can take many forms. When CIOs approach KM as an academic initiative instead of a business initiative, they often try to teach executives and business leaders about the theories and language of KM. According to Youman, this can result in fuzzy explanations that fly over everyone's head, such as: "We want to forge communities of practice that use asynchronous collaboration to turn tacit knowledge into an explicit corporate asset." Project leaders should translate the concepts of KM into the language and practices of their organization.
Youman advises CIOs to think about the following questions:
- Are there pressing needs for better knowledge sharing and use in areas that are important to your organization?
- Can you find a group of people willing to explore new ways of working to address pressing knowledge needs?
- Can this group or another source provide limited seed funding to pilot new tools that enable new ways of working?
- Can you map out a pilot model that will scale to the entire organization?
IT and organizational leaders often make the mistake of trying to achieve cross-organizational consensus before starting the project, a surefire way to guarantee everything gets pushed out a few months. Sometimes they try to change the corporate culture in advance of the project, rather than setting the business objectives and then judging how and if the culture should change. Then there's the inevitable KM-for-KM's-sake approach, which, Youman says, has nothing to do with business objectives. During KM initiatives, project leaders frequently forget to set benchmarks along the way because they forget that KM is a process, not a project with a finite end.
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.