Como em todos os projetos vão existir forças de
resistência. Muitas pessoas não vão colaborar e várias vão ter medo das
novidades. Aprender a lidar com o medo do novo e dissonância cognitiva é fácil.
A comunicação honesta e transparente gera o alinhamento político pelo
entendimento. Membros da equipe que fingem adesão e tem atitude em relação ao
projeto pautada apenas pelo sucesso ou falhas precisam ser reavaliados.
É preciso ter um time orgulhoso com a mudança
proposta. Um projeto de ITSM pode ser extremamente difícil se membros da equipe
entenderam que é melhor deixar as coisas como estão. É comum encontrar os caçadores
de culpados que assumem que tudo o que foi descrito nos livros de melhores
práticas deve ser seguido rigidamente para os novos processos e os problemas
são sempre causados pelos usuários.
É preciso evitar a contratação para a equipe do
projeto de profissionais sem capacidade de comunicação. Em geral, eles incapazes
de manter o foco na tarefa programada. Também devem ser evitadas as pessoas que
tradicionalmente mantêm uma agenda oculta em relação à iniciativa. Estes
profissionais apenas pareceram que estão do lado do projeto. As incertezas em
relação às motivações destas pessoas geram problemas que em geral são
insolúveis. Também existem as pessoas que insistem que o projeto é apenas um
truque de modismo ou marketing.
O perfil de membros da equipe que oscilam
facilmente de posição conforme o sucesso ou falhas normalmente são a primeira
causa da sabotagem da sustentabilidade de longo prazo da iniciativa de ITSM.
Como todos nós sabemos, estas forças fazem parte da cultura organizacional das
empresas. É este cultura que faz com que pequenas mudanças sejam sempre mal entendidas
pela interpretação errônea.
Muitas vezes apenas os conceitos envolvidos
criam tanta discussão e comentários que a ideia é inviabilizada. O tempo do CIO
não pode ser monopolizado para responder perguntas como: Quando será feito? Porque
ninguém o discutiu o assunto comigo? Quem vai decidir sobre as mudanças nos
perfis profissionais? Estas situações causam danos graves aos trabalhos do
projeto. O equilíbrio cultural de uma organização passa pelas pequenas coisas
conquistadas diariamente pelas mudanças e ideias. As ondas de perturbação
causadas pelas mudanças são dissipadas rapidamente pelo canal de comunicação permanentemente
aberto. A colaboração coletiva das pessoas para os assuntos de ITSM fazem com
que cada problema do processo de mudança seja seriamente entendido e resolvido.
TI oculta
É muito comum encontrar CIOs afirmando que
existem sistemas ocultos rodando no ambiente suportado. Entregar qualidade
comprovada para o desconhecido é muito difícil e é a causa raiz do fracasso de
milhares de projetos de ITSM. Os usuários não querem saber se são sistemas
ocultos que rodavam na infraestrutura sem o conhecimento do suporte ou se são
programas identificados e plenamente conhecidos. Eles querem qualidade de
entrega. Não são admitidas perdas com o projeto.
Isto significa que é preciso perguntar sobre
todos os sistemas em uso no gerenciamento de configurações no início do projeto
para que não existam interrupções nos sistemas porque foi adotada uma melhor
prática. Um bom estratagema para evitar o problema da TI oculta é conversar com
os donos dos serviços de negócio e descobrir quais sistemas estão sendo
utilizados pela empresa em todos os locais. Redes de varejos precisam
considerar as pequenas lojas também.
Uma vez identificados todos os sistemas é
possível usar os padrões da ISO/IEC 20000 para determinar se a qualidade
proposta endereça a necessidade. Se sim, o processo é formalizado. Se não, é
desenvolvido um projeto de transição para o processo. Este é caminho mais
efetivo para construir a confiança no projeto diante das incertezas da TI oculta.
É preciso considerar tudo o que está trabalhando bem, endereçado as metas e
satisfazendo os usuários no projeto de ITSM. Isto inclui a SHADOW IT.
Resistências
É preciso enfrentar as resistências contra o
projeto ativamente. O principal objetivo deste trabalho é vencer o desafio de
comunicar com clareza todos os aspectos do projeto e criar um balanceado nível
de entendimento das motivações e resultados. É fundamental que os colegas percebam
que o diálogo franco e direto é o melhor caminho e que o CIO está escutando com
muito cuidado todas as observações. Todos na organização precisam descobrir
pela coerência dos propósitos que o projeto não é uma ameaça para o seu
emprego. O CIO precisa trabalhar com vigor para assegurar que o projeto endereça
as expectativas e sentimentos de todos os impactados e influenciadores. Para
fazer isto é preciso escutar com atenção todas as conversas. Sempre é bom deixar claro que todos estão no mesmo barco.
Gestão das sugestões
É muito provável que o CIO receba
várias opiniões sobre o gerenciamento dos serviços de TI. O CIO deve ser capaz
de escutar, mas precisa ter em mente que ele será cobrado pelo prazo de entrega
do projeto e que todos vão cobrar o cumprimento do cronograma. Isto inclui os
que fizeram sugestões. Nunca esqueça que a empresa em todas as esferas quer o
projeto entregue. Existem razões diferentes, mas todos querem um final feliz. Isto
significa que o suporte para os donos dos serviços e processos precisa ser
planejado e entregue com todos lendo a mesma página do trabalho. As sugestões
para a adoção do ITSM devem ser bem vindas, no entanto a chave para levar o
projeto para o sucesso depende da habilidade de filtro e negociação para que as
principais expectativas dos influenciadores sejam entregues dentro da proposta
de orçamento, cronograma e qualidade.
Controle, Transparência e Previsibilidade (CTP)
É fundamental que o CIO seja claro
e honesto com o projeto. É melhor ser honesto sobre os reais propósitos da
iniciativa e não agradar a todos do que enfrentar um verdadeiro turbilhão de
pressão das pessoas durante a execução do projeto. Nunca ceda à tentação de
falar sim para tudo. Sempre use dados reais e confiáveis para tomar decisões.
Usar a intuição para decidir vem comprometendo o sucesso de diversas
iniciativas de ITSM. Busque sempre advogar as decisões com coerência, honestidade
e transparência. O escopo e Service Level Agreement (SLA) proposto pelo projeto só pode ser alterado via
gerenciamento de mudanças. O projeto não é uma receita de bolo ou conjunto de
instruções ou corpo de conhecimento. Não faz parte do âmbito da iniciativa
manter um esforço de flexibilidade pleno para o escopo. As alterações do escopo
e gols devem ser feitas dentro do possível desde que não exista comprometimento
da qualidade do projeto.
