Using Templates from Past Projects

Who was your role model when you were a child? Do you remember someone you used to emulate? Did you want to be like them? Did you try to copy that person's behavior to get the same results?

Templates for organizational planning work the same way. You can model your project according to similar successful projects from the past.

Using the successful elements of a former project will save you both time and money.

Although the details of each project are unique, the basic components are often similar. This helps you in your planning. For example, you can use the role and responsibility definitions, or reporting relationships, of a similar project to expedite the organizational planning process.

Peter, the project manager for a large insurance company, is preparing a responsibility chart for his team members. How does he decide how to do this? One effective method is to see how responsibility has been distributed in the past. Peter can do this by using the responsibility charts of other successful departments in his organization, or he can copy those of another successful company. Either way he chooses, he is using a past template to ensure the success of his project.

You can disassemble past templates and reassemble the plans you need for your own project. Possible plans you can use for your own project include:

• organizational structure
• Work Breakdown Structure
• company policies and practices

IRT is a successful IT consulting company. One of the services it offers is a Software Development Life Cycle Methodology. Within that methodology are predefined roles and responsibilities and organization charts. Before starting a project, the team members at IRT use their company's model as a starting point. By doing this, they are using templates of organizational structure and work breakdown structure. The team modifies its own template to suit its clients' needs, while building upon past success.

As a project manager, you will want to use templates to guide your organizational planning. Building on the success of others is a sure way of steering you toward your desired goal.

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.

The Sources and Uses of Project Historical Data

There is an old adage that history repeats itself. The negative connotation to this is that humans tend to make the same mistakes over and over again. Despite this tendency, people can learn from studying history.

Like world history, historical information from past projects provides you with the opportunity to benefit from past successes while avoiding past failures.

Past projects provide you with inputs for your current project, telling you what people, equipment, and materials were needed for which tasks. Project historical data also tells you which practices and procedures were effective and which were not.

Analyzing project historical data is made easier when you keep a project notebook. A project notebook holds data records in the form of various reports. These reports include:

• project plans
• status reports
• budget reports
• resource and supplier QA and performance reports
• project logs (issues and problems).

Previous project plans can give you ideas for how you can approach your project. You can see how tasks were accomplished, what methods were deployed, and what type of resources were used.
Status reports indicate how well the resources that were used functioned while budget reports provide information about the cost of potential suppliers and contractors, which can help you estimate the cost of future projects.

Quality assurance reports give information on the quality level of the resources used on a project. The same type of information regarding suppliers is found in supplier performance reports.

Project logs reveal past issues and problems. You can apply these "lessons learned" to your current project.

Consider the example of an international telecommunications project. A similar project estimated the timelines for various stages of a project in its project plans. The actual timelines were recorded in the status reports. Reasons for the discrepancy between the two were recorded in the project logs. The budget report stated the costs, and an analysis of the project flow was included in the resource and supplier performance reports.

The paper trail left from previous projects helps you estimate costs, choose suppliers, estimate timelines, and see different approaches to a project. As such, it is your guidepost to the success of your current project.

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.

Conditions for Using a Network Diagramming Template

Think about building a house when all the pieces are already prepared. You're only responsible for assembling the parts and making minor adjustments. Once you build the first house, you can use the pattern to build others.

Network diagram templates, like prefabricated houses, are standardized, pre-built components. They allow you to use successful past projects as models for the current project and schedule planning activities. Using network diagram templates helps you improve the accuracy of activity sequencing by highlighting successful practices from past projects.

Network diagram templates help you complete your work more quickly because much of the work has already been done for you. Using the successful elements from past projects also saves money on the overall current project.

Finding similarities between past and current projects is extremely helpful in planning and activity sequencing. It is appropriate to use network diagram templates as a tool for activity sequencing, when there are similarities between overall projects and among subprojects in larger projects.

• Similarities between projects - The first situation in which you should consider using network diagram templates as a tool for activity sequencing is when similarities between two separate projects are identified. Some similarities between projects include phases and deliverables. Effective network diagram templates cover the entire project and are especially useful when the past and current projects share a common structure.
  
  Consider the following example. Jack, the training director for a large engineering firm, is responsible for the continued development of in-house training courses. Since each training course has the same design cycle, Jack is able to use network diagram templates for activity sequencing of these internal courses.
  

• Similarities between subprojects - The second situation in which network diagram templates are useful is when there are similar features within a single project. These features are often called subprojects or subnets. Subnet templates are useful for projects where there are several identical features within the work breakdown structure. After completing a network diagram for the first subnet, you can use it as a template for other components within the same project.
  
  It is best to use subnet diagram templates with projects that have repetitive phases, such as floors in a high-rise building, clinical trials in pharmaceutical research, or program modules in a software project.
  

Network diagram templates can help you save time by reducing the duplication of effort where similarities between projects and subprojects exist. Understanding when to use diagramming templates will allow you to reach project goals more quickly an

Publish Post

d efficiently.

Project Decomposition and Templates

To complete any task, you need to know what tools are at your disposal. Project managers who are engaged in defining project activities use two main tools to accomplish this task: decomposition and templates.

Decomposition
Decomposition means breaking a project deliverable down into a list of achievable activities.

