Bill Andersen never thought of himself as an expert. If you asked him what he did for a living, he probably would have shrugged his shoulders and given you a simple answer.
I work on projects.
That answer included years of experience with successful project execution. Experience working with inspection, supplier quality, and supplier data. Bill had worked on petrochemical facility, pipeline, processing plant, refinery expansion, and many other projects. He spent over 70,000 hours (about 35 full time years) in fabrication shops and project offices, and at construction sites across North America.
Over the years, Bill developed a solid reputation. Not because the projects he worked on finished ahead of schedule or under budget. Projects rarely work that way. His reputation came from something far less noticeable.
His projects seemed to have fewer surprises. And for all surprises, he had solutions. It seemed unremarkable. Predictable.
The supplier data was usually complete and correct, including Manufacturing Record Books (MRBs). Commissioning teams spent less time searching for information and more time preparing facilities for handover and startup. Integrity and operations & maintenance (O&M) personnel inherited useful records.
Except Bill, nobody paid attention to this. Why pay attention to what works? That was the problem.
Everyone assumed Bill simply knew what to do. They assumed he had a knack for spotting issues before they became embarrassing and expensive.
He didn’t. Bill had learned most of what he knew the hard way – through experience.
Early in his career, he experienced projects struggling with missing supplier data and incomplete MRBs that caused delays and rework. He saw commissioning teams spend weeks waiting for records that should have been available. He watched integrity and O&M personnel inherit facilities without all the information needed for reliability and safety.
Bill never forgot those lessons.
Early on, he had noticed a pattern. Different projects, different suppliers, different companies – all with remarkably similar problems.
Somebody knew what data would be needed. But nobody wrote it down.
Somebody knew which supplier deliverables could delay startup. But nobody documented the expectation.
The problems were rarely caused by incompetence. The problems were usually caused by assumptions. Bill never forgot that.
If a Purchase Order (PO) was missing critical data requirements, he knew the risk because he had seen the consequences before. If a project team assumed a supplier understood an expectation that was not communicated, Bill asked the right questions before expensive mistakes were made.
Over time, people stopped noticing what he was doing. They simply accepted that projects ran better with Bill as a team member. Then, finally, Bill retired.
There was a retirement lunch with handshakes, a plaque, gratitude, and promises to stay in touch. Colleagues shared stories and remembered the good old days when projects used paper. Management thanked him for his years of service. Then Bill sailed off into retirement.
Bill wasn’t worried about future projects. Why would he?
The organization still had experienced project managers, team leads, engineers, supply chain specialists, and construction personnel. It had completed dozens of major projects using procedures and standards that appeared satisfactory.
Everything Bill knew seemed obvious. Like common sense. Why wouldn’t they figure it out?
The very next week, a new project started.
At first, nothing seemed different. Engineering progressed. Suppliers were selected and POs were issued. Progress meetings were held. Equipment and materials were produced and delivered. Supplier data was provided.
Then the emails and phone calls started.
Commissioning needed information that suppliers had never submitted. Integrity and O&M records could not be located.
Some data was incomplete, incorrect, or had never been requested in the first place. Some MRBs were thousands of pages long, yet the critical two-page data report could not be found.
The project team responded the way project teams always do. Meetings were scheduled. Suppliers were contacted. Action items were assigned. Overtime was approved.
In some cases, data deficiencies were not identified until long after project close out, when the opportunity for correction had already passed.
The project team included talented engineers who were comfortable using modern software, search engines, and artificial intelligence (AI) tools. They searched for answers and reviewed available documentation. The problem was not a lack of intelligence or technology. The problem was that critical project knowledge had never been effectively transferred.
Some knowledge existed in procedures, markups, emails, and lessons learned. Other knowledge existed only in the memories of experienced personnel like Bill. Nobody had documented which supplier deliverables routinely caused delays, which records integrity and O&M personnel would eventually need, or which questions should be asked before POs were awarded.
AI can help people find information and answer questions. However, it cannot recover information that was never captured, documented, or transferred. Even the most advanced AI tools are limited by the information available to them.
Bill’s value was not simply knowing the answers.
His value was knowing which questions to ask before expensive mistakes were made.
Eventually, the project was completed, but only after significant cost overruns. Startup was significantly delayed while waiting for missing supplier records.
In the end, the project team spent weeks chasing supplier data that should have been identified before the POs were issued. Hundreds of hours were consumed locating, reviewing, revising, and resubmitting supplier data that should have been available much sooner. Nobody considered it a business failure because sometimes, that’s just how projects work. Then, everyone moved on to the next project.
That was another part of the problem. The additional cost and effort were accepted as normal.
When the dust settled, someone finally asked the question: Why didn’t we see this coming?
The answer turned out to be surprisingly simple.
The organization realized that many of the best practices Bill used had never been formally captured, shared, or transferred. The questions he always asked before POs were awarded were not asked. The mark ups he made for supplier data reviews were not made. The lessons Bill learned from previous projects were not recalled by anyone.
Some of it existed in procedures, markups, notes, and project files. Much of it, however, still existed in one place: Bill’s memory. But Bill was already sailing away and chasing sunsets.
The organization had not simply lost an employee. It had lost decades of accumulated project knowledge – what to do, what not to do, and why.
And this is where many organizations find themselves today.
Knowledgeable personnel quietly prevent problems before they occur. They know which supplier documents matter. They understand which requirements must be specified. They recognize tell-tale warning signs because they have seen them before.
Unfortunately, experience is not the same thing as knowledge transfer. Bill’s knowledge was never transferred to other personnel.
Knowledge transfer allows the experience and knowledge gained by Bill to survive after people like him leave.
New hires, personnel starting their careers, and individuals transitioning into new roles often bring enthusiasm, intelligence, and fresh perspectives. The challenge is not their capability. It is unfair to expect them to immediately replace decades of accumulated project experience. Without effective knowledge transfer, many of the lessons previously learned by experienced personnel must be relearned through avoidable delays, trial and error, and costly rework.
When organizations fail to capture and document critical knowledge, they unknowingly create a ticking countdown clock. The risk remains hidden until a reorganization removes that knowledge.
Until the same problems return, suddenly.
The same lessons are relearned, but unfortunately, not quickly.
Not because people are doing anything wrong.
Because the knowledge they need was never transferred.
Somebody knew what information would be needed. But nobody formally captured and transferred the knowledge.
Which brings us back to Bill. Bill Andersen is a fictitious person.
Yet, if you’ve spent enough time working on projects, you’ve probably met someone just like him (or her).
They work in different companies under various names. Sometimes as a project manager, supply chain manager, team lead, or Supplier Quality Surveillance (SQS) coordinator. These people quietly prevent problems before they happen. Too often they receive little recognition because nobody sees the problems that they prevent unless the problems reoccur.
In this case, Bill’s experiences are drawn largely from the career of Roy O. Christensen.
Roy began his career as a welder, Non-destructive Examination (NDE) technician, and welding inspector. For the last 25 years he has worked as an SQS coordinator and technical writer for major energy projects.
Throughout his career, Roy has repeatedly observed the same pattern. Projects encountered preventable challenges because critical knowledge had never been documented, transferred, or preserved. Sometimes the problems appeared differently, but the underlying cause is often the same.
Bill knew. But too much of what he knew left with him.
That realization ultimately led Roy to establish the Knowledge Transfer (KT) Project. It was created to capture, preserve, and transfer critical project knowledge before it disappears. Its guidelines and services are based on decades of project experience with quality surveillance, supplier data, and technical documentation.
Knowledge transfer is not a project activity; it is a project asset.
Is the next Bill Andersen working somewhere in your organization?
Will their knowledge disappear when they do?
Does your organization rely on project knowledge that has never been documented? If so, now may be the time to determine whether that knowledge is being effectively captured and transferred.
Somebody in your organization probably already knows.
The question is whether that knowledge will still be available when you need it most.
If your project needs knowledge transfer resources, contact the KT Project.
Transfer the knowledge before it is too late.
Related: The Project Time Bomb: Supplier Data – Will a ticking time bomb wreak havoc and scuttle your project success?
Figures
- The Sunset of Project Knowledge. Derek Rosner. Rendered using ChatGPT 5.5.
About the Author
Roy O. Christensen founded the KT Project to save organizations significant money and time by providing key resources to leverage expert knowledge transfer for successful project execution.
Other articles by Roy about career and project success are available here.
Contact
Roy O. Christensen
Email: [email protected]
Telephone: +1 403 703-2686
