The People, Process, & Progress Podcast - How to Become Irreplaceable as a Project Manager with Donna Gregorio, PMP | PPP #92

Episode Date: October 24, 2021

Sharing Donna Gregorio's 30+ years of Project Management and leadership experience through a great conversation on how Project Managers should seek to become irreplaceable not irrelevant, the importance of conducting "get well checks" on your projects and more practical tips for new and experienced Project Managers alike.

As PMs, we often get wrapped up in creating schedules and developing administrative details rather than focusing on project execution. Although doing what we are told, the status reporting PM services can become extraneous. PMs need to be irreplaceable, not irrelevant. With so much to manage, how do you know where to focus your energy? How do you know which game changer techniques to use in each phase of complex projects to drive your energy? How do you know which game changer techniques to use in each phase of complex projects to drive project success? Well, fortunately, on People Process Progress episode 92, The Successful Project Manager with Donna Gregario, we are going to hear from the author who wrote those words and who wrote the book, The Successful Project Manager. But first,

please silence your cell phones, hold all sidebar conversations to a minimum, and we will get started with People Process Progress in three, two, one. Hey, everybody. Welcome back to People Process Progress episode 92, the successful project manager with Donna Gregorio. Donna is going to share with us her 30 plus years of project management experience. We'll talk about the book and a few other topics. We're really lucky to have Donna. Donna, thanks so much for being on the People Process Progress podcast. Kevin, it's a pleasure to be here. Thanks so much for having me. I'm a big fan of what you're doing with the podcast and elevating project management as much as we possibly can. And the whole business analyst career avenue. Those two avenues are very closely tied together,

and we'll talk today about how they overlap. But I'm very happy to be here. As you mentioned, I'm a veteran corporate IT manager and a recent author, so I'm excited to talk to you a little bit about the book and some of my experiences with project management. So let's get started. Yeah, no doubt. Yeah. And I like, and we'll get into this too, the kind of practical nature. And when we touched base before, it was good to just connect and talk about. And again, we'll dive into some of that. But before that, let's learn a little bit more about you. I understand, and folks may guess from your accent that you're not from the South. So where did you grow up and kind of, you know, what's a kind of quick history of what got you to, because we'll kind of start, you know,

get up to where you were doing some, you know, business analysis and things like that. But where are you from and where are you found these days? Yeah, you can hear my Boston accent. It's pretty strong. Born and raised Massachusetts. I work at the MITRE Corporation, which is a federal contractor. We manage several federally funded research and development centers. I'm in IT. We're about a 10,000 person organization. And so our domains range from aviation to military to healthcare, different organizations. And really, my background is in computer engineering and my technical IT project management skills really started out as a software developer and kind of morphed into project management over the last, I would say, decade or two decades. I should say it's been a while now that I've been in the project

management area. I'm particularly a big fan of reconnecting with tools, getting back to basics, and in addressing challenges and what matters most to achieve really those positive results on projects. And as you mentioned in the paragraph that you read there, the key really for project managers is to become an irreplaceable team member, one that really people rely on for all of the answers. And I think that's a challenge in today's corporate environment, some of the complexities of the projects that we're on. I manage the Department of IT project managers and systems and business systems analysts. And I really like to guide my team as well as much as I can through constant change, which is really a fast paced environment in today's commonplace, changing, fast changing. We've got cloud, we have AI, we have lots of new technologies coming on board, and we have zero trust, we have security, cryptocurrencies, all these things that we have to be worried about today.

And it can get overwhelming. And as a project manager, I feel that I'm often looked on for recommendations to move forward. I'm asked the tough questions, and I have to have the answers. So I'm here to give you some of my experiences with those things and some specific examples of challenges that I've had and how we've tried to address them. Some cases we were successful, some cases we were not successful. So that's what I think that my background is. And as I said, born and raised in Boston and been at MITRE for a long time, over 30 years. So that's my background. That's awesome. And a couple of other tidbits that we talked about with you. You also have a family member that's in the podcast business. That's right.

If you want to mention that and give them a shout out real quick. Yeah, shout out to No Filter Friendship. My daughter, Jen Gregorio, and her friend, Haley McNutt, are the co-hosts of that. They've been at it for about a year now. And their podcast is all about maintaining friendships and how difficult that can be and the issues that you can run into when you have friends near and far, friends from long-term friends that you've had for many years, new friends that you're meeting at work, and how to navigate that whole area. She's from a different generation than I am, of course, and so I think there's a lot of really good insights that they have.

So, yeah, give them a shout-out. Give them a listen. and so I think there's a lot of really good insights that they have so yeah give that give them a shout out give them a listen no filter friendship is the name of their podcast that's cool yeah I imagine that topic's been very interesting between you know politics COVID staying connected all these kind of things with friendships and changes so yeah um no filtered friendships check them out uh and then another another thing that i think is is and you tell me too is being a musician yes yes i am a band member i am the lead singer and rhythm guitarist for my band we play at work there's four of us we all work at mitre we play at mitre we perform at mitre we don't play outside of mitre at all because one of my band members has some pretty serious um stage fright so he doesn't

like to perform in front of huge groups so uh we we keep it small and uh it's great we have a we have a great time we've been doing it for about seven years believe it or not um had to take a break during covid which is sad it's the one thing i really missed during that time but we're back at it now we get the band back together and uh we've got a rehearsal next week so i gotta get practicing well that's great and and i can you know in my head as as i do and i'm sure you do and others may be listening to is parallels of things right and being in a band me, is a can with all the different instruments and expertise and coordination to projects.

Yes. You know, you've got to be in tune, you know, and folks take the lead at different times. And guess who the project manager is? It tends to be me. I'm the one that schedules all the rehearsals. I run all the practices, and I, you know, I keep everybody together as per usual. I think that

they would be surprised if I didn't do that. It's kind of expected. My daughter just got married and that was another big project management undertaking, man, oh man. I had all kinds of spreadsheets and schedules and timelines, as you can well imagine. So, yes, I mean, I think project management rolls into lots of things that we do in our everyday lives, and it sure does come in handy, although I think sometimes I can overdo it. I'll speak for myself. But it's kind of a – it's born and bred. It's inside of me, and it's what I do every day. So I enjoy it.

I do. That's awesome. And like we talked about before same thing and and my family i remember growing up uh mom with the lists going to the mall christmas time presents my wife same thing and um you know we we are both project managers or she was uh i still am as well so yeah there's there's a planning that happens uh here as well so that that's cool and i think um you know we'll enjoy sharing that kind of knowledge as well as we go through this. So, yeah, one thing that I thought of, too, when you mentioned coming from a very technical side. So you were pretty familiar with the computer aspect, having requirements, getting technical things.

Do you feel like that helped shape your kind of transition, I'll say, you know, to doing, you know, as a business analyst, so knowing maybe when you've gotten good requirements or not, or how was that transition going from what sounded like a very technical thing to someone that's trying to help gather that technical information to then, you know, relay that maybe to the PM or the rest of the team? So, that's a really great question and a great segue into this discussion. So I do think that I started out as a business systems analyst and spent a lot of years doing technical requirements, doing work breakdown structures, and doing the kinds of things that a business systems analyst has to get involved in. One of my bigger projects that was really successful during that time was a process improvement activity, right? I mean, those of you who are business analysts in the audience can

relate to that, how I was able to reduce the amount of time it was taking for a particular process to be executed. And I think that when I moved into project management, I recognized the need for a lot of those business analyst skills to partner with the project manager. So I see a lot of project managers in my organization who really are coordinators. So what I mean by that is they keep track of schedules and they schedule meetings and they take notes and they report up to executive management. And that's really the extent of their expertise on the project. Maybe there's a racy diagram.

Maybe they keep track of a risk register. But for the most part, they're not embedded into the program and really understanding what the project is all about and knowing what everyone on the team is doing and actually delegating those responsibilities, driving the mission forward, generating metrics to prove success, helping with the change management, presenting and briefing and demonstrating and getting in front of management, that's a lot of the role of what would traditionally be a business systems analyst. But meshing those two roles together is really, I think, one of the best ways to become irreplaceable on the project. So let me give you a quick example. When you start out any project, big project management effort up front, lots of schedules, risk management, problem definition, business cases, project charters, all those things that you typically do at the start of a project. Then as the project starts to get into execution, there's less of those kinds of things that you need to get involved in, particularly if you're in an agile project. And I think we'll talk about agile a little bit later on. That's when some of the business analyst tools start to come into play. That's when you need to start to do some journey maps, some workflow diagramming,

