The broken system I inherited, and what fixing it taught me
I once took over a 50-project portfolio where the tracking had quietly fallen apart. Status lived in scattered spreadsheets and people's memories. Nobody could give leadership a straight answer.
When I took over a portfolio at FEMA Region 9, I inherited fifty floodplain projects and a tracking system that had quietly fallen apart. Status lived in scattered spreadsheets, a few inboxes, and several people’s memories. Nobody could give leadership a straight, current answer about where anything stood.
On a portfolio that size, with projects running eight to twelve years, that is not a clerical annoyance. It is the precondition for missed deadlines, blown budgets, and audit findings that nobody sees coming until they are already a problem. The risk was not any single project. It was that the whole thing had gone illegible.
So I rebuilt it. New reporting workflows, a single place where status actually lived, dependencies made visible, and dashboards that gave regional leadership a real-time read for the first time. None of it was clever. It was mostly the discipline of deciding what ’the truth’ was and defending that one source against the natural entropy of a busy program.
The lesson stuck with me, and it generalizes well past disaster work. The most dangerous risks in any program are usually not the dramatic ones. They are the ones no one can see, because the system that was supposed to surface them stopped working and nobody noticed.
I have come to think a manager’s real job is less about heroics and more about legibility. Keep the program honest with itself. Make the bad news visible early, while it is still cheap to fix. The rescue is rarely the exciting part. It is just refusing to let things drift.