Change, Release, and Projects: Difficult interfaces (Part 4)
How to avoid redundances?
Concerning "Change Management" process:
Some practical advice must be heeded to avoid redundancies between Change Management and Project Management activities and responsibilities:
Clarify which authorities and processes support validations linked to change:
A decision-making authority must be chosen: either the PMO, or the Change Manager, or the PMO integrating the Change Manager as an authority. But a decision should be made about the relevant authority. It is essential not to leave two approaches operating in parallel nor let stakeholders find their own way without guidance, inevitably confronting each other because each one believes they are right.
However, according to organizations, a few complexities can appear:
► PMO do not always exist across the entire IT organization. An infrastructure PMO is involved in infrastructure projects and does not have the decision scope Change Management would like it to have. Let's not forget that the Change Manager has a responsibility over all changes affecting IT Service (including Design).
► All changes are not managed by project authorities, because they are simply not considered as projects. Change Management is supposed to implement all changes (even the smallest ones). So, in principle, it is a more universal governance mode.
Only start Change Management when impact evaluations are actually possible:
ITIL actually invites to initiate an RFC as soon as there is a need for evolution (business or technical need). The main question is whether this is really necessary at that stage. In order to find out, we must remember the following principles:
► The main vocation of Change Management is to control change impact on the Live environment. Pretending to record a change when it is only an “idea” will significantly limit impact assessment capacity
► In reality, only after project needs have been expressed, after a solution (on paper) has been designed, after its operational and budget terms have been accepted by the customer, is it possible to know which components are to be created (or modified). At this stage only, is it possible to launch an assessment of change impact on the IT department. Intuitively, RFC must be created at this point for that purpose
Also note that in IT organizations current operations, validation principles efficiently assess the business benefits of some changes:
► Strategic changes or significant business evolutions, owing to their business and/or financial stakes, are often discussed at specific steering committees or project committees involving high hierarchical levels for validation (before committing any financial and human resources)
► In organizations with mature Project Management, changes are less strategic but sufficiently complex to be managed in project mode and benefit from draft stages which can (or potentially can) help assess the business benefit of a change
► Obviously, the approval stage should not be reproduced for all changes during the Change Management process. Ideally, this responsibility consisting in naturally coordinating relations between contracting authorities, customers and prime contractors should be left to Project Management. This is in order to avoid any overlaps of identical roles
► The problem is not solved for changes which are not managed in project mode, or those which are, but do not implement business benefit assessment principles. For example, small projects or changes carried out on the fly, outside any project approach, such as small-scale application or infrastructure changes. For those, Change Management must absolutely have a validation role.
There are also redundancies within ITIL, where approvals at “strategic change” level overlap validations carried out punctually by Service Portfolio Management (see Strategy Service in ITIL framework). On this point, the framework suggests the existence of an authority at strategic level (an executive committee or a Service Management Office) acting as “super-PMO” for all decisions on portfolio evolution (evolution, removal of existing IT Service or creation of new IT Service).
Find a smart combination between Change Management quality control responsibilities and Project Management control of project deliverables:
Quality control of deliverables and control of their compliance with expectations remains a responsibility given primarily to Project Management, because the latter defines the principles and methods specific to project objectives. Of course, some norms or test principles gathered through capitalization of experience gained (e.g.: PIR) must be shared and used by project teams (as project frameworks do, as already previously mentioned in this book).
Change Management can play the role of a cross-functional referee defending general interests (not specific to the project), insuring that the organization standard quality principles are actually implemented and assessing the risk on the rest of the IT system. Change Management does not follow up quality controls in detail, which are performed at the “macro” level. Results and their impacts are essential.
Concerning "Release and Deployment Management" process:
Some practical advice should be taken to avoid redundancies linked to overlaps of Release and Deployment Management and Project Management activities and responsibilities:
Give priority to process mode
Give priority to process mode for standard operation and only turn to project mode when processes cannot meet the level of complexity required by change.
The process mode is an industrial operational mode aimed at meeting all requirements,
► It is based on structured and standardized operations and deliverables compliant with expected results,
► Based on resource sizing or industrialization level, it allows to cope with workload while maintaining the required quality level
► It can be launched on the fly without having to set up a specific organization to process the activity
Project mode is only useful when the complexity level is so high that operating in process mode would be likely to lead to seizure, due to a number of specificities.
► Project mode sets up a management and release organization totally focused on a specific goal. It is not standard, irrespective of the activity.
► The benefit of project mode is to operate every specificity on a “custom mode”, a process mode is not designed for.
► But this capacity also hides flaws as far as industrialization is concerned. For this reason, it should only be used when it is justified and not as a usual operating mode.
The schedule set up at integration or deployment projects level must not be disconnected from the main change schedule nor from Release policy, since the latter is normally the reference as regards production implementation:
► Project Managers integrate the schedule of their activities into the Central Change Schedule (with bigger grain size than their own Project Schedule, detailed by definition),
► When assessing the delivery dates of their deliverables, they take the release dates set up by Release Policy into account,
► They implement rules associated to Central Change Schedule and to Release Policy (rules linked to shifts, release units principles, etc.).
Align Management jobs wherever possible
Are Release Managers and deployment Project Managers the same people?
Their scope of action as well as integration, validation and deployment business skills are the same, but the competences required of a Process Coordinator are not the same as those of a Project Manager. Here are a few examples:
► The Project Manager has a specific know-how: project management. Which is not required of a Release process coordinator
► The experience required to be a good Deployment Project Manager able to find solutions in every particular scenario is wider than the one of a process coordinator whose field of action is more controlled
► The Process Coordinator is in a routine. Even if they smartly solve problems, they are determined to meet customer’s expectations. The Project Manager is a specialist of unexpected situations. They can mobilize around more difficult punctual situations. They are more of a “builder” than a daily “operator”
* The author takes liberties with this title. It is not mentioned as such in the ITIL framework.
The illustration below shows all potential redundant points between Process and Project modes. They appear in their optimal operating conditions.
Copyright © 2013 - PRACT Publishing