some work breakdown structure details, start to really get into the project. And I think that execution phase is really when the business analyst tools start to kick in. And sure, there's status reporting that has to be done. That's usually the role of the project manager. But you can't spend all of your time doing status reporting. That's when you start to become irrelevant to the program. If you're not actually moving the project forward, then I've seen it happen in the past where a project manager can become irrelevant and actually moved off the program because they're not really adding value in the eyes of management in the eyes of the stakeholders so I do

think that combination of those two sets of skills both a business systems analyst and the project manager skills make for the best project manager on a project. And I think we'll talk a little bit more about some examples of that. Yeah, absolutely. And so, you know, that's a good point. And I see both. I've seen it in my work that we had coordinators. Now we have associates and PMs and then senior PMs. But I've seen in other places like Reddit, PM, subreddit, you know, basically all these different forums, folks that want to come into project management or they're in it and looking at kind of the positions and, you know, what responsibility kind of lives where. And, you know, to your point, so it sounds like and certainly jump in that the coordinator aspect is really kind of checking the task. So we are we doing

that reporting status, maybe some notes, things like that. But to truly get into doing kind of deeper project management, you have to have an effect on the project itself and report new presentations. But do you find one, I guess, is that kind of where you can see a line? And then do you find that it depends on the effectiveness of the PM, whether they're kind of delegated that authority or they have to kind of read the environment? Or should PMs kind of know that, hey, if I was asked to be the project manager to support this effort, I need to make sure that I'm moving it forward, plus doing all the other things. I guess, how do you kind of differentiate that coordinator and PM role? And how is that affected by, you know, kind of the environment that that project structure is in? Yeah. So, Kevin, I think that a lot of times people are tasked to be a project manager, and it's not clear to them exactly what that means and what

the responsibilities are and and and that can ebb and flow based on this phase of the project so again if you're in project initiation you're doing one set of tasks if you're in execution you're doing something else and if you're in closeout you're doing something else altogether and so it does depend on what phase of the project you're on. But how do you know what's expected of you? Well, I can give you a case study, and I think this will resonate with a lot of the audience. So I was working on a project, and when the management hired six project managers from across the company, they collected a bunch of expert project managers, not myself included. I was on kind of one of the aspects of the program. It was a pretty big program with a lot of people, a lot of money being spent, etc. So they hired these six people really to do reporting.

And so their sole responsibility after about six months was just reporting to executive management on the status of the project. They were collecting feedback from all the various people that were working on the project and the program. And they were looking at budgets and reporting on finances and the status of all that. And that was really all they were doing. Earlier on, they were more involved. They were partnering with projects. They were helping pull together artifacts, like, for example, metrics. They were helping put customer focus groups together. They were really helping to guide these projects. But after about six months, all they were doing were these status reports. They were doing what they were told, by the way. That was, in fact, what they were told to do.

But at one point, there was a budget review and we were spending too much money and somebody needed to be cut. And all six of those project managers got removed from the program. And it was pretty devastating, actually, not just for them, but for the rest of the team, because anytime someone near you gets removed from the project, everyone wonders if they're next, of course. So it was pretty traumatic when it happened. But if I look back on it and say, why did that happen? and I do believe it's because they had become truly irrelevant on the project. They were not moving the project forward. There wasn't anything that the project was benefiting from because of them except for those reports that could not have been

necessary to what was actually happening. I think the executives decided that since they they had uh money that needed to be saved and they could probably do without those reports that they sacrificed those reports for um a big money savings and the labor required to pay those people so um that's one of the big reasons why i come i come to that mantra that says you need to be irreplaceable and not irrelevant. And even though the managers were saying we need you to do reports, they needed to push back on that. And they needed to say, hey, yeah, we'll do the reports. These are very basic reports, nothing complicated, nothing difficult, very basic reports that we can repeat every week, very easy to collect. We'll get people to fill them out for us so we don't even have to do any consolidation of

data and we'll have them automatically generated in any way we can. But we're spending the majority of our time driving the project forward, partnering with the business, cross-organizational support, what are the integrations that need to take place, what testing is coming down the road, how can we help with change management, all of those things that they were not doing because they were spending all their time doing reports. So that's an example of a situation that I was in where it became pretty evident after a while that those were the things that they were not doing. And in the end, they were all replaced with some consulting from a consulting group. And they partnered with all the projects and they focused on integrations and they were more involved in driving the programs forward. They also did reporting, but not to the degree that the prior group was doing.

You know, that's a good point. It sounds like, you know, there was opportunity, and maybe there's folks in that situation now, but, you know, there's opportunity to, yep, do what you're asked to do, but use that information to say, hey, here's, you know, what we could do with these metrics or those metrics. Here's how I think it's going to positively or negatively affect. So maybe trying to action what you're reporting on versus just being stuck in that administrative loop, which happens because

at some point, everybody from the C-suite to the boots on the ground, one information, some more than others in different formats. You know, you get in that kind of cycle of report land, you know, but but to your point, it sounds like, you know, there was opportunity to say, yep, we're going to get all this information, which, you know, information is knowledge is power, all that kind of stuff. So how do we then use this to make things better that didn't happen? And, you know, for folks that are in that situation now, what else? So, you know, and looking at that information and maybe trying to be more proactive, what else would you suggest to maybe a PM or a coordinator now that's in that administrative loop that, you know, maybe could take some initiative? What do you think they could do or how do you think they could approach that assignment or their leadership that's given them that assignment? Well, it depends on the project. So, if you're working on a project that is very user-focused

and you have a set of users involved and they're considered stakeholders on the project, they need to really completely and thoroughly understand what it is you're delivering. And in a lot of cases, a lot of projects that I've been on, that hasn't been the case where the users really have a good grasp of that. So take it upon yourself to be the one to really partner with the users. I've been in situations where I've partnered with users and I actually love that. That's probably my favorite project to work on when I can interact with people who I know will be using our system eventually. And so now you become a trainer, you become a change management expert, and you become an expert on the as-is system versus the to-be system.

So you can say, this is the way you do business today, and this is how it will change. And you make that clear to them with diagramming. You can use journey maps. You can use workflow diagrams. You can use all kinds of diagramming techniques. I happen to be a big fan of graphics and any sort of picture that you can show me that said that we are, you know, cross this out, X this out, that you're not doing this anymore. Instead of that, you're doing this. That makes it resonates with a lot of people more than a bunch of words.

The other thing I've done is kind of a set of bullets on the left side that says, today you have to do this. And on the right side is a similar set of bullets that says, instead of that, now you'll be doing this or you'll be seeing these things. So that's another way, if you're not a graphics person and you'd rather use words, that's another way to depict what do you do do how do you do things today and how will things happen tomorrow so that's you know that's if you if your system happens to be one that is very user heavy and that would be a great a great role for a project manager and i've done that as a project manager i have done that and i have found a lot of success with that. Now, if you don't have a system that's very user-focused,

then that obviously is not something that you can do. And instead of that, you might want to get into the more technical details of the integrations. Any system that you build has to integrate with some, you know, very rare is it a system today that stands alone. So how does that system integrate with other systems? And now you're getting into a little bit more of the technical details. If you happen to have a technical background, terrific. I do. So that works for me. Where are we getting data from? What are the

security issues? What other systems are impacted? What are the downstream applications that are impacted? So there's a lot of system related. If your system happens to be that in that more of that vein, then you'd focus more on that in that aspect. Another aspect I mentioned earlier was metrics. I'm always being asked as a project manager, how are you proving that what you're doing is better than what you had before? And that's metrics, cost metrics. So, you know, how are you saving me money? That's one big thing. Another big thing is how are you saving me time? That, of course, translates to money. So there's questions, there are questions about that. How do you collect those metrics? Another really good job for the project manager. So those are

three, I think, areas and I could go on and on and I won't. But, you know, users, look at the users. Number two, look at integrations with other systems, other data, other aspects. And number three is to collect metrics. Those are three really good roles for the project manager that make a lot more sense than any sort of reporting that you're putting together that's a regular, very time-consuming job. I had a situation once where my vice president called me, and I'm in a pretty big company, so for a VP to call me is kind of a big deal. And he had some questions about the project, and they weren't, believe me, they were not reporting related. They were more around what's the biggest risk, when are we going to be done, and how are we going to get this

