This is a blog post from a consultant I work with. I found it helpful to get a basic grasp of how to manage the systems engineering process in a way that is lightweight and flexible.
Except for one time, when the United States Army Aviation Safety Office took the reins and corralled all the panicked cats and dead-eyed MBA drones. The integrator that was in charge is still one of my favorite engineers of all time. "The hell this has forty parameters? It's fuel. Am I outta gas? Yes. No. That's the parameter."
tosses paper down table, picks up next paper.
Hammered out a doc system for that guy on the fly, something that everyone could see without paying 50k in license costs, and worked my ass off but felt better than I had in years. That kind of magic doesn't happen often, but you gotta save it in your mental cabinet of treasures when it does.
Funny enough, this also (over-regimented documentation and too many requirements) also happens in small organizations when they don't have the expertise to know doing systems engineering isn't to produce a pile of documents. Unless it's driven by someone from higher up, it's an uphill battle to say that we can get rid of 90% of requirements that's just a repeat of some section from different standards.
What usually happens is that consultants are selling time, not outcomes. So it is in their interest to waste time and minimize risk to themselves.
I’ve had experiences like yours a few times, most recently during the nadir of COVID. It felt great.
Is there a follow-up? This is a crucial piece. You clearly need all of these: current state, plans for the future, past states, past plans.