I was recently reading "The Joy of SOX" (reviewed here) and it lead me to read up some on COBIT (Control Objectives for Information and related Technology - produced by the Information Systems Audit and Control Associationor ISACA). COBIT is "a generally applicable and accepted framework for good IT governance and control practices". As I was flicking through this I cam across one particular section. Under "Acquire and Implement" there is a "Manage changes" objective (for those of you following along in the spec this is AI6). This control objective talks about "the business requirement for IT of responding to business requirements in alignment with the business strategy, whilst reducing solution and service delivery defects and rework".
The section goes on to talk about how this means having change procedures, actually following them and measuring things like disruptions and emergency fixes. This is all well and good but it struck me that the details were predicated on all changes requiring IT to write code. Regular readers (Sandy and the other one) will know I don't buy this and that I work with customers who want to go further towards getting business users able to make changes for themselves (like egg for instance). This is not to say that I think you don't need good change control and release/version management when business users are making the change - you do - but that assuming that improving the process by which IT makes changes is only one way to increase agility while retaining control. If you take the approach, as COBIT does, that IT must make all changes to the system then the best you can do is that this process is managed, measured and constantly changed to reflect changing business realities. For me a REALLY mature organization would manage change but putting the people who understand and can best assess the impact of a given change in charge of making it. This means IT making IT changes and the business making business changes.
Don't aim too low.