It’s easy for the lessons learned from a project to get lost once it’s over and there’s new work to be done. And it’s equally difficult for project managers to rush through the documentation process to stay on schedule. Read on for advice on avoiding such pitfalls, as well as planning for low-risk events.
Got a project management nightmare? Looking for a solution? Send us a note with the details. Tom may consider it for an upcoming column.
Learn from prior projects
Sam and I meet on an ad hoc basis to talk about his project to install a new release of the company’s financial software package. When he calls, there is usually something on his mind.
“We were testing the new release of our package when we discovered that a small piece of the system contained custom code that needed to be rewritten. This code was written a number of years ago by a contractor, and we forgot that it would need to be upgraded separately,” he explained recently.
“It’s too bad that you discovered the problem so late in the project,” I said. “But at least you found it. I guess that says something about the value of good testing.”
“I’m glad we found it, too. Actually, it would have been pretty embarrassing if we hadn’t. I found out that this same problem occurred the last time the package was upgraded. Now, I need to figure out how to make sure this is not overlooked again the next time we do an upgrade.”
“You’re right.” I said. “The accumulated knowledge of a project tends to exist only in the minds of the people who actually worked on it. You need to make sure this information is available the next time your package gets upgraded. What information did you have available from the previous upgrades of this package?”
“All I had was what the two team members who were here the last time could recall.”
“Let’s make sure the next project manager is better off than you were. We need to package and save all of the key project information before this project is completed.”
So much organizational knowledge gets lost over time if there are not formal processes designed to capture and exploit the information. Project knowledge is accumulated throughout the project. It starts with the project definition and work plan and continues through the issues log, business requirements, test plan, and so on. In the type of project that Sam is managing, almost all of this information can be utilized the next time a new release is installed. Before the project is completed, time must be allocated to capture all the relevant information and bundle it in one place for future use. (Don’t zip all of the information and place it in an obscure spot or on someone’s local hard drive.) If the information is saved and reused, the new project team will be able start off more quickly, and lessons learned during the course of a prior project can prevent repeated mistakes.
The need to manage documents
Juan and I are meeting every other week until his project to upgrade the phone mail system is completed. He is beginning to see the value of practicing more formal project management techniques.
“I’ve been doing all right so far, but I made an embarrassing mistake,” Juan began. “I was so excited to send my project definition out for approval that I e-mailed an old version of the document to the sponsor and my manager. The sponsor actually approved the document, but my manager saw that there were errors in the budget and the deadline. So I had to send the project definition back out a second time.”
I asked Juan how he is storing documents.
“I’m storing all the internal project documents in the same way that we always have—by placing them in a shared folder on the server. I have a central folder for holding everything related to the project.”
“How did the documents get screwed up?” I asked.
“A stupid mistake.” Juan said. “I e-mailed a draft of the project definition to a team member for feedback. She then stored the document in the same shared folder with a slightly different filename. When I sent out the ‘final’ document, I forgot the name of the original document, and sent the old draft version out instead.”
“This is not an unusual problem.” I replied. “The more people that are assigned to a project team, the more discipline and rigor are needed in the management of project documentation and knowledge.”
One of the more sophisticated aspects of managing a project is to manage the flow of documentation. Small project teams normally don’t need to put a lot of effort into document management. However, sharing information becomes more and more complicated as a project team gets larger. Document management tools can enforce many of the rules for sharing documents, but most companies are still relying on manual processes. These can get very complex and involve naming conventions, versioning, folders, sub-folders, and access rights. For Juan’s project, having a shared folder to hold information is a good start. He also needs a good directory structure, including a work area for each team member. Then he needs some simple rules about where to place information and who can update what folders. Like many other processes, planning the document management process up front will save much more time and confusion as the project progresses.
What happens if low-risk events occur?
I had my first meeting with Terry, whose project is to make all the hard-copy reports that support the factory floor available through the Web. Terry’s project is two-thirds complete, and since she asked to see me on the same afternoon, I assumed that there must be a problem.
“We’ve been using the beta release of a Web reporting tool, but now the vendor has decided not to bring the tool to market,” Terry explained. “There’s no question that this will impact our project end dates. First, we will have to decide on a new tool and then retest everything. I wanted to talk to you about some ideas we have to resolve this. Each potential solution has some positives and negatives.”
“I’ve been reading that this vendor was having some financial difficulty for the past few months,” I remarked. “Would it have made sense to identify this as a project risk?”
“You’re right.” Terry replied. “We were aware of the vendor situation, but they kept telling us that their reporting tool project was going to be fine. In fact, we looked at the situation a number of times and always concluded that there was a low risk. So, it wasn’t included in our risk management plan.”
“Well.” I said. “In the future, include a second factor in your risk analysis—the impact to your project if a low-risk event actually happens.”
The first step in the risk management process is to identify potential risks and assign them probabilities of high, medium, or low. The team should then prepare risk plans for all the high risks and the medium risks where it makes sense. However, the low-risk events should be reviewed to understand the potential impact to the project if they occur. If the impact to the project is disastrous, then these risks should also be part of the risk plan. For instance, the probability of a computer failing on the space shuttle is probably very low. But the impact of a failed computer while the shuttle is in space would be disastrous. Therefore, a backup computer and a second backup computer need to be available. In Terry’s situation, her team’s conclusion that there was a low risk associated with the Web reporting tool may have been sound at the time. However, since the impact to the project of the event occurring was very high, the risk still could have been included in their risk plan. Then, if there were vendor problems, they would have been in a position to mitigate the impact to the project.