I remember all too well the end of a certain pilot for benchmarking I was involved in. Although there was some success, there also was more failure than I wanted to see. After we regrouped, our management decided the effort would continue, as it was part of a large initiative. I then moved to making benchmarking a permanent feature of the landscape. I figured it would be clear sailing from then on.

I was being naive again (well, I’ll admit to stupid this time). Within a few weeks, I couldn’t believe the change in my outlook. I couldn’t believe how many new problems appeared, and how much harder it was to scale up. It was my first lesson in how having a successful pilot doesn’t guarantee a successful program. A successful pilot doesn’t even guarantee that you’ll get a thumbs-up to proceed any further. You can bank on being much smarter than when you started. You’ll be ready to do a better job than you would have without a pilot. But you’re still under the gun. You can go from being the hero to being a goat. If anything, the pressure increases.

But this is the part that matters in the long run: embedding knowledge management into your organization. If you succeed, you’ll have changed the way work is done. Permanently. In this chapter, we’ll look at what’s involved in embedding knowledge management into an organization.

If you were in the same room with me, you’d probably be tugging on my arm and demanding to know how many years you should plan on to embed knowledge management. I’m tempted to say “more than the sentence for a misdemeanor, closer to some felonies, but less than first-degree murder,” but I’ll resist. In practice, the answer is that it depends. We’ll look at our two primary case studies, Hewlett-Packard Consulting and British Petroleum, to give you a rough idea.

This abbreviated version of the time line later developed at Hewlett-Packard Consulting shows both the major activities and how long it took to implement their program.

This time line at BP, developed by Dr. Carol Gorelick, shows many similarities and also some differences.

Your time line could be entirely different. It’ll depend upon many factors:

Tread the fine line between being a hare or a tortoise as gracefully as you can. I predict this’ll necessitate much negotiation with your leadership and some adjustment as you go along.

After the pilot it’s time to forward all of your phones, hang a sign on the door (Skiing in the North Pole—back in a few months), and lock yourself in. Even though you should have been reviewing as you went along, now is the time to reflect at length. You need to look back at the pilot from start to finish. It’s also time to switch from recommendations on the day-to-day work of the pilot to recommendations for scaling up—or quitting.

To do this, I suggest that you use the learning-after process called a retrospect developed at British Petroleum and documented by Chris Collison and Geoff Parcell in Learning to Fly. Essentially, a retrospect is a review of a project or other major effort. The goal is to examine the lessons learned and to make recommendations for the future.

Preparation before the meeting is critical. First of all, the meeting should be scheduled as soon as possible after the project ends. Make sure that you invite the right people. Find yourself someone to facilitate, someone who wasn’t involved in the pilot. The actual retrospect has several parts:

Let’s now look at how you expand beyond the pilot. There’s a number of things you can do now.

Start with a clean slate on approaches. During the discussion of your expansion strategy, you may want to date around and marry some new approaches. If you had a single pilot with one approach, now’s the time to play the field before you settle down. HPC began with one pilot and then expanded its approaches.

This phase can resemble a gold rush, as everyone heads out to stake a claim and start panning for gold. No doubt about it, you want lots of enthusiasm and eager participants. What you don’t want is folks going hog-wild and doing any darn fool thing they think of. Too much enthusiasm could lead to a big mess.

This is when you need some standards, policies, and procedures. You also need some enforcers (peaceful means only)—a central KM staff, an overseer group (such as the IT group at Hewlett-Packard Consulting), or some other group that can dance the dance of imposing as much order as is needed while still allowing people to exercise their creativity.

You also have to decide how you will ramp up the effort. You have three options:

Now you need a whole bunch of resources. One of those that could be a showstopper is a knowledge management staff that can facilitate the rollout. During expansion, central KM teams tend to increase in size geometrically. You also may want to position such people within actual business units, close to the work and preferably with an in-depth knowledge of how the work is done there.

The larger the rollout, the higher level of management support you need. I wouldn’t even dream of a global rollout without the CEO’s support. For one thing, it’s a matter of practicality. You just squared the resistance you will encounter.

