The People, Process, & Progress Podcast - Why You Should Treat the Planned Event Like a Project

Episode Date: June 2, 2025

Planning a public event without structure is a risk you can’t afford. In this episode, Why You Should Treat the Planned Event Like a Project, Kevin Pannell shares how to apply project management principles and ICS tools, like RACI matrices, project phases, SMART goals, and SitReps, to plan safer, smoother public safety events. Whether you're leading a 5K, a drill, or a community gathering, treat the event like a project—and lead with purpose.Topics Covered: event planning, project phases, stakeholder roles, ICS, SMART goals, emergency management, public safety leadership

Planning a public event without structure is a gamble. I've seen it firsthand. Political events, 10Ks, and other community events or festivals. Sometimes they weren't like clockwork. Other times they unravel before the first tent goes up. The difference? Planning. Ben Franklin said, failing to plan is planning to fail. That's a mantra that have carried with me in public safety or project management.

And I think this quote applies just as much to public events as it does to emergencies. In fact, according to FEMA, nearly 40% of small businesses never reopen after disaster. I believe that's largely due to planning or pre-planning that didn't happen. And if poor planning can take down a business, imagine what it can do to an event with thousands of people, moving parts, and safety risks. That's why I think we should treat every event like a project and you should too. Please silence your cell phones, hold all sidebar conversations to a minimum, and let's get started with the People Process Progress Podcast. Welcome back to the People Process Progress Podcast. I'm your host, Kevin Pennell.

Today's episode is the third of the All-Hazards Project Management series with a simple but powerful idea. The event is the project. So let's start with what matters most to people. Events don't fail because a checklist was missing. They fail because people didn't know who was in charge of what. That's where our stakeholder mapping comes in, right? So this is a project management component,

but we do it in Incident Command, and I'll talk about that here in a second. This is a simple tool, I've talked about it in other episodes, but it's a very simple tool, easy to use, in a spreadsheet or whatever the format, but it provides a lot of value. And so the RACI matrix,

it clarifies who's for the R responsible. Now, this is the person who's going to do the work. So let's say in the incident command system, this is typically operations, right? They're the ones out there doing it, who we all work for the hands-on worker in a project. There's the technician, the analyst, whoever it is.

Again, the people that are out there deploying machines, all that kind of stuff. The A in RACI is accountable. This is a person who ultimately owns the outcome, right? So the incident command system, the operations section chief, and then above them the incident commander. And in a project, it's gonna be the business owner often

and for sure every time the sponsor, right? Ultimately the incident commander is responsible, just like a sponsor is responsible on the project level. And then who needs to be consulted, right? These are individuals whose expertise and input we who needs to be consulted, right? These are individuals whose expertise and input we need to seek for decisions, right? These are our subject matter experts and this could be a technical person,

it could be a disease expert, it could be a hostage rescue expert in public safety and it's at command, but we need to consult them when we're making the plan so that we do the right thing. We're not just guessing because we stayed at a Holiday Inn Express last night. And then the I in RACI is informed, right?

These are those who need to be kept up to date. So a lot of policymakers, leaders that have interest in what we're doing, stakeholders that might be affected by the change, the public, right? That public information is huge for the incident command system, for planned events. And it is for projects as well. It's just we're calling it kind of communications and talking to folks in our organization largely, maybe we're a partner organization. So I sprinkled Incident Command System terms

and positions in here, and to show that it lines up with the planning process, right, the Planning P. So in our Incident Briefings, right, or especially let's say earlier on when we're getting that briefing, that 201 work in the leg of the pier, we're getting our command and general staff meeting,

like we're calling out these stakeholders. So we're essentially doing a racy matrix. We're not quite saying who's gonna do what job, because that's a little bit later for the tactics meeting, but we're saying who's in command, who's gonna lead planning, who's gonna lead operations, who's doing logistics for us, who's safety, who's public information, who's the liaison,

who's gonna do our finance admin. So we're getting those key positions just like a racy matrix does for a project. It clearly defines for us who's running the show, right? And if they're not clearly owned, and again, then we're gonna waste time on a project from people who they're not doing work thinking somebody else is,

or for two people doing the same work or being in each other's space, or especially if you're, you know, a planned event where you have perimeters and you're doing security, you might have a gap in the perimeter because someone thinks someone else is color covering it. So we need to clearly define that. And we do this through other tools later on, right? Through our project management plan, through our incident action plan. And of course I'll do more episodes on that,

but I remember I once supported an incident or was part of the planning for an incident, right? And there were assumptions that we were all talking to each other and we'd all plan together on who was in charge of radios. There are set in the incident command world, there are set positions who are responsible. There's a communications unit responsible for all the radios,

but we walked out of a briefing and some of my counterparts from a public safety agency, not to be named, were looking at their dials going, oh, I guess we'll just use this one. That's horrible and it's unsafe. And think about if you left a project meeting going, oh, I guess we'll just use this budget code. Who's money are you spending?

