Episode 180 –  Fuel Your Project with the Power of Dynamic Documentation

Episode #180
Original Air Date: 07.03.2023

33 Minutes

Listen Here

Our Guest This Episode: Adrienne Bellehumeur

Will your project’s documentation pass the test of time once the project is done and the people are gone? As project leaders, we need to make sure that project requirements are fulfilled and that we can trace what has been done, who has done it, and when it was done. Adrienne Bellehumeur shares how accurate documentation makes teams more efficient and effective. Adrienne says that it is not your technical skills or the latest buzzword, framework, or course that makes you effective in what you do. It is this underlying practice of documentation, hidden beneath the surface of other processes, tools, and methods.

Join us as we discuss some key elements to consider when beginning a project, or how to improve on a project where your documentation is weak. Adrienne talks about finding the right balance on our project teams to ensure that we’re documenting enough, but not too much to the point of overkill. Hear how we can get our team onboard, and some of the best strategies to maintain effective, efficient, and timely documentation.

Adrienne Bellehumeur is the founder of Bellehumeur Co. and co-partner of Risk Oversight, based in Calgary, Alberta. She is an expert on productivity, documentation, governance, risk and compliance. She has 15 years of experience as an auditor, accountant, analyst, problem-solver, and independent consultant. Adrienne developed a documentation approach called “Dynamic Documentation”, and she is a published author of the book “The 24-hour Rule”, which discusses the importance of following documentation best practices and the significance of information management in the current world.

Earn more PDUs with our online course: COLLECTING CUSTOMER REQUIREMENTS (1 PDU)

Favorite Quotes from Our Talk:

"I actually say documentation is at the intersection of information management, organizational design, and personal productivity. So documentation kind of underpins these three major disciplines, but the personal productivity is often forgotten."

- Adrienne Bellehumeur

"So I think documentation is a subtle, sort of nonpolitical and non-offensive way to get people to work harder or work smarter. I use this myself. I don’t criticize the individual. I criticize the documentation."

- Adrienne Bellehumeur

Share With Others

The podcast by project managers for project managers. Will your project’s documentation pass the test of time once the project is done and the people are gone? Documentation is at the intersection of information management, organizational design, and personal productivity. Accurate documentation makes teams more efficient and effective.

Table of Contents

01:23 … Essential Project Documents
03:43 … Defining Information Management
04:34 … Adrienne’s Story
05:59 … Performing an Information Audit
09:19 … Signs Your System is Out of Control
11:33 … Dynamic Documentation
12:44 … Improve Your Documentation
15:19 … Budget for Closing Documentation
16:57 … Finding the Right Balance
19:12 … Kevin and Kyle
20:27 … Strategies for Meeting Notes
23:49 … Have a System
25:54 … Getting Everyone Onboard
27:25 … Documentation No-Nos
30:06 … Personal Productivity
31:06 … “The 24-Hour Rule”
31:41 … Contact Adrienne
32:43 … Closing

ADRIENNE BELLEHUMEUR: I actually say documentation is at the intersection of information management, organizational design, and personal productivity.  So documentation kind of underpins these three major disciplines, but the personal productivity is often forgotten.

WENDY GROUNDS:  Welcome to Manage This, the podcast by project managers for project managers.  My name is Wendy Grounds, and with me in the studio is Bill Yates and Danny Brewer.  We’re talking today to Adrienne Bellehumeur, and she is the founder of Bellehumeur Company and co-partner of Risk Oversight.  She’s based in Calgary, Alberta.  She’s also an expert on productivity, documentation, governance, risk, and compliance; and has delivered 15 years’ experience as an auditor, accountant, analyst, problem solver, and independent consultant.

Adrienne developed a documentation approach called “dynamic documentation,” and she’s a published author of the book “The 24 Hour Rule,” and she’s going to tell us more about that book, as well.

