The Risk of Fixing It Yourself: A Lesson in Data Governance

by Nicole Holt, Preble Street

Somewhere on Franklin Street in downtown Portland, Maine, in December of 2014, I was sitting in traffic that would not move, calling my son's daycare to frantically apologize for a lateness I could not explain. I did not yet know the explanation was a man in a truck with a possible pipe bomb sitting in a bucket of water.

Here's what actually happened: a contractor was cleaning out a utility closet in a building near the base of Munjoy Hill and found an old wired cylinder that looked exactly like what it turned out to be (Portland has a wild history, folks). He almost tossed it in the dumpster. Then some instinct kicked in, and he looked closer. 

Good instinct! We have to give him credit for that at least.

Here's where his good instinct goes sideways: He didn't call the police to say, "I found a weird thing, please come see if it’s a bomb!" Nope. He filled a Homer bucket with water—Would that have even helped? I don't know, and I’d guess he didn’t really know either—put the device in it, loaded it into his truck, and drove it downtown himself, through actual Portland traffic, over actual Portland potholes, maybe over some quaint Portland cobblestone, and parked in front of the Portland police station.

By the time he arrived, he'd singlehandedly created the exact scenario that threat containment protocols exist to prevent. 

An unknown device.

Now in motion.

Now in the middle of a city.

Now everybody's problem at once instead of one contained problem in one contained closet. 

Police shut down Franklin and Middle Streets. They evacuated floors of the building across from the station. A robot had to be sent out to pull the thing from his van. And somewhere in the six blocks of gridlock the contractor’s well-meaning decision created, I was on the phone with a daycare worker, explaining a delay I couldn't imagine. 

I think about this story more than a decade later because I spend my professional life around a much lower-stakes but structurally identical failure mode.

The instinct that causes the problem is indistinguishable from the instinct that would have prevented it

The contractor wasn't intentionally reckless. He was trying to be helpful. That's what makes this a governance story and not just a "well, that escalated quickly" story. He saw a risk, correctly identified it as a risk, and then made a second (incorrect) decision that he was also the right person to resolve it himself. 

That second decision is the one I want us to sit with, because in a nonprofit data environment, it's not rare. It's  your typical Tuesday. Do any of these I’ll-fix-it-myself scenarios sound familiar?  

Someone finds two constituent records that are obviously the same donor, duplicated across a batch import, and merges them by hand before anyone else notices there was ever a mess. 

Someone finds an old export sitting in a shared drive that clearly shouldn't still exist and quietly deletes it, without checking where it came from, who pulled it, or what report depends on it. 

Someone notices a Power Automate flow is writing to the wrong fund code and patches the flow directly in production on a Friday afternoon, no change log, no second set of eyes, no note for the next person who inherits that flow and has no idea it was ever touched. 

None of these people are careless. All of them are doing the same thing the contractor did: correctly spotting the risk, then incorrectly assuming that spotting it also qualifies them to resolve it alone, quietly, right now. Those are not the same skill.  

Finding the bomb and knowing how to disarm the bomb are two entirely different competencies, and the entire point of a hazardous-devices unit is that the person who happens to be standing there when the risk appears is very rarely the person equipped to neutralize it.

Protocols aren't a vote of no confidence

The protocol on Munjoy Hill was never "find a device, panic." It was something much smaller: flag it, don't move it, let it be assessed by the process built to know what it actually is, and how to deal with it. That protocol doesn't exist because we all believe the average contractor is reckless. It exists because "I'll just take care of it myself" is precisely how a contained, one-closet problem becomes a six-block, building-evacuation problem.

The equivalent in a Blackbaud Raiser's Edge NXT or Dataverse environment isn't dramatic. There's no robot, no evacuated building, no roads closed. But it’s still dangerous. A quiet, unlogged fix to a data problem doesn't announce itself as a near-miss. It just sits there, invisible, until someone six months later is trying to reconcile a fund report or trace why a donor's giving history doesn't match what development remembers, and there's no ticket, no note, no way to know what was touched, by whom, or why. 

The absence of drama is what makes it dangerous. 

Nobody evacuates a building over a silently overwritten field, so nobody learns from it either. Unless someone insists on writing it down.

A format for writing this down

You don't need a governance department to do this. You need a page. Here's a shape that works for a team of one, five, or 50:

1. What counts as a "found device"

Name your pipe bombs, meaning the categories of things that should never be quietly fixed alone (your list may look different than mine!): 

