Spotlight: Lessons Learned
By Gregory J. Offner (12/04/2009)

Offner

Back in the early 1990s our company began developing a new tool to help employees learn from one another. We established a Lessons Learned Library as a compendium of real-life experiences and knowledge gained from positive and negative experiences, situations and events actually experienced by managers and staff from each of our operating companies.

Why did we do it? The answer is pretty simple — to promote the frequency and reoccurrence of successful outcomes and to limit the reoccurrence of unsuccessful outcomes.

Learning through shared experience forms the central premise of the program.

It is very painful — financially, professionally and personally — to learn only through making your own mistakes first. Naturally, we all hope to never make the same mistake twice and we certainly understand there is a less painful, less costly way to learn — from the mistakes of others.

By applying our own experiences, as well as those of others to the situations presented to us, we can usually spot the potholes and avoid them. If you have not developed a program like ours, chances are you are unnecessarily hitting the same pothole more than once.

In the design and construction of secure environments, mistakes can have severe consequences. Applying our collective lessons-learned knowledge in our design philosophy and construction methodology is an important tool in providing safe and secure facilities for our customers.

What’s a lesson learned? 

A lesson learned is not simply a restating or paraphrasing of existing company policy, procedures or protocols. To be of value, a lesson learned should be a significant, valid and applicable practice in your day-to-day operations.

Sometimes just plain old common sense, lessons can be experienced whether or not you followed standard operating procedure. A painful “hot-pot” experience provides a good situational analogy.

Like most households, we use potholders when handling hot pots as a standard operating procedure. Despite appearances to the contrary, an empty pot left on the stove after cooking retains some residual heat and persons entering the kitchen and touching the seemingly cool pot run the risk of getting burned.

Out of a moderately painful experience comes a valuable lesson learned: treat every pot on the stove as a hot pot. The successful-outcome strategy adopted — we now leave a potholder on every stove-bound pot, whether hot or cold.

Lessons learned should describe a situation or issue that you have experienced, investigated and for which you have come up with a fail-safe method to prevent recurrence of a bad outcome or generate reoccurrence of a good outcome. If you can’t determine whether you have a successful solution or plan, chances are you need to do a little more investigation.

Some of the lessons in the AECOM library describe situations where potential problems were actually avoided by being proactive — mistakes do not even have to occur for a lesson to be learned.

Avoiding problems before they arise and sharing the positive experience, strategy and outcome with others forms another central tenet of our lessons learned program.

To date, our library contains more than 60 published case history lessons on topics spanning the full range of our practice including proposal preparation, contract language, documentation, negotiations, client relationships, design problems, shop drawing review and construction phase services. Although sanitized of certain specific information to protect the identity of the companies and people involved, the lessons to be learned from the case studies remain clearly evident.

In our firm, lessons learned are posted in the quality section of our intranet site, while links to the lessons learned library also appear on our risk management page, and we encourage their use at every employee level from management to intern. If you have a company Web site you should consider establishing a tab devoted to your lessons learned. As a justice design and management firm, we use our lessons learned when formulating evidence-based programs and designs.

From Me to You 

If you want a good night’s sleep, prepare a project work plan. One of the most common defects on many projects is the lack of a written work plan to guide the team through the project.

The objective of a work plan is to capture in a single-source document all of the essential information that will allow project staff and corporate leadership to efficiently and effectively fulfill their roles in completing the job.

Although most companies have a policy that requires a written work plan for every project, you would be amazed how many projects do not have one or how many have a work plan that is not worth the time it took to prepare. Be careful not to over-elaborate — the detail and complexity of a work plan should reflect the size and sophistication of the project.

As a CMAA best practice, a realistic, workable work plan should be prepared for every project. Small projects with a short duration may require a work plan of only a few of pages, while large, complex jobs demand a larger planning tool. Keeping it simple, relevant, realistic and proportionate works best.

On my project work plans this information usually includes:

Project description: A summary description of what we are designing or building, including the project location and all of the pertinent facts, figures and data normally transferred in a set of construction drawings. This information rarely changes.

Client expectations: Who is the client, what are the client’s goals and objectives (do not assume the contract terms and conditions encapsulate the client’s expectations). This part of the management plan changes with moderate frequency and should be updated if the client representative changes. This should be part of your project quality plan.

Scope of work: A summary in non-contract terminology of what we are getting paid to do. This information rarely changes and each scope item has a quality plan developed and attached. This should also be a part of your quality plan.

List of deliverables: A detailed summary in nontechnical terminology of what we are getting paid to provide. This information rarely changes and each deliverable has a quality plan developed and attached. This should form part of your quality plan.

Schedule of submittals and milestones: Although this information changes frequently, a simple calendar bar-chart schedule is a project work plan absolute.

Budget: Usually the project work plan functions as an internal management tool for my company, not a management tool for my client. The project budget is a profit plan developed from the estimated hours and dollars associated with the contract. This information changes with every cost event.

Organization chart or staffing plan: The who’s who of the project specifies who is doing what and can include a succession provision.

File index and filing procedures: A vital component for control. Each procedure should be audited with regularity. This should be a part of your quality plan. 

Project directory: A list of internal and external contacts. Changes frequently.

Communication protocol (written, verbal, e-mail): Make sure you have your client buy-in and remind the client to insist on following established protocols.

Design and construction criteria, applicable codes and standards: Define the design and construction standards by reference. Remember, an industry standard is usually the lowest acceptable level of quality. Each criterion should have a quality plan attached. Rarely changes during the course of a project.

Permits: A list of regulatory agencies, including who is responsible for permit payment and acquisition.

Lessons learned: Every project yields a lesson learned. Memorize them as regularly as possible to ensure future successful outcomes.

While a management plan template represents a good start toward a successful outcome, a properly prepared, well-thought-out work plan is an essential ingredient in the delivery of a successful project. Much of the work plan material can be transposed directly from the project proposal, agreement and/or plans and specifications, but merely furnishing copies of the project agreement to the project team does not a proper work plan make.

The project manager should arrange, assemble and, in most cases, summarize the content of the project agreement so that it can be easily read and understood by all members of the project team. Occasionally, I will include the contract as an attachment to the work plan. Work plan revisions and supplements should be issued to all project staff.

The project work plan is a living document that should reflect changes in scope, budget, schedule or procedure as they occur.

For my part, I try to include at least one lesson learned in every section of my work plan. Indeed, there are lessons embedded in the paragraphs above. I included them to encourage you to establish your own Lesson Learned Library and should you have a lesson of your own, please feel free to share.

Projects managed using lessons learned have a better chance of finishing with successful outcomes, and when they do, I usually get a good night’s sleep.

Gregory J. Offner is vice president of DMJM H+N – AECOM in Arlington, Va. He is a member of the Correctional News Editorial Advisory Board.

PrintPrint EmailEmail