This is a discussion of the tension and its mitigation between ITIL Release Management and Application development (projects) and enhancements from a particular real world occurrence.

While working for a major global manufacturing company they elected to re-outsource with a new model in the middle of last year. This was managed in a coherent programme fashion, but of course not all the details could be fleshed out and integrated in advance as they are a huge organisation.

There was a fundamental schism in the re-outsourcing between Services (infrastructure and operations) and Systems (application support and projects for applications). Each side of this schism placed contracts both for the front line performing suppliers, but also for a higher level set of integration services.

On the Services side of course there was bed rock written into the agreements to employ ITIL processes. And of course the integrating supplier on the services side arrived with their own vision and tool(s).

On the Systems side these contracts brought a standard approach to a considerable portion of the legacy application sustain (break / fix) and small enhancements. Vendors were organised by sets of applications the performed a band of business process functions.

However the integration was meant to occur with two layers of vendor, and the over arching did not get to a standard or common approach on application enhancements quickly. As a result different organisations defined by bands of functionality executed somewhat differently for application support.

Mechanics for governing changes were vague, but in the space in which I worked discretionary (not the break / fix) enhancements were set up with service level wording that clearly required their management change by change, item by item. Additionally, more because of history, governance was set up to support the dialogue about when each change could be made with the end user or business partner.

The company was far more standard on macro co-ordination of application projects. There were a set of different cases but all of these were derivatives of a recognisable PMBOK (Project Management Book of Knowledge) approach.

For our purposes I will put projects into two groups. First there were waterfall projects (Plan, Define, Design, Construct, Test, and Deploy) and then there were iterative, or cyclic (RUP) kinds of projects.