Adrienne likes to talk about processes, tools, and methods, and some of the best strategies to use to maintain effective, efficient, and timely documentation.  So as you may have gathered, we’re talking about documentation and information management.  So Bill, my question to you is what are some essential project documents that project managers should be maintaining?

Essential Project Documents

BILL YATES:  Oh boy, the list goes on and on.  They’re all essential, every one of them.  Let me start with the legal stuff first.  I think project managers who’ve ever done work with, either with outside contractors or their customers, an external customer, they would agree anything related to contracts, addendums, agreements, even the email threads where those may have been negotiated or key decisions were made, those should be considered mandatory.  You’ve got to have those backed up.  They can’t just be living on your hard drive.  They need to be backed up.  Also things like the project charter, anything with signatures that gives authority to the project.

And then kind of going down the list, there’s scope things like requirements, scope statement, the product roadmap, the backlog, change requests, logs that keep up with things, task lists, or issue logs.  These are dynamic.  These need to live.  So you have to document them almost with a date stamp on them.  That’s true with a risk log or risk register, as well.  Major communications, major rollouts, maybe you hit a milestone or something significant, you want to keep those documents.  Think about, okay, could someone who doesn’t know anything about this project take a look at it six months, two years later and go, “Oh, okay.  Yeah, I get it.  I see why you guys made that decision.  I see who was involved in it and then what action took place after.”

And then one of the biggest challenges, and I think we’ll hear this from Adrienne as well, when you’re getting ready to wrap up your project, that is one of the most difficult times to make sure that you’re doing good documentation.  It’s like more important than ever.  It’s almost like think about when you move into a house.  You have this checklist, the punch list, the final step before you go sign those contracts to own the house.  Well, for our projects, too, we’re trying to wrap things up, but we’re losing key resources.  The team is starting to get dispersed to more projects, and we have to gather that information out of their head and make sure that it’s been documented somewhere for future, for lessons learned, both for this project and into the future.

WENDY GROUNDS:  Thanks, Bill.  That’s a lot to keep in mind.  Let’s see what Adrienne has to say, and let’s get some advice from her on how to correctly manage our information and our documents.

Hi, Adrienne.  Welcome to Manage This.  Thank you for talking with us today.

ADRIENNE BELLEHUMEUR:  Thank you.  Thank you so much for having me.

Defining Information Management

WENDY GROUNDS:  Yeah, the first thing is, I think just to kind of put an explanation out there, could you define what information management is really all about?

ADRIENNE BELLEHUMEUR:  So information management is basically the management of existing information.  If I have this piece of paper here on my desk, and I do something with it and put it in the right spot, I’d call that information management.  It’s actually a wide range of things that can be anything from organizing the files on your computer all the way up to an enterprise content management for a multinational company.  So it actually has a wide range.  Information management is a close cousin of documentation, which is my area of expertise, but a very wide discipline that often incorporates a lot of technology and tools and metadata and taxonomy and stuff like that in practice.

Adrienne’s Story

WENDY GROUNDS:  So where does your interest in information management and documentation originate?  How did you start out?

ADRIENNE BELLEHUMEUR:  Oh, that’s a great question.  I mean, it spans many years.  I actually had a bit of a nerdy fascination with notes, taking notes in class.  And I remember having lots of cool notebooks, and looking around the classroom, wondering what are people doing with their notes.  This interest actually spanned throughout my career.  I’m a chartered accountant by background.  And I do remember how important documentation and managing information is in the workplace, and how actually poorly we train people when we enter the workforce.  So I’ve had a big interest in helping people to be better trained because I actually didn’t think the training was that good.

And then as a business owner and consultant, I watched so much money being wasted in companies by consultants leaving without anything written down.  People can’t find documentation that they spent millions of dollars on a project, tons of money on resources that we have meetings and no record of what was said, and we can’t remember.  So this kind of threefold reason, it’s actually spanned many years.  I’ve seen so many patterns of a need for students, professionals, the knowledge workforce to have a better understanding of this practice.

Performing an Information Audit

