Change, Release, and Projects: Difficult interfaces (Part 3)
Consequences of difficult interfacing
Creation of artificial jobs
To compensate the lack of process overlap between IT departments’ fields, organizations create coordination jobs. Indeed, a functional incident handled by the IT operations Service Desk does not stop at Design’s door. In order to fix it, it is necessary to transfer it to development teams. The same applies to change!
To create a dialogue between two change management processes specific to two different frameworks, totally artificial coordination jobs must be created to compensate what should normally be done by a common process coordinator.
Examples of redundant coordination jobs in companies:
To create a dialogue
The illustration below shows the potential redundancies between Change Management and Project Management:
*Illustration of the situation induced by gaps and compensations through artificial coordination jobs:
Example: The French subsidiary of a big global insurance company had reorganized into business IT services to better manage business IT systems (as many big organizations do). With their Design culture, business IT managers (and managers of their applicative fields) had difficulty managing their customers’ requests (Business Units) end-to-end. Whenever these requests included an infrastructure or Release element, change fluidity and stakeholder coordination became a source of difficulty and delays as well as dissatisfaction for customers. A “Release Correspondent” job was created to generate a dialogue with the Release and Infrastructure department, which thus became an internal operator hosting the IT Service, supplying access to it and operating it. This job, reproduced for each IT Business Unit (there are 4 of them in this company) only compensated the coordination job Change Management was supposed to do. In this case, the coordination brought by this artificial job attempted to reconcile two change processes operating with different principles and policies. This led to inevitable gaps in terms of commitment on deadlines and service level guarantees.
Lack of management tooling interface
Today, due to the absence of an overlapping process, IT departments must get their own tools to manage their events. They duplicate investments in functionalities expected to be identical, such as Incident Management. The same applies to Change Management tooling.
Most frequently, we observe that Design/Development departments use tooling specific to development Request follow-ups, which structure all build and test cycle stages, from formalization of functional specifications to final end users approval. This tooling often includes a notion of Release Unit Management (meaning development in this case). So far, this tooling is practically never interfaced with Change Management, whereas the connection is more than obvious and the information to transfer, very useful.
Creation of pseudo-processes
Facing request complexity and volume, IT organizations implement an internal organization to clarify the confusing dialogue between Design/Development and IT operations departments. Usually, this includes formalizing a single point of contact for all requests, possibly some qualification and processing activities (guiding towards the right people) which can be called “pseudo-processes”, and tooling (usually a simple portal) to deposit “requests” and follow up their processing.
This organization layer does not at all clarify the confusion since the issue remains unresolved. Apart from the single point of contact (SPOC) which seems to simplify things at first sight, the issue of processing requests depending on their nature, to the right stakeholder and through the right process still exists. This layer is no intrinsic value since it merely compensates what each overlapping process of Change Management, Release and Deployment Management, Request Fulfillment or any other, depending on request nature, should automatically be provided in a more accurate way.
Illustration of activities carried out by SPOC, devoted to Design / Release relations within companies:
Example: The Design department of a global bank specialized in applications dedicated to Investment bank activities (grouping several hundreds of developers), wanted all requirements sent to IT Operations (Production) to be centralized through a single point of contact. And this SPOC to be as automated as possible. For them, this solution was the final answer to a complexity that had existed for years. So, a portal was built to centralize all requests: new workstation, supply of a virtual machine, creation of a test environment, request to release a new application version, recall of programs to be modified, creation of an account and access rights for a developer, etc. Finally, this portal did not fill the existing gaps. It only created a lot of expectations and frustrations. This SPOC, a totally dehumanized contact point, could not make up for the lack of maturity of existing processes. A portal cannot replace the indispensable education and animation leading to the understanding that each request must be dealt with through a dedicated process such as Request Fulfillment, Access Management, Change Management (standard of not), or even Release and Deployment Management.
Copyright © 2013 - PRACT Publishing