F
H
F
G
G
G
Solution A
Solution B
Solution C
run a limited pilot program with the top vendor. A contract is negotiated. Within three months, the pilot content management suite is installed in the company’s research and development (R&D) division.
The challenge before the CKO, management of the R&D division, and the vendor is applying the technology in a way that demonstrates a measurable ROI.
Issues
The steps CGF undertakes that result in the pilot program illustrate several key issues associated with identifying and evaluating potential KM
solutions:
• The selection process begins with looking inside the organization to determine needs, not looking to vendors for solutions.
• The driving force for collecting information within the organization is the creation of a request for proposal, a working document that specifies the functional and technical requirements of the technology solution to the current KM
challenges facing the corporation. Because the RFP is drafted collaboratively, it represents a consensus of opinion inside the organization.
137
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t
• The RFP specifies vendor selection criteria. These typically include infrastructure requirements, price, product functionality, vendor and developer reputation, and the fit of technology with corporate culture.
• The company’s CIO or technically competent CKO must be involved in selecting a solution.
• A technical KM solution not only enables the existing KM
processes and workflow of the organization but fits the organization’s culture. Therefore, potential solutions must be evaluated on nontechnical, functional issues as well as technical merits.
Evaluation Process
The story of Custom Gene Factory’s quest for an enterprise-wide Knowledge Management solution illustrates the process of evaluating the merits and cost of technologies that can support a KM initiative.
Although some stages often are performed in parallel, the solution evaluation process is best appreciated as a serial process, as diagrammed in Exhibit 6.2.
The process of enabling a KM program with technology involves nine stages:
1. Determine the needs of the organization.
2. Establish a budget.
3. Develop a request for proposal.
4. Issue the RFP.
5. Assess the proposals from vendors.
6. Evaluate the potential solutions.
7. Negotiate a contract with the vendor of choice.
8. Work with the vendor to implement the solution.
9. Assess the results.
138
S o l u t i o n s
E X H I B I T 6 . 2
Determine Needs
Internal
Establish Budget
Focus
Develop RFP
Issue RFP
External
Assess Proposals
Focus
Evaluate Solutions
Negotiate Contract
Collaborative
Implement Solution
Implementation
Assess Results
For the purpose of identifying and assessing potential technology-based solutions to KM challenges, the first six stages of the implementation process are the most critical. Therefore, the discussion here focuses on those stages. The last three stages, which involve the actual implementation of the solution, are covered in Chapter 8.
The first three stages in the process, which culminate in an RFP, are primarily internally focused. As in the story of CGF, creating a 139
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t meaningful RFP requires consensus among management and knowledge workers in the organization regarding what constitutes an ideal technical solution to the current KM challenges. The next three stages, leading to the identification of the best solution available that satisfies the constraints defined in the RFP, are primarily externally focused.
They involve focusing not only on the technology but on the developer and vendor. A technologically superior product from a developer with an unrealistic business model or poor reputation is a high-risk investment.
Determine the Needs of the Organization
In the story of CGF, the technical needs of the organization become apparent to the senior management as the knowledge workers and management became familiar with how technology can support and enhance existing KM processes.
Similarly, a corporation faced with choosing its KM technology should look to current KM practices and how technology can be used to enable them. In addition, simply because a KM process is being performed with, for example, the aid of a meeting room with wall-to-wall whiteboards and a refrigerator full of soft drinks doesn’t mean that moving to a computer-based system will improve on the effectiveness of communities of practice. Working collaboratively in the same space creates a certain group dynamic. Thus, the meeting room, designated for meetings of communities of practice, may be more valuable to the organization than a new videoconferencing system or electronic whiteboard.
That’s where the expertise and knowledge of a CKO comes into play—
recognizing which KM processes should be technology enabled and which ones are best left alone. Only then can he or she find the most appropriate technological solutions for a given KM challenge. Examples of situations in a knowledge organization that suggest an enabling technology may be able to improve on the effectiveness of—or extend the 140
S o l u t i o n s
reach of—current KM practices include rapid growth, geographical expansion, and feedback from knowledge workers that the current infrastructure isn’t supportive of their KM efforts.
The potential downside of driving a cultural change through the introduction of an enabling technology is that the amount of time from when the early adopters start using the technology to when laggards embrace the technology can span several years. For example, when e-mail was first introduced into a large organization, it typically took several years for everyone to come online. There are exceptions, of course, as when senior management dictates that paper memos are no longer allowed.
However, it’s impossible for management to dictate the formation of communities of practice and expect them to produce meaningful results. The easiest, quickest path to Knowledge Management is when technology follows and enables established KM practices.
Establishing a Budget
Establishing a budget for a minor or even a major Knowledge Management initiative typically isn’t as challenging as actually obtaining the funds for the project. However, when faced with coming up with a reasonable budget, the best approach is to consult with companies of roughly the same size and scope in the same field that have installed KM technologies. Another approach is to hire a consultant with the requisite experience in KM technologies. However, when a consultant is used, the issue becomes one of locating someone who isn’t wedded to a particular vendor or approach.
From a practical perspective, the incremental cost of implementing a corporate-wide KM initiative varies from about $100 to $6,000 or more per seat for software alone. A major component of the cost is the infrastructure, including the underlying network, support hardware and software, and desktop or hand-held systems. The incremental cost reflects the expense of software licenses, hardware upgrades, and training.
141
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t Develop the Request for Proposal
The most important internal step to take in identifying a technologic solution to enabling Knowledge Management in the organization is to establish exactly what management and knowledge workers need to support an ongoing or planned KM initiative. In this regard, the RFP
encompasses not only the minimum technical requirements for a technology but instructs the vendor how it can meet and exceed corporate expectations. For the knowledge organization, an RFP is an internal working document that serves as a sounding board for all internal stakeholders involved in the KM effort. The RFP forces those involved in the initiative to consider the benefits that they expect the system to deliver—
T I P S & T E C H N I Q U E S
Multifunctional
Request for Proposal
For a company not certain of the options available in the Knowledge Management market, investing the time to craft an RFP that describes the corporate environment can pay for itself many times over in consulting time, lost time on the job, and travel expenses.
Senior managers or company representatives won’t have to waste time at KM trade shows and meeting with vendors, instead vendors will beat a path to the company to point out how their products can be applied to company’s current KM processes. Competing vendors are more than happy to point out faults and gaps in the competition’s offerings, and provide industry-wide pricing norms, references, and other information that otherwise the company would have to pay to acquire. Although the practice of using vendors as free consultants may not be completely fair to vendors, it’s an excellent starting point for a company serious about acquiring technology to enable its KM activities.
142
S o l u t i o n s
the requirements specifications—as well as the technical, detailed specifications that the system must conform to—the functional specifications.
The requirements specifications are qualitative descriptions of the expectations of knowledge workers and managers. For example, a statement such as “The system will provide our knowledge workers with the ability to communicate using audio, video, and text, in real time, over our existing network system” could appear as part of the requirements specifications of the RFP. Exactly how this expectation is met is the challenge that vendors must address to win the corporation’s business.
However, rarely are vendors completely free to devise a solution without several technical constraints—as defined by the functional specifications.
The functional specification for the real-time audio, video, and text communications system could define, in explicit technical terms, the quality and bandwidth of the audio, video, and text; exactly what “real time” means; and could provide a technical definition of the network constraints.
The functional requirements are listed in the RFP so that vendors know what the corporation has in mind and senior management is in agreement regarding what a vendor is expected to deliver. The corporation’s objective evaluation criteria, such as the contribution of up-front costs and the use of subcontractors added to the vendor’s estimate, provides an overall evaluation score that gives vendors a clear idea of where they need to be in order to be competitive. Internally, the objective evaluation criteria listed in the RFP are helpful in overcoming personal biases and emotional attachments to a particular vendor during the evaluation of proposals.
Issue the Request for Proposal
There are several ways to issue an RFP. The first is to use a shotgun approach, using a variety of print media and the web to invite vendors 143
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t to contact the corporation for a copy of the RFP. This nonspecific approach has the advantage of attracting vendors that would otherwise be unknown to the corporation. The disadvantages are that some major vendors in the Knowledge Management market may not take notice of the RFP and that the corporation may be inundated with time-wasting, generic proposals that don’t address its specific needs.
A second approach is to target specific vendors, based on the advice of a consultant, the results of a web or magazine search, or by interviewing several experts in the KM field. The advantage of a targeted approach is that vendors contacted directly are more likely to respond in a way that addresses the RFP.
One challenge in using the directed approach to issuing RFPs is that vendors must be identified for each class of tools required. As shown in Exhibit 6.3, certain companies specialize in a variety of KM
products as well as general, industry-standard products can be used for TEAMFLY
Knowledge Management. In identifying specific technology vendors, the experiences of the CIO and CKO are particularly relevant. For example, every CIO will have experience with or at least be familiar with standard database products from Microsoft, Oracle, Sybase, IBM, MySQL AB, and InterSystems.
Another approach, as illustrated in the story of the Custom Gene Factory, is to use a combination of shotgun and directed approaches.
The downside of this hybrid approach is that a potentially large number of proposals may have to be evaluated very carefully.
Assess the Proposals
As the deadline specified in the RFP nears, proposals from vendors will begin filtering in. In assessing these proposals, it’s tempting to turn first to the solution and ignore the peripheral information that has a direct bearing on it—information on the vendor and the developers of the 144
Team-Fly®
S o l u t i o n s
E X H I B I T 6 . 3
Technologies Example
Companies
Content management
Autonomy, BroadVision, Citrix, Documentum,
Epicentric, FatWire, Hummingbird, IBM, Merant,
Microsoft, Open Text, Oracle, Plumtree, SAP,
Stellent, Teltech Resource Network
Data mining
Brio Technology, Cognos, Cr ystal Decisions,
Microstrategy, IBM
Database management
Microsoft, Oracle, Sybase, IBM, MySQL AB,
systems
InterSystems
Digital rights management
HP, Xerox, Microsoft, Sun Microsystems
Exper t systems
Vanguard Software, Tacit Knowledge Systems,
NEC
Intelligent agents
Intelliseek, Copernic, Lexibot, WebFerret,
(desktop)
SearchPad, WebStorm, NetAttache
Intelligent agents (web)
Dogpile, Ixquick, MetaCrawler, QbSearch,
ProFusion, Sur fWax, Vivisimo
Interenterprise computing
SAP, i2 Technologies, Manugistics, Ariba,
Commerce One, Oracle
Intracorporation search
AskMe, Cadenza
engines
Professional databases
LexisNexis, Factiva, OCLC Online Computer
Librar y Center, Inc., RocketNews, Dialog,
InfoTrac, EBSCO Online, SkyMinder, ProQuest,
Intelliseek, Scirus, Softbase, Ingenta
Public search engines
Google, Lycos, Yahoo!, Excite, AltaVista,
AllTheWeb, CompletePlanet
Real time collaboration
TeraGlobal, Groove Networks, Lotus, Divine
Simulation systems
Imagine That!, Decision Engineering, Promodel,
Production Modeling, Simul8
Visualization
The Brain Technologies, SAS, Minitab,
Advanced Visual Systems
145
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t technology discussed. Any vendor can claim to provide solutions with virtually unlimited functionality—either because the vendor doesn’t understand the RFP or because it wants the business so badly that it will agree to anything. For this reason, the first two items to be assessed in the proposal should be the vendor and developer. Consider the information on the products and services promised only if the vendors and developers fulfill established criteria.
As illustrated in Exhibit 6.4, assessment of developers and vendors involves consideration of unique features and many common elements. For example, in assessing a developer, a key issue is provision for future products. Some developers have a single product that hasn’t been upgraded in years, except for slight modifications to make it compatible with operating system upgrades. Other developers have a vision for future feature sets, integration with other systems, and increased functionality. These forward-looking developers are generally more likely to be around in three to five years than developers content to milk current offerings.
E X H I B I T 6 . 4
DEVELOPER
VENDOR
Future Products
Cer tifications
Market Share
Customization
Product Reviews
Marketing
Software Escrow
COMMON
Style
Suppor t
Bank References
Training
Client Base
Company Profile
Focus
Histor y
Location
Management
References
Reputation
Viability
146
S o l u t i o n s
Another developer issue is market share, in that it’s safer to go with a developer that controls a significant share of its market. Product reviews, especially independent reviews in magazines or journals, are another source of information about developers and their products.
They should be consistently positive. The willingness of a developer to provide a software escrow is also a critical assessment factor. Software escrow can lessen the likelihood that a developer will leave the corporation stranded with a dead-end product if the development effort fails or falls behind the development schedule.
A major vendor-specific evaluation criterion is whether a vendor is developer certified. Not only should vendors be certified by the developers they represent, but the certification must be meaningful. It should represent, for example, the fact that the vendor regularly receives training on the specific product. Lack of official certification may mean that the vendor either didn’t take the time to attend the requisite classes or failed the certification process. Certification is especially relevant when the solution must be customized to fit the corporation’s needs. Customization performed by a noncertified vendor may not be supported by the developer.
The availability of the vendor for internal marketing efforts may be critical for a successful implementation. Integrating a Knowledge Management product into an organization involves much more than simply installing a software package and plugging in the associated hardware. It takes a concerted internal corporate marketing effort to achieve buy-in from the knowledge workers and managers the technology is intended to empower.Vendors should be ready and willing assist with the buy-in process by participating in an official kickoff event and by providing management and knowledge workers with additional information. For example, vendors should be prepared to share successes stories and, more important, accounts of failures in similar companies.
147
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t I N T H E R E A L W O R L D
Technology Disconnect
In evaluating the ability of technology to enable or amplify an existing or nascent KM initiative, it’s easy to lose sight of the underlying prem-ise of Knowledge Management. As defined in Chapter 1, Knowledge Management is a deliberate, systematic business optimization strategy that selects, distills, stores, organizes, packages, and communicates information essential to the business of a company in a manner that improves employee performance and corporate competitiveness. However, it’s possible to technology-enable a process that performs superbly at improving employee performance, for example, but doesn’t improve the bottom line. In other words, it’s possible to have a disconnect between what is viewed as sharing, communications, and Knowledge Management, and the business of making money.
For example, Xerox’s Palo Alto Research Center (PARC), the advanced R&D center created by Xerox in 1970, has a reputation for excellent R&D, work environment, sharing, and Knowledge Management—but no business sense. As in many companies with innovative R&D divisions, PARC traditionally has failed to fully capi-talize on its innovations, leaving other companies to reap the business rewards for its work.
One lesson that can be learned from the PARC experience is that management shouldn’t limit its activities to enabling communities of practice, virtual collaborations, and other KM activities. It must ensure that the information and innovations developed in these groups don’t stay within the confines of R&D but are communicated to those who can take innovations and successfully bring them to market.
148
S o l u t i o n s
A vendor’s style has to mesh with the company culture if management is to get buy-in from internal knowledge workers. A compatible style is also necessary for effective training and support. For example, a vendor with a laidback approach may be incompatible with high-powered knowledge workers who value their time above all else. For these workers, a vendor with a slow, methodical, and complete style of teaching and product support may be intolerable.
Many vendors and developers work in concert with a client. For example, the vendor may provide sales and account management, while the developer provides training and ongoing support. The common factors related to vendor and developer assessment focus on parameters that define the business relationship and the likelihood that the vendor and developers will continue to exist in the long term. Bank references regarding financial status, breadth and depth of the client base, and management structure and experience are good indicators of vendor and developer stability.
The reputations of the vendor and the developer, references, and history provide a subjective measure of what the company can expect in terms of adhering to time lines, cost, and service. Finally, location may be a practical concern, especially the relative location of the vendor. Off-site training at the vendor’s facilities is much less expensive when the vendor is local. Similarly, it’s a bonus to be able to drop by the developer’s main offices to discuss product issues. At the other extreme, developers located overseas often present a considerable risk, even when there is a local vendor. If the developer folds, enforcing contractual obligations may be impractical.
Evaluate the Technology Solutions
With the proposals from viable vendors and developers in hand, the next step is to evaluate the technology solutions. This phase of the evaluation 149
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t process involves obtaining hands-on experience with the product. To this end, most vendors of shrink-wrapped software solutions will agree to a 30-day free trial. For more complicated systems that require some degree of customization or special hardware, many vendors will agree to absorb some of the cost of a pilot program in which a limited installation is provided for a three- or four-month trial.
The KM-specific criteria for evaluating solutions are a function of the product. Assuming a software application aimed at enabling communities of practice, potential criteria include:
• Compatibility. The product should be compatible with the operating system used, third-party KM programs, and legacy systems.
• Support. Product support should include official user’s groups, vendor or developer newsletters, and official publications.
• Synergy. The product should support for processes within the organization that enable ongoing communities of practice.
• Performance. The effectiveness and efficiency with which the product supports activities within communities of practice should be a performance standard.
In the end, the features and benefits of every solution have to be evaluated in terms of price. In this evaluation, it’s important to distinguish between the initial purchase price and ongoing, long-term costs. Besides the purchase price, there is the cost of maintenance—typically 30 percent of the original price per year. Ongoing license fees, can range from 10 to 20 percent of the purchase price annually. The cost of upgrades should be evaluated if they aren’t covered in the maintenance contract.
Solutions should be evaluated in terms of indirect costs that are usually not included in the contract with the vendor. For example, if the system is intended to support real-time video conferencing over the web, the buying organization may need to upgrade its current network 150
S o l u t i o n s
hardware and software and purchase additional peripherals, such as larger monitors, digital video cameras, and speakers.
Negotiate the Contract
After a thorough evaluation of the proposals, the next step is to negotiate a contract with the top vendor. As noted earlier, since a vendor’s response to an RFP isn’t legally binding, it’s prudent to fold the original RFP and the vendor’s proposal into the final contract. Negotiation and the next two phases of the implementation process are covered in more detail in Chapter 8.
Implement the Solution
Implementation is usually a shared activity that requires resources from the vendor, the developer, and the organization. Details of the implementation that should be specified exactly in the negotiated contract include the time line, deliverables, the sign-off procedure, and means of resolving disputes.
Assess Results
Assessing the results of an implementation involves comparing the functional and requirements specifications with what is delivered as well as evaluating the overall effect on the organization, especially the bottom line. Chapter 8 continues the discussion of Knowledge Management from the perspective of the numerous stakeholders involved in a KM
initiative and the likely return on investment.
Summary
Technologic solutions to Knowledge Management can be evaluated as part of a nine-phase process that revolves around the RFP. Inside the corporation, the RFP serves as a working document that management 151
E S S E N T I A L S o f K n o w l e d g e M a n a g e m e n t and knowledge workers can use to specify their KM needs. For vendors, the RFP serves as the basis for their responses. The RFP also provides the knowledge organization with a standard with which proposals can be evaluated objectively. Finally, the RFP and the top vendor’s proposal are folded into the negotiated contract to make the vendor’s responses legally binding. In searching for a technologic solution to KM challenges, the RFP is central to setting expectations both within the organization and with the selected vendors and developers that will implement the solution.
Do not believe what you have heard.
Do not believe in tradition because it is handed down many generations.
Do not believe in anything that has been spoken of many times.
Do not believe because the written statements come from some old sage.
Do not believe in conjecture.