finished? And I had to have the answers. I couldn't say, I'll call you back and I'll let you know, which I think some project managers wouldn't have the answers to those questions. He expected me to have those answers. So I think you want to put yourself in a position as a project manager. If your VP called you tomorrow and asked you some detailed questions, would you have those answers? And I hope that you'll be able to say yes to that. Yeah, it's a great point. And I'm sure you've seen it. I have of folks, you know, a standard tempo, right, of a project check-in meeting is like weekly, let's say. And so sometimes, and then if it's all the report outs, you know, sometimes it's, oh, we're going to have the conversation about what's going on now in the meeting versus you're supposed to be able to

do what you just said in the meeting. You know what I mean? Like this is the chance where we're going to say, boom, here's my elevator pitch about the project that gives you the information you need to know quickly, which I think is a great point of, you know, PMs, you know, whoever, if you're in the project, particularly if you're the PM or the lead PM of a project, you need to have that ready to go at any given time, particularly, you know, what's a short and sweet summary of it, and then you can get more information. But yeah, I've definitely, to your point, seen folks that even in a scheduled one, they're supposed to give that report, maybe weren't as ready. So there's opportunity to make sure that you have that 30,000 foot view of the entire project. But also note your point, we're about halfway done, here's why. And another thing, to to me at least is about reporting and hopefully

you're, you know, the environment that, that folks are in accept that as you're, you're pretty objective in it. Right. So we're only 50% done and here's exactly why. And that's just the facts of it. You know, so it's, it's, it's not worrying about, Oh, it's not perfect. And maybe we're running late or we're ahead or it just is. But what's the solution that you're going to facilitate? Also, if you're behind, you know, for the let's say negative, if you're reporting a negative like your stoplight wise, yellow or red or something. So I think in addition to having that information ready, like you suggested, also knowing, you know, what are solutions to problems that you're about to tell this VP or other leader, because, you know, it's your

responsibility to help facilitate those kind of things. Right. And we have a rule, no surprises. So if we're presenting to any stakeholders, as you said, vice president or down, down or whatever, we want to make sure that we're truthful and honest, because if we present and say, everything's great, everything's great, everything's green, we're doing terrific, we don't have any reds or yellows, everything is fantastic, and then a week later everything goes wrong, why weren't people warned that something was coming? And again, I've been criticized for that.

I have a tendency to be a little bit more positive and more optimistic. I've been criticized in the past for saying that we'll be done in two weeks and then two weeks are over and we're not done. We still need more time. So I do have a tendency to be much more optimistic. And often when I present status, I'll say, oh, yeah, things are going good. We have this one issue, but for the most part, things are going well. And then a week later, you know, everything breaks. And so at least I did say we had that one thing wrong. But, you know, I think that I've learned over the years to be

honest with things. I know I've been in presentations where people say, oh, everything's great and we're doing great. And meanwhile, I know some of the team members and I know I've been in presentations where people say, oh, everything's great and we're doing great. And meanwhile, I know some of the team members and I know things are not going great. But the project manager is saying that everything is great. So, you know, I think that maybe a little combination of that is appropriate where, again, you're saying for the most part, things are good. But we do have a few outstanding things that we're working on. And that, I think, makes you seem like you're a little bit more honest. You certainly don't want to be negative. That's the worst.

And I've been in meetings where people are, oh, this is never going to work. And it doesn't matter how many people we put on this project, it will never be successful. No one wants to hear that. So that's not good. But some vulnerability is always a good thing to demonstrate, I think, in meetings. And I think you hit the nail on the head when you said it's not easy to report to management. And I know I've had some trouble with it before. Having that elevator pitch ready at a moment's notice and having a status

ready, a little preparation in advance goes a long way. Yep, absolutely. Yeah. And I've been fortunate to have leaders that are, that to your point, will flat out say no surprises. And I'd rather it be like, okay, it's yellow versus, you know, the other way. But, but to your point too, that also varies. And I've, I've, I think, you know, the, the kind of easiest guidance that I've gotten on the whole stoplight, you know, green, yellow, red, um, is, you know, green, obviously everything's going well. Maybe there's some hiccups, but no big deal. Yellow, there's some, some issues, but we have plans for them. Um, red, we've got some issues and we're working on plans for them so we're not we don't quite have the solution it's kind of a quick

gauge because you know every every org you know probably does that differently whether it's a percent changes the color or a date or whatever it is complexity right yeah absolutely and so it's you know to me that was an easy guide to go okay you know good have a problem but we have a plan have a problem working on a plan those kind of things but but yeah and and just you know i think to the opportunity for if you're a project manager to not be disconnected from your team where you're the face of them saying one thing and your team is thinking another probably doesn't bode well for the culture of the project either, you know what I mean, in the environment of it. And so,

yeah, I think to me, one thing that I'm that I'm big on is, you know, the statuses that I get to represent for the team, for the project. I've already talked to the whole team about it, you know, because it's it's not like my Kevin's project. Right. Exactly. It's ours. And so I want you to tell me if I'm but to your point, I'm going to be proactive and say, here's where I think we are. What do we need to change? Or is this accurate or something like that? So it seems like a balance of, you know, we still need to know and still need to be able to gauge, you know, and be honest, because I'm sure you've seen too there are times where let's say i know it's in yellow and this and a person on the team wants it to be in green and i'm like well we can't do that you know what i mean so you have you have to have the other

way hard discussion and just come to that you know middle ground and say you know and i think hope explain like what you mentioned and and i with is, look, we can't have surprises and then all of a sudden the system is going to blow up and go, well, wait a minute. Everything was awesome. It was worse. Another really critical thing that I've seen recently in a big project I was on and before is change management, which isn't the same as you know as project management, but very, very integrated, I think, and important. Yes. More so lately than I've seen in the past. Change management seems to be the big thing now. Seems to be very, very important. Much more important than ever before. Yep. Yeah. And I wonder if it's because of the complexity of systems that take over multiple other systems.

So it's like, hey, we're going to change what half of the org is going to do. So so without good change, you know, or however it goes. But, yeah, we were fortunate where I am to be trained and we did ProSci, P-R-O-S-C-I, the ADCAR model. So we learned about like awareness, desire, knowledge, ability, reinforcement. And of course, within each of those is a bunch of different, just like project management, templates, tips, all that kind of stuff. But yeah, change management for sure. When to your point, like you mentioned earlier,

not every user is going to know, even if you do an awesome communications job or change management job, there's going to be someone that's like, what is this? I haven't heard of it. No one reads their emails. No one reads the articles you post. No one uploads the thing you ask them to upload until they absolutely have to do it. So I think that's definitely the case in what I see. And you know what, Kevin, I see a lot of project managers trying, a lot of people who are not project managers trying to be project managers.

And so these people are very technical. They're chief engineers, they're network engineers, and they try to be project managers and they don't know what they're doing. And as they start to move through it and they're asked to report on resource allocations against real budgets, and they're asked to talk about schedules. It's the last thing on their mind. And so what I found is I decided that I wanted to teach project management, not just to my co-workers, but at the college level. So I started teaching, and I found that people really love to hear my stories. And so that's what my book is all about. Like stories of, of things

that I've, I've experienced. I told you the one story about the, uh, the project managers that all got removed from the project because they became irrelevant. Um, but it seemed like my students woke up when I start to tell stories of actual situations that have been involved in a work that have been, you know, problematic. I had one project, I can give you another example. I had one project where, um, uh, we got canceled before we even got started. So, uh, you know, every five years we relook at some of the systems that we, uh, we own and we decide, should we upgrade or should we replace? Is it time to get something new? So we did this vendor analysis and we decided that it

was time to replace a system that we had in place. This was an HR system. So we spent six months doing an evaluation. We brought in six vendors. We had about 20 people on the project doing the evaluation. We had written responses from the vendors. We had demonstrations from all the vendors. We scored each of them with this most very complex Excel spreadsheet. We calculated all those scores, and we had a unanimous winner. We wrote a business case, which was a very detailed PowerPoint presentation.

And I presented that to the vice presidents that were involved. There were three vice presidents, the CIO, the CHRO, and the CFO. And we presented to all three of them at the same time. They all agreed that we picked the right tool but when they saw the price tag they couldn't believe how expensive it was and uh they all pointed at each other and said well he's going to pay for it isn't she going to pay for it i thought he was going to pay for it and none of them could pay for it so because it was so expensive uh they turned us away and said, we can't afford

this. Now, three years later, they decided they found the money and they wanted to do it, but we had to redo this whole process again. We had all the vendors come in again and we had them all write a written proposal again. And guess what? We picked the same tool and they went for it this time and and so the system has been installed and we we now own it um but that first time you look back at the first time you say how could we have done that differently how could we have been smarter about that number one we should have floated the price tag to someone uh so that we had some sense of whether that price tag made sense. And I'll blame myself. I did not do that. I assumed, and you know, it was an incorrect assumption that someone would pay for it, but no one realized it was going to be that much money.

