Suggest an idea and you end up being the one instructed to do something about it. On your own time, of course, as if you weren't already completely loaded with things to do. I knew all about the "volunteer and you're it" phenomenon at WedgeMark when it was time to propose continuity management officially. I wasn't concerned that it would fall into my lap, however; I even welcomed it. There was something about continuity management that inspired me, if that's not too strong a word. It took me back to an earlier time when there weren't as many layoffs and people got excited about projects and wanted to do something meaningful and got a bunch of other enthusiasts together to help them do it.
Once our continuity management inquiry was officially recognized, more people joined us and KC Prime's size made it unwieldy as a think tank. So we divided it into prime teams, each with a set of responsibilities. Although officially sanctioned, KC Prime remained informal and somewhat irreverent. The first item on the agenda was planning, so we elected Cheryl Supreme Continuity Planner of the United States and put her in charge of it. Cheryl's planning team promptly met (out of spite, we think), and, after a period of time, developed a reasonable and generally coherent plan for implementing continuity management at WedgeMark.
I sat in as a member of Cheryl's planning team from the beginning. It was one of the most important of the teams we created out of KC Prime, because its charge was to design the continuity management initiative. The team's first step was to develop a set of get-started definitions for basic continuity management terms that would give us the beginnings of a common language on which to base our discussion of continuity management implementation. The choice of terms was easy. We selected incumbents to mean current employees who possess the critical operational knowledge that will be harvested and transferred to successors. Successors, obviously, are the employees who will replace the incumbents and receive the critical operational knowledge. And peer incumbents are current employees who share the same job classification, form a community of practice, and can serve as resources to each other in identifying (and later refining) the critical operational knowledge to be passed to their successors.
The next, more difficult step, was to develop a plan that would launch continuity management in our business unit and, hopefully, throughout WedgeMark. Since successful change initiatives follow a fairly standardized plan, Cheryl's team adhered to that template in developing the six steps to continuity management. Those steps are previewed here and discussed in more detail in subsequent paragraphs:
Conduct a knowledge continuity assessment to determine the state of knowledge continuity (and discontinuity) in the organization.
Determine the objectives and scope of the continuity management initiative.
Establish coordination responsibility for implementing continuity management.
Plan the continuity management implementation initiative.
Create the methodology to harvest and transfer the critical operational knowledge.
Transfer the operational knowledge.
While these steps are logical and, to some degree, self-explanatory, it remained to fit them to our organization. The ways in which we applied these steps at WedgeMark are described in later chapters. What follows here is an overview of the steps. The usual caveats apply to this neatly ordered set of steps intended to create change: They are not as discreet and sequential as they seem. For example, while it's true that the results of the knowledge continuity assessment (Step 1) will build a more powerful business case (from Step 2), it is also true that building the business case (from Step 2) makes a comprehensive knowledge continuity assessment (Step 1) more likely.
We had never formally addressed knowledge discontinuities at WedgeMark other than to acknowledge that we had an impending retirement problem and to make assorted efforts to grab the knowledge of some key people when we discovered they were leaving—if we discovered it in time. As a result, we had no real understanding of how serious the knowledge discontinuity problem was at WedgeMark. The first step, therefore, would be to determine the extent of that problem by conducting a knowledge continuity assessment. In essence, the knowledge continuity assessment was a form of risk assessment that sought to identify the critical operational knowledge that was most at risk of being lost. We began with the obvious positions: those with impending retirements, high turnover, unique operational knowledge, or knowledge with very high value. In each of these cases, knowledge loss would be unusually costly and disruptive.
As our assessment continued, we expanded the list of jobs. In the end, we came to the conclusion that the vast majority of WedgeMark employees were knowledge workers, so that virtually all of the operational knowledge that was critical to them would be critical to their successors. All of the knowledge did not have the same potential value to the company, however. Some knowledge was less complex or unique or difficult to harvest, so the loss of that knowledge was less important. All knowledge loss, in other words, was not equally disruptive. But the accumulated effect of the knowledge loss that WedgeMark suffered every year was beyond anything we had expected to find.
Chapter 7 describes the knowledge continuity assessment in detail.
Continuity management is highly flexible. It can be customized in many different ways to meet the diverse needs and resource limitations of an organization or its subdivisions. By design, the general template that Cheryl's team developed was suitable for all of WedgeMark, which meant that we had to customize it to fit our own business unit.
In the process of developing our own set of objectives for continuity management implementation, we proposed the following mission statement:
To make knowledge continuity an integral function of managing at WedgeMark, seamlessly practiced and supported at every level of the company, in order to preserve operational knowledge continuity between employee generations and thereby protect and build the capital asset of knowledge for ourselves and for those who succeed us.
The scope of continuity management implementation can be described in terms of four factors: breadth, depth, technological sophistication, and support. Breadth refers to the number of positions for which critical operational knowledge is captured. Depth refers to how much operational knowledge is captured for each position. Technological sophistication refers to the degree of technological sophistication used in the capture and transfer of the critical operational knowledge. And support refers to the extent to which the organizational culture and reward systems are aligned to support continuity management implementation.
The following paragraphs explore each of these dimensions in more detail.
Breadth refers to the number of people who will be designated to participate in continuity management. It would be possible, for example, to ensure knowledge continuity for only a few top positions, such as the CEO or vice president of finance. Such a knowledge continuity program would have virtually no breadth, and continuity management would not have been implemented. At the other extreme, every employee in the organization could participate in continuity management, which would be the broadest possible implementation, but such breadth would be unnecessary. The knowledge continuity assessment will determine the appropriate breadth for a given implementation.
Three questions can be used to analyze the breadth of continuity management implementation:
How many structural units of the organization will participate in continuity management? Will continuity management, for example, be implemented in single or multiple structural units (departments or divisions, for example)?
How many levels of the hierarchy in each of the structural units will participate?
How many people within each hierarchical level will participate?
We knew that continuity management could be implemented at any level of an organization and that it could be initiated by any manager at his or her level or below. Even rudimentary versions of continuity management will reap significant benefits in knowledge continuity and productivity. But implementation in one or two structural units or in a minority of the levels in those units does not have the salutary effect of implementing continuity management in the majority of the structural units or throughout the whole organization. The greater the breadth of implementation, the greater the synergy, and the greater the potential rewards are for the organization. This synergy results from five factors:
Knowledge continuities in one unit reinforce and complement knowledge continuities in other units, so that the greater the number of participating units, the greater the effect of continuity management on an organization's productivity.
The greater the number of people participating in continuity management, the greater the likelihood that valuable new knowledge will emerge that can be spread throughout the organization, using knowledge management tools that capture best practices or otherwise make knowledge available to others who need it.
More sophisticated technology is likely to be employed with organizationwide adoption of continuity management. This greater sophistication makes it easier to capture, access, transfer, and utilize the operational knowledge.
With organizationwide adoption, continuity management is more likely to be completely integrated into the operations of the organization, accepted as a function of management, and supported by the organizational culture.
With organizationwide adoption, powerful extrinsic reward systems can be introduced to support continuity management.
The Information Age has transformed organizations into webs of knowledge, with nodes so interconnected that knowledge continuity improvements in one area of the web race throughout the knowledge web to other nodes, affecting them in unexpected but positive ways. By the same token, knowledge discontinuities in the web have a negative impact on other nodes. It is for this reason that knowledge continuity improvements at even the lowest level of a hierarchy can have a significant effect on the whole organization.
The goal of continuity management is to harvest critical operational knowledge for a given position and transfer that knowledge to successor employees. But how critical should critical knowledge be? Obviously, there is a range of knowledge even within the critical knowledge designation. And once critical knowledge has been identified, how much of that knowledge should be harvested and transferred to successors? Any critical knowledge is better than none, but, within limits, the more comprehensive the knowledge, the better it will serve both incumbents and successors.
Additional critical knowledge, however, comes at a cost in time and technology. The fundamental question in determining the depth of continuity management implementation is: How much operational knowledge do we need to transfer to successor employees? Or, put another way, how deep do we want to drill down into the incumbent's critical operational knowledge base?
The third component is the degree of technological sophistication used in continuity management implementation. This issue is so important that it was tackled by a special team and is discussed in more detail in Chapter 11 ("Creating the Knowledge Profile"). Basically, the technology questions we posed were:
How sophisticated should the technology be that is used to identify, capture, and transfer the operational knowledge?
To what extent can continuity management technology be adopted from, or integrated with, existing knowledge management technology?
The fourth factor in continuity management implementation is the extent to which it will be supported by the organization. This dimension involves three components:
These factors indicate how seriously an organization takes its knowledge loss and how committed it is to preserving knowledge continuity between departing and arriving employees.
As we considered the objectives and scope of continuity management at WedgeMark, we were simultaneously developing the business case for implementing it. Building the business case is a key step in garnering the support necessary to initiate any new program, especially one as far-reaching as continuity management. Dave Pollard, global director for knowledge innovation at Ernst & Young's Centre for Business Knowledge in Toronto, describes the need for the business case in any attempt to persuade people to share knowledge. "Knowledge by itself," he advises, "is too abstract for many people to relate to. If you can tell them how their lives will be better or easier than today, then that really helps sell the concept. It makes the abstract concrete" (Buckler, 2001, p. 3). We heeded that advice.
We based our business case on the compelling need for continuity management described in the continuity management chapters I had distributed to members of KC Prime. In early discussions we held with respected colleagues, we used an approach that emphasized both the serious threats of knowledge loss and the rich opportunities they presented for maximizing the use of our knowledge capital. We began with the acute threat to productivity that impending baby-boomer retirements posed, resisting the attractive fantasy that the retirement problem would go away by itself or that it could be postponed. That forced us to confront what would happen to us when the institutional memories took their gold watches and said goodbye. We were the ones who would be left holding the empty knowledge bag, not them. This reality personalized the threat of knowledge discontinuity and provided an incentive for a knowledge continuity program that would benefit the company in the long term because it would benefit us in the short term.
The other threat we raised was the chronic loss of knowledge from rapid job turnover. The greener-grass syndrome was taking its toll at WedgeMark. So were the bouts of downsizing that struck like a recurring fever, leaving us more and more debilitated. Everyone recognized the severity of this chronic problem. They also recognized that the victims of downsizing weren't just the ones who left, but the ones who were left. Whether the turnover created new successors without sufficient knowledge to carry their load or transferred the work to remaining employees who also had insufficient knowledge, the results were equally nasty. We made the case that our own best protection from knowledge loss through job turnovers and downsizing was continuity management.
In addition to these threats, we talked about the opportunities. We emphasized the payoffs of the continuity management process: the positive effects of clarifying our knowledge needs, identifying knowledge leverage points, and eliminating work that was largely or completely irrelevant. We recounted stories of early successes related to continuity management. For example, I disclosed how my own continuity management initiative had revealed that a long-standing report I regularly received was no longer valuable. It might have been valuable to my predecessor or her predecessor, but not to me. I suggested to my boss that it be discontinued, thereby saving my subordinates the time it took to prepare it. In that vein, I also suggested that it was possible that I was providing him with reports that he didn't need or that he needed less often. At the same time, I requested additional information that would boost my productivity but that I had a hard time getting—if I could get it at all. Even as a proposal, continuity management gave us a forum in which to discuss our knowledge needs with one another. It was one of the most refreshing conversations I've had in my years at WedgeMark.
We all knew that good ideas and innovative approaches were being lost when our colleagues left. But they were also lost when we left. That was a problem for WedgeMark, but it was also a problem for us. Those creative solutions might have been a small legacy to leave, but it felt good to have our solutions and insights preserved for others. Whether it was a fleeting sense of immortality or a desire for recognition, the legacy idea resonated with people. A lot of our colleagues do take pride in their work and would like to see their insights passed to others. And some of them wanted to leave something when they left WedgeMark.
As we discussed the implementation of continuity management among ourselves, other potential advantages emerged. We knew that if we survived to experience another job at WedgeMark, we could access the operational knowledge of the people who had preceded us. That opportunity would increase our confidence in our new positions, an advantage that did not apply to everyone, of course, but that was important when it did. More and more people were being transferred internally, which was partly due to so many cross-functional teams and to a reinvigorated policy that encouraged internal promotions.
The members of KC Prime were not entirely sure where this step belonged in the sequence, but our experience indicated that, ultimately, someone had to assume coordination responsibility for implementing continuity management. That person might be a manager if continuity management were launched in a single department, or it might be a vice president if it were launched in a division, or it might be someone else. But someone had to assume the role. I took it on informally at first, but a formal arrangement finally became necessary. Implementing continuity management was not an onerous task, but it was time-consuming. The degree of required coordination depends on the level of implementation, but even the simplest requires someone to get it started.
It was our belief that whoever took the coordinating position would eventually work himself or herself out of the job, although it might take half a decade or more for that to happen. As we conceived the process, continuity management would start as a program but would finally evolve into a function of management, as much a part of what a manager does as planning, organizing, controlling, and leading. At that point, continuity management would be an integral part of how things worked, supported by the reward systems and the culture of the organization, and no one would be required to coordinate it. That conclusion was based to some degree on WedgeMark's experience with quality improvement, which we thought might be analogous. Richard Leinert, CEO of Deloitte & Touche LLP, pointed out this analogy between knowledge management and the quality initiative, although we applied his comments to continuity management rather than to knowledge management. "If we look back at corporate America 10 or 15 years ago," he observed, "many organizations created senior vice presidents of quality..... What they did over the ensuing 10 years is essentially work themselves out of a job. They served as change agents, cheerleaders, focal points to elevate the attention and emphasis on quality, and then over time that responsibility was embedded back into the operating units" (Haapaniemi, 2001, p. 65). That vision was one that some of us had for continuity management, but not everyone on the team agreed.
"Fantasy," Sarah called it. "Even if continuity management were fully operational, it would require someone to oversee and maintain it," she said. "The analogy between continuity management and quality improvement isn't valid. Quality improvement is important, but it's not a function of management; it's a goal. The true analogy is another organizational function. In other words, there will have to be a VP–continuity management just like there has to be a VP-finance or VP-marketing. That's how critical the function is. In fact, there may be a chief knowledge continuity officer or even a chief continuity management officer."
Andre disagreed. "Continuity management is an integral part of knowledge management," he said, "perhaps, in fact, the foundational part. There won't be a chief knowledge continuity officer, except possibly as an interim measure. The duties that would be assigned to such a position will be assumed by the chief knowledge officer or chief information officer. Continuity management and knowledge management will ultimately be regarded as a single process, which will be under the CKO."
Our differences in perspective regarding the ultimate disposition of the continuity management start-up coordinator were based on timing rather than function. We all agreed that someone was necessary to coordinate the initial implementation of continuity management. As the role of continuity management expanded, the responsibilities of that position would also expand, at least for awhile. We were confident that continuity management itself would continually evolve, because the operational knowledge it captured and transferred was continually evolving, just as the circumstances that made that knowledge valuable were evolving. Whether the coordinating position became a permanent position in the executive hierarchy, became another function of the chief information officer, or disappeared as continuity management became an accepted management function was something we would have to wait to find out. We could predict, however, that until continuity management was well established as a process, it would require someone to plan, implement, and coordinate it.
The person chosen to lead the continuity management initiative has the fundamental responsibility of coordinating the work of the teams responsible for the design and implementation of continuity management. Small-scale implementations (as would be the case with a pilot for the whole organization or an implementation in a single business unit or a small organization) would call for fewer teams than a large-scale implementation (in which continuity management is implemented throughout the organization, for example). In small-scale implementations, multiple functions can be assumed by the same person or the same team. But the functions that are necessary to carry out the six steps to continuity management described in this chapter remain the same. Once implemented, various elements of the knowledge-harvest-and-transfer system that preserve operational knowledge have to be updated, revised, and enhanced if the value of the knowledge asset is to be protected and multiplied.
As one of Cheryl's planning team members pointed out, continuity management is a major change initiative, which means that its implementation has to be well planned if it is to succeed. Even continuity management on a small scale requires this strategic approach. In our own case, we followed the eight-stage plan for bringing about change that John Kotter describes in his book Leading Change (Kotter, 1996). We had each of the team members read the book and relate it to continuity management at WedgeMark. Although there are other change models, we would suggest this book to anyone intending to implement continuity management.
Just as Kotter suggests, we established an urgent need (the business case for continuity management), built a guiding coalition (which we later expanded to include a large group of people), developed a continuity management vision, and employed all the means at our disposal to communicate that vision to the people in our unit. We were also careful to restructure, retrain, and retool wherever necessary (including aligning the organizational reward systems) to encourage implementation of continuity management.
We built in short-term wins for employees who implemented continuity management (and communicated those successes through as many different media as possible) so that they would be encouraged and would encourage others. We consolidated the early gains we achieved with continuity management (easy when we had retained the critical operational knowledge of someone who had left the company) to increase enthusiasm and support for it. And, finally, we tried in every way possible to anchor continuity management in our corporate culture. The eight-stage process for leading change that Kotter describes is straightforward, although, as we discovered, its stages are less sequential and have more simultaneity than he suggests. Once you have read Kotter's book, it will be clear how to apply these steps to continuity management.
After the knowledge continuity assessment identified key knowledge discontinuities, it was time for a more complicated task: creating the methodology to harvest and transfer critical operational knowledge from incumbents to successors. Since the design of the methodology was crucial to the success of continuity management, Cheryl appointed a specialized team to handle it. While all the team members agreed on the general parameters of their assignment, they were not sure what they should call the process or processes they were creating.
Roger favored operational knowledge audit because, in his view, the process of harvesting operational knowledge was, in fact, an audit of an employee's operational knowledge.
But Andre objected. "Nobody likes to be audited," he said. "Besides, our process is more inclusive than an audit, which might analyze knowledge, but wouldn't gather or transfer it. What we need is something to harvest operational knowledge from incumbents and a knowledge profile to transfer it to their successors."
We liked the term knowledge profile and promptly adopted it. With that endpoint in mind, it was easy to determine the additional instruments that were needed to create the profile. The first was a set of questions that would identify and harvest an incumbent's critical operational knowledge. Since these questions would ultimately result in the knowledge profile, we called them the knowledge profile analysis questions, or K-PAQ for short. K-PAQ and its development are described in Chapter 9 ("Developing K-PAQ: The Knowledge Profile Analysis Questions").
The second instrument we needed was the questionnaire that would contain questions from K-PAQ that were relevant to the knowledge profile for a particular job classification. We dubbed this instrument, logically enough, the knowledge questionnaire, which we shortened to K-Quest. The process of creating the knowledge questionnaire from the questions in K-PAQ is described in Chapter 10 ("Developing K-Quest: The Knowledge Questionnaire"). An integral part of developing K-Quest is choosing the proper technology for its administration, since the answers to K-Quest will be converted by technology into the knowledge profile.
Our objective in administering K-Quest was to harvest a comprehensive body of operational knowledge and to focus the attention of WedgeMark employees on knowledge as a critical asset—one to be preserved, enhanced, and adroitly exploited. With that in mind, the process of administering K-Quest assumed special importance. The complete administration process that we envisioned included an orientation day for explaining continuity management and for administering K-Quest to designated employees (described in Chapter 10, "Developing K-Quest: The Knowledge Questionnaire"). It also included follow-up meetings of peer incumbents so they could share their answers to K-Quest and validate the critical operational knowledge they had harvested (described in Chapter 11, "Creating the Knowledge Profile").
The dual objectives of continuity management are (1) the identification and analysis of critical operational knowledge by incumbents and (2) the transfer of that operational knowledge to their successors. Implicit in the knowledge transfer process is the successful acquisition of knowledge by the successor. In continuity management, the design of the knowledge transfer (and acquisition) process focuses on the format of the knowledge profile through which the operational knowledge will be transferred, the context in which that transfer will occur, and the organizational reward systems that support or undermine the transfer. (These issues are addressed in Chapter 12, "Operational Knowledge Transfer and Acquisition").
With the completion of these six steps, we were ready to move the continuity rocket to its launching pad. Except that we had no rocket yet, just the design for one. We were enthusiastic about our progress and impatient to move forward, but the devil is in the details. There was a great deal more to do before we could launch continuity management at WedgeMark. Our next project would be to design the knowledge continuity assessment. First, however, we received Roger's take-always. Then we celebrated with a hearty lunch of KC Prime steaks, baked potatoes, Caesar salad, and the desserts of our choice. The company even picked up the tab.