What are the most common IT conflicts during change management processes?

The involvement of multiple stakeholders involved in the approval cycle of a change, if not aligned, communicating clearly and in a timely manner within a predetermined structure or framework, can result in the failure of the execution of the planned activity due to not getting the needed approvals within the preset timeline. This can cause major disappointment to the customer at the receiving end of the service, not to mention the risk of imposing penalties on the service provider as a result of poor adherence to the agreed upon SLAs. Some changes can bare the possibility of being rescheduled, others don't and can pose a serious threat on the customer product. An example of the latter are changes related to cyber and infosec.

In my experience a few places communication break downs occur are: - Communication starts off well with a kick off but falls through cracks as project progresses- any change decisions taken need to be continuously communicated to stakeholders and impacted parties - Teams know the first level of users downstream but not aware of the next level of users of data they are producing. Understanding this can be difficult in large organizations with several multiple systems managed by multiple teams unless it has been documented well

Em atuações ao longo da minha carreira, vejo que é essencial estabelece um canal de comunicação ágil e aderente ao envolvidos, isso irá garantir um melhor fluxo de troca de informações, usar ferramentas como uma Matriz Raci para projetos que envolvem diversos membros evita conflitos e traz clareza aos executores. Um bom plano de comunicação engajara e evitara desalinhamentos durante o gerenciamento de mudanças.

Na minha experiencia a melhor forma de lidar com um conflito de recursos é evitando que o mesmo ocorra, nesse contexto é muito importante uma analise de requisitos bem elaborada, onde os requisitos mínimos para aceite das partes envolvidas estejam mencionados, no entanto para gerenciar esses recursos lidando com a sua escassez será importante uma metodologia de priorização, garantindo que as mudanças sejam entregues conforme o valor agregado ao projeto e aos envolvidos.

Durante a minha jornada acessamos pessoas de diferentes crenças e valores. Empatia será a bússola para nos guiar nesses conflitos. No gerenciamento de mudanças será muito oportuno e estratégico manter todas as pessoas engajadas, se posicionar como um facilitador será importante para lidar com esses cenários.

It is critical to keep interoperability in view as design decisions are made. The architecture should align with the higher level architectural runway for the Agile Train/ Portfolio/ SBU or have a incremental plan to get there. Else it can cause rework, integration issues and a bad user experience.

In my experience a lack of focus on user experience and an over emphasis on the technology and process engineering derails successful implementation and uptake every time.

Some organizations exhibit change fatigue in various ways. Most common is, not documenting the change anymore. No one cares. No one is doing it. This is going down a slippery slope. Documentation helps with traceability and accountability.

This could attribute to non-adherence to agreed frequency of change either on the customer or support side. Or worst no provision on the agreement that address this. There is also no planning that is happening for the roadmap of development and/or support fixes deployment necessary to both update/improve or deploy fixes to bugs of the product.

Cuando TI lidera un proyecto de tecnología debe tener muy involucrados a los stakeholders y asegurarse que el equipo de negocio tenga la disponibilidad de tiempo planificada, porque cuando no ocurre esto genera retrasos, falta de credibilidad en el proyecto y la fatiga al cambio como consecuencia