When you start a project, what’s one of the first things you do? Before creating a schedule, before planning out what needs to be done, you look for evidence of what happened in the past.
It’s like an archaeological dig.
What are they doing now, why, what happened to make it that way? If your client is in pain, how did it get this bad?
Once you have a few hints, you start to dig a little deeper. The greater your discovery, the more you treat your “find” with care, asking questions that might be sensitive.
Sometimes you’ll hit the jackpot—that evidence that helps you understand the why and how.
Most of the time, unfortunately, you won’t find much of anything. A pottery shard letting you know something was done, but you don’t have enough evidence to piece it together.
You’re still in the dark, for the most part, trying to help solve the puzzle with most of the pieces missing. If only someone had left documentation behind. Trained the right Super Users and left a note about why the quirky process is the way it is!
I was talking with a new Project Manager at a client. Mike had a ton of experience and was hired to pick up where the old PM left off. I asked him how things were coming along and he expressed his frustration that there was no documentation—no requirements, no meeting notes, nothing! I was taken aback because I’d received some very nice templates from the former PM. We hunted around the system a bit and as it turns out, all the documentation was complete, but no one showed the new Project Manager where to find it. He was digging in the wrong place!
It’s a good thing Mike expressed his frustration to the right person. Pure coincidence that I knew where all the documentation existed. What a waste of effort if Mike had to start over from scratch, figuring out what decisions were made and asking endless questions about the current process. Not to mention the old PM’s extensive documentation would have gone to waste. (Hey, they do call it “artifacts” for a reason!)
When we close our project and roll off, not only is proper documentation important, but so is Knowledge Transfer. KT includes much more than training end users. Anyone who is impacted by the project can benefit from a proper hand-off.
Here are a few groups that benefit from a solid KT:
- The Support Team. Most projects these days include some type of software. If a user has a question or problem, they’ll call the Help Desk or their favorite IT source. Make sure they are looped into what you’re doing, when you’re going Live, the type of system it is or may impact, and, if appropriate, give them a list of people they should inform if they get a call.
- Super Users. Your Super Users require more than extra user training. These folks will collect comments, questions, and requests for changes to the process. The more you arm them with what, why and how, the more they can keep the “clean” process you’ve designed from getting messy and inefficient. Super Users stand between a well defined & documented process and the quicksand of “tribal knowledge.”
- End User Managers. The end users will have the most to say about the new process. Talk with their managers about the new process and the impact to their team. Don’t leave them in the dark. No manager wants to hear their team’s role has shifted after the fact. And remember to loop them into the other groups receiving KT, especially the Support Team and Super Users.
- The Process Owner / Sponsor. This person doesn’t need to know the nuts and bolts. They may never even use the process themselves. But they’re likely to own the budget for the area, and they need to understand the impact of the project on the end users and other processes. They may also be responsible for future enhancements, so show them where to find the original requirements and hand them a simple process for gathering future requests.
- Owners of process on the front and back end of yours. Everything in business is interrelated. What happens before your process begins? (An order is placed? A call is made? Something is shipped?) What happens after? (A bill is paid? A shipment is made? Something is produced?) You likely talked with these process owners back when you were gathering requirements. Close the loop and let them know how it all turned out. Make sure they understand who to go to with questions or issues in the future.
As you are planning your Knowledge Transfer, remember that not everyone requires the same information or the same level of knowledge. For example, a Help Desk will benefit from a high-level overview so they can pass along issues to the right person, but they probably won’t need to be trained to fix issues themselves.
Consider a KT plan as part of your overall documentation strategy. Start thinking through the groups who need to be informed before you start planning your Go Live and Close, and leave time for it in your overall schedule. You don’t want to skimp on this vital area of communication!
Take heart, though. Knowledge Transfer doesn’t need to take long, and the documentation you’ve written along the way contains most of the information required. If you can’t hand over a document as-is, it’s usually a matter of cut & paste or simply reformatting it.
Finally, make sure part of your KT is telling people where to go for the information. Is it a Team Room? A shared drive? A department site? Wherever it is, leave a map, or at least some breadcrumbs. The next Project Manager will be looking for it. Don’t let them dig in the wrong place!