So that was number one. Number two, if we had worked with the vendor and came up with alternatives, there was no question we could have had option one, two, and three. Option one is we go all in, and this is the all in price, which is the price we presented. Option two would be if we did a little something different. And option three would have been something smaller. And so it still would have been the same vendor, which is the unanimous choice, but we could have at least – and I'm sure the vendor would have worked with us. We talked with them afterwards and said we could have done something like that. So presenting alternatives is always a key facet. We didn't do that.

We should have represented alternatives and going forward that's a lesson I learned and I do that now I recommend it to my staff and I do it myself present alternatives it cannot just be one choice and the second vendor choice was was not half as good as the first choice vendor was so it wasn't that we we did talk about the second place vendor, but that vendor was never going to be picked. We wanted the first one. So there was some, is there some way, by the way,

he was just as expensive, if not more than expensive, than the first place vendor. But that's either here or there. The point is, if we had presented alternatives for that first vendor, maybe we would have had a shot the first time through. Maybe we still would have gotten a no, but at least it would have felt better that we had a better presentation and that we had considered alternatives. And I think the vice presidents might have had a place for that. That's a great perspective where, you know, I use, it makes me think of one-year alternatives to your point, you know, here's 100% solution, 50 less, you know, whatever, whether it's

money schedule, all that kind of stuff. But when I think of like contingency planning, hey, what if it goes great? What if it doesn't? Although usually it's a like when we launch thing, but I think it applies way early to this point where you're doing this analysis. Okay, what if we get all the money? What if we get some of the money? But it also makes me think, you know, one of the things that I'm big on to have this

kind of foundational five concept, but of leaders intent, like before we get started with anything, we need to know what's the intent, is, you know, was there opportunity also from the leadership to say, look, here's what we're going to do, and we have this much money, you know, like your ownership of it, I love that, but I also think of, could we make sure, I guess if we, I guess if we don't get it for us as PMs owning it, you know, like we do a lot of things. If it's not given to us, maybe to the point, ask for it. Like, hey, what's our spend limit? I think one of the things I've learned and that I've done since is I do a lot of greasing of the skids, if you know what that means. I mean, what I should have done, you know, is met with

each of those VPs separately in advance of the big meeting to say, here, this is what we're going to be recommending. What do you think? And again, didn't do that. But do it now. You bet. I do it now. Whenever I have a big meeting with multiple stakeholders in the audience, I try to grease the skids and get at least one meeting in advance of that, if not more, to let people know what's coming so they're not surprised. Again, no surprises. Sure. And at least they can sleep on it and think about it before the big meeting so there aren't any embarrassing conversations that take place in the big meeting.

So that isn't always available. These VPs are often very difficult to get on their calendars. So I understand for those of you in the audience who are saying, oh, yeah, that sounds good at your company, but it doesn't work where I come from. So I get it. But I think that lessons learned, I know a lot of people don't like doing lessons learned because they think, well, the project's over now, it's time for me to move on to something else. But these lessons are critical. It's not always easy to transfer lessons from one project to another. But if you're the one who goes from project to project and you're not learning from one project to the next, then shame on you. You

should be learning those kinds of things. As I said, I learned the hard way. Present alternatives and make sure you grease the skids if you can. Those are two critical lessons learned from me from that one experience that disappointed a lot of people. We all thought we would be working on this project, that we would be installing the product, that we would be, you know, getting these new features to our user community. We were all excited about it. And then that just the wind came right out of our sails when they said, nope, we're not doing that. So it's too bad. That's the other tough thing about being a project manager. I did. And I think it was one of my brief episodes, you know, we're the Ronin, Ronin, which were like traveling samurai, kind of masterless samurai.

You go around from project to project or mission to mission. And then the thought of like, don't fall in love with your project to that point, because I've definitely had that, too. You're like, oh, it's great. Even if you're kicked off and you're going, it's like, oh, we need you somewhere else. You're like, oh, so whether it's canceled or you're reassigned or who knows, there's always that chance. And this goes along with what you and I chatted about before, too, and what I've helped folks trying to get a PM or whether it's a technical person trying to become a PM, like you mentioned earlier, is none of this is in kind of the textbooks. It's in some books, right? It's in your book.

Right. But it's not like in the, you know, let's say say, the quote official project management book that people study to get credentials. But it's the invaluable stuff because people think a gateway is the credential. So could it be on a resume search? Yes. Will it be when you're actually going to do this? No. You know what I mean?

All these tools you mentioned, work breakdown, those kind of things, great, you will do those, those kinds of things. That's awesome. But I think to your point, the intangibles of lessons learned, which also, by the way, I've found and would like to hear you, like you don't just get those at the end, you get them throughout the whole life cycle. So how are you grabbing those and where are you putting them? Um, and to your point, if you're not, then, you know, kind of shame on you because there's lessons to be learned when you're gathering requirements, when you're putting the scope document chart or whatever together all the way through at the end. There's just so many opportunities to do that. And so that's a, you know, hopefully it's not just in your notebook. It's somewhere that you have, you know, even if it's I guess if your company doesn't have a project management system, you know, a spreadsheet you save somewhere that you have you know even if it's i guess if your company doesn't have a project management system you know a spreadsheet you save somewhere that folks have and it's a running you

know some kind of tally or something like that but i've found gathering them throughout is also easier um how about you yeah so i think going back to your your comment about the book that everybody likes to get certified out of um there's 75 tools, at least in that book that they describe. I do not use 75 tools in my day-to-day job. There's no way. There's probably a dozen that I've used over the years and probably a half dozen that I love that I use all the time. And I have samples of those on my laptop, on my desktop. I have a folder of schedules. I have a folder of work breakdown structures. I have a folder of journey maps and others. There's maybe a handful of others. And those are the ones that I really use. And I think that's really the key

for me anyway. It's been a key thing for me when I'm stuck on a project and someone says, what do we do next, boss? You're in charge. You're delegating us. What are the next steps? And people rely on me, right, as a project manager to direct them. I look to my tools and say, is there something that can help me here? Is there a JIRA board, a Kanban board? Is there some sort of task list in a Microsoft project? Is there a Gantt chart? Is there a journey map that can help me here or a workflow diagram? Is there a business process model, business process flow that I can do using Visio or, you know, where are my tools? And I'm not just talking about applications like Visio or Microsoft Project. I mean,

where's the PowerPoint schedule or the Excel resource plan? Where are those things? And, you know, often we get involved in what we call a get well plan. And you could call it a tiger team or a blue team or a red team or whatever, health check, whatever you want to call it. And that's what we do. We go into these projects and we say, where are your artifacts? Where are your items that you're using to track the project? And if you don't have any, you know, that's a problem, number one. But if you have some and they're stale, you're not keeping them up to date, or no one has access to them because they're sitting on your desktop, you don't have a shared repository or whatever,

whether it be Teams or SharePoint or whatever you use to share documents, Slack, you know, if you don't have them in a place where everyone can get at them that's a red flag so you know you're looking for red flags as you go into these projects that are having problems you know where's your risk register and if you don't if you're not a person that my company is not we don't manage by risk i know a lot of companies are very risk focused we don't do that. So that's not really a huge thing for us. But in your company, maybe that is a big thing. In my company, a big thing is schedules.

We use a tool called Clarity to help us with our resource allocations. That's a big focus of our company. If you're not in Clarity and allocated on a project, that's a problem. So like what are the key things for you? I know what the key things are for my company. What are the key things for your company that are red flags? And so that's, those are the things that you should be sure you have on your project in terms of artifacts. And as I was saying earlier, there are certain points in the project where your project management tools really kick in.

And so you've got some checklist of what those could be. And I have a checklist on my, again, on my desktop of what those things are. As I mentioned earlier, schedules, resource plans, RACI diagrams, whatever they are. And again, I look at that checklist and I say, hmm, do I have all those? No, maybe I didn't do my RACI chart yet or my org chart for my project. Who's the deputy? Who's responsible for this work breakdown structure item? Who has the responsibility for this, that, or the other thing? Those are the things that maybe you need for the early part of the project. Then when you're in execution, there's a whole other set of things. And again, if you're not a business systems analyst, then maybe you don't know a lot about journey maps or business process flow diagrams.