BILL YATES:  This is so good.  I feel like we’re going to the doctor today.  And you are our specialist.  But let me just start out with this idea of an information audit. For our project managers that are out there, let’s say you performed an information audit on one of their projects.  What questions would you be asking the project manager and the team in that audit?

ADRIENNE BELLEHUMEUR:  Often information audits are really tied to a problem you’re going to solve.  So if people can’t find something, or they’re struggling to get people to document, or Larry built your system from scratch and is retiring in two months, or Sally is the only person who knows how to run critical process.  Like I’m often brought in for very specific problems.

But if I were running a more generic audit, which I do, I really focus on how users interact with their information.  I ask questions like what information or knowledge do you care about if someone won the lottery?  We don’t say “hit by a bus” anymore.  We say “win the lottery.”  What is actually getting used or not?  Can people follow, I call it the re-performance standard?  Can people use the standalone documents to actually do their job?  Or, and this is applicable to project managers because they often have to hand it off to others, it has to meet that re-performance standard.  Can it meet the clarity standard?  Do people understand what you mean without having to interpret it?

The operative word I’m getting at here is “standalone.”  In today’s workforce, we need to build documentation systems that people can use the content and materials.  And this is broad, too.  It covers stuff like video and systems, SharePoint, everything.  When I say “documentation,” I’m not necessarily meaning a piece of static paper, but they have to be able to find things, understand, do their work, basically in the absence of the people who built them.  And this is just a new reality of the workforce.

We have a new knowledge-based economy geared to how a project’s documentation and systems will sustain once the people are gone.

BILL YATES:  I love that you use that keyword of “standalone.”  To me, I think that’s important to point out because I know I have certainly been a guilty party and thinking, okay, I was in the room when we made this key decision with the customer.  This defined the scope that we ended up delivering.  And I can just make some basic notes because I’ll remember just enough to jog my memory.  Well, that’s not really standalone.  Let’s say I get assigned to a different project.  To your point, it needs to be something that someone can pick up and read without me explaining it or without me being on the other end of a call.  And it needs to be standalone.  And I think in many times I have not documented to that level.

ADRIENNE BELLEHUMEUR:  In general, you start off really strong on projects.  There’s lots of stakeholder analysis and communications plans, and plans, and templates.  I mean, there’s no shortage of that material.  It’s usually the everyday notes, follow-up, and then the closeout where in my professional experience you have the most issues when it comes to documentation.  But the start, if you have a good project manager, the start is usually well done.

Signs Your System is Out of Control

BILL YATES:  Yeah, that’s good.  When you’re engaging with a team leader what are some of the signs that you see that says, okay, I think their system is either there’s not a system or it’s out of control?  What are some of those signs?

ADRIENNE BELLEHUMEUR:  Well, companies or teams or departments, they follow about five stages of documentation.  Number one or two is kind of, you know, just getting off the ground.  You could see this if a project is starting, a team is starting.

Stage three is where you’re going through the motions.  And going through the motions is, I’m doing this project plan because I have to, my boss says I need to, you know, you know, our steering committee says we have to do this.  I’m doing it.  My lawyers say I have to do this, so I’m going to do this.  Our auditors need this document.  Really just going through the motions style of documents.  That is actually a sign of a problem because you’re not getting the value out of it that you want.

Stage four is my ideal stage.  That’s where you are actually getting – documentation is driving change.  You write a business case, and it makes a decision happen.  You have a plan, and people follow it.  That is about driving the right behaviors.  It has nothing to do with being perfect.  It just means you’re driving the behaviors you want.  Stage five is my other warning area, and that’s where it’s overkill.  So if you ask me the two areas I see challenges, stage three, going through the motions, is very dangerous because you’re kind of not getting the value out of what you’re doing.  Stage five, overkill zone, is where documentation is actually becoming a hindrance.

