That's all standard stuff at the organizational level of the software lifecycle. It works pretty well up to a certain size organization, at which point if the organization doesn't break up into individual divisions (each with their own, usually the same but not related, process) the whole concept is too much to manage and things start to break down.
Sadly, I've seen very few VPs that have the hands on experience to recognize when this happens, even when told right out over and over and over again. Usually it will stay compeltely bogged up for a couple of years until a seemingly random draw reorg happens... it takes the divisions a year to straighten themselves out, but by then, the VP has decided that it didn't work and does it a second time based on something some consultant said to them at a luncheon. You can tell the difference between an actual attempt at improvement and a crappy attempt at fixing an actual attempt by how many buzzwords are attached to the reorg process.