Like it or not, Document Control is designed to be an obstacle ... in the sense that a properly-functioning Document Control department should prevent a product from being released until it is fully documented.  That documentation will be needed later, so the delay is entirely in the company's interest -- but this fact doesn't make the Document Control function any more popular.  Nobody likes speed bumps either.

All the same, a Document Control department does not have to act like an obstructionist bureaucracy, even if obstruction is part of its charter.  The key is simple: give them something to do and make them accountable for doing it.

Too many Document Control departments make the engineers change all their own drawings and documentation, and then simply check for accuracy.  This is a waste.  Let the engineers make the design changes which only they can make, and then let the Document Control group finish the package: getting all the revisions right, updating all the routine files, and so on.  This frees up your engineers from tasks that look like routine drudgery to them; it allows your Document Control staff to be responsible for work of their own instead of just checking other people's work.  And realistically, your Document Control staff is probably paid less per hour than your engineers anyway ... so it makes sense to offload to them tasks at which they are the real experts.

Meanwhile, add them to the project teams.  Add their tasks into the project schedule -- don't assume that the product will magically release itself at the end of development.  But then, once you have solicited their input and added them to the schedule, hold them accountable for meeting their milestones like any other department.  Once they are fully engaged with the project, they can contribute proactively.