If you have really lengthy procedures, you see this a lot in policies, really overly burdensome policies, people are not likely to follow them.  It’s same with project plans.  If you have an overkilled project documentation, project plans that have every little detail, that’ll also kill your ability to move forward.  And I think I see this pattern repeat quite a bit with going through the motions or overkill.  And I would say watch out for those two stages. Going through the motions people don’t really care about, but they do it.  Or overkill, someone who’s just a real detail lover, and it’s to the detriment of your project, yes.

Dynamic Documentation

WENDY GROUNDS:  What do you mean by “dynamic documentation”?  It was something you developed.  Could you explain that a little bit to us?

ADRIENNE BELLEHUMEUR:  Sure, Wendy.  So the name “dynamic documentation,” which is kind of the approach I teach, it’s not because it sounds cute.  It’s actually very intentional.  “Dynamic” is about moving forward.  Have you guys ever had the experience of working on a team that doesn’t write anything down?  Yes?  Okay.  Bill, you have.  What happens generally?  Well, generally the opposite of dynamic.  You move in a circle, right?  So I’m a believer that documentation should drive action.  That’s really the bar you want to hit.

You document, if I write “Call Mom” on my to-do list here, am I more likely to do it?  Yes, I am.  Documentation has for a long time been viewed as static – metadata in a database, files in a folder, dusty piles of binders.  But when it’s dynamic, that’s actually where the magic happens.  You’re driving yourself in a forward state of action.  This is extremely relevant to project managers that should almost always have this kind of litmus test in their brain to use documentation to put them in a forward state of action.

Improve Your Documentation

WENDY GROUNDS:  So if you’re running a project to have a good set of project management documents, it’s certainly going to pay off in the end.  What are some key elements that are important to consider if you’re beginning a project, or if you want to improve on a project where your documentation is weak?

ADRIENNE BELLEHUMEUR:  So this is a big one.  My recommendation is to set up a good structure for managing documentation throughout.  Like meeting notes, and how the documents actually become dynamic.  If you meet, where does it go?  Like that’s where I see most of the issues on projects.  It’s kind of that middle zone, or in the closeout, too. 

It’s, I mean, the reality is you need budget if you want to do a thorough closeout.  Sometimes you get a good budget to do a great cleanup, and it’s a great opportunity to practice information management best practices where you clean things up, get them usable and pushed out in the right direction.  I would almost say plan for the closeout and plan how you’re going to manage documents throughout, and how information flows throughout that project.  In general most project managers that are trained do the initial part pretty well.  But it’s kind of that middle zone, and it’s usually losing meeting notes, not having a system to kind of take those notes and fire them off in the right places if things get lost throughout.

BILL YATES:  And I’m going to go back to that adjective that you used, “dynamic.”  I think that’s a key for project managers is remembering that the information, the documentation should drive action.  This isn’t just to cover your backside in case something comes up…


BILL YATES:  …six months later.  This should be actionable.  This should be something that, okay, either we made a key decision, here are the actions that come from that.  And I agree with you.  I think it’s in the middle of the project, and then a scary time at the end where that’s where we can kind of get off our game and get off that rhythm.  Because to your point, in the rhythm or in the middle of the project, you can have significant risks occur, or you just have a lot of execution.  You got your plans built.  You documented a lot of those decisions early on.  And now you’re executing. 

But yeah, you’re also having things that work and things that don’t work.  We need to document those so we’re better in the future.  Then on the end I’ve seen that over and over where you have this inertia of delivering the project, finishing it up.  You start to lose team players.  Their information walks off to another project.  So capturing that at the right time is important, and somebody has to stay on top of that.  And it’s up to that project manager. That takes a lot of discipline.

Budget for Closing Documentation

ADRIENNE BELLEHUMEUR:  Absolutely.  And information shifts over time.  And when a project closes, there’s a dramatic shift to the nature of all that documentation and knowledge that you’ve built.  Something that used to be for the project now shifts to operations.  So even just basic principles of information management, information does shift at critical junctures.  And a project close or a critical stage is a great time to revisit your documentation and to kind of parse it off into its rightful home, or get rid of some of it.  But budget, and it’s usually the last thing in the world people want to do.