Don’t regard the CEO merely as a bank to be wooed for funds. A former CEO once asked me and my colleague to do something that I wish we’d thought of ourselves: conduct an assessment similar to what Hewlett-Packard Consulting did when they questioned their customers. The experience was as harshly illuminating as a theatrical spotlight. By golly, the CEO’s some smart guy, I remember thinking. It changed the way I thought about him from being a semi-deity to just someone I worked with.

This is the time that mistakes you made way back when about scalability appear like the ghost of Christmas future to threaten you with a dismal end. Some could be:

And so on. Actually, no matter how carefully you planned to scale up, my bet is that you’ll encounter some bumps along the road. Be prepared to deal with whatever problems pop up as you expand to the big time.

Let me tell you that it’s never too late to benchmark. Unless you compare yourself to external knowledge management programs, you have no way of knowing how good you are. Or how many gaps you have. You have no yardstick with which to measure yourself.

Sometimes you find out (to your immense surprise) that you’re the benchmark. It turns out that the people you thought were such hot stuff are bowled over by what you’re doing. Sometimes life is less kind, and you spend the exchange frantically taking notes and wondering if you’ll ever catch up.

Usually the results fall somewhere in the middle. Some of what you’re doing is great; some has room for improvement. But you’ll never know until you go outside your own walls.

At the same time, you know your own organization best. You can best test the organizational waters to see how you’re perceived internally. Don’t discount your own knowledge, but combine it with a realistic view of what others are doing.

As you get further along in the expansion, both looking outside and relying on your own knowledge can help you to assess the strengths of your program, the weaknesses, and options for making it better. But this will only happen if, like you did during the pilot and initial expansion, you take the time to evaluate what you’re doing.

Until the top dog joins the team, you aren’t in the big time. You may have noticed (with envy) that both the top leader of Hewlett-Packard Consulting and British Petroleum were firmly committed to knowledge management. That’s typical. The American Productivity and Quality Center notes that the best practice organizations come to rely on the CEO having a personal belief in the efforts and including effective knowledge management as part of the organization’s vision.

However, depending upon your organizational scope you may be limited to embedding KM in a major business unit or division. In that case, you must have the support of the head of that unit or division, but not the CEO’s. Never forget that it’s extraordinarily difficult to embed KM across an entire large, global, and diversified organization in one fell swoop. Even with the CEO’s support!

Of course, even CEO’s can leave. Another way to embed knowledge management is to make it a permanent part of the way business is done. This may be spelled out in the strategic plan. It may be part of policy. Or it may simply be an explicit part of the way your organization does business. Then even if the CEO does leave, it’s more entrenched and harder to dislodge.

The time also has come to take on the reward and recognition system. If the current system fails to reinforce the behaviors needed for knowledge sharing, change it. I don’t underestimate how difficult this may be. But what gets rewarded gets done. Some organizations have created separate rewards and recognition for knowledge sharing.

You also could add new rewards and recognition to the existing system. That makes me a little uncomfortable, though. If other forms of rewards and recognition contradict knowledge sharing, I wonder which ones people will pay attention to.

Closely related and equally important is your performance evaluation system. A performance evaluation system should act as a coach, spelling out what behaviors are expected and giving suggestions, if needed, to steer someone back on track.

You also need to decide what sort of supporting personnel structure you want for knowledge management:

With knowledge management, in addition to retaining several people on a KM staff, British Petroleum also decided to allow some members of the team to leave with the intellectual property and form an independent company. That company, Knowledge Transformation International, now contracts to provide knowledge management support for British Petroleum and other clients. The ties are so close that the majority of their people have BP e-mail accounts. You may think it was foolish to make that decision, but it is consistent with the BP way of doing business. It also ensures that they still get additional support as and when they require it.

Even if you dislike how BP handled it, it beats the heck of out declaring victory and sending all the troops home. That leaves no one to monitor how things are going and take action if necessary. Some believe that the hallmark of a truly successful knowledge management program is that a knowledge management staff disappears. I think that mind-set begs the question: If knowledge was so important that you launched an effort to better manage it, isn’t it worth a continuing effort and attention?

That mind-set also ignores organizational entropy, the tendency to regress to old habits. If no one remains to sound the clarion call to value knowledge, an organization might revert back to the bad old habits.

Whether or not a knowledge management function does the work, do establish a means for assessing and monitoring continuing knowledge management efforts.