A pet peeve perhaps.

We are victims of our tools.
DOORS is a relational database.  We use it as a CM/DM tool and a word processor.  And, I think, just because we can.
Engineers, I believe, tend to create and follow "process" just because it's our nature.  We like to organize and pigeonhole things.  It makes us feel productive.  But we seldom ask the hard question "Why".  Where is the cost benefit trade.  Where is the 80% solution, the "good enough".  Begin with the end in mind.  These are programmatic issues that are supposed to be part of the decision equation.

DOORS is appropriate for managing the relationships between objects.  Requirements and pssibly their relationships through ICDs and CONOPS documents might be a possibly a candidate for incorporation into DOORS.  But then the Pandora's box is opened,…  We will ask (or have asked) ourselves,…Why not link the documents through DOORS.  This means the documents must be entered/ingested into DOORS.  And the links established.  And validated (mistakes are very possible/probable).  Which creates another mindless audit opportunity for the bureaucrats; "how many orphans?", "What's your 'burndown' rate?" 

It's hard for me to argue against "process" and "tools"; but somebody has got to ask the hard questions and do the trades;  Where is the "value added"?, Where is "good enough"?  These are programmatic questions.  Engineers don't like to address them because we can't calculate the "right" answer.  They aren't quantitative and there is risk.  We don't like that.  I think the commercial world may "work" because of the Dilbert "pointy haired" boss, who we like to make sport of.  Maybe there is method in his madness?  Maybe we actually need more programmatic management?  I had the good fortune (I think) of growing up as a Systems Engineer in an environment with a very strong Chief Engineer and a very strong Program Manager and hearing these to very strong women argue (cooperatively); "It's not always about the technical, cost and schedule matter", "Sometimes it is about the technical".  These are not easy decisions but they are extremely important to a program's viability.

Systems Engineering was supposed to help Program Management by performing the technical management but we have abandoned that role and replaced it with armies of adminichrats who generate and execute "process" mindlessly.  And play with the tools; DOORS, Rationale ROSE, TAU, Rhapsody, etc,…

Begin with the end in mind!   Why are we doing "X"?  What are the benefits?  What are the risks?  What is the cost in dollars and schedule?  (Hey- that's the basis of the SBIRS (or any) change process)  WHY DON"T WE FOLLOW IT FOR THESE BUREAUCRATIC DECISIONS!?