And unfortunately, we don’t always compensate people for this, as well.  We might congratulate the project and getting the system in, but kind of almost not give that compensation and reward to all those people that make the documentation correct so that it saves the company time and money in the future, unfortunately.  So that is a little bit of a disconnect in the project world, at least in my travels.

BILL YATES:  No, it’s so true.  One of the terms that we talk about a lot with IT projects is “technical debt.”  And we sometimes in our efforts to get to market as quickly as possible to finish up this software, to finish up this project, we don’t take the time to document as we should, or we don’t take the time to refine the code and then document it.  And through that, we’re just building up technical debt that eventually somebody’s going to have to pay for, either the customer will pay for it or we’ll pay for it with our maintenance and whatever system or whatever group inherits this project and has to keep the product going after the fact.

Finding the Right Balance

 Now, we asked you for a couple of indicators of problems when it comes to documentation.  And one of those that you mentioned was overkill, which I completely agree with.  That brings me to the question related to Agile and trying to find the balance.  Within Agile project management, there’s this notion of barely sufficient documentation.  And there it’s talking specifically about software code, you know, barely sufficient documentation of the software code so that somebody, a different programmer or team can come in later and see, how things are structured and why the code was written the way it was, if there is a problem, or if there’s even an enhancement that the customer wants us to make.  So there’s a sense of barely sufficient documentation.

Adrienne, some people look at that and go, “Hey, that means I don’t have to document anything.  My project’s Agile.  I don’t have to document.  All I have to do is deliver value.”  But we know that’s not true.  So talk to us a bit about this finding the right balance, not the overkill side, but also not neglecting documentation. 

ADRIENNE BELLEHUMEUR:  Yeah, I will go back to my very simple benchmark.  Does your documentation drive action?  Really, it’s actually a remarkably powerful benchmark.  If your documentation is in a state of overkill, it’s actually less likely to drive the action or behaviors that you’re looking for.  You see this again in policies, procedures, project plans that are overkilled.  You’ll see less action driven out of them than the right-sized amount.  I’m a firm believer in Lean in general – Lean, Agile, call it what you want.

If people aren’t using your documents, if they aren’t engaging with them, if your system is so cumbersome that they can’t find things, if it’s too complex to get on your repository or your SharePoint site you built or your Internet or other enterprise content systems, then you’re in the overkill zone.  Anything that detracts from usability and the ability to drive action is a good indication of overkill.

And a lot of documenters are perfectionists. I don’t think everything has to be perfect.  That unfortunately is a misconception that, if we document it, it has to be absolutely gorgeous and perfect.  It’s more about just doing something to drive action.

Kevin and Kyle

BILL YATES: Let’s take a break from this conversation, jump over to Kevin and Kyle, and see what they’re up to.

KYLE CROWE: For a new project manager, collecting customer requirements can be a daunting task. But, it’s far too important of a task to skip or rush through! If you don’t know what your customer actually wants, you can’t really plan your project. Understanding the requirements of the project helps us to determine the resources we need, the cost, and the estimated timeline as they all relate to our project.

KEVIN RONEY: There’s a great quote by Eric Ries that comes to mind: “We must learn what customers really want, not what they say they want or what we think they should want.”

When capturing our client’s needs, we should also evaluate how each requirement impacts the other requirements, so we can come up with the most efficient way to solve the problem.

KYLE CROWE: Here is another tip when discussing your client’s requirements. It’s very helpful to separate the “must-haves”, from the “nice-to-haves”.  If their requirements have not been accurately determined, ranked and then documented, your project which is intended to help satisfy those needs will almost certainly be unsuccessful.

KEVIN RONEY: Velociteach offers a very helpful course about COLLECTING CUSTOMER REQUIREMENTS by Harold Samson. This course teaches methods for collecting customer requirements, including how to ensure each requirement passes the SMART Test. If you want some helpful tips on the proper approach to collecting customer requirements, check it out.

