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.

Documenting Lessons Learned

Each new project provides a unique opportunity to learn something new and then apply it to improve the planning and execution of future projects. The body of the knowledge gained while working on a project is sometimes referred to as "lessons learned."

Some of the most common lessons learned from the schedule control process are:

• the causes of variance
• the reasons a particular corrective action was chosen
• the new processes that were implemented
• the issues with internal or external sources
• the successes or failures measured

Because lessons learned are helpful in planning future projects, care should be taken to document these lessons and make them available to future project teams. Consider the following example.

A company's planned launch of the space shuttle was set for April 1st. During the pre-launch servicing stage, workers inspected and tested the Orbiter wiring. During the testing a system malfunction occurred. Upon examination, the team discovered a short circuit in the wiring, which caused the malfunction. A complete system rewiring would be required. This procedure could significantly delay the project, since the wiring would have to be ordered from a specialty supplier in Europe.

The project team and shuttle crew met to discuss this dilemma. The team decided to increase the number of project workers. This would allow the rewiring to be completed while continuing with the remaining pre-launch servicing and testing. The target launch date could still be met.

The need for complete system rewiring and ordering the wires from an outside supplier was what caused the project to fall behind schedule. Therefore, the detection of the cause for the schedule variance was one of the lessons learned by the shuttle team.

Another lesson that can be recorded in the historical database is the approved corrective action. Adding more resources was positive and ensured the successful completion of the project. The target date was achieved.

A toy manufacturing company has just designed and developed a prototype of a new infant toy. The toy is to be launched at the International Toy Fair in two months. In order to prepare, the company needs to produce 2,000 prototypes, which will be available for sale at the fair. The project is running on schedule. However, during the testing phase, the company discovers a flaw that could cause the toys to malfunction. With only three weeks to go, the company cannot possibly start from scratch and reassemble 2000 toys.

Closer examination reveals that fixing the problem simply involves ordering a different part and replacing it. This will take at least one month, working solely with the current team. Management's only option at this time is to add project personnel, allowing the project to be finished in time for the toy fair.

A lesson learned, in this situation, is the discovery of the variance from plan. The manufacturing flaw resulted in the need to order and replace a fundamental part of the toy. This unanticipated problem has the potential to significantly delay the project's completion.

Another lesson learned is the reason for the corrective action chosen. Increasing man-hours by adding project personnel is the only viable option for the toy manufacturer, given the time crunch.

Once a project team has identified the lessons learned through the schedule control process, there are a number of succeeding steps that should be implemented to ensure the information is not lost.

• Step 1: Record lessons learned - Information should be recorded and stored in a way that permits team members to easily identify any applicable lessons learned. This information is invaluable when planning projects and processes.
  
  
• Step 2: Analyze information - Lessons learned should be analyzed to assess improvements, or identify valuable or detrimental project trends. The analysis should focus on improvement efforts.
  
  
• Step 3: Measure effectiveness - Lessons learned programs should include a means for measuring project effectiveness. The purpose of measuring effectiveness is to determine if information is being disseminated and past lessons are being incorporated.
  
  
• Step 4: Review and validate information - Lessons learned should be reviewed and validated for appropriate personnel to determine accuracy and applicability.
  
  
• Step 5: Disseminate information - Information about lessons learned should be disseminated to all project team members as well as key stakeholders. Information dissemination may be accomplished through a variety of vehicles, the most common being written documentation or through meetings or workshops.
  
  
• Step 6: Archive irrelevant information - Information that no longer has relevance to organizational activities should be archived or eliminated. Archiving is often the preferred choice, as currently irrelevant data may have inherent value in future project planning.
  
  
• Step 7: Obtain feedback from stakeholders - Feedback from key stakeholders and users can assist saving time or money, preventing a recurrence of a problem, or improving project design or processes.

To ensure project quality, you will want to use the new insights and processes that result from lessons learned. To benefit from this practice, lessons learned must be well documented and reviewed occasionally to determine if past lessons are being realized and integrated into project planning and ongoing development.

Historical Information and Project Activities

Historical information is an invaluable input to project activity duration estimating. As a project manager, you can use historical information, in the form of past project data, to make estimates on current similar projects.

For example, on a past project, John's company, Quick-as-a-Wink Computer Consultants, took five days to complete the audio for a two-hour software project. Based on this previous experience, John estimates it will also take five days for audio on the current two-hour software project.

There are many sources of historical information available to a project manager. You can start by checking the following three sources.

1. Project files
Past project files provide a fountain of information for project managers. A company may maintain records of previous project results that are detailed enough to aid in developing future duration estimates.

For example, John needs to know how long it will take to install a hub for a computer network system. John remembers installing a similar hub on a previous project. By retrieving the previous project files, John is able to find the information he needs. Since the first hub took 11 days to install, John will plan for 11 days on the current hub installation project.

2. Commercial duration estimating databases
Historical information is also available commercially through databases. These databases tend to be extremely useful when the activity duration is not driven by the actual work content.

For example, John needs to determine how long it takes a government agency to respond to a request for a license. John can contact a commercial duration estimating database company, which keeps information of this type on file. For a fee, the company will sell the information to John.

3. Project team knowledge
Another source for historical information is individual project team members who have worked on a similar project in the past. They can sometimes provide estimates of how long it took to complete the previous activity.

Remember, historical information can be a powerful tool for project managers. Don't be condemned to repeat the past. Instead, learn from it by using historical information.

Incorporating IT Project Deliverables

Your promise to complete a project by a particular date has fallen through. As you think back, you realize that you had no way of knowing whether or not things were progressing smoothly.
How can you ensure that you have a check process in place for your next IT project? One suggestion is to incorporate project deliverables.

Project deliverables are the final product or result of a particular phase of a project. Deliverables are ultimately passed on to another party, either professionals who will use the deliverable to begin the next phase of the project, or the customer if it is part of the final product.

When planning a project, IT professionals establish specific types of project deliverables to help determine when a stage in the process is complete. These deliverables also can help you identify whether a problem exists early in the process.

There is no limit to the number of deliverables you can incorporate into each phase of your project. The following are a few examples of the most common deliverables.
1. Organization charts. Organization charts show the breakdown of the responsibilities or duties of the individuals in each unit. These charts can include information about the sponsoring company, the customer's company if external, and the authority, responsibilities, and communication breakdown for a project.
An example of an organization chart is the organizational breakdown structure. Your company's OBS chart may include the name of the employee performing each of the roles identified on the chart.
2. Work packages. Work packages are comprised of a number of precise working documents that provide details on specific business tasks of the project. An example of this deliverable is the Statement of Work (SOW).
3. Planning documents. Planning documents are used to develop and maintain a feasible method for addressing the business needs of the project. The amount and detail of the information contained in these documents depend on the size of the project.
Work schedules and cost estimates are examples of this deliverable. Work schedules can help you determine the staff numbers and skill sets needed for the project. Cost estimates give you an approximation of the total project cost.
Remember, by incorporating deliverables into the project phases, you and you team can more effectively plan and manage your next IT project.