Showing posts with label checklist. Show all posts
Showing posts with label checklist. Show all posts

Monday, March 23, 2009

Updating Risk Identification Checklists and Response Plans

Have you ever tried to follow a plan only to find that the plan wasn't up-to-date and contained inaccuracies? For a plan to be effective, it must be kept current. New information, changes, and corrections have to be made in a timely manner to prevent inappropriate actions being taken on inaccurate or outdated information.

When monitoring and controlling risks, documentation is especially important because project managers and teams use risk documentation to:
  • track risks
  • to identify new risks
  • to plan additional risk responses
  • to record any actions taken to control risks
If the information being acted on is not current, a new risk is introduced—the risk of acting on inaccurate or outdated information. To avoid this confusion, you must strive to keep all documents up to date.

Two of the most important documents to keep current are the risk identification checklist and risk response plan.

Risk identification checklists
Risk identification checklists describe the criteria used to identify new risks. Project team members should use the experience gained during their projects to update the checklists. This will make the checklists more effective for use in the risk management of future projects.

Risk response plans
The risk response plan is a document that describes in detail what actions should be taken in response to specific risks. Since the risk response plan acts as a guide to risk monitoring and control, the project team should update it regularly to keep everyone equally informed.

There are many elements that you can include in updates to risk response plans. Usually updates are the product of an action or event that changes the risk situation of the project. In some cases, the fact that an action was not taken leads to the need for an update. Some of the common elements included in updates to a risk response plan are:
  • Implementing risk controls - The implementation of risk controls may reduce the impact or probability of identified risks. Documenting the implemented risk controls will provide the project team with the information it needs to change its future expectations for particular risks.

  • Changing risk rankings - Risk rankings change throughout the project's life cycle. You should document these changes so you and your team can properly control higher ranking risks.

  • Closing risks - Risks that do not occur and that are no longer considered a threat should be documented and closed in the risk response plan.
Updating documentation can help avoid confusion and keep everyone on the project equally informed. The information added to the documentation will help you prepare for similar risks that may occur in future projects.

Thursday, September 25, 2008

Maintaining Documents and Records

Every key step or change in the project or quality control change needs to be documented so that the reason for any changes can be traced at a future date. The documentation serves as authorization for action and evidence that the change did occur.

Project or process documentation begins with the original concept plan. It then evolves into activity-based documentation in which there are a variety of possible documentation types.
  • Checklists - can be developed to ensure that documentation flows properly and that certain documents are retained for archival purposes. There should be a checklist for every major activity that needs to be completed before another can begin.
  • Control sheets - record the flow of key documentation and changes. Data on decisions, changes, and who made them, are recorded.
  • Sign-off sheets - are documents which verify that a particular stage to a project has been completed to the quality goals. Sign-off sheets record specific information about which activity has met the standard and when.
  • Approval forms - verify that permission was given to advance to the next stage in a tightly controlled project. They are somewhat similar to sign-off sheets.
  • Reviews - examine a process or stage of a project to ensure it has met the particular goals set out in the original plan or to other quality standards. Most reviews recommend changes of some sort.
  • Testing reports - are carried out by specialists such as laboratory technicians, programmers, and quality testers. Their language is quite technical, however the use of non-statistical and statistical techniques can aid understanding. Test reports can express if a change, or no change, is required.
  • Logbooks - record the movement of documentation and when certain activities occur. This ensures an orderly flow and if a problem arises, it can be examined to see when and even what was responsible. Logbooks in manufacturing often contain the data required for analysis.
  • Acceptance reports - indicate whether a project or product was done satisfactorily. If not acceptable, suggestions can be offered. It is similar to a sign off sheet, but with more detail.
In addition to these activity-based documents, various standards organizations may require you to maintain records verifying conformance to industry standards. These records may be in the form of:
  • inspection reports
  • test data
  • qualification reports
  • validation reports
  • survey and audit reports
  • material review reports
  • calibration data
  • quality-related cost reports.
Depending on the project, you may also need to save instructive documents such as:
  • drawings
  • specifications
  • inspection procedures
  • test routines
  • work instructions
  • control sheets
  • the quality manual
  • operational procedures/checklists
  • quality system procedures.
All records and documentation need to be clear, legible, dated (including revisions), identified, accessible, and stored to prevent deterioration or loss. These can be in the form of images, hard copy, CD-ROM, and electronic files. The quality management plan for the project or company should specify how long documents need to be kept and how they should be disposed of once out-dated.

The control of documentation depends on the process or project undertaken. Long duration projects may require documents and records to be archived at set intervals. Short duration projects may allow subordinates to retain documents until the end of the project and then they are stored. For most projects there should be some sort of post project review. The idea is that the record keeping can provide specific information to see if the various procedures work well. This is a function of quality assurance.

Documentation is often relegated to minor status in a project. Many people think once the key work is done, that there will be time later to catch up on the paperwork. However, in a proper project, documentation is designed into the process to ensure an orderly flow, without unnecessary paperwork. The preservation of data, decisions made, and the general plan and outline of the project are key to ensuring quality.

Saturday, June 30, 2007

Planning for Future Project Development

What lessons did you learn from your last project? Whether the project was a success or not, it can teach you valuable lessons you can incorporate into your future projects.

However, applying lessons learned from past projects to future projects usually does not happen automatically. You must plan for future project development. By following the two strategies described below, you can ensure that you have an appropriate plan in place, so you can learn from past projects and manage future projects more effectively.

1. Gather project data.
You should begin by examining your data. If you have been documenting the progress of your project from the start, you can use the data you have collected to identify the most effective techniques to incorporate into your future projects. You also can implement the following three strategies to gather project data.
  • Postmortem meeting. You can hold a project postmortem meeting, where all members can openly discuss the positive and negative aspects of the project. A postmortem meeting gives all team members an opportunity to discuss issues and brainstorm ways to eliminate similar problems in future projects. This strategy is useful only when participants have had a chance to review the project.
  • E-mail summary. An e-mail summary from each participant is also a great strategy for gathering information on the good and bad aspects of the project. This strategy is useful when time is of the essence or when team members do not have time available to meet.
  • Written reports. Written reports that describe the team members' experiences throughout the life of the project are useful when written documentation is required. For example, use this strategy when senior managers request a report.
2. Document the information.
Once the project information is gathered, it is imperative to document this data for future project development. There are three strategies you can use to document the information you've gathered.
  • Develop a checklist. A checklist is effective as a reference tool for similar projects in the future. A checklist normally contains the positive points from the present project that your team can apply during specific stages of future projects.
  • Create a top-10 risk list. A top-10 risk list contains negative points from your current project. It is an effective way to help your project team develop strategies for the elimination of similar risks in future projects.
  • Prepare a formal report. You would prepare a formal report when documentation of both the positive and negative aspects of a project is required. For example, this strategy might be useful when the data requires a more thorough evaluation by senior managers.
Each project you manage will require the use of different strategies for gathering data and preparing this data for future project development. With a bit of foresight, you can easily determine the appropriate strategies for gathering and documenting data, and ensuring that lessons learned are applied to your future projects.