Strategies for Meeting Notes

WENDY GROUNDS:  You said earlier about just making sure you know where things go was important.  Like you say, you finish a meeting, you have documents, somebody’s taken some notes, and then where does it go?  How can we develop some strategies within our teams?  How can we encourage our teams to be better and maybe keeping effective reports during meetings and planning on where they go to? 

ADRIENNE BELLEHUMEUR:  So I think notes, and I take a broad view or definition of the word “notes,” is fundamental to all documentation.  And obviously meetings are a big part.  Some project managers spend almost all day in meetings.  That’s a whole other topic, whether that’s a great use of their time.  But it’s true.  Meetings are a huge source of information.  They can be a huge information time suck, as you know.  So you need a practice of taking notes in meetings.

So number one, you just need discipline.  I believe that there are different styles of taking notes.  There’s one that’s called the floodlight, which is like a broad way.  You almost take it like a minute style, and you write as people talk; or a flashlight, which is about having very specific little tips for drawing that 20% of the meeting that matters to you.  This is actually the way that human attention span works.  You can either take notes broadly, almost writing as people talk, or flashlight style.  That’s how your attention span works.  So the way you take notes should kind of emulate that.

So first of all, have that practice.  That’s step one.  A project that does not have a good discipline for reading notes, really you can see these runaround discussions.  I call them “groundhog day discussions” where you’re spinning on the same topic over and over again.  If you sit in a meeting, and you’re just like, “I swear we had this meeting two days ago,” or “I feel like I have déjà vu here on this project,” or “We’ve had this same conversation from about 20 different angles.”  I mean, groundhogs are a real problem in organizations, and especially projects.  And documentation, especially notes, is one way to stop it.  You have to get things on paper.

So Wendy, to your comment about where you put things, this is a hot topic about where you put things because now we have Teams and we have SharePoint.  We have so many easily accessible repositories.  But the concept is still the same.  I mean, if I put my keys in the same spot every day, I’ll probably find them; right?  Information management is actually not that complicated.  You need approved repositories.  So step one, you need to say, “This thing goes here.”  And even sophisticated organizations with complex information management, people miss that very basic point.  If you consistently keep things in an approved repository, that’ll help you.

And you also need, I call it “controlled information.”  It just means you’re very clear on what you control and where you put it.  So I could go into more information management principles, but you’d be surprised how far you can get by just being very clear on what you’re going to control and where you’re going to put it.  And all the talk about all these different channels and everything, they’re just throwing more complexity at really a problem that’s been around forever.  It’s just, “Okay, where do I put my keys?  I put them here, and I’m going to find them.” 

Have a System

BILL YATES:  Yeah, I completely agree. You know, regardless of what system you’re using, to your point, it doesn’t really matter as long as you have a system; and as long as, yeah, you’re consistent with it.  I think back to, This is back before I was working with Velociteach, and we had software that utilities were using.  And Wednesdays in the morning I had regular meetings with two active projects with the customers.  One was Verizon; one was Pacific Gas & Electric.  And the meetings were back-to-back.  And it was a status meeting.  It was an update.  You know, okay, what are you guys working on?  What are we working on?  What is the status of these different action items?

At that time, it was a simple spreadsheet.  This was years ago, so we weren’t using Asana or any other nice software, some of the options that we have today.  But we had a spreadsheet that we would keep between us and the customer.  We would update it.  And that was where we documented.  That kept us away from those groundhog days.  We could say, “Hey, what’s the status of this big decision we have to make about how to handle this particular group of assets in our system?”

And we could look at it and go, “Okay, yeah, all right.  It was in your court Thursday, that email that we sent.  Have you guys made a decision?”  “Yeah. Here’s a decision that was made. This is how we’re going to treat it.”  Perfect.  So now we go make our code change or reporting change or whatever.  That way, it was a living document. It was, dynamic.  It was actionable.  And then, again, six months, two years later, if somebody came back and said, “Hey, why did you guys set this up the way it is?”  We had a reference point that we could refer back to.  It avoids the, “Okay, we’re reliving this.  Why are we talking through this again?  What’s the history on this?”