Telecom Corp. is a telecommunications company. One service that it provides to its clients is the virtual private network (VPN). VPN project deliverables include a firewall, routers, encryptors, Internet service, IP backbone, and secure remote access.

The last deliverable could be decomposed into the following three activities:

1. provide remote access
2. provide encryption key
3. authenticate users

After dividing a deliverable into potential activities, the team must evaluate each activity using the following six criteria.

1. Status is measurable.
2. Sign of completion is visible.
3. Start and end conditions are clearly defined.
4. Time and cost are easily estimated.
5. Duration has acceptable limits.
6. Work assignments are independent.

The first criterion to consider is whether the activity's status is measurable. For example, one deliverable in a Telecom Corp. VPN project is secure remote access. One activity defined for this deliverable is authenticating users, and it is measurable. When half the users have working login IDs and passwords, the activity is fifty percent complete.
Whether there is a visible sign that the activity is complete is the second criterion. This sign could be the delivery of a document or product, or it could be the manager's signature. In the Telecom Corp. example, the visible sign that users have been authenticated to the network is when all users can access the network with a functional user password.

The third criterion to use is whether an activity has clearly defined start and end conditions. Once the beginning event has occurred, work may begin on the activity and continue to a visible sign of completion. For Telecom Corp., the authentication activity should only begin when the network is in place. The authentication activity is clearly finished only when the users are able to use their login IDs and passwords to access the VPN.

Whether activity time and cost can be easily estimated is the fourth criterion to consider. This is accomplished by estimating the time and cost of a project's activities. In the Telecom Corp. example of authenticating users to the VPN, time can be estimated at a few days.

The fifth criterion to examine is whether an activity's duration is within acceptable limits. Although there is no set rule on this, projects should avoid activities with long durations. Delays in such activities can create serious scheduling problems. In evaluating Telecom Corp.'s authentication activity, duration can be estimated at a few days. Delays here would not create huge project delays or large-scale scheduling problems. The authentication activity then meets this fifth criterion.

The final criterion is an activity's level of independence from other project activities. Independence in an activity means that once work has begun on the activity, it may continue without interruption. For example, once Telecom Corp.'s authentication activity begins, it is not dependent upon any other project activities for completion.

Templates
The second tool a project manager and team uses to define project activities is a template. A partial or total activity list, or WBS from a previous project, can be used as a template for a current project. Using templates simplifies project activity definition and reduces project costs by improving team efficiency.

To define project activities, project managers use decomposition and templates. Decomposition means breaking project deliverables into achievable activities. A template is a partial or total WBS, or activity list defined in a previous project, which can be used in a current project.

Work Breakdown Structure Templates

Like a map that shows you the entire world at a glance, the Work Breakdown Structure (WBS) is a graphical representation of the entire work effort of a project. It is a deliverable-oriented grouping of project components that is used to:

• organize and define the total scope of the project

• confirm a common understanding of the project scope.

Often, you can use a previously developed WBS as a template, or pattern, for new projects because most projects will resemble one another. Patterning a project after a previous one will enable a project manager to save both time and money. The project manager needs to consider three factors when deciding whether a previous project's WBS can be a template for a new project.

• Project life cycle. Organizations usually create a framework that all project managers follow when developing projects. This framework is known as a project life cycle. The project life cycle defines the beginning and the end of a project. Project life cycles are usually organization specific.

• Project phase. A project life cycle is broken down into phases that make it easier for a project manager to manage a project. Each project phase contains related project activities, usually culminating in the completion of a major part of the product or service.

• Project deliverable. Each project phase is broken down into deliverables, which helps the project manager to control the project. A project deliverable is any measurable, tangible, verifiable outcome, result, or item that must be produced to complete a project or part of a project.

Many companies use a framework for project development that begins when an idea for a project is accepted and ends when the product or service is delivered to consumers. This is considered the project's life cycle. The life cycle includes the following phases:

• planning—understanding the proposed product or service

• designing—creating a detailed plan

• manufacturing—building the product or developing the service

• testing—making sure that the project or service meets expectations.

If a past project and a new project share similar project life cycles and deliverables, the past project can serve as a WBS template for the new one. The more similarities that exist between the life cycles and deliverables of the old and new projects, the more appropriate the old WBS will be as a template for the new project.
To determine similarities in the two project life cycles, look at the project phases of the two projects. Are the phases the same or similar? Do the projects have the same number of phases? Are the phases in each project named differently but accomplish the same thing?

If the answer to any one of these questions is "no," you can't use the WBS from the past project as a template, and you don't need to do any further research. However, if the answer to all three questions is "yes," you can probably use the past project's WBS as a template for the new project.

If the project phases of two projects are similar enough that the WBS from the older project can be used as a template, the project manager should then look at each projects' deliverables to see if they are the same in number and similar in outcome. Although the deliverables may be project-specific, project managers can consider them similar as long as they are accomplishing similar tasks.

In summary, when comparing past projects to the current project to determine if you can use the WBS template from the previous project, you should look for similar life cycles, phases, phase outcomes, deliverables, and deliverable outcomes. If a previous and a new project have the same or similar project life cycles, phases, deliverables, and outcomes, save yourself time and money and reuse the WBS from the previous project.

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.