What is the scope of a governance project?

One thing that I get to consider: what is the right way to govern large IT projects?  I'm in the fortunate postion of asking that question because I'm trying to figure out the correct and most useful role for Enterprise Architecture in providing input, insuring quality, and measuring progress towards goals through the process improvement lifecycle.

Governance is an odd thing.  To some, it means "getting roadblocks cleared."  To others it means "preventing goofy mistakes by assigning responsibilities."  Still others care about "keeping cost in focus" and "leveraging the portfolio."  Like any sufficiently complex project, the project for creating a uniform governance model has many stakeholders.

At the end of the day, the governance project will decide "who is responsible" for many if not most of the key decisions that need to be made.  The governance model doesn't say "here's your answer."  It says "here's how to get your problem answered." 

There are two natural problems with defining any project that has the responsibility for assigning responsibility: It's an opportunity for rearranging the deck chairs to your liking.  Everyone will be tempted to move 'hard stuff' onto someone else's plate.  In addition, every problem that needs solving will be tossed into the bucket.  Without a filter, the governance project will accept these problems as part of its scope.  That is nuts.

So, like any multi-headed hydra, one clear method stands out for filtering out the scope... start with the strategy that the CIO wants to accomplish, and figure out the specific tactical approach that includes "oversight," "review" and "alignment".  From there, you can more easily see which of the various needs actually belong in the 'bucket' marked 'governance' and which more rightfully belong in project management or software quality control.

For example, is governance a mechanism by which the portfolio comes together in a rational manner without excessive cost?  If so, then things like "buy vs. build" belongs in the bucket, but things like "Agile vs. Waterfall" are clearly outside.  (before I'm flamed: Being outside the bucket doesn't mean that there isn't a pressing need to solve the problem... it just means that this isn't the project that will solve it.)

So in order to solve this conundrum, and build a project with a snowball's chance of success, I need to start with the IT strategies and work my way down. 

Otherwise, the train will be laden with so much junk, that it will never leave the station.