Those tend to be more something that a business systems analyst might do. But you certainly have status that you have to report on. You have change management. You have test plans that are coming along the way. You know what's coming. You should always be looking forward and know what those things are that are coming up. So I think I'm a big fan of tools. I use them all the time. I certainly don't use 75. Find out what those tools are that are important for you and stick with them and use them on every project. I bet if you asked a half dozen or a dozen project managers that you know that are effective, what are their five or six tools that they go to that they use on every project? Maybe you'd get a varied answer. Maybe you'd get the same answers.

But the fact is, I bet they have their set of tools that they like to use, that they rely on. Yeah, that's a great point. And keeping track, like you said, by phase. And I'm fortunate where I am now, our leadership, you know, helped put that together and with input from us of like, okay, what do we have to have? What can you do if you have the time or it helps you? I think that's the other balance too is, you know, earlier we talked about the reporting loop or something, but you can really get bogged in an administrative loop if you have too much stuff, um, like those 75 things, but you know, what is going to help early in the middle at the end, those kinds of things. And what is expected that you have to report on, um, meaning it's because it's gonna, you know, both legal documentation, this, that, you know, all the right stuff that you have to report on, meaning it's because it's going to, you know, both legal

documentation, this, you know, all the right stuff that you have to have versus what is nice to have if you can do it, but not necessarily required, you know, and some of those are the big things that are, you know, mentioned in some of the credential things, you know, credential documents or other places, but they don't necessarily help your project move forward. Versus to your point, like an org chart to me, I like pictures too. So if I know who is doing what on the project, and then I can also look at the breakdown, you know, who has the tasks and those kinds of things, that alone tells me kind of what's going on in one image, you know, or flow. So it's, yeah, to your point, and that's definitely a question I see a lot on like

the project management subreddit on Reddit of, you know, what tools do you use? What should I report on? I'm just starting. What am I? You know, what do you do there? So that's a great advice is, you know, find out. And then if, you know, for folks that maybe are in a new PMO or it's not established, where can folks go to maybe find some tools and templates, do you think? What are good sources that you know of? Yeah, they're really hard to find, Kevin, I have to say. I presented last week at the PMI Virtual Experience Conference, and I was able to chat online with the audience and I had 50 people send me an email and ask me for example tools and templates. And it was like 47 people that sent me an email.

I said in, I said in the chat, if you want, cause there's a couple of people said, can you send me examples of tools and templates? And I said, yes, send me an email and I'll forward it to you.

And they're mostly the tools and that I have in my book. So that was what I forwarded them, plus a couple of extra templates that I don't have in the book, but just basically sent them, you know, it's a PowerPoint slide deck with all kinds of different examples. And I think that it's very hard to find those tools if you look to the pmi um documentation the pmp documentation there are there are tools there but uh i think they're they're not they're a little bit more theoretical and they're less you could get lost in there there's just so many so um you know my favorite i have three favorite tools and um one of the things i that has been a problem for me in the past is scope creep. And I know you all know what that means, so I don't really need to go into what it is. It's a problem for almost every project that I'm on.

And so how do you control scope creep and how do you make sure that you stay on task, on schedule, and on budget and don't have all these extra requests from folks. So I think that it's one of the first things that I like to use is a journey map. Now, I've mentioned that a few times. Those of you in the audience who are unfamiliar with it, you should look it up. Google it. There are lots of templates and lots of different ways to do it. But effectively, the journey map is a graphic way to describe what your system is doing from a user's perspective.

So you could do a journey map of the as-is system and you can do a journey map of the to-be system. And by doing that, you're clearly delineating what the users will expect to see in your system. Now, if there's a scope change, if somebody comes up and says, oh, instead of A, we want B, then you need to redo the journey map and demonstrate to them how that will affect the change in the use case and into the description. When you do that, it makes it clearer to the audience that that is a big change. But just describing it sounds like a small thing. But when you say, oh, well, that's going to change the scope of the program and here's how it will change it exactly in this particular area. And oh, by the way way that's going to cost you X amount to add that to the system, maybe we could remove this feature that you don't need as much.

We learned something new, we learned that we can do this new and nice feature, we would like to really do that but in order to not expand the scope we'll remove something else. So there's some negotiation now that you get involved in with your stakeholders. So you don't turn down every single thing they say. Another way of getting around scope creep is to phase your project. So you say, this is phase one. When you want to add features, those are going in phase two. And that's another great way to avoid scope creep.

But the journey map can really help you depict exactly what it is you're planning to build. The second tool I like to use to help manage scope creep is that status report. I mentioned earlier not to make it too big and too onerous to put together and also to read. No one wants to read six pages of a huge status report. Let's make it nice and short and sweet. But that status report definitely informs the stakeholders, what is it that you're building? And that's what you want to make sure you're building what they're expecting to get. So that's another one that I like. And then the third one, and really, I think I keep saying it's my favorite, but the work breakdown structure is also one of I like. And then the third one, and really, I think I keep saying it's my favorite,

but the work breakdown structure is also one of my favorites. The ability to break the project up into manageable and executable pieces. And that's another way from a technical standpoint to depict your system. So what you've got now is a journey map for the users or the stakeholders. You've got status reports that give a view for your stakeholders so that they can see what the changes are, what the implementation, where you are. And then you've got your work breakdown structure, which is more for the technical team so that they can understand how to build the system. Those are my three favorite tools. And so for the journey map too, you need to account for time to put all that together because it's back and forth conversations, right? And then, you know, if there's one of those

three, I think that from a practical planning, time management, team management standpoint, that one seems to be probably the most labor intensive because there's so much back and forth. And I think probably like a bunch of other tools toll status reports vary widely, but I love your comment of like, it needs to be pretty succinct. And it made me think of kind of the resume rule, like one to two pages, that's it. Because we don't need to see everything else. And if you're tying what you're reporting to either the objectives of the whole project. Like, you know, you don't tie them to every 500 tasks that it's going to take to do this giant thing. And I think that's a skill, too, for PMs and folks coming up or wanting to be a PM or, you know, somewhere somewhere in there. There's my dog. Yeah. So I think that one of the things that you mentioned, Kevin, is that building a journey map can be time consuming. So I can give you an example. We created a journey map with a one hour meeting. So we we had the right people in the room. We spent an hour interviewing them and we had a set of questions prepared in advance to ask them what their process is and what they expect the to-be process to be for their particular persona.

So what is it that they're, in this particular case, we were interviewing payroll. And so we were asking them, how do you run payroll today? And how, what are the issues that you currently have? What are the bottlenecks that you have? What opportunities do you see that could make improvements? Where do you see, where do you have issues today? So we spent an hour with them. We went back and with those notes, we were able to put a journey map together. And then we had a follow-up meeting with them and we reviewed the journey map with them after the fact. And they made a few changes and that's how we came up with it.

But it probably took us, you know, at least eight hours to put the journey map together from our side. Plus we had that one hour meeting and the follow up. So you're right, it is time consuming, but it's a great artifact. And it's one that a lot of people can resonate with. And it ends up being one of the favorite tools that gets ponied around when it's time to give a presentation. I know I did a journey map on a project recently. And I changed it and fixed it and adjusted it and changed it so many times I can't even count. But that journey map was presented all the way up the chain to the executives so many different times. And it was the only way on one page that you could grasp the whole system and what we were actually planning to implement.

And if I showed it to you, you'd see it's very complex, lots of very small font and lots of lines and lots of systems depicted. But it was a great, great way. When you first saw it, you were like, oh, my God, what is this? But as you start to walk through it, you really could see what it was we were trying to build. And invaluable, absolutely invaluable. Yeah. And it's great that it's user-driven really because it makes me think when it's not particularly in IT right because often I have I have either maybe not seen as often but know of and maybe been part of before as a PM and I was maybe one of the technical folks that was a hardware

guy years ago and when kind of the design it's like here's your new system make it work first how do you want the system to work you know and that's a huge design kind of thing involving the users is just key and it makes me think of that comic or cartoon where there's the sidewalk right and people wear a picture and people walk through the grass to cut the corner so there's like you design the sidewalk to go this way, but the users really just want to, you know, the shortest route to the thing, which is a great point. And to the, you know, the whole reason we're doing any project

in really any space is for the people that are going to be using or the facility or the system or the whatever it is, software, you know, something like that. So, and that's, I think, easy to lose sight of when you're that so yeah and that's i think easy to lose sight of when you're just so busy and trying to get things going and off the ground and and things like that as well so right so i i think uh i think i talked a little bit about um the fact that i presented last week at a conference and i i had some questions some great questions that came at me from from the session.

