November 1, 2025 • 64 mins
What does it take to keep billion-dollar projects running on the latest version?
Document Control expert Leanne Allgaier joins Orion Matthews to unpack how great document management saves time, money, and even lives across the world’s largest industrial projects.
In this episode of The Major Project Podcast, Orion Matthews sits down with Leanne Allgaier—a veteran document control leader who’s managed major assets from gas fields to refineries for companies like BP and Phillips 66.
They explore why Document Control—the discipline ensuring every engineer, contractor, and regulator has the right information at the right time—is one of the most underrated functions in billion-dollar project delivery.
Leanne breaks down:
- Why document control is not clerical work, but a technical, process-driven function critical to cost, schedule, quality, and safety.
- How to structure doc control under Project Services, define lifecycles, and establish version control that prevents costly errors.
- The dangers of “ready, fire, aim” project starts where doc control is added too late—and how early planning avoids rework and risk.
- How to scale document teams across project phases and transition to operations.
- Practical leadership lessons: earning compliance, handling pressure, and using humor and empathy to build trust.
- The role of checklists, procedures, and “one source of truth” in maintaining integrity under deadline pressure.
- How AI tools like OpenText and M-Files are already transforming search, reporting, and document insight—accelerating, not replacing, skilled document controllers.
From managing pipelines and refineries to mentoring the next generation of document controllers, Leanne shows how a discipline often overlooked at kickoff becomes the backbone of safe, efficient, and compliant mega-projects.
🎧 You’ll Learn- Why document control belongs in project pre-planning—not after execution starts.
- The real ROI of good doc control (cost, schedule, quality, and risk).
- How to build scalable document control teams and choose the right tools.
- Leadership strategies for compliance, clarity, and collaboration.
- How AI and automation are reshaping the future of document management.
Mark as Played
Transcript
Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
(00:00):
Welcome to the Major Project podcast, your inside.
Look at the high stakes world of billion dollar projects.
Welcome to the Major Project podcast.
I'm your host, Orion Matthews.
And with me today to talk about document control is Leanne Gyer.
She's worked on major billion dollar assets on the owner side from gas fields to pipelines to refineries.
(00:25):
Leanne, welcome to the podcast.
Thank you.
Thank you very much.
Glad to be here and we're glad to have you.
And maybe before we get started and really jumping in on doc control, I think a lot of people here might not even know what that is.
And if that's the case, you're in the right place.
We're gonna take it easy and start from a 1 0 1.
(00:47):
But before we get into that, Leanne, maybe you can tell us a little bit about how you got started in the space kind of a bit of your career path, maybe some of the projects that you've touched, and just kind of catch us up and get to know you a little bit.
Okay.
Well, it's, it's kind of a circuitous route here, but, um, how I got into this space, uh, before I did in the late nineties, I was working in newspaper and magazine production business.
(01:15):
And this was the point at which Printed media was making a shift from being typeset to being produced via desktop publishing programs on computers at the time Apple MAC twos to be specific.
And in 1998, I wanted to move back to Alaska and a friend got me a job in an IT consulting firm as a technical writer producing user guides for some of the software the company wrote or implemented for their oil and gas and utility clients.
(01:46):
And this is actually a natural progression.
Being in the graphics and publishing industry to this because I had already been producing user guides for the software we were using and the graphics I was creating in desktop publishing.
Got into technical writing and then from technical writing, I graduated to n to mapping out the business processes that take place in this industries, in the industries that are served by this IT consulting firm, particularly in document control.
(02:19):
And then after a few years and a few projects in this framework and those projects included things for BP up the north slope.
It also included the railroad Alaska housing that those sort of clients really kind of across the board.
Then I eventually found my niche as someone who could implement doc control programs.
(02:42):
From both a system and a program perspective and set up the maintenance of both once the software was implemented.
Awesome.
And then also it sounds like you were in the lower 48 as well major way to working on a few refineries, if I recall correctly.
Is that right? Um, yes, I did.
(03:02):
I worked, um, at the BP Cherry Point Refinery in, um, Blaine, Washington.
And then I also was a Phillips 66 employee for a while.
They have a great group of people at the refinery in Ferndale, Washington.
Awesome.
Thanks for that intro, Leanne, and thank you for coming on the pod.
(03:24):
Real quick just to frame it up document control is this crucial.
But often overlooked discipline on major billion dollar projects.
Mm-hmm.
Especially in the engineering construction infrastructure phase.
And I am really curious for you to unpack, I think part of why it's overlooked is that it's maybe misunderstood.
(03:50):
Perhaps you could unpack it for us from a 1 0 1 level.
What is it, how is it different from maybe just clerical work? Like what is doc control? Doc control when it's done correctly, um, is to make sure that the most updated information is easily acceptable by the correct audience at any moment.
(04:17):
And it should come from a, an agreed upon single source of truth.
Those goals are simply stated, but maybe not so easy to, to achieve.
And you're correct.
A lot of organizations mistakenly think that doc control should fall under the duties of an admin staff, but it shouldn't.
In document control, you really have to focus on the lifecycle of a document and how to move it through its various stages and take appropriate actions.
(04:45):
So, for example piping and instrumentation drawing, that's an engineering document in a typical oil and gas project.
This document is designed and generated to reflect conditions in the field, which requires cycles of reviews and changes and approvals.
(05:05):
And all of this has to be monitored and recorded just to get a facility built.
That's just to get it built.
But as the facility operates and and conditions in the field change over the years, this document again must be updated, verified again, go through the review and approval process numerous times.
(05:26):
Alright? So multiply this by the thousands of other engineering documents like this at a, um, refinery or an oil field and the decades or even centuries that a field is operated in, right? And then, so you have innumerable versions of this document to monitor and track, multiply this by the thousands of other engineering documents like this and the decades or even centuries.
(05:54):
That a field is operated and then you're gonna have an enumerable version of this document to monitor and track.
And so an admin already has enough, they already have a full-time job managing other type of documents that don't have to have this sort of, this level of control and not to mention all their other duties.
Um, this task is really best left to specify dock controllers that understand the lifecycle and how to manage it.
(06:24):
It makes a lot of sense.
So then, where does doc control sit? Like for you as an expert in the space, what's your optimal, uh, reporting structure for doc control? Um, and maybe you'd have to break that up into like an operating field versus a a major capital project for us.
(06:45):
But where do you wanna, where do you think doc control should be? My, most of my experiences was on the project side and, uh, oh, well, it, and I do have some experience on the operations side, so, it, it varies by organization and sometimes in some organizations it sits under it or possibly engineering.
(07:07):
Where I've seen it, uh, be most effective in a project structure is to have it sit under project services and then, uh, reporting directly to the project services manager.
This gives the document control personnel access to the folks who are involved in the documents lifecycle.
(07:28):
And they can report to the project services manager who can then summarize updates to the project director.
When I worked on the operations side.
I found that a lot of times this was under, say, the pipeline technical authority.
So really the discipline that you're doing the document control under there were folks that were doing health and safety that were in the health and safety department.
(07:57):
I was generally looking at regulatory documents for the pipeline.
And those sit under, that sat under the pipeline technical authority, which made a lot of sense because again, they're involved in decisions about documents and a lot of times this particular discipline also had a lot of responsibilities to regulatory agencies, specifically the Department of Transportation.
(08:24):
So it made sense for the technical authority in that situation to be over for me to report to that individual in that position.
So on doc control, you sort of talked about a couple different scopes there.
Like what are the typical areas that you apply doc control to? Perhaps if you're on a major project, is it every document for the project? Is there some sort of boundary condition? Are you just focusing on engineering documents? Like how do you narrow your scope so that people can have little word docs on a SharePoint file and you're not grabbing those and putting 'em under your processes? It really comes down to what in a project needs to be controlled from a lifecycle.
(09:13):
Example.
And it really, when we, it needs to have the kind of control and, and really it comes down to version control revisions of a document.
Engineering, obviously you have every pl, you know, you have places on the document where you list when it was updated in which revision.
(09:33):
This is of course important in engineering because you're building things or modifying them.
Having the most having the most current version is important and so that needs to be controlled.
That should be in the document management system For project documents, you're making policy, you have procedures.
Again, you have version control on these.
(09:53):
That also needs to be in the document control system because you are formalizing when it is being updated and when it's being updated.
You're also doing a formal distribution of these, of this document to let everybody who's needs to know this is the latest revision and to make sure that that's getting to the proper people.
(10:16):
So it really comes down to what has to have revision control meeting minutes.
Don't need to have revision control.
They have a, their static content that happened on a static date and they can reside on a a SharePoint or a shared drive with, minimal risk.
And so how do you explain that to people and sort of set up doc control Well, or how have you seen it done well in the past? So imagine you're, you are, we're doing a major capital project together again and mm-hmm.
(10:54):
Starting doc control on a major project blank slate.
What are the first steps to establishing this good doc control? Okay.
Doc control should really be part of the pre-planning stages in a, in a project because it allows your document controllers to understand what documents will be managed.
(11:18):
And to put in the proper processes and systems in place prior to the deluge of documents that are going to inevitably follow during planning and define and execute.
I've been on projects where this was not the case.
I, the doc control was introduced well into execute at this stage.
(11:42):
We call this ready, fire, aim, the ready, fire, aim approach because you're creating a structure for these, for your program and simultaneously managing a lot of documents.
And under a time crutch, it is not ideal.
It introduces risk and in the end it costs way more than if you would've introduced it early on.
(12:06):
So again the stage is really pre-planning because again, you know the type of documents, you know who needs to access.
And how to set up your proce a better idea of your processes and tools that you need to set up.
First and foremost, I'd look at the type of documents that are to be managed.
(12:27):
If it involves engineering documents, I need to consider how am I going to manage concurrent engineering? Something I'll talk about later if it is a project that doesn't require engineering, that gives me more options in terms of the processes and or systems I can use to manage them.
The next thing I need to know is who needs to have access to these documents? Are they people within my organization and behind the firewall that I can easily give access to a shared repository? Or are some folks say contractors supporting from outside the organization and I have to give some thought to how they can securely access and possibly edit documents.
(13:09):
My organization's, IT department is certainly gonna have a lot of input on how this needs to be set up.
So then armed with this information, I can next look at my options for a tool.
Okay.
And this might be something I have very little control over.
If this is a fairly new organization or project, my only option might be sharing documents via a shared network drive or SharePoint.
(13:36):
There's very little I can automate with this kind of setup.
So it will be very process heavy with a lot of manual tasks and it's gonna require more people.
Ideally, your organization will have some sort of enterprise document manage sys management system.
Some I've worked with in the past that I can name off the top of my head are Documentum, which is now owned by, uh, OpenText AEX pims Omega-3 65.
(14:04):
Other assorted programs, you're gonna be ahead of the game in this situation if you do have access to one of this type of tool, because you can determine your processes for the documents, right? For example, wiring documents will be reviewed by engineer A, engineer B, and the project manager with the engineering director providing final soft the engineering director providing final sign off.
(14:31):
And then you can leverage the power of your system to automate these processes as much as possible.
And all the while, this is very important.
You're making these decisions, agreeing upon processes, then you write them down in a procedure and you train your users well.
So let's talk for a second because I wonder if there's like leadership on this pod.
(14:54):
And they've gotten to this point and they're like, oh, okay.
I'm gonna make a list of those three things that Leanne just said.
Documentum, pims.
And, uh, we'll pick one and then we're gonna have our dock control.
And sometimes I like to tell people that the runner doesn't the shoe doesn't make the runner.
So if you're thinking about getting in shape and you're at a Nike store and you're trying to figure out what your best shoe is so that you can become super great at running, you're kind of already on the wrong track.
(15:23):
Uh, having good shoes is a great part of running.
But sometimes I think people forget all the other pieces that go into that.
And I would love to kind of hear maybe from you a little bit about the non tool tips.
You kind of touched on it there, but maybe reinforce my message or tell me I'm wrong.
And if this is a case where you just gotta get a good tool in place, maybe that's all you need.
(15:49):
Do you have any thoughts on that one? Oh, yeah.
Um, I think it was you in a conversation that actually said the tool is only as good as the discipline of its operators.
And that's very true.
And that's why I do emphasize the procedure, because when you're writing down procedures, you e you know it's important be to emphasize to your users and your stakeholders that this is the agreed upon.
(16:18):
This is the agreed upon playbook.
This is what ensures that we're all singing from the same sheet of music.
I'm sure there's more analogies, but I'm gonna try to stop here.
And the procedures could also list the consequences of not following the processes.
Mm-hmm.
So when you do this upfront work, you give your dog controllers the guidance they need when they are considering taking a shortcut.
(16:45):
And this usually involves a time crunch.
I need to get this out.
I don't wanna follow these procedures.
Or they might be pressured by somebody who wants them to take a shortcut.
I, you know, I don't have time for this.
Just give me this copy, or I'm gonna use this copy.
That's not the latest.
This lays it out for everybody.
(17:07):
And when you're faced, when your dock controllers are faced with that.
Those sort of dilemmas, they have something they can refer to.
This is our process.
If we don't follow this process, we are at risk of A, B and C.
And it's not, you know, I don't want to come from a point of rigidness, right.
(17:29):
Rules and processes are ever evolving and they're gonna change.
But by putting them down in a controlled document, like a procedure, you ensure that these changes happen a fo in a formalized manner and are communicated to the necessary users.
Okay.
So you mentioned something, I don't wanna put you on the spot, but I am super curious in that procedure, you mentioned consequences.
(17:52):
Uh, compliance with dock control is a difficult area in organizations.
What kind of carrot and sticks do you employ that have been useful, uh, in getting that compliance that you need? You really did put me on the spot, but it's carrot and stick.
(18:15):
And this is, I think it's a delicate position.
You know, you're, you're dealing with somebody's, we're losing money.
We're this, we're this, and at that point you have to, humor helps, but also really what it is, is saying, look, I'm not here to make your life more difficult and make every, the person who's maybe challenging you.
(18:39):
It is super important to say we're on the same team.
I'm not making up these rules because I don't have anything better to do and I wanna ruin your day.
It's best, when you trust your coworkers and they trust you, but sometimes it takes just a little bit more work.
And really what what it is, is understanding, I'm helping you.
(19:03):
We're on the same team, let's work together.
That's really that's really how it works for me.
Let's work together and, and to make them understand, hey, this doesn't get done correctly.
There's not only costs, but there's risk.
If something is built incorrectly, and it's not up to specs, it could cause injury to people, you know, and, and without getting dramatic or, you know, making a catastrophe, just laying things out and say, and approach it from the perspective of how can you know, let's work this out together.
(19:42):
That my strategy.
Well, so that's a, yeah, that's a that's a really great tie in into a question that I think a lot of folks may be thinking about doing a billion dollar project, and doc controls not number one on their list of things to care about.
And I think that is probably because there might be misunderstandings about the return on investment.
Mm-hmm.
So a lot of people see doc control just as an admin function, something they need to have, but not necessarily something that's critical because it's not really hitting the key financial levers of the project, like cost, schedule, risk, quality, you just mentioned risk, but maybe you can, can, could you help us make a case mm-hmm.
(20:21):
To keep putting you on the spot here to a project director about why they even should care about doc control and make what is probably needing to be a substantial investment for the project's life to have it done right.
Mm-hmm.
Absolutely.
Um, document control has a direct effect on all of this costs schedule, quality, risk, and the consequences can be highly visible when the document control practices aren't followed.
(20:51):
Distributing documents that are outdated.
Like I just mentioned, again, could co, could impact the cost if something's not built to proper specifications and it has to be rebuilt, this affects both costs and schedule.
You've just built a module, but you didn't build it correctly.
We have to, you know, now we're behind on the schedule and we're paying twice to have the same thing done.
(21:15):
And then if an outdated drawing used doesn't say, reflect the bolts made from the required material to create, um, a facility or a module, your quality is affected.
And that's where you're introducing risk, that a structure or piece of equipment could fail and you could involve injury or even death, even death to field personnel that said, I think it's fair to say that Doc Control really delivers your return on investment, even though it may not be immediately obvious to you.
(21:48):
Well, maybe we can unpack the investment a little.
'cause I'm gonna keep putting you on the spot on these ones.
But, uh, let's say that we're doing a, you know, a $5 billion build and we're gonna make, let's say, a really cool data center or something like that.
Or we can switch it up into a refinery if that's more your, your style.
But what size, and I know you can't answer this fully, but like, what does a good built out doc control, you know, team look like? Like what are some of the kind of key things that someone might need to be thinking about as they're deciding? Okay.
(22:22):
Those, those ROI things we wanna get serious about this.
What does serious look like? What's good? So, like, what does, what does good document control look like? Is that what you're saying? How much do I need to spend to do this? Right.
Like in terms and in terms of head count, am I setting up a team of three for a billion dollar project or is it a team of 25? Like what is the scale of the footprint of dock control typically that you've seen that's been kind of effective? Well, it's, it, you know, it has a lot of, it depends on a lot of different things.
(23:00):
Where are you in the, like I said before, if you've, you know, your tool is say a shared file structure, then you're gonna need a lot of people because you have a lot of, you have a lot of manual processes also at the be, you know, I was recently on a project where, a lot of things were being built in Canada and Malaysia, so you have an enormous amount of documents that are being update, they're being submitted, they're being reviewed, they're being returned, updated, a lot of in and out, a lot of in and out.
(23:37):
And so when that is the case, you have to have a lot of people to address that volume.
But then when things are built, then I'm talking the project side of things, then your doc control team can then be reduced because you, as the project comes closer to an end, you're not dealing with that volume of documents.
(24:04):
And so you need flexibility of course.
And be able to pivot when you need to add or you know, remove people.
But it's also, you know, you, you have options here.
'cause a lot of times when something is that is coming and it's being produced and is now operational, some of those document controllers can get, can then because upon I'm leaving that in, that was too good.
(24:32):
That'll be in the loopers role.
Yeah.
When you get to the point where your, these modules or structures are operational, you can take a couple of those dock controllers and put them over on the operations side now, right? Because you've got your standard operating procedures, you have all of your.
(24:54):
Equipment and engineering drawings that are referenced on the operation side and possibly being updated if things are found in the field that are not accurately reflected on those documents.
So it can expand and contract depending on the phase that you are in in a project or in a the building of a pipeline and the operations of a pipeline.
(25:21):
Does that make sense? Yeah, it does.
And I think what I'm hearing from you is that you have to make an upfront investment in dock control first to establish processes.
That's probably a one-time capital project charge.
Once you get that, you sort of run into either, if it's, if it's a, if we're talking about sort of a greenfield project, you're gonna have a team upfront.
(25:48):
Mm-hmm.
Probably starting in define where you wanna have several folks available for the influx, and then as the project gets towards handover or you're, you're closing down, you can sort of balance it.
Do, do people use consultants a lot for that or, uh, yes.
To kind of balance the, yeah, absolutely.
(26:09):
Okay.
That makes a lot of sense.
And then all right, let's switch it up.
'cause we just talked about a new project, but let's say that you are a new project director and you're coming into a midway through.
How do you know if you've got good doc control versus bad? What are some clues to look for? Uh, or maybe you're just an engineer and you're like, this is not working for me.
(26:34):
I don't think this is good.
Like, what are how do you sort of clue in that you have work to do on the doc control space? Um, this goes.
When we talked about setting up a doc control and why you need to, and if you've got good document control, you don't hear a lot of noise.
(26:56):
The most updated information is easily accessible by the correct audience at the correct time with very little fuss, right? The more noise you have, the more it is an indicator that document control is not going in a great direction.
So noise will come in the form of people complaining that they can't find a document or a type of.
(27:24):
So then this is where you, to mitigate this, you want to work with the user that's having the issue, user or users.
And when you have users, then you're saying, Hey, this is happening more than once.
You wanna verify that the documents in question are stored in the proper hierarchy, and they contain the correct attributes so that when people are searching for a document and they put in the required metadata, it's coming up, and then troubleshoot and find out why that's not happening.
(27:56):
Sometimes it's your system, sometimes it's operator error.
You know, your folks don't know how to, don't know the correct metadata, um, the correct attributes to find the documents they need.
Another example of noise, complaint of noise are complaints about lack of access to a document.
(28:19):
So if people can't get to a SharePoint or a web interface, they've been given a link to, this is an example where, you know, to, to mitigate this, we have to make sure that everyone is aligned on who is supposed to be given access and updating any permissions if necessary.
(28:39):
And this, it can happen in a project because, it's projects are very dynamic.
Maybe you have a set of contractors, they didn't work out.
You bring in another set of contractors.
They're external, the system, they need to have access.
And so then this is where you again, get aligned and make sure that these people have the process.
(29:00):
Proper access and noise will be even louder and have more of an impact when outdated drawings are used to build something that is unusable because it's not built to the proper specifications and will cost more time and money to reveal, to rebuild.
And so this is where your project director is really gonna notice.
(29:23):
That's when it really rises to the surface.
And you're gonna have to address this by reviewing your pro your procedures with your users to ensure that they are following the processes for assuring the most updated version revisions.
And verify that everyone's pulling from the, the agreed upon single source of truth and not from an outdated folder, they have squirreled away on their C drive.
(29:49):
Uh, that makes a lot of sense.
You know, I like to say in the tech space we have something called the principle of least privilege, which means you wanna give people the least amount of access they need to do their job.
And that's really helpful 'cause it reduces risk.
But I believe there's a missing phrase in that, which is you need to couple the principle of least privilege with a principle of speedy access and the more you locked down people's privileges to protect an organization.
(30:22):
There should be a, a commensurate metric of how quickly you can issue access.
Because what I see a lot of orgs do is they're great at locking things down and then they get worse at granting access at the same time.
And that is a recipe, in my opinion, for disaster within organizations.
Um, 'cause it leads to a lot of frustrated people.
(30:43):
You can't get the information you need in the time you need it.
Or like you were saying with contractors, they can't gain access to systems.
Exactly.
Um, you make a great point about, you know, making your, your security permissions access as nimble as your, and dynamic as your workforce because you know, you'll, yes, you've identified this person was legit, they need access, but then to have, to make them wait.
(31:14):
Again, it is just frustrating on all sides and is very inefficient.
Well, and just to close the book a little bit on like what does good, uh, doc control, if I'm this project director looking at it, and these are really great tips.
You're gonna hear some noise, you're going to potentially build the wrong thing, that's like your red flag.
Or maybe if you're taking over a project, you would look back and sort of see, oh, okay, like our people are not building correctly.
(31:40):
There might also be like permitting delays and things like that.
I imagine that you might see Is there also, let's just say I just took over a project last week and I'm drafting my email to sort out doc control, so I'm gonna ask someone to kind of look through and see if there's any things like that.
Maybe I'm gonna survey the engineers and kind of see how they're feeling about things.
(32:01):
Hopefully I'm thinking about access speed.
Maybe I'd ask a question about that.
Is there a set of.
Documents you might, and this, this might tie into a question kind of about assurance processes, but like what also would you be looking for if you're, if you wanted, you know, as a casual sort of leader, wanted to audit quickly the doc control.
(32:22):
So is it like, hey, I need the compendium, do Wikipedia of our organization and it should roughly be like a one page, like here's the naming convention of things, here's the, here's a couple process workflows.
Like what do you think are some critical sort of key foundational documents that would just, should kind of be at the ready if they're even already for doc control? Um, I find that work process flows are very valuable to have and to be able to show.
(32:55):
Again, this is this, I mean, you are mapping your processes of.
How you are handling a document and you're interacting with the system.
And because a lot of times people don't understand that documents, different documents under have a different life cycle or go through different reviewers, you have to it.
(33:19):
It's an easy way to illustrate that.
If you have a project document, it is gonna go through this lifecycle.
This is how it'll be handled.
And if you have an engineering document, this is how it's going to be handled.
This is the lifecycle.
And so that's sort of document at the ready, um, has proved invaluable in the past for helping management understand what the people in document control are doing, why you have as many people as you do and how.
(33:53):
How things are getting done.
So that would be definitely my number one thing that I would have at the ready to help people understand the process.
And so, just to flip this around, 'cause I, I think it's a sort of an interesting area to dig a little bit on.
So I've been talking from the perspective of the leadership, but if you take a look at it from a fellow doc control manager, what advice would you give them? If there's a leadership change on a project or you feel like things aren't going well, like what have been some tips that you could give to fellow doc controllers about how to sort of share or affect change within an organization during states of transition or other times you need to kind of rally and, and um, gain control over your function better? I think that the best way to do that.
(34:47):
Again, we, we need to have graphics.
I mean, pictures worth a thousand words.
And I have had an experience in the past where I was trying to explain something and nobody was getting it.
And finally when another person and I sat down and put it in a graphic format, and I think it was mostly process, but to say, this is where we're at, and this is what happens.
(35:14):
If we make this change, this will happen.
And it has to be something that's easily understood and visual.
What do they say? Like, to management only has the bandwidth for like three things or three topics.
To really present something, don't do a, uh, what do they say, PowerPoint to death or whatever, death by PowerPoint.
(35:39):
Do, do that.
But really just succinct.
This is, when this happens, this problem is created.
If we change this to this, it will solve that problem.
And our world will look like this, and your metrics will look like this.
I think that's the tip I would give anybody who's trying to make who's trying to work with management to make things more efficient.
(36:05):
That, that's interesting.
It, it leverages your background in graphic design.
I'm a big form over function guy for technical disciplines.
I think that communication is usually at the heart of a lot of problems particularly when you're deep in a technical discipline like doc control and so to, to sort of bring everyone together and create that meeting of the minds.
(36:25):
Sometimes a picture or a simplified way of expressing things can make all the difference, and it's often overlooked because it's not really technically doing anything different.
You're still advocating for the same things, but somehow.
Good design can make all the difference in how your work gets done.
(36:46):
It's amazing.
No doubt.
Well, so shifting it a little bit, kind of sticking with the dock controller perspective, let's say you take over and you've got these, big projects are executed across multiple vendors, partners, divisions, owners.
How important is it for those partners to have good dock control? It's imperative for smooth and efficient running of a project because if they are, if they're dropping the ball, so to speak, you, you're gonna get noise.
(37:24):
If you, and with noise, you are going to be wasting a lot of time and researching.
And mitigating problems created.
Say if they're distributing outdated revisions of a document, you're on the side that has to track that down.
I'm, you know, sometimes I feel like a forensic scientist on some of the projects I've, I've worked on and, and finding out, so how something happened.
(37:50):
So that's time that you don't need to do, best time.
You don't have to figure out a problem created by somebody else.
And if they haven't, I've also been in situations where vendor vendors have not properly tracked what they have sent to me, and then they rely on me to run reports for them to say, this is what you sent me.
(38:13):
It's imperative if you want things to run smoothly and efficiently otherwise you're gonna get noise.
How do you, when you're picking your vendors, if you're sort of intersecting this at the pre, pre uh, sort of pre-planning stage and you're looking at different people, how do you, do they write it into the contracts oftentimes with vendors? Does doc control have a little carve out? Like how do you, do you add that to your sort of RFIs? Like what do you think is a good strategy for people to make sure that their vendors do have good doc control? 'cause in my experience, uh, that's not always the case across different groups.
(38:53):
You know, and I, I don't know that, that you have that kind of control that you've can be that prescriptive.
And really what drives a lot of decisions regarding vendor vendors and vendor bids? Obviously, cost of course comes in, pretty heavily, but I would say that most of the time it's reputation and Hmm.
(39:20):
You know, particularly, I mean, here in Alaska, you know, we, people know all the players essentially.
And so when you know which people are working at, which organizations, you've worked with them in the past, and you say, oh, we, okay, I worked with this organization and I, I had really good experience with them and not a lot of noise.
(39:42):
And, and you become also familiar with the programs that they use, you know, you'll know, oh, okay, this organization uses Aex and, you know, that will weigh in, certainly if they'll talk to document control when they're doing these RF Qs, you can weigh in on that sort of thing and say, Hey, yeah, AEX, we've worked with it.
(40:04):
We know how to work with it.
We've worked with, you know, they did a good job on such and such a project.
So that's really the only sort of input you have.
Not really control, but, um, input and insight, uh, like so many things in our space, reputation seems to be a really big way that you carry the day when you're picking your vendors and setting up a major project at really interesting that way.
(40:31):
Would you say, just to touch back on tools, since you said the word Aconex, I can kind of open up the floor.
If you have a system that would, you, would you rather have SharePoint slash no system basically, or a poorly implemented Documentum or Aex, like what's your.
(40:52):
Choice, how easy is it to sort of dig out of a badly implemented system? And kind of following on that, like is it more, is it like a badly implemented SAP project or is it like a badly implemented sort of, I don't know, P six thing where you can just sort of wipe out and start over? My answer on this would be that I would want to leverage as much of the bad system as I could and you know, you say it's badly implemented, so I would imagine that it does not do everything it's supposed to do, but any automation that I can leverage will put me in a better position than having to do everything manually.
(41:39):
I mean, and that's, you know, if you can find your system is going to consistently.
Perform on certain tasks that you can rely on and that it's not, you know, something you can't replicate or whatever.
But if you can find some things that it will do, I think that it would be better to leverage that.
(41:59):
Because when you are trying to circulate a document to 12 different reviewers and you have to manually set that up or manually distribute it, it's the, the time is overwhelming, particularly when you talk about an enormous amount of documents.
(42:20):
And I've been in situations where we started out with only, uh, a very manual system, just a, shared files on a shared drive.
Yeah.
And while it was feasible at the beginning of the project when you had less than 200 documents, you were fine.
(42:42):
But it quickly grew outta control.
And it also pro created problems later when we migrated to a system and we didn't have data standardization or integrity document numbers that were inconsistent.
That sort of thing that we, that really, really bit us in the bu.
(43:03):
So I would say anything that you can do to put your information in something that is standardized and automated.
Even if you have to wrap a lot of processes around that, you're still gonna be ahead of the game than if you just go manual because you want the control because it'll just get out of hand too quickly.
(43:25):
Well, you just mentioned standardized like names, right? Doc control numbers, I assume like function, discipline.
Is there a global standard for that? Like how do you figure out what your doc control naming standard is and implement that properly? You know, it's, uh, it, again, it depends, um, a lot.
(43:54):
Uh, it's funny 'cause I find like a lot of naming conventions are based.
On the inadequacies of a system.
So I know a lot of places that include equipment name or some attribute that they haven't been able to put into the system they include in the title.
But I think that, uh, fortunately here in Alaska, everyone has worked on a lot of the same projects and we come in with sort of a, a similar view of how things should be named.
(44:26):
But there's also just on the web there are definitely different places that you can look to talk about industry standards and find things that are out there that give you direction on that sort of thing.
Well, uh, strap in.
I think we're gonna try and take a rocket ship and go to Mars now and really get out there.
(44:47):
High level.
This question on everybody's mind right now.
And I'll set the frame.
We will talk about AI a little bit, but the frame probably is what I've noticed in the enterprise space is that AI is not really making an impact on tools yet.
There's a lot of talk, there's not a lot of action, particularly if you like thinking of, and I, I don't know a XI don't know what their plans are, but I'm just saying in general, when you look at Documentum or big systems like that, they tend to move slow.
(45:15):
I think people are really excited about ai.
So can you, let's, you know, let's go to Mars.
What do you think about how AI is gonna impact this space potentially maybe in like five, 10 years? Like what, what does, how is this tidal wave gonna disrupt doc control? Well, um, I amm seeing it have more and more impacts and not five years down the road.
(45:39):
I mean, it's, it's happening now.
I.
As you and I have discussed, it's a subject worthy of its own podcast because it, but I can tell you that I've seen a couple of examples already, particularly with OpenText and M files.
They're developing AI in their products.
(46:01):
And for one thing it makes, you know, one easy win was just making searches easier because it allows you to use your natural language searches like you do for Google.
So rather than having to know SQL and the, you know, or using dropdowns from a pre-populated search template, you can really just say, I'm looking for a document that this, is this, this, and this.
(46:28):
AI is also able to summarize data quickly.
We've seen that in a lot of the programs that when you're looking on the worldwide web and you see an article and it can summarize it, AI is able to summarize in these programs data on the fly, and it can generate reports that give you a snapshot of the metrics related to your system, how many documents came in, how many, you know, which discipline they were.
(46:56):
And this is, you know, without having to create a canned report, I mean just, you can just verbalize it and then there's your canned, you know, it works, there's your canned report.
So those are just two things I've seen and bigger things to come.
Definitely.
Should people fear job reductions related to AI adopt control? Do you think that's the ultimate end result of that? Or do you think that.
(47:26):
It's really gonna be those pain points we've talked about, about the confusion, the inability to find what you need.
It'll really just be an accelerant.
Or do you think this, someone listening to this is like, okay, I, I need to find a new career path because AI is gonna replace me.
What would your advice be to those dock controllers out there wondering if they have a job? I think it's going to be more like your original, it's gonna be, it's gonna accelerate, AI is going to accelerate, but not replace because, and certainly not for many, many years because there are just so many nuances and, and until all of those nuances are verbalized and recorded and used.
(48:15):
You're still gonna need the human perspective.
Yeah.
So I, I would say that it, it accelerates and makes it easier, but I don't see it replacing dock controllers in the very near future.
Well, and I like to think there, I could be very wrong about this, but when we think about the tidal wave of job losses, I generally think about the economic principle that you learn where it's as the price per unit of a given sort of good or services that you consume goes down, consumption goes up.
(48:50):
So I would not be surprised if the inverse of job losses happen for dock control.
If dock control becomes super efficient and highly useful within an organization, I think you would actually see demand increase, uh, possibly.
Rather than seeing people say, oh, we're good now.
Okay.
Mm-hmm.
Uh, so perhaps that'll be the outcome.
(49:11):
'cause I think ai, as you just said, it's like search is gonna get easier, summarization of information is gonna get easier.
And then just sort of overall me metrics and sort of ana like basic reporting is gonna get quite a bit easier is what I heard you say.
Mm-hmm.
Awesome.
Okay, well, let's get back in the rocket ship, go all the way back from Mars to Earth now, and maybe land at a university because I'd be curious to talk about this as sort of a, uh, we just dispelled the myth that there's no career path here.
(49:44):
I think there's an amazing career path.
And what would you say to university students or people looking to make a career change and they're listening to you saying like, I can do this.
I resonate with Leanne and the work.
What would you.
How would you, how do you get into doc control? I really think, well basically because it was successful for me, but understanding requirements around document control are, it's very important.
(50:18):
And I think that years ago when, uh, you know, after I graduated from technical writer, I was a business analyst and I could never explain to people, I could, they never understood what I did.
And now it's an everyday conversation.
A ba, a business analyst in in it.
(50:39):
It's just a given.
And there are so many people in this field.
Or that, you know, it's become a, a definitely an accepted field.
And I think that is the place to start.
And really the job of a business analyst is to map processes and determine efficiencies and to determine requirements for any system that you're gonna implement.
(51:05):
And so I would say that anybody wanting to get into document control should really start with business analysis.
There's plenty of certification programs out there, and it's usually under the overarching.
Project management certification.
And I, you know, I, I don't have anybody I would list or, or endorse.
(51:29):
I, I'm not familiar with that space.
I really have come up a different path.
But that is where I'd start because once you understand how to map processes and determine requirements, you're setting yourself up for a number of positions, whether it's document control, whether it's, something that's, uh, a program you need to in, implement at a utility or a gas, organization, oil and gas organization.
(52:04):
It's a really good foundation that you're not just limited to document control, but sorts of industries.
And it's something that's really, really important right now because there are more programs available, there's more applications, there's more technology, but available.
(52:25):
But in order to drive to the correct technology, you really need to be able to understand your processes and how to make these tools work for you instead of how you can, how you are gonna have to change everything you need to do to implement these systems.
So I, that is what I would say.
(52:45):
Research, business analysis and project management to get those fundamentals that will lead you to document control or other, other fields.
And what, what would you say to a university student or a career change person that's sort of doing a self check-in and saying, what are the things I like about life? I like meeting people.
(53:06):
I am active.
I don't wanna sit at a desk.
Right.
Like the, what are some qualities that you think might be, if, if you had them, it might be either a deal breaker, not deal breaker's the wrong word, but might be more challenging for you.
Or these are the kinds of profiles that you've seen be really successful in the space, the things that people like.
(53:30):
Do you have any advice there? If someone's just started doing a self-assessment of like, would I like this, would this be a good career? Um, I found working with when you're, when you're in a project.
Things are they're very fluid and you're, sometimes you're building this air, what is it? You're flying this airplane at the same time you're building it.
(53:51):
Um, and so people that like change, I thrive on change and that's what made document control interesting for me is we've been doing it this way, oops.
We found that we need to do this.
So that's more of like a project mindset.
And if you're somebody who likes to start something from the bottom and develop a program and see how it goes and make modifications and really look for the most efficient way to do something, then I would say, project doc control would be something that, would appeal to you and that you would thrive in because, it's ever changing and it's important to see how things are, are run and then reflect that in your procedures and in your information that you're disseminating to people.
(54:40):
Something that I've found when you're more of, say, a Brownfield you know, a facility that's been around for a very long time and your processes are pretty, pretty stable, you know, not a lot is changing.
This really a appeals to people that are in a space where they don't mind re, things that they are, they thrive in environments where things are very repetitive.
(55:09):
I will, give this stack of 300 documents and I will process 'em and put the correct naming and, you know, they, that's their jam.
They do well for that.
And I would say that anybody, you know, a lot of document control, you're not walking around, you are at a desk and you're looking at your computer and you're looking things up.
(55:34):
But you deal with a wide variety of people.
And for people that are really wanting to be present and working opposite people, working on the North Slope really satisfies a lot of people job wise because they like helping people and meeting new people.
And you really have to have a helping people mindset, you know, and some of the folks that you work with.
(56:01):
Are able to talk a shorthand with them and, and you're able to teach them and, and facilitate them finding something.
Some people you're probably gonna have to hold their hand a lot and that's fine because they're, you know, most of the time they're very grateful and, so I would say be, if you're a social being, that's gonna be great.
(56:24):
And even if you're not on the North Slope, you're still talking to people.
I love working on a, previously I worked with a oil company that was, that's built currently building pipeline.
I love talking to the other vendors and that sort of thing.
But I would say that sort of, you know, like I just explained.
(56:44):
If you want a lot of movement, a lot of change dynamic fly by the seat of your pants, sometimes projects are gonna be your niche.
And then if you're want to get into that real groove, then working on the operation side is gonna be, appeal, is gonna appeal to you and you'll, be welcome and successful.
(57:06):
Thank you.
That's a really good overview.
Appreciate it.
I think that I have another question for you kind of along those lines a little bit, which would be, if you are a doc controller, and I've worked with them in the past, and I've always noticed doc control can be stressful.
And I think it's related perhaps to, like you said, you've got hundreds of people on the line.
(57:30):
There's a lot going on high stakes to make sure these documents are right.
And what I've noticed is sometimes teams burn out.
I, I think also because of demand.
So you've got it staffed right for a project.
You've got a team of three or four and then this big like wave crashes over the dock control team and they don't have anybody they can add.
(57:53):
Even if they had someone, there's not enough time to train 'em.
It wouldn't be useful.
So you just have to like bear down and push through that moment.
And depending on how often that happens, I think it can lead to burnout in a project.
I think doc controls work really hard.
I think they're often underappreciated and I think that they go through those spurts of intense work.
(58:17):
So do you have any tips, tricks, things that maybe would work for them to push through those moments? If or, or recharacterize, how I describe them, but I'm curious to kind of talk about the stress of the position and any advice you have for folks.
That are maybe listening to this podcast and feeling a little stressed out.
(58:38):
So how did you manage it? I, I think in the past and you're right, as it's, as we mentioned, it's, it can be very fluid.
Sometimes the way a project happens, somebody, you know, figuratively backs up a dump truck and gives you 1000 documents in one submission.
(58:58):
And so something that I have found besides pizza that gets me through these times are checklists.
And so going back to those procedures that I keep harping on, because that's your go-to.
They're generally, they, they can be very detailed, right? Because you have to.
(59:19):
You're explaining in your procedures not only just the overall process, but the following metadata has to be filled out.
It has, you know, when you're talking about both the process and the system, but I find that when I do these now, at the end, I usually do a checklist.
And from that I, I summarize what needs to be done really in a, in literally a checklist form.
(59:46):
And I think that when you have a lot to do and you get overwhelmed, um, it really helps to have something that you can check the box just as it's a safety net for you.
It's, yep, I did it.
It's a second.
It's like a, you know, it's something that will help you.
(01:00:06):
Feel confident that you're doing everything and remind you when you're not.
Oh, wow.
Yeah, this checkbox, wait a minute, I didn't do that.
So that would be, what I say is, um, would, it would be something that would get you through those hard times.
Just, okay, here it is, there's my checklist, it's done.
That really is something that would get you through and really again then the employing what we, I talked about earlier, about making your users and your customers understand that we're all in this together.
(01:00:40):
And you know, maybe saying, okay, we've got these three people that are dock controllers, these two, so for four hours of the day.
These resources will be devoted specifically to, to this heads down work.
And there will be one person designated for answering ad hoc questions or dealing with with things that need to be escalated.
(01:01:05):
Oh, that's really insightful.
So having time blocks for that.
You know, they talk about switching costs in terms of how people work, that if you're switching a lot of what you do, like say you're answering the phones it's really hard to have focused time during that time.
Mm-hmm.
So I could see if you had a team of dock controllers and you scheduled certain people to say, this is your, this is your long mm-hmm.
(01:01:32):
Uh, moment, and then you have someone else handling the fires, that could be a really great strategy.
Thank you for that tip.
Another, just following on your checklist, I think one of, there's a book called The Checklist Manifesto.
I'm sure you, you probably read it.
It's um, by Atul Gand, I'm probably butchering the name, but he did a deep dive on checklists and it was really a great read for anyone that loves checklists.
(01:02:02):
The upshot of that book is sort of, he was looking at certain things, for example, why are medical procedures so bad? Oftentimes the outcomes as a percentage are so much worse than like the aviation industry.
And so they learn sort of, he teased out that humans are very bad at estimating how much they need a checklist.
(01:02:26):
So there's a reason that pilots who have 20,000 hours of experience flying planes go through a checklist.
It's a very simple checklist like, do you have fuel? And these are the things that have kept our planes flying.
We're gonna have 300,000 plane flights today and none of them are gonna crash, hopefully.
(01:02:47):
And that's where, uh, c check the power of checklists were born in the aviation industry is his example, because it was so critical not to crash those planes.
But other disciplines that have similarly critical things, checklists could really benefit.
And they did some studies where they, for example, with like surgeons, they would use a checklist before a procedure because sometimes they cut off the wrong leg.
(01:03:09):
And the stats on that were not really good.
So the medical industry over the last 20 years or so, and probably as a result maybe of this book, really changed the way that they thought about needing checklists in their process.
So that is a great call out.
I am in love with checklists and the checklist manifesto is an awesome read for those that wanna go a little deeper.
(01:03:31):
Yeah.
Leanne, thank you so much for sharing your expertise with us.
If people hear what you have to say and want to reach out and connect with you, throw you a question, what's a good way to get in touch with you? Uh, the best way would be on LinkedIn.
(01:03:52):
I think you said you were gonna put this in the in the comments.
Leanne Gyer and the name is German for those that who think it's French.
And yeah just contact me there and, and if there's, I'll be happy to, you know, reply whether I can help you or not, but you know, just I will get back to you.
(01:04:14):
Leanne, again, it has been such a pleasure.
I really appreciate you taking the time to share your learnings with us.
I think we've.
A tremendous amount about doc control.
I, I feel much more, uh, inspired about what a cool profession it is.
And thank you so much for coming on the pod today.
(01:04:37):
Thank you for having me.
Thanks for listening to the Major Project podcast.
Be sure to follow us wherever you get your podcasts and learn more at the major project podcast.com.
Until next time, keep building big.
Welcome to the Major Project podcast, your inside.
Look at the high stakes world of billion dollar projects.
Welcome to the Major Project podcast.
I'm your host, Orion Matthews.
And with me today to talk about document control is Leanne Gyer.
She's worked on major billion dollar assets on the owner side from gas fields to pipelines to refineries.
(00:25):
Leanne, welcome to the podcast.
Thank you.
Thank you very much.
Glad to be here and we're glad to have you.
And maybe before we get started and really jumping in on doc control, I think a lot of people here might not even know what that is.
And if that's the case, you're in the right place.
We're gonna take it easy and start from a 1 0 1.
(00:47):
But before we get into that, Leanne, maybe you can tell us a little bit about how you got started in the space kind of a bit of your career path, maybe some of the projects that you've touched, and just kind of catch us up and get to know you a little bit.
Okay.
Well, it's, it's kind of a circuitous route here, but, um, how I got into this space, uh, before I did in the late nineties, I was working in newspaper and magazine production business.
(01:15):
And this was the point at which Printed media was making a shift from being typeset to being produced via desktop publishing programs on computers at the time Apple MAC twos to be specific.
And in 1998, I wanted to move back to Alaska and a friend got me a job in an IT consulting firm as a technical writer producing user guides for some of the software the company wrote or implemented for their oil and gas and utility clients.
(01:46):
And this is actually a natural progression.
Being in the graphics and publishing industry to this because I had already been producing user guides for the software we were using and the graphics I was creating in desktop publishing.
Got into technical writing and then from technical writing, I graduated to n to mapping out the business processes that take place in this industries, in the industries that are served by this IT consulting firm, particularly in document control.
(02:19):
And then after a few years and a few projects in this framework and those projects included things for BP up the north slope.
It also included the railroad Alaska housing that those sort of clients really kind of across the board.
Then I eventually found my niche as someone who could implement doc control programs.
(02:42):
From both a system and a program perspective and set up the maintenance of both once the software was implemented.
Awesome.
And then also it sounds like you were in the lower 48 as well major way to working on a few refineries, if I recall correctly.
Is that right? Um, yes, I did.
(03:02):
I worked, um, at the BP Cherry Point Refinery in, um, Blaine, Washington.
And then I also was a Phillips 66 employee for a while.
They have a great group of people at the refinery in Ferndale, Washington.
Awesome.
Thanks for that intro, Leanne, and thank you for coming on the pod.
(03:24):
Real quick just to frame it up document control is this crucial.
But often overlooked discipline on major billion dollar projects.
Mm-hmm.
Especially in the engineering construction infrastructure phase.
And I am really curious for you to unpack, I think part of why it's overlooked is that it's maybe misunderstood.
(03:50):
Perhaps you could unpack it for us from a 1 0 1 level.
What is it, how is it different from maybe just clerical work? Like what is doc control? Doc control when it's done correctly, um, is to make sure that the most updated information is easily acceptable by the correct audience at any moment.
(04:17):
And it should come from a, an agreed upon single source of truth.
Those goals are simply stated, but maybe not so easy to, to achieve.
And you're correct.
A lot of organizations mistakenly think that doc control should fall under the duties of an admin staff, but it shouldn't.
In document control, you really have to focus on the lifecycle of a document and how to move it through its various stages and take appropriate actions.
(04:45):
So, for example piping and instrumentation drawing, that's an engineering document in a typical oil and gas project.
This document is designed and generated to reflect conditions in the field, which requires cycles of reviews and changes and approvals.
(05:05):
And all of this has to be monitored and recorded just to get a facility built.
That's just to get it built.
But as the facility operates and and conditions in the field change over the years, this document again must be updated, verified again, go through the review and approval process numerous times.
(05:26):
Alright? So multiply this by the thousands of other engineering documents like this at a, um, refinery or an oil field and the decades or even centuries that a field is operated in, right? And then, so you have innumerable versions of this document to monitor and track, multiply this by the thousands of other engineering documents like this and the decades or even centuries.
(05:54):
That a field is operated and then you're gonna have an enumerable version of this document to monitor and track.
And so an admin already has enough, they already have a full-time job managing other type of documents that don't have to have this sort of, this level of control and not to mention all their other duties.
Um, this task is really best left to specify dock controllers that understand the lifecycle and how to manage it.
(06:24):
It makes a lot of sense.
So then, where does doc control sit? Like for you as an expert in the space, what's your optimal, uh, reporting structure for doc control? Um, and maybe you'd have to break that up into like an operating field versus a a major capital project for us.
(06:45):
But where do you wanna, where do you think doc control should be? My, most of my experiences was on the project side and, uh, oh, well, it, and I do have some experience on the operations side, so, it, it varies by organization and sometimes in some organizations it sits under it or possibly engineering.
(07:07):
Where I've seen it, uh, be most effective in a project structure is to have it sit under project services and then, uh, reporting directly to the project services manager.
This gives the document control personnel access to the folks who are involved in the documents lifecycle.
(07:28):
And they can report to the project services manager who can then summarize updates to the project director.
When I worked on the operations side.
I found that a lot of times this was under, say, the pipeline technical authority.
So really the discipline that you're doing the document control under there were folks that were doing health and safety that were in the health and safety department.
(07:57):
I was generally looking at regulatory documents for the pipeline.
And those sit under, that sat under the pipeline technical authority, which made a lot of sense because again, they're involved in decisions about documents and a lot of times this particular discipline also had a lot of responsibilities to regulatory agencies, specifically the Department of Transportation.
(08:24):
So it made sense for the technical authority in that situation to be over for me to report to that individual in that position.
So on doc control, you sort of talked about a couple different scopes there.
Like what are the typical areas that you apply doc control to? Perhaps if you're on a major project, is it every document for the project? Is there some sort of boundary condition? Are you just focusing on engineering documents? Like how do you narrow your scope so that people can have little word docs on a SharePoint file and you're not grabbing those and putting 'em under your processes? It really comes down to what in a project needs to be controlled from a lifecycle.
(09:13):
Example.
And it really, when we, it needs to have the kind of control and, and really it comes down to version control revisions of a document.
Engineering, obviously you have every pl, you know, you have places on the document where you list when it was updated in which revision.
(09:33):
This is of course important in engineering because you're building things or modifying them.
Having the most having the most current version is important and so that needs to be controlled.
That should be in the document management system For project documents, you're making policy, you have procedures.
Again, you have version control on these.
(09:53):
That also needs to be in the document control system because you are formalizing when it is being updated and when it's being updated.
You're also doing a formal distribution of these, of this document to let everybody who's needs to know this is the latest revision and to make sure that that's getting to the proper people.
(10:16):
So it really comes down to what has to have revision control meeting minutes.
Don't need to have revision control.
They have a, their static content that happened on a static date and they can reside on a a SharePoint or a shared drive with, minimal risk.
And so how do you explain that to people and sort of set up doc control Well, or how have you seen it done well in the past? So imagine you're, you are, we're doing a major capital project together again and mm-hmm.
(10:54):
Starting doc control on a major project blank slate.
What are the first steps to establishing this good doc control? Okay.
Doc control should really be part of the pre-planning stages in a, in a project because it allows your document controllers to understand what documents will be managed.
(11:18):
And to put in the proper processes and systems in place prior to the deluge of documents that are going to inevitably follow during planning and define and execute.
I've been on projects where this was not the case.
I, the doc control was introduced well into execute at this stage.
(11:42):
We call this ready, fire, aim, the ready, fire, aim approach because you're creating a structure for these, for your program and simultaneously managing a lot of documents.
And under a time crutch, it is not ideal.
It introduces risk and in the end it costs way more than if you would've introduced it early on.
(12:06):
So again the stage is really pre-planning because again, you know the type of documents, you know who needs to access.
And how to set up your proce a better idea of your processes and tools that you need to set up.
First and foremost, I'd look at the type of documents that are to be managed.
(12:27):
If it involves engineering documents, I need to consider how am I going to manage concurrent engineering? Something I'll talk about later if it is a project that doesn't require engineering, that gives me more options in terms of the processes and or systems I can use to manage them.
The next thing I need to know is who needs to have access to these documents? Are they people within my organization and behind the firewall that I can easily give access to a shared repository? Or are some folks say contractors supporting from outside the organization and I have to give some thought to how they can securely access and possibly edit documents.
(13:09):
My organization's, IT department is certainly gonna have a lot of input on how this needs to be set up.
So then armed with this information, I can next look at my options for a tool.
Okay.
And this might be something I have very little control over.
If this is a fairly new organization or project, my only option might be sharing documents via a shared network drive or SharePoint.
(13:36):
There's very little I can automate with this kind of setup.
So it will be very process heavy with a lot of manual tasks and it's gonna require more people.
Ideally, your organization will have some sort of enterprise document manage sys management system.
Some I've worked with in the past that I can name off the top of my head are Documentum, which is now owned by, uh, OpenText AEX pims Omega-3 65.
(14:04):
Other assorted programs, you're gonna be ahead of the game in this situation if you do have access to one of this type of tool, because you can determine your processes for the documents, right? For example, wiring documents will be reviewed by engineer A, engineer B, and the project manager with the engineering director providing final soft the engineering director providing final sign off.
(14:31):
And then you can leverage the power of your system to automate these processes as much as possible.
And all the while, this is very important.
You're making these decisions, agreeing upon processes, then you write them down in a procedure and you train your users well.
So let's talk for a second because I wonder if there's like leadership on this pod.
(14:54):
And they've gotten to this point and they're like, oh, okay.
I'm gonna make a list of those three things that Leanne just said.
Documentum, pims.
And, uh, we'll pick one and then we're gonna have our dock control.
And sometimes I like to tell people that the runner doesn't the shoe doesn't make the runner.
So if you're thinking about getting in shape and you're at a Nike store and you're trying to figure out what your best shoe is so that you can become super great at running, you're kind of already on the wrong track.
(15:23):
Uh, having good shoes is a great part of running.
But sometimes I think people forget all the other pieces that go into that.
And I would love to kind of hear maybe from you a little bit about the non tool tips.
You kind of touched on it there, but maybe reinforce my message or tell me I'm wrong.
And if this is a case where you just gotta get a good tool in place, maybe that's all you need.
(15:49):
Do you have any thoughts on that one? Oh, yeah.
Um, I think it was you in a conversation that actually said the tool is only as good as the discipline of its operators.
And that's very true.
And that's why I do emphasize the procedure, because when you're writing down procedures, you e you know it's important be to emphasize to your users and your stakeholders that this is the agreed upon.
(16:18):
This is the agreed upon playbook.
This is what ensures that we're all singing from the same sheet of music.
I'm sure there's more analogies, but I'm gonna try to stop here.
And the procedures could also list the consequences of not following the processes.
Mm-hmm.
So when you do this upfront work, you give your dog controllers the guidance they need when they are considering taking a shortcut.
(16:45):
And this usually involves a time crunch.
I need to get this out.
I don't wanna follow these procedures.
Or they might be pressured by somebody who wants them to take a shortcut.
I, you know, I don't have time for this.
Just give me this copy, or I'm gonna use this copy.
That's not the latest.
This lays it out for everybody.
(17:07):
And when you're faced, when your dock controllers are faced with that.
Those sort of dilemmas, they have something they can refer to.
This is our process.
If we don't follow this process, we are at risk of A, B and C.
And it's not, you know, I don't want to come from a point of rigidness, right.
(17:29):
Rules and processes are ever evolving and they're gonna change.
But by putting them down in a controlled document, like a procedure, you ensure that these changes happen a fo in a formalized manner and are communicated to the necessary users.
Okay.
So you mentioned something, I don't wanna put you on the spot, but I am super curious in that procedure, you mentioned consequences.
(17:52):
Uh, compliance with dock control is a difficult area in organizations.
What kind of carrot and sticks do you employ that have been useful, uh, in getting that compliance that you need? You really did put me on the spot, but it's carrot and stick.
(18:15):
And this is, I think it's a delicate position.
You know, you're, you're dealing with somebody's, we're losing money.
We're this, we're this, and at that point you have to, humor helps, but also really what it is, is saying, look, I'm not here to make your life more difficult and make every, the person who's maybe challenging you.
(18:39):
It is super important to say we're on the same team.
I'm not making up these rules because I don't have anything better to do and I wanna ruin your day.
It's best, when you trust your coworkers and they trust you, but sometimes it takes just a little bit more work.
And really what what it is, is understanding, I'm helping you.
(19:03):
We're on the same team, let's work together.
That's really that's really how it works for me.
Let's work together and, and to make them understand, hey, this doesn't get done correctly.
There's not only costs, but there's risk.
If something is built incorrectly, and it's not up to specs, it could cause injury to people, you know, and, and without getting dramatic or, you know, making a catastrophe, just laying things out and say, and approach it from the perspective of how can you know, let's work this out together.
(19:42):
That my strategy.
Well, so that's a, yeah, that's a that's a really great tie in into a question that I think a lot of folks may be thinking about doing a billion dollar project, and doc controls not number one on their list of things to care about.
And I think that is probably because there might be misunderstandings about the return on investment.
Mm-hmm.
So a lot of people see doc control just as an admin function, something they need to have, but not necessarily something that's critical because it's not really hitting the key financial levers of the project, like cost, schedule, risk, quality, you just mentioned risk, but maybe you can, can, could you help us make a case mm-hmm.
(20:21):
To keep putting you on the spot here to a project director about why they even should care about doc control and make what is probably needing to be a substantial investment for the project's life to have it done right.
Mm-hmm.
Absolutely.
Um, document control has a direct effect on all of this costs schedule, quality, risk, and the consequences can be highly visible when the document control practices aren't followed.
(20:51):
Distributing documents that are outdated.
Like I just mentioned, again, could co, could impact the cost if something's not built to proper specifications and it has to be rebuilt, this affects both costs and schedule.
You've just built a module, but you didn't build it correctly.
We have to, you know, now we're behind on the schedule and we're paying twice to have the same thing done.
(21:15):
And then if an outdated drawing used doesn't say, reflect the bolts made from the required material to create, um, a facility or a module, your quality is affected.
And that's where you're introducing risk, that a structure or piece of equipment could fail and you could involve injury or even death, even death to field personnel that said, I think it's fair to say that Doc Control really delivers your return on investment, even though it may not be immediately obvious to you.
(21:48):
Well, maybe we can unpack the investment a little.
'cause I'm gonna keep putting you on the spot on these ones.
But, uh, let's say that we're doing a, you know, a $5 billion build and we're gonna make, let's say, a really cool data center or something like that.
Or we can switch it up into a refinery if that's more your, your style.
But what size, and I know you can't answer this fully, but like, what does a good built out doc control, you know, team look like? Like what are some of the kind of key things that someone might need to be thinking about as they're deciding? Okay.
(22:22):
Those, those ROI things we wanna get serious about this.
What does serious look like? What's good? So, like, what does, what does good document control look like? Is that what you're saying? How much do I need to spend to do this? Right.
Like in terms and in terms of head count, am I setting up a team of three for a billion dollar project or is it a team of 25? Like what is the scale of the footprint of dock control typically that you've seen that's been kind of effective? Well, it's, it, you know, it has a lot of, it depends on a lot of different things.
(23:00):
Where are you in the, like I said before, if you've, you know, your tool is say a shared file structure, then you're gonna need a lot of people because you have a lot of, you have a lot of manual processes also at the be, you know, I was recently on a project where, a lot of things were being built in Canada and Malaysia, so you have an enormous amount of documents that are being update, they're being submitted, they're being reviewed, they're being returned, updated, a lot of in and out, a lot of in and out.
(23:37):
And so when that is the case, you have to have a lot of people to address that volume.
But then when things are built, then I'm talking the project side of things, then your doc control team can then be reduced because you, as the project comes closer to an end, you're not dealing with that volume of documents.
(24:04):
And so you need flexibility of course.
And be able to pivot when you need to add or you know, remove people.
But it's also, you know, you, you have options here.
'cause a lot of times when something is that is coming and it's being produced and is now operational, some of those document controllers can get, can then because upon I'm leaving that in, that was too good.
(24:32):
That'll be in the loopers role.
Yeah.
When you get to the point where your, these modules or structures are operational, you can take a couple of those dock controllers and put them over on the operations side now, right? Because you've got your standard operating procedures, you have all of your.
(24:54):
Equipment and engineering drawings that are referenced on the operation side and possibly being updated if things are found in the field that are not accurately reflected on those documents.
So it can expand and contract depending on the phase that you are in in a project or in a the building of a pipeline and the operations of a pipeline.
(25:21):
Does that make sense? Yeah, it does.
And I think what I'm hearing from you is that you have to make an upfront investment in dock control first to establish processes.
That's probably a one-time capital project charge.
Once you get that, you sort of run into either, if it's, if it's a, if we're talking about sort of a greenfield project, you're gonna have a team upfront.
(25:48):
Mm-hmm.
Probably starting in define where you wanna have several folks available for the influx, and then as the project gets towards handover or you're, you're closing down, you can sort of balance it.
Do, do people use consultants a lot for that or, uh, yes.
To kind of balance the, yeah, absolutely.
(26:09):
Okay.
That makes a lot of sense.
And then all right, let's switch it up.
'cause we just talked about a new project, but let's say that you are a new project director and you're coming into a midway through.
How do you know if you've got good doc control versus bad? What are some clues to look for? Uh, or maybe you're just an engineer and you're like, this is not working for me.
(26:34):
I don't think this is good.
Like, what are how do you sort of clue in that you have work to do on the doc control space? Um, this goes.
When we talked about setting up a doc control and why you need to, and if you've got good document control, you don't hear a lot of noise.
(26:56):
The most updated information is easily accessible by the correct audience at the correct time with very little fuss, right? The more noise you have, the more it is an indicator that document control is not going in a great direction.
So noise will come in the form of people complaining that they can't find a document or a type of.
(27:24):
So then this is where you, to mitigate this, you want to work with the user that's having the issue, user or users.
And when you have users, then you're saying, Hey, this is happening more than once.
You wanna verify that the documents in question are stored in the proper hierarchy, and they contain the correct attributes so that when people are searching for a document and they put in the required metadata, it's coming up, and then troubleshoot and find out why that's not happening.
(27:56):
Sometimes it's your system, sometimes it's operator error.
You know, your folks don't know how to, don't know the correct metadata, um, the correct attributes to find the documents they need.
Another example of noise, complaint of noise are complaints about lack of access to a document.
(28:19):
So if people can't get to a SharePoint or a web interface, they've been given a link to, this is an example where, you know, to, to mitigate this, we have to make sure that everyone is aligned on who is supposed to be given access and updating any permissions if necessary.
(28:39):
And this, it can happen in a project because, it's projects are very dynamic.
Maybe you have a set of contractors, they didn't work out.
You bring in another set of contractors.
They're external, the system, they need to have access.
And so then this is where you again, get aligned and make sure that these people have the process.
(29:00):
Proper access and noise will be even louder and have more of an impact when outdated drawings are used to build something that is unusable because it's not built to the proper specifications and will cost more time and money to reveal, to rebuild.
And so this is where your project director is really gonna notice.
(29:23):
That's when it really rises to the surface.
And you're gonna have to address this by reviewing your pro your procedures with your users to ensure that they are following the processes for assuring the most updated version revisions.
And verify that everyone's pulling from the, the agreed upon single source of truth and not from an outdated folder, they have squirreled away on their C drive.
(29:49):
Uh, that makes a lot of sense.
You know, I like to say in the tech space we have something called the principle of least privilege, which means you wanna give people the least amount of access they need to do their job.
And that's really helpful 'cause it reduces risk.
But I believe there's a missing phrase in that, which is you need to couple the principle of least privilege with a principle of speedy access and the more you locked down people's privileges to protect an organization.
(30:22):
There should be a, a commensurate metric of how quickly you can issue access.
Because what I see a lot of orgs do is they're great at locking things down and then they get worse at granting access at the same time.
And that is a recipe, in my opinion, for disaster within organizations.
Um, 'cause it leads to a lot of frustrated people.
(30:43):
You can't get the information you need in the time you need it.
Or like you were saying with contractors, they can't gain access to systems.
Exactly.
Um, you make a great point about, you know, making your, your security permissions access as nimble as your, and dynamic as your workforce because you know, you'll, yes, you've identified this person was legit, they need access, but then to have, to make them wait.
(31:14):
Again, it is just frustrating on all sides and is very inefficient.
Well, and just to close the book a little bit on like what does good, uh, doc control, if I'm this project director looking at it, and these are really great tips.
You're gonna hear some noise, you're going to potentially build the wrong thing, that's like your red flag.
Or maybe if you're taking over a project, you would look back and sort of see, oh, okay, like our people are not building correctly.
(31:40):
There might also be like permitting delays and things like that.
I imagine that you might see Is there also, let's just say I just took over a project last week and I'm drafting my email to sort out doc control, so I'm gonna ask someone to kind of look through and see if there's any things like that.
Maybe I'm gonna survey the engineers and kind of see how they're feeling about things.
(32:01):
Hopefully I'm thinking about access speed.
Maybe I'd ask a question about that.
Is there a set of.
Documents you might, and this, this might tie into a question kind of about assurance processes, but like what also would you be looking for if you're, if you wanted, you know, as a casual sort of leader, wanted to audit quickly the doc control.
(32:22):
So is it like, hey, I need the compendium, do Wikipedia of our organization and it should roughly be like a one page, like here's the naming convention of things, here's the, here's a couple process workflows.
Like what do you think are some critical sort of key foundational documents that would just, should kind of be at the ready if they're even already for doc control? Um, I find that work process flows are very valuable to have and to be able to show.
(32:55):
Again, this is this, I mean, you are mapping your processes of.
How you are handling a document and you're interacting with the system.
And because a lot of times people don't understand that documents, different documents under have a different life cycle or go through different reviewers, you have to it.
(33:19):
It's an easy way to illustrate that.
If you have a project document, it is gonna go through this lifecycle.
This is how it'll be handled.
And if you have an engineering document, this is how it's going to be handled.
This is the lifecycle.
And so that's sort of document at the ready, um, has proved invaluable in the past for helping management understand what the people in document control are doing, why you have as many people as you do and how.
(33:53):
How things are getting done.
So that would be definitely my number one thing that I would have at the ready to help people understand the process.
And so, just to flip this around, 'cause I, I think it's a sort of an interesting area to dig a little bit on.
So I've been talking from the perspective of the leadership, but if you take a look at it from a fellow doc control manager, what advice would you give them? If there's a leadership change on a project or you feel like things aren't going well, like what have been some tips that you could give to fellow doc controllers about how to sort of share or affect change within an organization during states of transition or other times you need to kind of rally and, and um, gain control over your function better? I think that the best way to do that.
(34:47):
Again, we, we need to have graphics.
I mean, pictures worth a thousand words.
And I have had an experience in the past where I was trying to explain something and nobody was getting it.
And finally when another person and I sat down and put it in a graphic format, and I think it was mostly process, but to say, this is where we're at, and this is what happens.
(35:14):
If we make this change, this will happen.
And it has to be something that's easily understood and visual.
What do they say? Like, to management only has the bandwidth for like three things or three topics.
To really present something, don't do a, uh, what do they say, PowerPoint to death or whatever, death by PowerPoint.
(35:39):
Do, do that.
But really just succinct.
This is, when this happens, this problem is created.
If we change this to this, it will solve that problem.
And our world will look like this, and your metrics will look like this.
I think that's the tip I would give anybody who's trying to make who's trying to work with management to make things more efficient.
(36:05):
That, that's interesting.
It, it leverages your background in graphic design.
I'm a big form over function guy for technical disciplines.
I think that communication is usually at the heart of a lot of problems particularly when you're deep in a technical discipline like doc control and so to, to sort of bring everyone together and create that meeting of the minds.
(36:25):
Sometimes a picture or a simplified way of expressing things can make all the difference, and it's often overlooked because it's not really technically doing anything different.
You're still advocating for the same things, but somehow.
Good design can make all the difference in how your work gets done.
(36:46):
It's amazing.
No doubt.
Well, so shifting it a little bit, kind of sticking with the dock controller perspective, let's say you take over and you've got these, big projects are executed across multiple vendors, partners, divisions, owners.
How important is it for those partners to have good dock control? It's imperative for smooth and efficient running of a project because if they are, if they're dropping the ball, so to speak, you, you're gonna get noise.
(37:24):
If you, and with noise, you are going to be wasting a lot of time and researching.
And mitigating problems created.
Say if they're distributing outdated revisions of a document, you're on the side that has to track that down.
I'm, you know, sometimes I feel like a forensic scientist on some of the projects I've, I've worked on and, and finding out, so how something happened.
(37:50):
So that's time that you don't need to do, best time.
You don't have to figure out a problem created by somebody else.
And if they haven't, I've also been in situations where vendor vendors have not properly tracked what they have sent to me, and then they rely on me to run reports for them to say, this is what you sent me.
(38:13):
It's imperative if you want things to run smoothly and efficiently otherwise you're gonna get noise.
How do you, when you're picking your vendors, if you're sort of intersecting this at the pre, pre uh, sort of pre-planning stage and you're looking at different people, how do you, do they write it into the contracts oftentimes with vendors? Does doc control have a little carve out? Like how do you, do you add that to your sort of RFIs? Like what do you think is a good strategy for people to make sure that their vendors do have good doc control? 'cause in my experience, uh, that's not always the case across different groups.
(38:53):
You know, and I, I don't know that, that you have that kind of control that you've can be that prescriptive.
And really what drives a lot of decisions regarding vendor vendors and vendor bids? Obviously, cost of course comes in, pretty heavily, but I would say that most of the time it's reputation and Hmm.
(39:20):
You know, particularly, I mean, here in Alaska, you know, we, people know all the players essentially.
And so when you know which people are working at, which organizations, you've worked with them in the past, and you say, oh, we, okay, I worked with this organization and I, I had really good experience with them and not a lot of noise.
(39:42):
And, and you become also familiar with the programs that they use, you know, you'll know, oh, okay, this organization uses Aex and, you know, that will weigh in, certainly if they'll talk to document control when they're doing these RF Qs, you can weigh in on that sort of thing and say, Hey, yeah, AEX, we've worked with it.
(40:04):
We know how to work with it.
We've worked with, you know, they did a good job on such and such a project.
So that's really the only sort of input you have.
Not really control, but, um, input and insight, uh, like so many things in our space, reputation seems to be a really big way that you carry the day when you're picking your vendors and setting up a major project at really interesting that way.
(40:31):
Would you say, just to touch back on tools, since you said the word Aconex, I can kind of open up the floor.
If you have a system that would, you, would you rather have SharePoint slash no system basically, or a poorly implemented Documentum or Aex, like what's your.
(40:52):
Choice, how easy is it to sort of dig out of a badly implemented system? And kind of following on that, like is it more, is it like a badly implemented SAP project or is it like a badly implemented sort of, I don't know, P six thing where you can just sort of wipe out and start over? My answer on this would be that I would want to leverage as much of the bad system as I could and you know, you say it's badly implemented, so I would imagine that it does not do everything it's supposed to do, but any automation that I can leverage will put me in a better position than having to do everything manually.
(41:39):
I mean, and that's, you know, if you can find your system is going to consistently.
Perform on certain tasks that you can rely on and that it's not, you know, something you can't replicate or whatever.
But if you can find some things that it will do, I think that it would be better to leverage that.
(41:59):
Because when you are trying to circulate a document to 12 different reviewers and you have to manually set that up or manually distribute it, it's the, the time is overwhelming, particularly when you talk about an enormous amount of documents.
(42:20):
And I've been in situations where we started out with only, uh, a very manual system, just a, shared files on a shared drive.
Yeah.
And while it was feasible at the beginning of the project when you had less than 200 documents, you were fine.
(42:42):
But it quickly grew outta control.
And it also pro created problems later when we migrated to a system and we didn't have data standardization or integrity document numbers that were inconsistent.
That sort of thing that we, that really, really bit us in the bu.
(43:03):
So I would say anything that you can do to put your information in something that is standardized and automated.
Even if you have to wrap a lot of processes around that, you're still gonna be ahead of the game than if you just go manual because you want the control because it'll just get out of hand too quickly.
(43:25):
Well, you just mentioned standardized like names, right? Doc control numbers, I assume like function, discipline.
Is there a global standard for that? Like how do you figure out what your doc control naming standard is and implement that properly? You know, it's, uh, it, again, it depends, um, a lot.
(43:54):
Uh, it's funny 'cause I find like a lot of naming conventions are based.
On the inadequacies of a system.
So I know a lot of places that include equipment name or some attribute that they haven't been able to put into the system they include in the title.
But I think that, uh, fortunately here in Alaska, everyone has worked on a lot of the same projects and we come in with sort of a, a similar view of how things should be named.
(44:26):
But there's also just on the web there are definitely different places that you can look to talk about industry standards and find things that are out there that give you direction on that sort of thing.
Well, uh, strap in.
I think we're gonna try and take a rocket ship and go to Mars now and really get out there.
(44:47):
High level.
This question on everybody's mind right now.
And I'll set the frame.
We will talk about AI a little bit, but the frame probably is what I've noticed in the enterprise space is that AI is not really making an impact on tools yet.
There's a lot of talk, there's not a lot of action, particularly if you like thinking of, and I, I don't know a XI don't know what their plans are, but I'm just saying in general, when you look at Documentum or big systems like that, they tend to move slow.
(45:15):
I think people are really excited about ai.
So can you, let's, you know, let's go to Mars.
What do you think about how AI is gonna impact this space potentially maybe in like five, 10 years? Like what, what does, how is this tidal wave gonna disrupt doc control? Well, um, I amm seeing it have more and more impacts and not five years down the road.
(45:39):
I mean, it's, it's happening now.
I.
As you and I have discussed, it's a subject worthy of its own podcast because it, but I can tell you that I've seen a couple of examples already, particularly with OpenText and M files.
They're developing AI in their products.
(46:01):
And for one thing it makes, you know, one easy win was just making searches easier because it allows you to use your natural language searches like you do for Google.
So rather than having to know SQL and the, you know, or using dropdowns from a pre-populated search template, you can really just say, I'm looking for a document that this, is this, this, and this.
(46:28):
AI is also able to summarize data quickly.
We've seen that in a lot of the programs that when you're looking on the worldwide web and you see an article and it can summarize it, AI is able to summarize in these programs data on the fly, and it can generate reports that give you a snapshot of the metrics related to your system, how many documents came in, how many, you know, which discipline they were.
(46:56):
And this is, you know, without having to create a canned report, I mean just, you can just verbalize it and then there's your canned, you know, it works, there's your canned report.
So those are just two things I've seen and bigger things to come.
Definitely.
Should people fear job reductions related to AI adopt control? Do you think that's the ultimate end result of that? Or do you think that.
(47:26):
It's really gonna be those pain points we've talked about, about the confusion, the inability to find what you need.
It'll really just be an accelerant.
Or do you think this, someone listening to this is like, okay, I, I need to find a new career path because AI is gonna replace me.
What would your advice be to those dock controllers out there wondering if they have a job? I think it's going to be more like your original, it's gonna be, it's gonna accelerate, AI is going to accelerate, but not replace because, and certainly not for many, many years because there are just so many nuances and, and until all of those nuances are verbalized and recorded and used.
(48:15):
You're still gonna need the human perspective.
Yeah.
So I, I would say that it, it accelerates and makes it easier, but I don't see it replacing dock controllers in the very near future.
Well, and I like to think there, I could be very wrong about this, but when we think about the tidal wave of job losses, I generally think about the economic principle that you learn where it's as the price per unit of a given sort of good or services that you consume goes down, consumption goes up.
(48:50):
So I would not be surprised if the inverse of job losses happen for dock control.
If dock control becomes super efficient and highly useful within an organization, I think you would actually see demand increase, uh, possibly.
Rather than seeing people say, oh, we're good now.
Okay.
Mm-hmm.
Uh, so perhaps that'll be the outcome.
(49:11):
'cause I think ai, as you just said, it's like search is gonna get easier, summarization of information is gonna get easier.
And then just sort of overall me metrics and sort of ana like basic reporting is gonna get quite a bit easier is what I heard you say.
Mm-hmm.
Awesome.
Okay, well, let's get back in the rocket ship, go all the way back from Mars to Earth now, and maybe land at a university because I'd be curious to talk about this as sort of a, uh, we just dispelled the myth that there's no career path here.
(49:44):
I think there's an amazing career path.
And what would you say to university students or people looking to make a career change and they're listening to you saying like, I can do this.
I resonate with Leanne and the work.
What would you.
How would you, how do you get into doc control? I really think, well basically because it was successful for me, but understanding requirements around document control are, it's very important.
(50:18):
And I think that years ago when, uh, you know, after I graduated from technical writer, I was a business analyst and I could never explain to people, I could, they never understood what I did.
And now it's an everyday conversation.
A ba, a business analyst in in it.
(50:39):
It's just a given.
And there are so many people in this field.
Or that, you know, it's become a, a definitely an accepted field.
And I think that is the place to start.
And really the job of a business analyst is to map processes and determine efficiencies and to determine requirements for any system that you're gonna implement.
(51:05):
And so I would say that anybody wanting to get into document control should really start with business analysis.
There's plenty of certification programs out there, and it's usually under the overarching.
Project management certification.
And I, you know, I, I don't have anybody I would list or, or endorse.
(51:29):
I, I'm not familiar with that space.
I really have come up a different path.
But that is where I'd start because once you understand how to map processes and determine requirements, you're setting yourself up for a number of positions, whether it's document control, whether it's, something that's, uh, a program you need to in, implement at a utility or a gas, organization, oil and gas organization.
(52:04):
It's a really good foundation that you're not just limited to document control, but sorts of industries.
And it's something that's really, really important right now because there are more programs available, there's more applications, there's more technology, but available.
(52:25):
But in order to drive to the correct technology, you really need to be able to understand your processes and how to make these tools work for you instead of how you can, how you are gonna have to change everything you need to do to implement these systems.
So I, that is what I would say.
(52:45):
Research, business analysis and project management to get those fundamentals that will lead you to document control or other, other fields.
And what, what would you say to a university student or a career change person that's sort of doing a self check-in and saying, what are the things I like about life? I like meeting people.
(53:06):
I am active.
I don't wanna sit at a desk.
Right.
Like the, what are some qualities that you think might be, if, if you had them, it might be either a deal breaker, not deal breaker's the wrong word, but might be more challenging for you.
Or these are the kinds of profiles that you've seen be really successful in the space, the things that people like.
(53:30):
Do you have any advice there? If someone's just started doing a self-assessment of like, would I like this, would this be a good career? Um, I found working with when you're, when you're in a project.
Things are they're very fluid and you're, sometimes you're building this air, what is it? You're flying this airplane at the same time you're building it.
(53:51):
Um, and so people that like change, I thrive on change and that's what made document control interesting for me is we've been doing it this way, oops.
We found that we need to do this.
So that's more of like a project mindset.
And if you're somebody who likes to start something from the bottom and develop a program and see how it goes and make modifications and really look for the most efficient way to do something, then I would say, project doc control would be something that, would appeal to you and that you would thrive in because, it's ever changing and it's important to see how things are, are run and then reflect that in your procedures and in your information that you're disseminating to people.
(54:40):
Something that I've found when you're more of, say, a Brownfield you know, a facility that's been around for a very long time and your processes are pretty, pretty stable, you know, not a lot is changing.
This really a appeals to people that are in a space where they don't mind re, things that they are, they thrive in environments where things are very repetitive.
(55:09):
I will, give this stack of 300 documents and I will process 'em and put the correct naming and, you know, they, that's their jam.
They do well for that.
And I would say that anybody, you know, a lot of document control, you're not walking around, you are at a desk and you're looking at your computer and you're looking things up.
(55:34):
But you deal with a wide variety of people.
And for people that are really wanting to be present and working opposite people, working on the North Slope really satisfies a lot of people job wise because they like helping people and meeting new people.
And you really have to have a helping people mindset, you know, and some of the folks that you work with.
(56:01):
Are able to talk a shorthand with them and, and you're able to teach them and, and facilitate them finding something.
Some people you're probably gonna have to hold their hand a lot and that's fine because they're, you know, most of the time they're very grateful and, so I would say be, if you're a social being, that's gonna be great.
(56:24):
And even if you're not on the North Slope, you're still talking to people.
I love working on a, previously I worked with a oil company that was, that's built currently building pipeline.
I love talking to the other vendors and that sort of thing.
But I would say that sort of, you know, like I just explained.
(56:44):
If you want a lot of movement, a lot of change dynamic fly by the seat of your pants, sometimes projects are gonna be your niche.
And then if you're want to get into that real groove, then working on the operation side is gonna be, appeal, is gonna appeal to you and you'll, be welcome and successful.
(57:06):
Thank you.
That's a really good overview.
Appreciate it.
I think that I have another question for you kind of along those lines a little bit, which would be, if you are a doc controller, and I've worked with them in the past, and I've always noticed doc control can be stressful.
And I think it's related perhaps to, like you said, you've got hundreds of people on the line.
(57:30):
There's a lot going on high stakes to make sure these documents are right.
And what I've noticed is sometimes teams burn out.
I, I think also because of demand.
So you've got it staffed right for a project.
You've got a team of three or four and then this big like wave crashes over the dock control team and they don't have anybody they can add.
(57:53):
Even if they had someone, there's not enough time to train 'em.
It wouldn't be useful.
So you just have to like bear down and push through that moment.
And depending on how often that happens, I think it can lead to burnout in a project.
I think doc controls work really hard.
I think they're often underappreciated and I think that they go through those spurts of intense work.
(58:17):
So do you have any tips, tricks, things that maybe would work for them to push through those moments? If or, or recharacterize, how I describe them, but I'm curious to kind of talk about the stress of the position and any advice you have for folks.
That are maybe listening to this podcast and feeling a little stressed out.
(58:38):
So how did you manage it? I, I think in the past and you're right, as it's, as we mentioned, it's, it can be very fluid.
Sometimes the way a project happens, somebody, you know, figuratively backs up a dump truck and gives you 1000 documents in one submission.
(58:58):
And so something that I have found besides pizza that gets me through these times are checklists.
And so going back to those procedures that I keep harping on, because that's your go-to.
They're generally, they, they can be very detailed, right? Because you have to.
(59:19):
You're explaining in your procedures not only just the overall process, but the following metadata has to be filled out.
It has, you know, when you're talking about both the process and the system, but I find that when I do these now, at the end, I usually do a checklist.
And from that I, I summarize what needs to be done really in a, in literally a checklist form.
(59:46):
And I think that when you have a lot to do and you get overwhelmed, um, it really helps to have something that you can check the box just as it's a safety net for you.
It's, yep, I did it.
It's a second.
It's like a, you know, it's something that will help you.
(01:00:06):
Feel confident that you're doing everything and remind you when you're not.
Oh, wow.
Yeah, this checkbox, wait a minute, I didn't do that.
So that would be, what I say is, um, would, it would be something that would get you through those hard times.
Just, okay, here it is, there's my checklist, it's done.
That really is something that would get you through and really again then the employing what we, I talked about earlier, about making your users and your customers understand that we're all in this together.
(01:00:40):
And you know, maybe saying, okay, we've got these three people that are dock controllers, these two, so for four hours of the day.
These resources will be devoted specifically to, to this heads down work.
And there will be one person designated for answering ad hoc questions or dealing with with things that need to be escalated.
(01:01:05):
Oh, that's really insightful.
So having time blocks for that.
You know, they talk about switching costs in terms of how people work, that if you're switching a lot of what you do, like say you're answering the phones it's really hard to have focused time during that time.
Mm-hmm.
So I could see if you had a team of dock controllers and you scheduled certain people to say, this is your, this is your long mm-hmm.
(01:01:32):
Uh, moment, and then you have someone else handling the fires, that could be a really great strategy.
Thank you for that tip.
Another, just following on your checklist, I think one of, there's a book called The Checklist Manifesto.
I'm sure you, you probably read it.
It's um, by Atul Gand, I'm probably butchering the name, but he did a deep dive on checklists and it was really a great read for anyone that loves checklists.
(01:02:02):
The upshot of that book is sort of, he was looking at certain things, for example, why are medical procedures so bad? Oftentimes the outcomes as a percentage are so much worse than like the aviation industry.
And so they learn sort of, he teased out that humans are very bad at estimating how much they need a checklist.
(01:02:26):
So there's a reason that pilots who have 20,000 hours of experience flying planes go through a checklist.
It's a very simple checklist like, do you have fuel? And these are the things that have kept our planes flying.
We're gonna have 300,000 plane flights today and none of them are gonna crash, hopefully.
(01:02:47):
And that's where, uh, c check the power of checklists were born in the aviation industry is his example, because it was so critical not to crash those planes.
But other disciplines that have similarly critical things, checklists could really benefit.
And they did some studies where they, for example, with like surgeons, they would use a checklist before a procedure because sometimes they cut off the wrong leg.
(01:03:09):
And the stats on that were not really good.
So the medical industry over the last 20 years or so, and probably as a result maybe of this book, really changed the way that they thought about needing checklists in their process.
So that is a great call out.
I am in love with checklists and the checklist manifesto is an awesome read for those that wanna go a little deeper.
(01:03:31):
Yeah.
Leanne, thank you so much for sharing your expertise with us.
If people hear what you have to say and want to reach out and connect with you, throw you a question, what's a good way to get in touch with you? Uh, the best way would be on LinkedIn.
(01:03:52):
I think you said you were gonna put this in the in the comments.
Leanne Gyer and the name is German for those that who think it's French.
And yeah just contact me there and, and if there's, I'll be happy to, you know, reply whether I can help you or not, but you know, just I will get back to you.
(01:04:14):
Leanne, again, it has been such a pleasure.
I really appreciate you taking the time to share your learnings with us.
I think we've.
A tremendous amount about doc control.
I, I feel much more, uh, inspired about what a cool profession it is.
And thank you so much for coming on the pod today.
(01:04:37):
Thank you for having me.
Thanks for listening to the Major Project podcast.
Be sure to follow us wherever you get your podcasts and learn more at the major project podcast.com.
Until next time, keep building big.
Popular Podcasts
Las Culturistas with Matt Rogers and Bowen Yang
Ding dong! Join your culture consultants, Matt Rogers and Bowen Yang, on an unforgettable journey into the beating heart of CULTURE. Alongside sizzling special guests, they GET INTO the hottest pop-culture moments of the day and the formative cultural experiences that turned them into Culturistas. Produced by the Big Money Players Network and iHeartRadio.
The Joe Rogan Experience
The official podcast of comedian Joe Rogan.
Stuff You Should Know
If you've ever wanted to know about champagne, satanism, the Stonewall Uprising, chaos theory, LSD, El Nino, true crime and Rosa Parks, then look no further. Josh and Chuck have you covered.