When are you spending it? So this knowing who's who and treating events like a process, I mean, for public safety planning largely, for a community event, treating it like a process. I mean, for public safety planning, largely for a community event, treating it like a project rather is important. Not just that it's this thing we're going to do to get folks signed off and stuff like that, but it's a project. It's a one time thing, even though you might do it every year.

Take the time to see who's who's responsible, who's accountable, who's consulted, who's informed. Do the planning process work through that completely? Because you all seen the news. If you're like me and you're interested and you've read the after action reports from when things have gone wrong, that's just a 911 call waiting to happen or just an after action report that says, yeah, they never plan together. They never practice together.

That's why their response was horrible. That's why this event was a failure when weather came in or a bad guy came in or a car crash through or we lost money. We didn't have a contingency plan on the project, whatever it is, you can tell immediately when folks didn't play in route. So stakeholder clarity, whether it's people in a business or the public that we're serving as public safety agents, right, prevents that. It starts every project with role alignment, who's doing what, we're going to write it

down or we're going to put it on the forms in the Internet Command system, we're gonna put it in the project management system on the project management side, right? So that leads us to the process, right? And this is where I've also seen events fall apart because people work their own process or they don't have a process, they're certainly not sharing a process.

We need a clear, clear framework. Now in the project management world, in the tradition, waterfall is it right? You initiate a project, you plan it, you execute it, you close it, and the whole time you're monitoring it. Sounds a lot like phase gates is what they are in project management. So are we ready to go to planning and when we initiate, are we ready to execute when we are planning? The same thing happens in the

incident in the incident action planning process, the planning P, right? Something happens, we're like, hey, it's initiated at this date and time. We're going to the planning process will say, not just the event, but we're going to start the planning. We're going to do the planning. We're going to execute when we do that operational briefing to tell our folks they're going to hit the streets, where they're going, what they're going to do. We're here.

We're, you know, if you need something, here's the radios. It's on the plan. And then we'll close or demobilize, that's what we do in public safety for the folks that aren't in that world. But we don't go to the next step until the current one's done or we shouldn't. The biggest crossover is probably in initiating.

As soon as, let's say even if it was a planned event, we already kind of foreshadowed some of the things we wanted to plan, who was gonna be in positions, if we knew them. We do the same thing in project management. If we know who's in our organization, we know who can fit the bill, we can do all that kind of stuff.

And that's good, it's good to think ahead. I think where we don't wanna get started too quickly is in executing from planning. And yes, I'm very familiar with the, you know, paralysis by analysis thing. And I understand people still need to be ready to some degree. We don't have to be at 100%,

we don't have to have everything perfect, fully stocked, all that. But we need to know that people know who to call if they need something, whether that's on a radio because it's an emergency or a team's message because they're stuck. That's the kind of planning that we need to get done at least, right, before we go to execute things.

And sometimes it costs money right. If we just start doing things that cost money and we're not approved for it. That's a problem on its own. So a good hybrid I'd say between public safety planning for an event and sprinkling or overlaying some of these project management principles or vice versa really is let's ask ourselves some things

in the process. What's the intent of this event right. That leaders intent I've talked about many times and that you all know is critically important. What are these measurable objectives, right? These smart objectives. Who are the operational leads? That's our stakeholder management.

Who's the head of the boxes that we're gonna put a bunch of people under in the org chart? And do we have contingency plans? This I've talked about and I strongly believe in and I urge for folks that I work with, have your plan if 100% isn't gonna happen, if you don't have all the money and the time and the resources and the quality How are you gonna fix that? How are you gonna do it with seventy one percent of the money? What are we gonna do for an event and it rains? What if a thunderstorm comes?

What if it floods like we need to plan for those things and it doesn't take a lot to have a pretty decent contingency plan One of the best planning efforts that I was a part of was focused on contingency planning. It was sitting with people that were going to be in the jurisdiction that my incident management team went to help. It was going to be this big rally, March, politically charged thing. And so we went through what if there's a fire, what if they drive through, what if there's a shooting, what if there's a heat stroke, they drive through or if there's a shooting what if there's a heat stroke what we went through? So many different things and it paid off because unfortunately something bad did happen during the event But we had practiced it we had talked about it The folks were ready and it doesn't negate the horribleness of what happened

But it made the coordination of the people that were there ahead of time work much much better together so that they could reduce injury, reduce loss of life, and coordinate resources much better. And the same can be on the project management side and should be because typically projects, standard projects aren't emergencies like can happen in an event where you're a public safety person

getting ready to do something, right? So there's a sign when people miss gaps, I mentioned that earlier, go look for after action reports from something bad that happened. And you'll see there's gaps between planning and execution, so please don't skip the steps. So we know who our people are,

we're working a process together, right? We've identified a racing matrix, we've got it on the org chart, we're working this instant action planning, we're working the phases of a project. So how are we gonna make progress? Well, we gotta track it, right? We can't just go, oh, we got it.

We pulled it off as a metric. We need to go, we made smart objectives, right? And the M is measurable in there. And on a good project, we've also got key performance indicators or KPIs. So we should know beforehand, how was it? Afterwards, did it change to get any better? Particularly a project?