• Duplicate constituent records
• Data exports leaving the system
• Direct edits to production flows or automations
• Anything touching gift or financial data
• Anything that would change a donor's giving history or communication preferences. 

If someone finds one of these, that's the moment the protocol starts—not after they've already tried to fix it.

2. Where it gets flagged, not fixed

One place. A ticket, a channel, a shared log—it doesn't matter, as long as everyone knows it and it's actually used. In constituent records, I’m a fan of constituent notes with a type “RE Record Maintenance.”

The goal is a trail that exists before the fix, not a summary written after the fact (if someone remembers). Pick one tool and make it boring to use. 

My own current plan is a SharePoint list, because it gives you columns you can sort and report on: 

• Date
• What I Found
• Where I Found It
• My Best Guess
• Status
• Resolution 

A Microsoft Form works well as the front door to that same list, if you want one. One link, works from a phone, no navigating to SharePoint in the moment you're standing over the thing you found. The catch: a form can only add a row, not edit one, so it's good for capturing the find but somebody still has to open the actual list to move the status along and close it out. This is a fine tradeoff as long as everyone knows which side of that line they're on. 

Here's what an actual entry looks like, no polish, no committee: 

“Found a table in the dev environment named import_backup_FINAL_v2_useThisOne. Looked like an abandoned duplicate of the live gift import, but the filename didn't inspire confidence. Did not delete. Flagged to [name]. Status: pending review.” 

That's the whole ritual. It's not eloquent. It's dated and it's sitting somewhere other than your own memory of what you meant to get back to.

3. Who assesses it

Name the person or role, not "whoever's free." In a two-person shop, this might just be "the other person." In a one-person shop, it might be writing down the issue and coming back to it with clear eyes later to make sure you agree with yourself. The point isn't hierarchy; it's a second set of eyes that isn't the person who found the problem.

4. What "safe to proceed" looks like

A one-line description of what needs to be true before someone acts: confirmed in a sandbox, confirmed with the data owner, confirmed it doesn't cascade into other reports or flows. 

This is the equivalent of the hazardous devices unit actually assessing the thing before anyone touches it.

5. The debrief, even when nothing blew up

This step is really easy to skip. When something gets caught and fixed correctly, say so, briefly, to the whole team: Here's what we found, here's what we did, here's what to do if you see it again. 

It doesn't need to be a formal postmortem. It needs to happen every time, including the boring times, so the protocol stays visible instead of existing only in someone's head. Honestly? As a reflexive fixer, I’m still struggling to build the habit of debriefing.

6. What story does the bigger picture tell?

There's a sixth thing that the log does for you, and it only shows up after you stop looking at it one-entry-at-a-time. Every few months, read the whole thing back, together, not as a series of individual fixes but as one document. 

What shows up more than once? If “duplicate constituent record” is half your entries, that's not five unrelated near-misses—that's one gap wearing five different disguises, and now you know where to point your next staff training instead of guessing. The log stops being just a record of things that almost went wrong and starts being a pulse check on the actual health of your data, which is a much more useful thing to bring to a training budget conversation than “I have a bad feeling about our import process.”

None of this is complicated. It fits on one page. The hardest part isn’t in the act of writing it down; it's in remembering that a data problem that's caught early and handled quietly by one well-meaning person is still the Homer bucket of water. It might have helped. Nobody can actually be sure. But this is the very reason the protocol exists: to remove the uncertainty of "nobody can be sure."

The part that’s easy to skip but important to do

The bomb debacle debrief is the part of this story I actually love. Portland's police chief went on the news that same night and didn't just clean it up and move on. He used it. He told the public plainly: If you think you've found something like this, call us, we’ll come to you! That's not a scolding. That's a system correcting itself in public, on the record, while the story was still fresh enough that people were actually listening.

 That's the piece that is so easy to skip. We fix the immediate mess and call it resolved. We rarely go back to the room and say: here's what almost happened, here's the step that got skipped, here's what to do differently next time you're standing in a utility closet—or a shared drive, or a production flow—holding something you're not sure about.

The bucket of water holding a pipe bomb is a good story. The chief going on camera afterward is the actual lesson. If your organization has an incident review process, a documented escalation path, and a habit of turning near-misses into the next training rather than a quietly closed ticket, you already have what that police department had. 

If you don't, the good news is it costs nothing to build an incident review process. It just takes someone deciding that "we handled it" isn't the same sentence as "we learned something," and that saying so out loud, on the record, while people are still listening is the actual lesson.