Project Manager Office Hours

Hi everybody. Welcome to the project manager meeting for the month of June 2026. I'm going to turn it on over to Heidi. >> Hi y'all. Uh Heidi Banky, statewide project manager with Georgia Legal Services Program. Um I am happy to talk to today about project documents. This has been a question we've got um or that we've received from several people. I don't know if you can also see the buttons that are popping up. Um but I we've gotten several questions about when do I need documents? Uh what documents do I need for what project? Um and the answer because we're in the legal world, we already know it depends. So the idea today is to talk instead of about specific documents, we'll talk more about the conditions under which certain types of documents might be needed. Um, so I'm not going to be presenting templates, but if this group decides that we really want to have certain templates on certain types of things, fantastic. We can build them into LSNAP, I'm sure. Um, especially since Kai's here, we'll just add to your plate. Um but yeah, so without further ado, let's get started. So basics of why documentation matters. Anybody who has done any kind of project management knows you have to if it's not written down, it doesn't matter. Um it's a basic of best practices. You have to not only do it for that document, it keeps historical documents going. Um it helps on a the very smallest level helps people keep clear on the work, understand who's responsible for what and it helps the team stay consistent throughout the process. Um there are uh the project management institute which I refer to frequently because I I am a member and I have a certified project management professional um certification. They have all sorts of things on formal communication plans, formal stakeholder plans, risk assessment strategies and whatnot. you can get drowned in the number of things that they recommend. They also even say you don't need it for every single circumstance. I'm not going to read off the slide because y'all can see it, but there are different factors that would say, okay, this might be something that's a little too much. So, core documents, almost every single project will need this. A clear scope, writing it down is important. just what is the project supposed to do. This helps not only with saying what it does do, but also saying what it doesn't do because it's very easy for other people to be like, "Oh, hey, this is interesting. What if we add this? What if we do this one thing? What if we help with uh this or what were we doing with this again?" Um, so those questions, just having it written down and being able to refer back to it is extremely useful. uh the timeline, knowing when you want to get things done. It's important for obvious reasons in legal aid. I have found that that is most easily accomplished when you have a grant because you have a solid deadline. When it comes to projects that don't have an external deadline on them, sometimes establishing a timeline can be useful. I will not pretend that I have not had projects put on multi-year weights because it's just sat on the back burner, but having conversations about timelines, even if it's as simple as saying, when do you want this part due or done? Um, can help people at least start thinking in the right way about it. Um, and it also helps you be able to say, "Hey, we wanted to get this done by here. if I don't have your answer here, I don't think I can make this deadline. And that helps you move the ball a little bit forward. Um, one, so one of the reasons that I found that forward thinking or proactive projects fail is because you've got all these different fires that are having to be put out. Executive leadership or whoever's in charge is having to deal with that part of it. sometimes it can be hard to get, you know, attention from the other side. Um, responsibility, again, pretty obvious. You want to know who's doing what part of the project. Writing it down allows you to not only say this person's in charge of what, but it also allows you to think more strategically about this person is supervised by this person. Does that person want to be involved in all of these decisions or does that person have more of a hands-off approach? Um, and then risk and issue tracking. This is probably one of the ones. Yes, you want to talk about risk and things that could go wrong or things that could be impacted by the project, the level of risk tracking will change depending on the complexity of the project. So, for example, if you're coming up with an AI uh policy and you have at the same time projects that are against the policy happening or you're waiting on the policy before you can plan it, you're going to end up with a giant roadblock and you you don't know one piece of it is not within your control and one piece is. um three- tiered view. We're going to talk about the different levels at which you want to talk about it um to match match the documents with the project. Um tier one obviously usually essential some are a sometimes thing. Sometime uh tier three is you probably want the formal versions of everything. Tier one we already started talking about a scope plan, a timeline, ownership, and a risk and issue log. The risk and issue log is really more just a bullet point of here's things that might be interfering with the project. Here's things that might come up rub against it. Here's here's potential problems. It does not need to be a formal risk log which without a template it's kind of hard to explain but it becomes a list of itemized things that you periodically check and re-evaluate the level of risk the level of likelihood for it to happen and you address those as it's going on and you check those periodically like monthly quarterly depending on the project. It does not need to be that complicated at tier one. Um, tier two stakeholder list. Especially if you're getting more complicated and you're doing cross functional teams or cross- departmental teams, you need to write down who's involved and what they're doing. Um, how to update people. If there's different types of stakeholders, not every stakeholder needs the same information. So, being able to say this information needs to go here this frequently. Uh, for example, I have a TIG grant right now where we have an advisory committee. That committee meets quarterly and we don't talk to them about all the different little itty bitty pieces of it, but we will update them on the broader picture. Um, a decision log is also a really good idea. This is just adding to the scope. Okay, we've made this change. Here's why. And that helps especially with historical documents because what ends up happening is you get to the end point and then you cannot remember what changed. If you get to that and you're looking backwards, what ends up happening is you you can't figure out if it was a change because of something more efficient for the project, a change because you ran into a wall, a change for some other reason. Being able to document why decisions were made a certain way and be able to say this is when this changed and how it impacted the project becomes much more useful. Um and that also goes into the change log. So decisions and changes at the same time. Um requirements list it's specifically saying you have the scope now let's add the pieces of the scope that must be completed. Um an example would be the scope of the project is to largely do a uh right now we're working on a revision of the clinics module in legal server. The requirement underneath it could be I need to have a report that can give me the amount of time spent on each clinic because we're looking for ROI. So it's a subsection. Um and the training approach this is more of a sustainability thing. You want to be able to when the project is done, show how you're going to train and integrate the project into the wider realm of wherever you're working. And then tier three is when you get extremely formal. You start talking about governance approval. You start talking about um extremely formal communications plans. What is the way that we are going to say things go up and down? Um chain of command. This is when you need that fun risk issue log. Um, compliance and legal review, it's just when you start getting into the point of you have extensive contracts, you have more sensitive information. You have to have all your eyes dotted and your tees crossed. Um, and everything just becomes a lot more you want this communicated effectively and you want it recorded because if you don't, you may run into problems both with that project and then beyond the project. if anybody comes in and completes say an audit. So an example of project scope we've talked about before. I'm going to speed through this one, but it's a document that makes clear what the project does, what it doesn't do, and what success means. It's just clear definition. Um it could be a one-page summary. Uh charter, sometimes people talk about the charter as the project scope. Most of the time in legal aid, just a statement about what we're doing and what we're not doing. I like to have a signature line at the bottom of it. so that the people who are signing off or the people who are making the authorization know this is what we do and we don't do because what happens if a project manager is not the person who's able to enforce the project say if I'm working with managing attorneys in a specific office I can't tell them what to do if I have a scope plan and I say this is what I was asked to do it gives me authority over what's going on um an improved intake form. This is not your statewide intake coming in to the system. This is more of how project changes and whatnot come in. Um and then a workspace entry so you can talk about and continue talking about how things are communicated and changing throughout the project. Um your communications plan. This one I've only included because I think it's communication is the key to project management. Um, and we've talked before in these presentations about how communication is two parts. What is said and what is understood. The idea of a formal communications plan when you're working on a two-eek project with three people is very different than if you're working on a cross- departmental project uh involving your entire program. uh as you get more complex the level of communication documentation that you need is very different. I actually am going to hold up let me find it because there is a very fun chart to show what communications looks like. Um the idea is you know when you have a larger team of people that they are going to communicate in several different ways. You've got IM you uh sorry instant messaging, you've got email, you've got the phone calls, you've got all these different things. So, this is an exam question, but this shows a chart of if it's eight people because eight people can communicate to each other, you've got 28 different communications channels. Um, so as you can see, it gets exponentially higher no matter uh how much you want to try and control it. And honestly, I don't think trying to formalize and rigidly control any kind of communication is possible. Nor do I think it should be an attempt. I've seen people before try and act like this information cannot leave this meeting room. Do not talk about this with anybody else. And at the same time, there's always one person who wants to gossip. Like, it's it's not realistic to try and assume information won't get out. Um, when it comes to having lots of stakeholders, what you want to do is more define what communication is essential for each stakeholder group. This isn't about secrecy. It's about who needs what information when. Um, does that make sense? because communication is all over the place and at the same time the formality of it does need to change and this was the piece I was a little more nervous about hearing nothing I'm going to keep going uh decision test the more documentation is required as people will disagree when there are decisions that are going to be revisited a lot when approval isn't clear when you start running into barriers. You know that formal documentation would be nice. It would have been nice in a previous project. It might help in a current project as you're defining the scope. If you see lots of people having comments or questions, that's when you're thinking, "Okay, I should probably have more." You're overdoccumenting if people are just ignoring it. Don't create documents that are going to not be used or that are going to be ignored. Um, and we all know the people who don't read their emails. So stick with that. And if the other one that's really worth highlighting is if nobody can explain why the document works. Um there's some basic questions about the documentation uh that you can ask yourself. Does it reduce confusion? Does it support decision or approval? Does it reduce work or risk? Will somebody use it? And is the project exposed enough to justify it? Um, all of it really can be summarized to is it helping the project or is it stifling the project. You do not want to spend time making work for yourself. You want to be able to say the focus is on getting this done. So, a practical way to adjust documents um you have your quick check. Think about who's involved. You know the personalities that you're working with usually. You know when you have the stickler for details. You know when you have the person who won't read the emails. You know when you have uh a longer term project and people are going to forget X Y and Z. If you know which types of person persons you're working with be responsive to their needs um from the get-go. And the way that you can approach it is going to be different. I'm going to steal an example from uh Chris Cook. Hi, I see you're on the call. Um where somebody was very against having a project formal plan. They didn't want to create the paperwork. They didn't want to do all of that. Uh so he just went in and basically got all the information through a conversation. So the person had no clue that they were filling out the form just by having the conversation. Um, and since I used your example, Chris, do you do you want to add anything to that? I was highly amused by it. >> Um, just that that happens more often than than one might think. Uh, there's something magical about lawyers where none of us actually want to engage in bureaucracy or and paperwork despite the fact that our entire profession is built on bureaucracy and paperwork. Um, but yeah, so sometimes like you can get the documentation without people realizing you're getting the documentation. Um, you still want to write it down afterward. Um, and then you want to start broad. You get a sense after experiencing several projects of all the different possible things that you can have. It's a lot easier to start with everything and then start chopping things out because they're not useful than to try and say, "What do I need?" Um, when you're starting with trying to add things, it just becomes it's like a rough draft. It's a lot easier to redline something after you've got the first draft. Um, and that's the step to find what fit or decide what fits. Learn from the past. If people have done anything similar to your project before, find it out. It doesn't have to be with your organization. It doesn't have to be the same exact type of project. It could just be a project that worked with the same personalities. Um, but if you find certain things that worked or didn't work, ask for things. Ask for examples there. One of the reasons this group exists is because we all have managed projects. Um, and we've all run into the same obstacles. We really all have hit our head against brick walls. Um and um we're hopefully this group can help reduce concussions. Um but yeah, there's there's a lot of historical examples. You would be surprised at how much people can talk about things. Um and then just a little quick version of it that can be referred to. And by the way, this PowerPoint will be sent out to the team. Um, but if you have a smaller project, you stick with those scope, milestone, ownership, issue tracker. Larger teams, you may want to start to doing the requirements list, the risk list, and the decision records. When you get to the higher risk things, you start adding more formal documentation and you start being ready to prove yourself when somebody higher up comes and says, "Why did this happen?" or "How did this happen?" Um but yeah, so if there's anything you take from this project, it's use what helps, which is a long way of going around to the project, the documents are the ones that work for you. But not every project needs everything. Pick the ones that match. These are the things that help you figure out more about what you need. If you need templates, if you want to talk with people, email LSN tab, email email me, email other people in this. I'll even throw my email in the chat right now. Um, but there are there's a hundred ways that you could go about it. What's important again is getting the project to move forward and not creating documents for documentation's sake. And I have sped through that presentation. Um, did anybody have questions? >> Uh, Melissa. >> Yeah. Uh, not really a question, but I do want to say thank you for the comment that you mentioned with regards to not creating documentation for documentation's sake. I think a lot of the times when it comes to PMing, a lot of people can get lost in um like the recommended structure of how to do things and end up creating a lot of superfluous work for no reason. So, I like that you hit on that. Um I know speaking from the perspective of Tech Think Tank and a lot of the different projects that that we manage, um sometimes we might get requested for certain documentation. and if they ask for it, we'll give it for them, right? But if they don't ask for it and the way that the project is structured really doesn't call for it, there's no need to create it just for the sake of creating it, like you said, so that you don't lose time. Things like static report structures or templates if you're not working on a project that really has key milestones that you have to, you know, hit and constantly fill in with information so that everybody knows where it is. sometimes email communications and just a general update is the better way to do it. So, gauging that um that need for documentation versus a requirement for it um is always a steady line and I appreciate the fact that you mentioned that. >> Thank you. I'm very glad that that is uh respected because I think as Chris mentioned, we are a bureaucratic uh we are a bureaucratic group sometimes in legal aid. Um so, yeah. And then Chris wrote, "You've done it wrong yourself. I'll strongly recommend airing on the side of not enough template rather than too much template." Um, the easier you can make it, the more buyin you get, too. So then you'll have people saying, "Oh, this was easy to work with and this got done." Um, so yeah, and then they'll continue trying to do things your way, hopefully. Any other questions, comments? I'll branch off a little bit on on not enough template instead of too much because we definitely started with way too large of a project charter. Um but you a great many it is far easier to persuade people to do something if they have seen the problem themselves than if you try to rescue them from a problem that has not happened yet. And that is a strong instinct in people who like to fix problems. Like what if I just made this not a problem? And especially as you are trying to convince people that they want to buy in to something that will look to them like this is more work for no value because they haven't seen the value yet. Um it's much better to get the feedback at the end of this hey this worked really well but like your form should be tracking this extra stuff than trying to convince them that it should that they should have taken the extra half an hour to add that stuff in. >> Yeah. And you're touching on something that I think is really important in project management in general. And this goes back to communication. Um, but also stakeholder management. People are more invested if they feel like projects are responsive rather than imposed. And I think one of the key things a lot of people forget is when you're trying at a higher level to think of all the things that could go wrong and creating documents or systems in case of something, >> you're you're going to turn people off versus if you're giving them the things that they are asking for or want or historically you can say this has been easier. um then you've got buy in and you've got more support for your project and that helps sustainability long term as much as it helps anything else. It helps people understand the way that you think. It helps understand that they are contributing to something important um and it keeps people happier and everybody wants happy people. I worked with a lobbyist once who said that um the a key factor in getting a bill passed was to write up the good version and then add some obviously dumb stuff into it because no legislator likes to feel like they rubber stamped something and they will locate the thing that is obviously dumb and remove it and feel like they've done something and now they're invested because they got to participate. Um, and I have a I have borrowed that wisdom for a great many sorts of places in terms of I if I want a bunch of people to care about this thing that they don't otherwise really have a reason to care about from their perspective, can I intentionally put something in their path that will allow them to be a contributor to the process I want them to buy into? I think the essay writing version of that is um hide the word unicorn somewhere in the paper and see if people find it.