Because typically projects are going to solve maybe a workflow or a new device to make efficiency better or to save money or something like that. A planned event, people show up, they want to do something and leave, but we could look at did sales go up? Did sales go down? Did we have more or less incidents? How did we respond to those incidents? Was it faster? So we can look at the data we had before from past events or similar events and then we can look at after. Right. And maybe we have a dashboard and there's some great particularly GIS folks, some friends

with folks that went from public safety to GIS. And it's amazing technology we have when we used to track people all over the place and now the data they can pull. And with the technology this day and age that can be out there for public safety, we can have a real time incident metrics dashboard. I mean, 911 centers have this all the time, right? We're looking at number of safety incidents, right? One time setup.

How long did that take? A resource usage. That's a big thing on projects is who has bandwidth or not on the team that we can ask for, right? How effective was communications? That's kind of probably more subjective one other than if there's technical for, right? How effective was communications? That's kind of probably more subjective one other than if there's technical measures, right? Volunteer check-in and check-out,

did it take more or less time? That's where I cut my teeth in incident management, was sitting there with a clipboard as we tried to get everybody to work together, and I had great friends who were pushing that and driving it and they changed our whole region, the state, and eventually the country and some of the world who are teaching around there now.

But you can start with these little things, did it take less time for everybody to get in and out of the event? Did it take less time for us to do this sprint in the project? Measure before and after, it's a huge thing, right? You don't need fancy software, you just need to get that clarity.

And that incident status report, right, that our situation usually is gonna do, is a great tool. Figure out a good tempo for those. Send a couple a day at the beginning. In the middle, if it's real busy, to give an update, a real short one. So you get kind of a comprehensive,

hey, here's what's happening for the day. Here's a real short where we're at. And at the end, it's a good daily summary. It gives a pulse check, especially if a multi-day event, or you have certainly a lot of projects are multi-day, week, month, years even. And then ultimately you want to measure that in your after action, your lessons learned

report, your project closeout report. That's critically important to not skip over it. Closing a project and demobilizing from an event are the two least popular, probably portions of planned things. Sometimes folks just want to leave, which I get. You've worked a long day or multiple days. And sometimes folks just want to check out of the project and go back to their regular job But it's important that we capture that info and we measure it and make ourselves better because again these events are projects these projects

Are events you could you could make it go back and forth, right? And if you want to get better You have to measure what matters So here's a challenge I put to myself and to you all that I want to keep top of mind is to think back to a recent event that you were involved in or a project if you're a project manager. Maybe you planned it, maybe you were part of it and ask yourself, could you map that to project phases? So when you started the planning cycle for this festival in your town, can you figure

when you initiated it, when you were planning it, when you executed it, you were doing the work, and then when you closed it, and then similar, hopefully for a project manager, you can clearly do that. Where did planning break down in your project during your planned event? Were stakeholder roles clear? Did you know who was who from the lowest level

to the highest level of who was responsible? Did they know who was who? And that's something you can capture that I recommend that I do. And all my lessons learned surveys that I send out is, did you know your position? Did you understand the objectives? Did you know what your job was? Right. And if not, then man, I need to do a better job of that.

And what did we track? What metrics do we have? How can we make a good closure report and after action lessons learned and improvement plan out of that, right? So take it through for the next event, do that RACI, right? That Responsible, Accountable, Consulting, and Informed and apply that to Incident Command System, right?

Use a simple checklist, project managers, we should be doing that pretty regularly. Even if you're agile, you're doing scrum stuff. It's very helpful, we know who's who, but it's good to have the RACI chart. It's an educational piece too, for people who aren't familiar with that. And of course, smart objectives,

we need to use those, right? They don't have to be perfect, but they should have some intentional planning, some intentional focus on getting ourselves better. So in closing, and again, thanks for you all for being here. Go to peopleprocessprogress.com. For more info, follow me on X and Instagram at Penel KG. Go to the panel, five fitness club, 15 seconds at a time.

You get fitness ideas, jujitsu, after action reports, and some cold plunge goodness. And check out the new kind of channel trailer, if you will, that I used with some experimenting with some stock footage and talking about the exercise furnace, right? That burns depression and fear and grief and self-doubt and just how much value that has and how I spread that and other messages across this platform and the ones I just mentioned. Just remember planning isn't just bureaucracy, right? It should be

leadership, right? We structure our events like a project. We can reduce risk. We can empower the teams. We can serve the public better. And that's what the All Hazards Project Management series is all about and the concept and the course that I've taught. It's bringing the best of emergency response and project leadership together because there's so many parallels and they can learn. Those two worlds can learn so much from each other and that's what I've helped cross over with people. And thank you so much for tuning into this podcast. Check out the Foundations Friday Campana that's coming up later this week, of course, and we'll quickly dive into structuring your event like a project and remember at the end of the day we're always going to keep people first we're going to work that combined process and

we're going to make progress together. Godspeed y'all.