ADRIENNE BELLEHUMEUR:  It’s a major source of waste in organizations.


ADRIENNE BELLEHUMEUR:  Groundhog.  I’m not going to sugarcoat it.  I think it’s one of the worst wastes of time, other than losing information that walks out the door.  That’s tragic.  But this is another waste of knowledge, is having great ideas discussed in meetings.  They never go anywhere.  My whole point is to have a dynamic nature of documentation that captures and moves things forward so we’re not spinning in a circle.

Getting Everyone Onboard

BILL YATES:  Adrienne, when you see the team as a whole embraces this, they see the importance of it.  They have a system.  They’re all using it.  But there are just a couple of team members that don’t seem to always be consistent with updating those documents.  What’s your advice to that team leader what kind of encouragement can they use to kind of get them onboard with the rest of the team?

ADRIENNE BELLEHUMEUR:  So I think documentation is a subtle, sort of nonpolitical and non-offensive way to get people to work harder or work smarter.  I use this myself.  I don’t criticize the individual, I criticize the documentation.  So in a roundabout way, you can require people to document.  It actually will, by osmosis, get them to work smarter and harder. I do find people have had such poor training in documentation in general.  It’s not engaging.  We have to remember how most of us were trained in the workforce how to document.  And I’m a chartered accountant.  I came from Big Four.  Like they had pretty top-of-the-line training, but it still was pretty dry.

So there are a lot of people in the workforce unengaged by documentation.  And I do think that’s a problem, the way it’s been taught.  So part of my mission is to make it a little more exciting for people and not to overburden them, and not to bury them in technical requirements.  In general you can control documentation, and it is a way to actually getting them to work smarter and better in a non-offensive way.

Documentation No-Nos

WENDY GROUNDS:  What are some things that you see people doing that are just documentation no-nos that they should not be doing on their projects?

ADRIENNE BELLEHUMEUR:  Now, the title of my latest book is called “The 24-Hour Rule.”  The basis of that is actually how humans process information.  We process information very well in 24-hour spurts.  So what people do incorrectly the most is that they wait too long to write things down.  After about 24 hours, 24 to 48 hours is where we really, our short-term memory does a major dump of information.  So if you finish a very important strategy session for your project, and you might have taken some rudimentary notes or typed them up, don’t delay past 24 hours to write them up, reflect, synthesize that information, or you will probably forget a lot of nuance that was said.

Now, this doesn’t mean you have to write a perfect strategy document after, but it means you have to take some reflection time to do something about it.  It is one of the biggest mistakes I see, obviously not just projects, but operations, where we don’t document in a timely manner.  And that could be notes.  It could be you had an idea.  You heard something in a webinar that’s life-changing.  We just don’t do anything with that information.  You actually kind of have to do something about it in the 24‑hour window to make it valuable.

So this idea of actioning information in the right window and even planning your workflow accordingly.  Of course, in today’s corporate world we jam people in meetings all day, don’t give them enough time to reflect.  That’s a whole other challenge, but that’s putting too much stress, and it’s actually hurting our productivity.  So getting a bit in the productivity zone here, but it’s a problem on projects when our project managers are just too buried in meetings to actually have time to reflect. 

BILL YATES:  This is right in line with a book that I’m reading.  It’s not a project management book, but it completely aligns with what you’re talking about with memory.  And the book is by Matthew Walker.  It’s called “Why We Sleep,” and it goes deep into the science of sleep.  One of his points lines up perfectly with your 24-hour rule, which is our brain’s great at taking in all this information during the day.  And then at night while we’re sleeping, the brain decides what to store in long-term memory and what to get rid of.  You sleep a couple of nights, and you’re not going to remember some of those detailed nuances of that meeting that you were in two days before that drove a major decision for your project.  So best to capture it while the memory is fresh.