And one of them was really interesting. So one of them said, so how do you ensure that you're being irreplaceable and not irrelevant? Is it the level of influence and trust that you have with your stakeholders? Is that how you get to that level? And my answer to that is, I mean, I think influence and trust and being a trusted advisor on a project is a critical factor for a project manager. But I think that the more important aspect is how do you gain that trust and how do you gain that level of influence on a project? I really think it's that being able to be proactive and seeing what needs to be accomplished and delegating to your team members and making sure that things are moving forward

and not just reporting out on status and updating meeting invitations and the things that project coordinators do. So I think that, you know, I had another question come across my way that said, my project is going massively wrong and there is an executive who is the project, the named project manager, but I'm supposed to be the project manager too. And no one listens to me. They only listen to the executive. And I feel like I'm an introvert and I feel like I'm ignored and I don't feel like any of my work is valued. And I think no one listens to my opinions. And how do I turn that around? And I think that's a really good question and a vulnerable question.

And I felt really bad for the person who wrote that to me. He said, how do I turn it around? I mean, things are really going bad and I don't know how to turn it around. I don't have the influence. I'm not in a position, but yet that's my job. How do I turn it around? So, again, I go back to the tools and I know you're in the audience saying, well, that's happened to me and I ended up switching roles or I ended up switching jobs or whatever. But what I would say is, you know,

if you can execute a get well plan of your own undertaking. So where are your artifacts? Where's the schedule? Where's the problem statement? Where is all of the materials, the status reports that have been developed? Take stock. Where are the problems occurring?

And if you can articulate those in some way, and if you can put those in some way and if you can put together a set of recommendations on what you think and how you think the project can turn around, that's when you gain that trust. That's when you get to be a more influential team member and you become a little bit more irreplaceable on the project. So I've seen situations where project managers just sit back and wait to be told what to do. And I've seen project managers that say, well, I'm trying to

put an integrated master schedule together, but I don't have all the inputs from everybody. So I'm waiting for the inputs. When I get the inputs, then I'll do it. And I think the word waiting is the word that gets me nervous because, you know, everyone's busy and emails get lost in the flow. And I don't know about you, but I'm in, you know, five or six hours of meetings a day and I don't have time, half the time to even respond to email. So if I don't respond to email, follow up with me. If you need something, you need to track me down. And the best project managers are the ones that won't take anything. They're going to stand up there. They're going to bang their fist on the table and they're going to say, I need this and I need it

now. And you need to get it to me because I'm not waiting any longer. And I love working with people like that because I don't feel like, oh, who is she to talk to me? No, I love that. Like, do that. I need that pressure. And most people do. They want to be told, you know, what is that you're expecting. And not only that, you know, I don't want to waste my time. So if this is going to help something or help you or help inform or help the project along, great, I'm all in. But I don't want to waste my time. Don't ask me for something I did last week in a little bit of a different format. And we've all been asked to do that too. And that can be frustrating. So I think there's a lot to be said for being proactive and taking a stand. And I know sometimes it's difficult, especially if that's not your personality.

Again, I know some project managers, they're very introverted, and that's not their thing. We try not to put them in situations like that because we know what their personality is like. And then I have other project managers who are going to blaze a trail because that's just how they are. So there's different personalities and different projects excel in situations like that. I have one project manager who's a trailblazer, and we put her on our most complicated, most difficult projects,

and she turns those people's heads around, and she's not going to take anything anything from anybody and people love her and then there's a i have another project manager who's kind of the opposite he's very laid back he's very quiet he's more in receiving mode and he's more like our project coordinator and there are some projects that we assign him to where that is a good fit for him. And he's satisfied in that role. And so those are the kinds of projects that we assign him to. But he'll never be the trailblazer that the other project manager is because that's just not his personality. And that's okay. But we still try to put him in a position where he is irreplaceable, even though he's not driving the project as well as much as we would like him to.

And we're still advising him and guiding him and helping him along. So there are there are I don't want to say grades or there's there's levels, I guess I would say of project management. And I think, you know, you need to find where you fit. I'm talking to the audience now. You need to find where you fit, where your characteristics and skills lie. And I think you'd like to strive to be that kind of a trailblazer project manager who really takes no prisoners and just keeps going no matter what. You'd like to strive to be like that. But if that's not your personality that's okay there's still a place for you and there's still value in the work that you're doing and i still think that there's a way for you to be effective and and be critical to the success

of the project and that is really what you're striving for is we want the project to be successful that's at the end of the day that's we want it to meet schedule for is we want the project to be successful. That's at the end of the day, that's it. We want it to meet schedule, budget, and we want the functionality to be where it should be, the three-legged stool that we're looking for in a successful project. So I think that was a great question. You know, the project goes massively wrong. What do I do? Those are some tips and some ideas on how you can turn things around for yourself. Yeah, that's a great point. It's, you know, and how you illustrated that and how folks can leverage their own personality in the different situations where

you're really being irreplaceable, but one is really right out front in your face version, because people know you're there, you're getting it done, you're directing folks, you're following up, you're very proactive, but also the person that's introverted with the executive that's technically the PM, but giving them the critical information to make decisions to being right there, having that out later pitch, like always being ready, but not necessarily having to be standing in front of the room full of people. Exactly. To your point, the people that going back to your, your story about the six folks that were let go, cause they weren't irreplaceable while the folks, if you're propping up an executive, that's a PM all the time, that's going to help you be irreplaceable when it comes to look at who's going to be there or not, whether you get tons of recognition or not. And I think that's another thing too, is

we, you know, we, there's still relationship building I hear there and opportunity to earn kind of respect or let them see your value. I could see that from the team, from, from the introverted person, perhaps, you know, the person that asked that question, but you're not always going to get, you know, awards and pats on the back for doing what you're going to do, even if, even if you're irreplaceable behind the scenes, which I think is one of the big challenges of being a project manager or coordinator or anything, you can be slugging away at keeping the team moving and this and that. But it, you know, it can't be, I think it has to circle back to what's the outcome for the users. And it's hard. I think it's hard to do that when you're tired and you've been working long days and weeks and months and all that kind of stuff.

But, yeah, it's a great illustration of the ways to have that relationship behind the scenes and still make sure it's going forward or you're out front leading the charge of the cavalry, I guess, project cavalry, so to speak. Absolutely. Yeah. We talked we talked, Kevin, about the difference between a waterfall project and an agile project. And I think that project management comes into play in both of those scenarios. And I've been involved in both scenarios. I could tell a story about an agile project that I worked on where we were replacing our company intranet, which at the time was a big deal. I think now there are all kinds of tools that you can get that help with that. But at the time, it was a big deal. And it was an Agile project. We had a scrum master and

we had a nice Kanban board. It started out as sticky notes on a wall, and then we converted to a tool. And then we also had retrospectives, and we had all the things that go with an Agile. And I was in charge of the backlog, the user story backlog. And that was my responsibility on the project at the time and helping out the product owner, really, as a deputy, so to speak. So anyway, we have this great backlog, right? And every three weeks or so we're doing a sprint and we're doing great and everything's going terrific and our product looks terrific and everybody really likes it. We have users coming in and checking it out and it's great. And we keep going and going and going because, you know, that's the problem with agile sometimes. There's no definition of done.

So you just keep going, right? I mean, why not? That's like the ultimate scope creep is your backlog of user stories. It just keeps growing and growing because, you know, that's the point, right? You're learning as you go. That's what is so great about agile. That's what people love about agile is the fact that you start out with uh you know a little bit of an idea and as the more you the

more you do the more you learn and the more you add well you know that can be a problem when you run out of money and you run out of uh management attention and they say you know what you guys are done it's time for you to finish and again not a planned time to be done we we had all kinds of plans of doing xyz all these nice features all this new stuff really some really cool things we wanted to add to this were they necessary no were they in our original plan no did we tell anybody we were going to add these nice cool features no we just learned about them and we were like oh this is neat let's add this this is really nice let's add oh look at this and all the coders were like oh this is terrific like they're in they're in they're in heaven right

they're coding away and they're they're adding all these really nice features we had this one thing called employee roulette and every time it came up it would like spin and a new picture would come up and the idea was you'd get to know people by looking at their picture and you'd maybe see them in the hallway or whatever i mean who needed that who asked for that no one but it was people thought you know the developers thought it was cool oh Oh, let's just add that. So they just added it. And the more things they added, you know, the longer the project went on. So, you know, our project got canceled, you know, prematurely. And, again, people expected to continue to work on it. There was no end in sight.

