Author Review Draft. Do Not Publish. Why You Should Treat Project Management Like Incident Management
Why You Should Treat Project Management Like Incident Management
Managing a project isn’t that different from managing an incident—once you understand the parallels.
By Adam Jackson
B Shifter Buckslip, July 7, 2026
Several years ago, I stepped into a new role that required me to manage a variety of projects. Although I was used to managing incidents as an incident commander, I did not have the knowledge or skills to manage projects that lasted several months or longer. One of my first projects was overseeing the purchase and implementation of new SCBAs. I started by doing what any good firefighter would do: I called neighboring departments to see how they had done the same thing. After getting some helpful tips and modifying them to meet our needs, I began. We started by deciding which brand of packs would meet our needs, then chose a well-rounded group of firefighters as evaluators. We then held several days of testing to evaluate ergonomics, serviceability, ease of use and communication clarity. The evaluators scored each pack, then we chose the winner.
It Was All Going Well, Then I Realized Something Didn’t Quite Fit
Next came the task of understanding all of the “extra” elements that go into a new SCBA purchase, such as adapters for air-fill compressors, different bottle sizes and styles for the hazardous materials and technical rescue teams, new RIT packs, and a training plan—as well as the rules and laws governing the purchase. After months spent going through all of these details, I thought I had everything figured out and moved forward with the purchase.
When the packs arrived several months later, we launched the implementation process, then hit a huge roadblock. Despite all of my work and preparation, I had failed to realize that the new, slightly larger bottles would not fit in the existing SCBA brackets in our apparatus. When I had to explain this to my boss, the assistant chief of operations, he was less than happy with me. I had to order new brackets (which took months to arrive) and then develop a plan with the logistics chief to outfit the entire fleet of 30-plus units with them before we could move forward. It was a hard-learned lesson, but eventually, the SCBAs were put into service, and I was able to complete the project.
I Realized I Needed Additional Training in Project Management
I decided to attend a Project Management 101 course taught at a local community college. The class lasted three days, and I was the only firefighter in attendance. The other students were city, county or state government employees. After our initial introductions, I realized that the other students were full-time project managers in one capacity or another. I feared I was in over my head, but I knew I needed some additional training, so I stuck it out.
Before you start any project, you need to ask, “What are we trying to accomplish?”
Define your solutions and strategies. What is the project’s value to the organization?
What is the business case or cost-benefit for the project?
After a few days and several group projects, I realized why so many fire department projects take forever or don’t achieve what they set out to accomplish: The challenge isn’t that firefighters are poor leaders. It’s that we’re extensively trained and highly proficient at managing fast-moving incidents measured in hours. This makes sense, as our primary focus is emergency response. But many of us are also responsible for leading long-term projects that unfold over weeks, months or even longer, requiring a different set of tools. These projects often have a direct impact on our response or are intended to improve our response.
Project Management through a Fire Service Lens
I soon realized that many of the skills we use on the fireground already apply to project management. The terminology is different, and the timelines are much longer, but the fundamentals—setting objectives, assigning responsibilities, communicating effectively and adapting to changing conditions—are remarkably similar. Many of the terms I learned in class have familiar fire service counterparts. The translation isn’t difficult, and once you see the parallels, it makes sense.
- The project manager = incident commander. This person oversees the project to meet the objectives as planned. They ensure the assignments are understood and completed. They are also responsible for ongoing communication and overcoming obstacles. May not do the actual work, but is ultimately responsible for ensuring it gets done.
- The stakeholders = citizens, governing bodies, support staff. These people might not do the work, but have an interest in the project’s outcome and are affected by its success or failure. These players may provide funding, input, approvals or requirements and can influence decisions.
- Team members = firefighters and support staff. They are the ones doing the work on the project. They are directly involved in day-to-day work, assigned specific responsibilities, report to the project manager and help develop the deliverables.
- Project goals = tactical priorities. The goals define what the project is trying to achieve. Always focus on the results or benefits. Define these goals at the beginning of the project and make sure they are SMART—specific, measurable, achievable, realistic and timely.
- Requirements = SOPs, SOGs and protocols. These describe how you will meet objectives. Keep in mind that there may be several types of objectives (technical, departmental, project-specific).
- Project scope = critical fireground factors. The scope describes the deliverables and the work required to complete them. Includes constraints, assumptions, criteria and what is not
- Deliverables = tasks/TLO. These are measurable outputs produced during the project. They are specific, can be approved or inspected, are developed by the project team and contribute to achieving the objectives. Deliverables answer the question, “What are we producing?”
- The work breakdown structure = the tactical worksheet and organizational chart. This outlines, organizes and easily displays all of the project deliverables.
As you can see, the language is different, but the core ideas are the same. Understanding these parallels helps us apply what we already know to new situations—whether we’re managing a fireground or running a project.
4 Phases of Project Management & Why They Matter
Before you start any project, you need to ask, “What are we trying to accomplish?” Define your solutions and strategies. What is the project’s value to the organization? What is the business case or cost-benefit for the project? From there, you can break down the project into specific phases, which I describe below.
1. The initiation phase helps define the project’s scope, goals and deliverables. Make sure these align with your department’s priorities and strategic plan. Ensure there is clarity on “What are we trying to solve?” Identify all of the stakeholders, including any SOPs, SOGs and any other items or groups that might be impacted negatively or positively by your project. I would have really benefited from this step when choosing new SCBAs. Had I included a mechanic in my stakeholder group, they could have helped me identify the need for new brackets and devise a plan for having logistics install them. When you are identifying stakeholders, including folks from the shop, IT, training or other areas that you may not think are affected can reveal key details you are missing. Identifying the sponsor, obtaining the budget/resources and outlining timelines/benchmarks are other key details handled during this phase.
2. During the planning phase, you will develop the roadmap that explains how the project will be executed, monitored and completed. Deciding how you are going to track all of these details, such as an Excel spreadsheet or a project management software program, might seem basic, but it is an important step. Identifying the roles and responsibilities of your team, sponsor, shareholders and project manager is crucial to your project’s success. Establish how often your team will meet, the form and frequency of communication, and how the team will provide feedback to the project manager. The last step in the planning phase is to review, critique and revise the plan.
3. The execution phase is when you implement your plan, ensuring effective coordination and communication while keeping the project on schedule. This is where the training and rollout happen. Really take your time planning this process. Sending out an email and dropping off a new piece of equipment at each station is a sure way to guarantee failure. I have seen a lot of projects flop due to poor implementation. If you are going to conduct training (which I highly recommend), who will conduct it? How and when will it happen? Coordinating with the training division (a stakeholder) early in the process can make or break the execution phase. Consider a pilot program before the full rollout to identify obstacles or unforeseen issues. As firefighters, we are wired for quick, decisive action; slow and methodical can seem painful to us. But a slow, methodical approach improves the chances that firefighters will actually use whatever you’re implementing.
4. The review/monitor/closing phase ensures implemented changes are working as intended. This is where you collect data on adherence to your new policies, procedures and equipment. Gather feedback from the field at the six- and 12-month marks to make any needed changes. Failing to do this can have a huge impact on your project’s success. We rolled out a new decon process that included new buckets, brushes and soap for crews to use post-fire. The equipment was stored on top of the engines. When we reviewed the project, we learned that many drivers were either forgetting to set up the new decon equipment or choosing not to climb on top of the engine to get it because of the time it required and poor workflow. We replaced the hard buckets with collapsible buckets, which allowed us to store all of the new equipment in a side compartment on the driver’s side. We also incorporated setting up the decon process at every multicompany drill we do. These two changes made a huge difference in the success of this new process. You also want to gather feedback from your team on how they felt the project went and any suggestions for improvement in the future. Once you have done that, you can officially close the project.
The same knowledge, skills and abilities that we possess as incident commanders can be utilized to successfully manage a project. Understanding this can give you the confidence to tackle any task.
Adam Jackson works for Central Pierce Fire & Rescue in Washington. He was a firefighter for 12 years and a company officer for 10. For the past several years, Adam has served as a chief officer. He currently serves as deputy chief of performance. In his off time, Adam enjoys cycling, camping and spending time with his family. You can reach Adam at ajackson@iaff726.org.