When the electricity went out in my apartment, I was ready for the obvious inconvenience. I had been alerted to the outage, and I had candles within easy reach.
What I hadn't thought through was everything else that depended on the electricity.
My Wi-Fi went down. I thought I'd switch to 5G, then realized my phone was almost out of battery and I had no way to charge it. The food in the freezer started to thaw. I couldn't boil the kettle for a cup of tea. Fine, I thought, I'll drive over to my parents' place. Then I remembered I drive an electric car.
I may be exaggerating a little, but the point still holds. We rarely think about the conditions that make even the most ordinary parts of our day possible. We notice the thing we want to do. We don't notice the network of dependencies underneath it.
The same habit follows us to work. Most of us are focused on what we need to achieve next: the project, the target, the next quarter. The baseline that keeps today's work running fades into the background. Yet that baseline is held up by processes, systems, people and suppliers. If you want to grow, change, or adapt safely, you need to understand what is carrying the weight today.
This is a big part of why business continuity management (BCM) can be hard to value. In the abstract, it sounds like paperwork about things that might go wrong. It starts to matter when people can see how it relates to their own work.
I often think about it like an orchestra. Ask a musician what they do and they'll tell you what they play. To understand what happens if they stop, you need the score: When do they come in? Who follows them? What are they supporting? What happens to the performance if they miss their cue? A Business Impact Analysis (BIA) without the connections between activities, dependencies, and impacts tends to capture people’s instruments. What you need is the score. And once you can see how all the parts fit together, the whole piece makes much more sense.
In this field note, I want to share a recent customer project where that became very clear to me. The people in the room knew their work inside out. What made the difference was being able to see it.
Starting in the BIA workshops
The project started the way many do, with a series of BIA workshops. Around the table were people who understood their business activities in real detail. They could walk you through their week, explain who they handed work to, and tell you which parts of the job kept them up at night.
When I asked what they did, the answers came easily, but when I asked what that work depended on, the room went quieter.
People would name the obvious system or the team next door. Then they'd pause. Was there a supplier involved somewhere? Who actually maintains that application? What happens if the one person who knows how to run the month-end report is off sick? The knowledge was in the room. What was missing was a shared way to see and describe the connections.
That contrast stayed with me. These people understood their business better than anyone. They had just never been asked to look at it from underneath.
Why dependencies are harder to see
It is relatively easy for people to describe the work they do. It is much harder to describe all the conditions that make that work possible.
Most of us see our own process clearly. We see much less of the wider network that keeps it running. And that network is bigger than it looks. In a single workshop, we touched on multiple dependencies including;
- Systems and applications, from the core platform to the small tool one team quietly relies on.
- Equipment and facilities, like the office, the warehouse, the printer that has to work on payroll day.
- People, skills and knowledge, especially the expertise that sits with one or two individuals.
- Internal teams and upstream activities that have to finish before your work can start.
- Suppliers and external service providers, including the ones nobody thinks of until the invoice arrives.
None of these show up on their own when you ask someone to describe their job. They sit in the background, the same way the electricity did in my apartment.
This is also why the classic BIA questions can feel strange in a workshop. How long could this activity be disrupted before the impact becomes unacceptable? What would you need to recover first? What's the minimum level of service you could live with? Asked in isolation, these questions can be hard to answer. Without enough context, it’s easy to end up with answers that don’t tell you much about the relative criticality of different activities, including recovery objectives that start to look very similar.
That was the musician describing their instrument. We still needed the score.
The moment the BIA became a picture
After the workshops, we structured the BIA data in Fortiv and brought it back to the same group as a visual representation of their business. I'll admit I was curious how it would land. Would seeing it laid out add anything?
It did. Almost immediately, the conversation changed.
People could see how their activities connected to each other. They could see what each activity depended on, and which of those dependencies were shared. One application that had come up briefly in a couple of workshops turned out to sit underneath several important activities across different teams. A supplier that one department considered minor was supporting work in two others. A handful of people kept appearing as the only ones who knew how to do something.
The potential vulnerabilities no longer needed much explanation. They could see them.
What struck me most was the shift in how people talked. Before, they answered questions. Now they started asking them. "Wait, does that mean if this goes down, we're affected too?" "Who else uses that supplier?" Someone pointed at the map and said, more or less, that this was the first time they had seen how their piece fit.
The information was no longer a series of workshop responses or fields in a spreadsheet. It had become a representation of how the business actually worked.
That shift matters. What I saw was that people engaged differently with BCM once they could recognize their own responsibilities in it. A visual map turns an abstract conversation about "dependencies" into something concrete: this activity depends on that system, which depends on this supplier, and several important services are affected if it becomes unavailable.
That was the aha moment. And it changed the quality of the conversation. People became more invested in understanding and improving the information they had contributed.
From BIA answers to a continuity plan
The next step made the picture even more useful. When we moved from the BIA into the business continuity plan (BCP), people could finally see why we had asked those workshop questions in the first place.
Each question had a job to do:
- The MTPD identified the point at which continued disruption would become unacceptable.
- The RTO translated that limit into a targeted timeframe for resuming the activity.
- Recovery priorities showed what had to come back first if everything could not be restored at once.
- Critical resources identified the people, systems, equipment, sites, and suppliers needed to resume those activities.
- Minimum acceptable service or capacity levels clarified what “good enough” looked like during recovery.
- Dependencies and alternative arrangements showed where the organisation was exposed and what could be done if a resource was unavailable.
In the workshop, these felt like boxes to fill in. In the plan, they became decisions.
This is what we recover first. This is who we call. This is the workaround if that application is unavailable.
That's the chain that makes BCM hang together. BIA findings inform your continuity strategies. Strategies shape the plans. Plans set recovery priorities, and exercising those plans shows you where the gaps are. Seeing that chain end to end gave people a reason to care about the quality of what they had put in at the start.
Data collection is only the beginning
For me, the project was a useful reminder that collecting the data is only part of the job.
Some of the BIA questions can be difficult to answer in a workshop, particularly when people haven't yet seen how their answers fit into the bigger picture. Understanding what they depend on, who depends on them, and what happens elsewhere when something stops can make those questions much more meaningful.
Showing people that picture early can make a real difference. Once they can see where they fit, they become much more invested in uncovering the information that matters.
Ultimately, BCM is about keeping the parts of the business that matter most running through disruption. To do that well, you first need to understand how those parts fit together.
When people recognize their business in it
Back in my dark apartment, the problem was never the candles. I had prepared for the thing I could see. What caught me out was everything sitting quietly underneath it.
Businesses work the same way. The people closest to the work usually hold far more knowledge than a BIA can capture through individual questions alone. What they rarely get is a view of how their piece connects to everything else. When we brought the BIA data back as a visual representation, the team got that view. The work stopped feeling like a series of questions they had been asked to answer. It started to look like their own business, with their own activities, dependencies and responsibilities in it.
That's when the musicians start reading the score.
The goal of a BIA is bigger than collecting information about the business. It's making the connections visible enough that people can help protect it.
Field Notes on Resilience is a series by Nynne Svenningsen, BCM Consultant at Fortiv, sharing observations from the field on how resilience and business continuity are applied in practice.
