My experience with a large library/small organization is that the best you can do when starting architecture is to get the stone rolling in the right direction, and subsequently, and only if absolutely necessary, nudge it from that point forward. It's impossible to stop the stone (any particular project or initiative) once it's built up some inertia.
We've tried "after the fact" governance processes that were too heavyweight and too late to be effective, no matter how logical or economical our arguements. My experience is that unless you start projects on a firm footing, there's very little chance of having anything but a limited impact on success of a project post-initiation.
Hence, we've put most of our effort in providing a service to business of helping them construct their proposals and manage the project initiation process. In some cases we'll initiate projects ourselves. In other cases, we'll parachute in to offer a prospective project proposer assistance with scoping, tasking and estimating a project early, and most importantly, with improved speed and efficiency as compared with the more traditional method.
We find that in our practice this reduces uncertainty and eliminates most of the "investigation" projects spawned from fear of not knowing the complete solution up front. Most importantly, ideas usually manage to move from thought to proposal stage an order of magnitude faster than they had otherwise.
The biggest challenge thus far has been to have architecture perceived as primarily an enterprise project management and business-related process than the common view of it as a technology-related process. This acceptance has proven to be achievable, but it's taken uncounted weeks and months of communication and demonstration to convey. And still the march goes on.