Instilling Lessons Learned into the Organization's Memory When a project ends, participants are usually in a hurry to get to their next project or opportunity. That's why it is vital to capture as much information as possible before the participants scatter. It is not necessary to create elaborate documents inches thick to be placed on the corporate bookshelf (which few people take the time to read). Instead, it is quite sufficient to create a PowerPoint-style presentation, or a brief five- or six-page document describing the key information needed. This presentation should contain the following information: Project identificationthe project's name, dates it was conducted, and names of the participants. List the updated contact information for the participants if it is known. A description of the project, its purpose, and the client. A description of the end-user community in terms of size and general attributes. A description of the program size in terms of the number of project team members, the project's duration, funding, and so on. A list of the program's key risks and what was done to mitigate them. Was the mitigation successful? What risks were unanticipated, how did they affect the project, and what was done about them? A description of the technologies used on the project in terms of programming languages, methodologies, and techniques. What was successful? What were the pitfalls, and how were the problems and challenges met? A description of how the customer relationship evolved throughout the project. What was the customer's perception of the project organization at the conclusion of the project? A description of the budget and schedule. What were the project's original budget and time duration estimates? What were the final budget and time figures? A readily accessible copy of the documentation. If possible, save the artifacts from the project in a central location on a LAN. Create hyperlinks to the artifacts from the project. (This may not always be possible if the customer does not consent or if regulations prohibit it.) This can be a great help for future projects. The artifacts can be used as examples to follow or can be improved for the next project.
Project Management Forums Another useful idea for contracting organizations is a messaging board that can be accessed over a company intranet. If managed properly, it can be helpful for obtaining quick "second opinions" or answers to questions. Another useful aspect is the ability to place a simple query such as "I am experiencing situation X on project Y. How should I handle this situation?" Here are some suggestions for operating a project management forum: It should have several categories of topics. For example, technical topics might include things such as development, programming language, platform, software process, Configuration Management, and Requirements Management. The forum should be kept strictly as a problem-solving dialog. There should be no proselytizing, unhelpful criticism, blaming, or complaining. Instead, the tone for answering problems should take this form: "We experienced that problem on Project N. Here's what we did to solve it." Another type of response might be, "If the audience is particularly large, a moderator may be needed to monitor the group, to keep the dialog on target." Posts should be kept online as long as practical. When this is done in conjunction with a good search engine, the message board becomes a storehouse of searchable information that can be useful for future projects.
The point is to have a forum where company team members can feel comfortable discussing ideas and can collaborate on solutions to problems without fear of ridicule or unfair criticism. |