And that's a problem, obviously. So everybody was disappointed, even though we did a great job and it was a big success. And that system was in place for many, many years because people loved it. It still was a bad taste in your mouth when you're working on a project and it gets canceled prematurely. It's not good. What would have been better, of course, was for us to have an end in sight, for us to know when we were finished, for us to have a definition of done, and for us to have a budget that said when we hit this dollar amount, we're going to end the project. We weren't that smart back then. This was several years ago. We didn't do things the quote-unquote right way.

We were kind of like we were winging it at the end, especially. And I think our management saw that and said, okay, we've got to cut these guys off at the knees because they'll never stop. They'll just keep going. So that was another lesson learned it sounds like that's maybe where that kind of blend of waterfall agile or waggle right so you get some structure up front i like did you just say waggle waggle yeah i certainly could make that up but yeah i love that because because you know i uh waterfall is kind of the standard PMOs start with. It's the whole PMP kind of focus thing.

A little more Agile in there these days, but overall what it is. But it sounds like that's kind of the Waterfall box with Agile inside it. Right, right. Because Waterfall, as you know, and many folks know, listen, you plan a lot of stuff out at the beginning. It's supposed to stay that way. You do all the steps you're supposed to but you know the mix it sounds like if we would have said yep here's we're going to go to your point here's the budget here's the date and okay now do all your agile stuff in the middle and then you know we're still going to work toward those dates and those kind of things so yeah it seems and that seems kind of like a judgment call

and a growth thing to your point because a lot of time we learn the best from maybe not our best projects. Right. You know, OK, let's do this next time or not that next time to the point. Lessons learned. But I think I think the evaluation of how far are we going to go on this should be every time you have a retrospective, you know, at some point, maybe six months in or eight months in or nine months in, you say, when are we finished with this? When is this ending? If you're not agile and you're really truly doing an agile project, there needs to be a question in there that says, when do we wrap this? It needs to be soon. Is it the next three sprints or is it the next five sprints or when is

when is it that we think that will be done and um i think that's a critical question that we never asked ourselves we just as i said we just kept adding employee roulette and things like that until to our hearts content and we thought we were we were doing a great job um people by the way like that employee roulette believe it or not that's but i was gonna say i mean it sounded like a fun project team to be on anyway it was a fun project i have to say it was it was a great team uh and it isn't it isn't a great project usually because of a great team um i mean my my my experience i could sit here all day and say oh this was a great team. Cause we had, we used all these tools and we had great, you know, a great product and whatnot. But

at the end of the day, it's the people that you work with that, that you remember. And, um, yeah, that was a great project because we had a great team. Yep. Absolutely. I agree. I mean, it's, it's the, the kind of, you know, the, the ultimate when you're a PM to have a team where, you know, they're already going to have their stuff done. You know, you're not chasing folks. They're like, Oh, I actually went ahead and did this too. And I'm like, don't you love that? Oh my God. Yeah. You just have all folks that, you know, do their thing, their go-getters, all that kind of stuff. Um, and, and you've mentioned this too. Um, and, you know, talking about people, um, I know this is project focused, the Get Well Plan,

but focus on there. And so you've mentioned it, but in some of the tools and things in there, can you also kind of talk about how often you do that throughout the project? Because I think that's such a great concept that I hadn't heard of. And then, you know, touch it on your book. And so just as a circle back before you get into that too. So the book, The Successful Project Manager is case studies, lessons learned, practical application. And this get well plan is something that you mentioned in there too. So can you share with us kind of what that involves and then kind of the frequency that you use or how you adjust that or just what that's all about? Yeah, sure. So I mentioned earlier, so we call it a get well plan.

We all, I've also heard it called a health check. I've, I've heard it called a red team, a tiger team, a blue team. I mean, you know, it's, it's got all kinds of different names. So in our organization, we call it a get well plan. And what we do, it typically it's partway through a project, typically around a milestone of some kind. And it's not necessarily a bad thing. We don't want it to sound like we're coming into your project. The police are coming in to check on you. It's a regularly done thing. And so people expect it and they know that it's coming. And it's really intended to ward off any problems that may be happening that not everyone is fully aware of.

So what happens with the Get Well program? Well, we put together a team of three or four project managers. And it's kind of an honor to be asked to be on one of these teams so it's it's always a good thing to be involved so we we come into that project and the project team gives us a presentation for an hour or so sometimes longer and we hear what what was intended to be built we have a project description have a schedule. We see what the resources are. We understand the current status of the project. We get some other artifacts that we can review later, maybe some status reports and any journey mapping or diagramming that's taken place.

And so we collect all that information and we go back as a team and we basically assess what we've learned. We maybe touch base, ask further questions. And then the second step, so that's the first step. The second step is we come up with a set of recommendations as a get well team. And so we go back and suggest changes. And we usually have a good set of recommendations. And we try to prioritize them by saying, these are the things we really think you should do. And this would be nice to have if you have time. And so typically, those are

things like you need to add resources. You need to reduce your scope. You need to phase this project and take out some of these features and move them to phase two. You need to accelerate your schedule. Sometimes we cancel the project. That hasn't happened often, but sometimes it does as a result of the get well check, the health check. And so that's the second phase. The third phase is the project goes back and decides which of the recommendations they are planning to implement. And then they execute on those and there's a follow-up with the Get Well team that was involved and there's a report out on the success of the project based on those recommendations. So it's a three-phase activity,

and it's well documented in terms of we have a report that we write. It's not really lengthy. We don't want to spend a lot of time on it, but we do want some sort of documentation that says we executed the health plan, here are the artifacts that we reviewed, here were the recommendations, here were the actions taken, and here were the results. And this is something that we try to do on the highest priority projects, the most expensive projects, and the highest visibility projects. So projects that the VPs are watching, for example, projects that are costing a lot of money. We bought a big tool that's a cloud tool and it's really expensive, so we want to make sure we're doing it right. Or a project that's impacting a lot of people. If it's impacting the whole company, 10,000 users,

we want to make sure it's right. If's a small project it's only impacting say facilities or it's only impacting the hr organization maybe we don't do a health check on that particular project or if it's a project that we know is is pretty successful it's it's chugging along it's going well it's being run by that woman i mentioned earlier who's blazing a trail and she's got everything under control. We don't feel like we need to do a health check on that project. Maybe we'll bypass that one. It just seems like lately everybody is so busy. It's hard. It's hard to really carve out time sometimes to do to do these kinds of things, even an extra hour. You know, you say, oh, it's only an hour for the

meeting, but you know, you have to prep for the meeting right now. You've got to pull all the artifacts together. You've got to maybe put slides together. There's work that's involved in preparing for that one-hour meeting, and so sometimes people don't want to do that. So there's a management call as to whether or not we can cancel it. So that happens sometimes. But I think the value of the get well plan and the concept of it is that as an individual project manager, you can execute your own get well plan whenever you feel like it in terms of where are all of the artifacts that we need. Imagine you're a project manager that's just put on a project and it's already underway. So it's partway through execution, and somebody either left the company or got reassigned or whatever, and you're the new guy on the block or the new lady

on the block, and now it's your turn to take over. How do you assess where the project is, and how do you move forward? Yeah, you can look at the SharePoint site or the Teams site all day and read all these documents. But what would be better is if you executed your own get well plan and you said, where are these documents? Where are these artifacts? And maybe, you know, get getting the right set of questions together that says, what were the expectations? Where are you today? Where do you expect to be? Are there phases in this project? Are there risks that we are anticipating? What has happened up until now?

Lots of great questions that you can ask. And a get well plan can help you with that. Again, you go back to the tools. What are the tools that have been used, that have been successful? Where's that schedule? Where's that journey map? Where's that work breakdown structure? where's that racy chart, all those things, not 75 of them, but only like a half dozen or so, where are those key elements, you know, for your company, maybe it's earned value, I never use earned value, but I know what it is, I have to teach it in my college project management class. I never use it at all,

but the project, the PMP, you know, uses it a lot and other companies use it. So I don't know what your company is, you know, what tools your company asks you to build or to use. I know what I use at my company and what I like to use. So, you know, whatever they are, find out, find out where, you know, who built them, where are they and what's the status of them? Are they stale? Are they up to date? And let's get them up to date. And so you execute your own get well plan. So the whole concept, I think of a get well plan, whether you execute those at your place of business or not, you certainly could do it yourself. And I think it's a good a good tool, a good set of tools to have in your back pocket. Absolutely. And I, you know, to your point and you and I haven't I'm sure others listening have to been dropped into the middle of something that needs help or that just, you know, staff change, whatever.