Personal Productivity

ADRIENNE BELLEHUMEUR:  Yeah.  And you see that pattern repeat a lot actually on projects.  I would say it’s almost our personal productivity practices tied to documentation that is the biggest challenge.  And if you action things in that 24-hour window, you’ll improve your documentation.  You’ll improve the action.  You’ll improve your communications.  You actually need to plan your calendar so you can give yourself that time, yeah.

WENDY GROUNDS:  Yeah.  The whole of documentation is so tied into productivity as well as time management.  Just go hand in hand.

ADRIENNE BELLEHUMEUR:  So that’s a really interesting point.  I actually say documentation is at the intersection of information management, organizational design, and personal productivity.  So documentation kind of underpins these three major disciplines, but the personal productivity is often forgotten.  In our corporate world, we get so caught up with what the lawyers want and the auditors want, and this is the template you need to use.  We kind of forget about how closely it ties to our productivity for us and our teams.

 “The 24-Hour Rule” 

WENDY GROUNDS:  You’ve mentioned your book, “The 24-Hour Rule.” 

ADRIENNE BELLEHUMEUR:  Yes, This is the first mass market book on documentation.  Documentation has been taught kind of in silos, quite honestly.  We teach PMs one way; we teach lawyers another.  We teach business analysts one way; auditors another way.  This is about the fundamental best practices for today’s knowledge workforce.  And it’s kind of a fun read actually on this very dry subject, but I’m trying to make it a sexy topic.  I believe it’s super important for the workforce, and there are ways of making it more engaging.

Contact Adrienne

WENDY GROUNDS:  If our audience has some questions for you, what’s the best way they can reach out to you?

ADRIENNE BELLEHUMEUR:  They should find me on LinkedIn, Adrienne Bellehumeur.  I will be sure to follow them back.  My website is BellehumeurCo.com.  That is my personal website where I do documentation speaking, training, and information management work.  I have a CPA firm, as well.  It’s RiskOversight.ca.  And we do compliance and risk work largely in the Alberta region.  So there are lots of ways to reach out to me.  I’d love to connect with any of your listeners for any questions.

BILL YATES:  Thank you so much for your time and for your advice.  This is something that, again, I’ll draw the analogy.  You have been the doctor in-house today, and this is a necessary annual checkup that all project managers need to have to think about their documentation practices.  What are their good habits?  What are their bad habits?  And what do they need to look at?  So thank you for your advice.  I really appreciate it.

ADRIENNE BELLEHUMEUR:  Thank you so much.  This was great. 


WENDY GROUNDS:  That’s it for us here on Manage This.  Thank you for joining us.  You can visit us at Velociteach.com where you can subscribe to this podcast and see a complete transcript of the show.  You just earned your free PDUs by listening to this podcast.  To claim them, go to Velociteach.com.  Choose Manage This Podcast from the top of the page.  Click the button that says Claim PDUs and click through the steps.  Until next time, keep calm and Manage This.

2 responses to “Episode 180 –  Fuel Your Project with the Power of Dynamic Documentation”

  1. Sandeep says:


    Great presentation. No one wants to do documentation as it is a thankless job. When the documentation is good it not only saves time, but reduces error down the line. You brought great energy into this topic with many suggestions.
    The first one emphasizes the right amount of documentation about Stage-4 as the Goldilocks level, while stage-3 being not enough and stage-5 being an overkill.
    The second one emphasizes the 24 hour rule to write down your comments while it is fresh in your mind. I am actually implementing that rule to write these comments as a reply to your podcast.
    Bill also added nicely about the book he read.
    One idea that came to me after the podcast, and that is to test the documentation for its usefulness by creating test case questions. These questions are generated by the project team members. Both the team members and new members to the team can use these questions to see if the documentation provides the required information.

Leave a Reply

Your email address will not be published. Required fields are marked *