I was reading a blog post the other day about motivating software developers to be motivated to ship code.  While I agree this is a problem I have to ask the question "do IT departments really want to ship code"? 

Here is where I am coming from.  I have seen enough IT departments where they stack release on top of release at such a frenzied pace that it causes them to split their resources.  When you have multiple versions of an application that have to be tested you need more environment that all have to be managed. 

The result of this splitting and multiplying resources is that company doesn't have enough subject matter experts to do all the work.  This leads to developers making changes without understanding the implications to other parts of the system.

Another problem is that of keeping all of the testing environments synchronized and stable.  Of course since each environment will be on a different version of the code, but it is difficult to ensure the configuration lessons learned are applied across the board.

The point is that the thinner you stretch your resources the less likely you are to be able ship quality code on time.  It takes a very mature IT department to pull this off and it should not be attempted without robust lines of communications between team.  If this is done wrong it will actually show the development staff that they don't need to worry about getting their code done because the company is not serious about the product.  The best alternative is to serialize you projects although that won't make management the happiest.  As architects I believe it is our place to identify these risks and present alternative.