And if you don't have a chance to have that a handoff with the outgoing person yeah to your it could be a treasure hunt you know you're like okay where is the info where's the original and and who knows there could be variation you know lucky if it's very well documented and it's all there and those artifacts are there and if not to your point that get well plan is a great point and and some things i heard when you mentioned it or we're talking about the get well plan is this team goes to projects that and do the projects always have a PM or are they projects sometimes run by staff? Right. And it's just you kind of come in, consult and then kind of step away just to help kind of guide them a little bit. But also for the big ticket items you mentioned. Right. We don't have enough resources in my project management office that I run in my department. My department is a group of 20, 25 people, half of them about project managers and the other half are business systems analysts. Now, we have a lot of contractors that help us. So we've got probably another 10 individuals, but that's still only like 20 people or less and there's a lot more projects than that in my in my organization that need project managers so right now i've got 55 projects

in my right now i've got my team is my team of 25 people are supporting 55 projects so a lot of them are on more than one project and um some people um excuse me some projects i have more than one project. And some people, excuse me, some projects I have more than one person on, et cetera, depending on the size of the project or whatever. The fact is that, you know, we've got lots going on, but we still can't seem to fulfill all of the resource requests that we have. One of the things we were talking about actually just today to try to help with that is to have some consulting where we don't actually get assigned to a project as a project manager, but we consult with a project. Excuse me. In that case, we come into the project when it's first starting up and we help them set the project up. So we do schedule, we do resource plans, we do work breakdown structures, we do a project

charter, we put together sort of the foundation, if you will, and then we disappear. And we let them, you know, we let them try to run the project as best they can. And then we come back maybe monthly or every six weeks and kind of touch base, how are things going? Is there anything we can help you with from a project management standpoint? They say, oh, we have a stakeholder that's giving us trouble or we have this thing that's blocking us from making progress or we don't know how to phase the project. Can you help us with that? So we might help them with that. Now, we talked about that today and talked about it as if to say maybe that's a service we want to provide. We have not been successful at that.

We haven't seen people gravitate toward that yet. You know, stay tuned. Maybe in six months that will be something that we're actually doing. And maybe some of you out there are saying to yourself, oh, yeah, we do that. That's something that we do. I know I talked to someone that I work with who at a previous company used to do that and said that it was very effective. So, you know, we're going to try that and give it a shot and see if it is useful. We, you know, we don't know if people will like it or not. But, you know, the fact of the matter is we have chief engineers who are trying to be project

managers and they actually are pushing back and saying, I can't do this anymore. I don't have time and I also don't have the skill and I'm not interested. So find me a project manager and we don't have any. So how do we fix that problem? We're trying to come up with ideas. The get well plan is something that you could do, you know, mid part way through a project, but that consulting service is something you could also do know mid part way through a project but that consulting service is something you could also do for project kickoff that would be very helpful to get them started yeah imagine it you would need kind of a primary from someone on that in the group right like okay who's gonna be your lead person because they still have that you know you still got a meeting you still got to

do some of those kind of things but they they don't have to, to your point, know how to calculate earned value or make a Gantt chart or, you know, those kind of things. And someone probably enough that can they can help out. But, yeah, that concept is neat, too, especially when you don't have enough staff and you have too many projects or, you know, the kind of ratio where if you have someone that can be the lead for something, you set them up with all the tools and some tips and, you know, maybe kind of some, which I think is always good, just here's a basic project management synopsis of how we do things here, or suggestions for you, or, you know, kind of short course kind of things that consulting thing sounds neat. I'd be interested to, or to your point, if there's folks out there that have feedback,

if you want to share that for this episode, people process progress at gmail.com, or certainly they could reach out to you as well. Donna, how could they contact you with questions about that? Kind of like questions that you got from PMI. Yeah. The best place to,

to find me is on LinkedIn. I, I get, I have lots of conversations with is on LinkedIn. I get I have lots of conversations with people on LinkedIn. I had that question I mentioned earlier where I had an individual who said massive problems on my project and and no one's paying attention to me. That was all I had that conversation with that individual on LinkedIn. And it's a it's a great, great way to find me. And my name is pretty unique. So I think I should be pretty findable. And yeah, I think that would be a great way to continue the conversation.

That's awesome. And it's D-O-N-N-A-G-R-E-G-O-R-I-O. That's it. You got it right. It's funny because I know I spelled it right when I'm looking at it, reading it. But you don't want to ever kind of say the say the spelling wrong so yeah I also have a website that the same my name.com so um yeah donagrigorio.com so that's another way that you can reach out to me if you can't find me on LinkedIn for some reason then that's another way to reach me that'd

be great and how can folks read how to be successful project managers and get those practical project guidance from your lessons learned? Where can they find your book, purchase it, download it? How can they obtain that knowledge? Yeah, that's that's great, Kevin. Thank you. I you know, I I my book is available on Amazon. That's the only place you can find it. So again, go into Amazon. You could search my name and it should come up, The Successful Project Manager. But I just really wanted to say that just to repeat what I've said earlier, really make yourself irreplaceable on projects and not irrelevant. That's the one thing you want to avoid. I know whenever there's budget cuts,

people get worried about their role as a project manager. And unless you're really making an impact and driving your project forward, then you don't want to be caught up in any sort of a removal of yourself from a project. You want to be able to be effective. And that effective translates to project success. And that's really key. At every project phase where you've had challenges, you know, address those challenges in the best way possible by using those tools. Keep a set of tools on your desktop, if you can, of things that you've used in the past that have been effective for you. I mean, I think that you should have a half a dozen tools. What are those tools that you use all the time? And really take an action tomorrow after you listen to this podcast and go into your office and start to pull some of those great things that you've done. I mean, we're all successful project managers. We've all had success in our careers.

And the reason we've had a lot of those successes are because of those artifacts. If you had to build yourself a website, which I'm not recommending you do because it's time consuming, but if you did, what would you put on that website? Say, hey, look, I did this. I did that. I built this. I built that. What did you build? You built a schedule.

You built a work breakdown structure. You built a journey map. Where are they? Put them someplace so you can get access to them. And I think that's one of the, if you have no other takeaways from this, listening to this podcast, that would be a key one for you. That's an action that I think you should take. And I think that will help you to be successful, whether you're a new project manager or an experienced project manager. Those are some of the things I think that will help. That's a great point. So LinkedIn, your website, any any other ways to reach you or social media or anything that you want to share with the audience? Yeah, I have I have an email. My email is my the initial of my first name, D, my last name Gregorio, and the number 20 at gmail.com.

So that's dgregorio20 at gmail.com. So feel free to send me an email, too. I'd love to hear from you. Love to continue the conversation. I think that getting that question in particular from one of my audience members at the PMI virtual experience conference last week really hit home for me because I think, you know, we as project managers, we go out and I teach my students in my college class and I presented conferences. And sometimes I wonder if people are paying attention.

And so to get that kind of conversation going, because I like to show some vulnerability and and say hey i don't do things right all the time and i gave you some examples of where i i've made mistakes and if i had to do over again i would have presented alternatives or if i had to do over again i would have defined a definition of done and and cut the project off at a time uh sooner than when we got can we we ended up getting uh canceled when the project was going on for too long i mean i've talked about some of the things i've done wrong and uh i love to hear from other people as well everyone has stories i mean everyone has a story

so yep absolutely yeah and to your point that's that's how we all get better is you know just putting it out there and lessons learned and being open and and you know i'm thankful for you sharing your knowledge and time and and to your point you know would love to continue this in the future about an hour and a half great conversation again after i don't know how many podcasts i've either been on or done and i'm always surprised how fast the time can go with a good conversation so i appreciate um meeting you and talking to you and and sharing your knowledge, your practical knowledge, and just, again, good conversations. So thank you so much for being on the show,

being on this episode. Thank you, Kevin. It's been a real pleasure. I really appreciate you having me on. And again, great work that you're doing. I know this is above and beyond your day job and advancing the project management careers of people and giving them tips and ideas on how to be successful is a great thing. So congratulations on a successful podcast.

That's awesome. Thank you very much, Donna. And thank you all, listeners. Remember, you can catch this on peopleprocessprogress.com, at PeopleProcessProgress on Facebook, Instagram. Also connect with me on LinkedIn. I'm Kevin Pinnell. I'm happy to connect. And be sure to go to Amazon.

Check out the successful project manager from Donna Gregorio. Buy it, read it, and learn how to be irreplaceable, not irrelevant. Thank you so much, everyone. Please stay safe out there. Wash your hands. And Godspeed.