quarta-feira, dezembro 01, 2010

Como desenhar processos

A prática da ITIL não faz simplesmente atrás de uma secretária. Antes que possa melhorar um processo, tem de compreender o processo existente. Tem de sair de detrás da secretária e percorrer o processo, o que até parece simples, mas como muitas outras coisas, fazê-lo não é tão imediato…

Sabemos que a IT Infrastructure Library® ITIL® descreve o que é necessário fazer. A ITIL só descrever os modelos de processos e não oferece direcção passo a passo. A ITIL é uma orientação que deve ser interpretada e adaptada antes da utilização.

Os processos descrevem o trabalho realizado por pessoas. Praticar a ITIL assim torna-se uma ideia simples: compreender os processos existentes (workflow), compará-los com os modelos ITIL, adaptar, improvisar e ultrapassar! 23259.strip

Os processos de TI são muitas vezes transversais a mais do que um silo e, assim, é muito difícil encontrar um colaborador ou um gestor que conheça de verdade o fluxo fim-a-fim do processo.

Esta realização é fundamental para o vosso sucesso na prática da ITIL – como funciona o processo corrente é muitas vezes diferente de como pensamos como é (ou deveria) trabalhar.

Proximamente indicarei alguns passos que podem ajudar no desenho ou redesenho dos vossos processos.

Precisamos de compreender os nossos processo!

segunda-feira, novembro 29, 2010

Quer saber como falhar nos seus projectos

Vamos rever como podemos fazer tudo errado dum ponto de vista de gestão de projecto. Isto parece o contrário de tudo aquilo que procuramos nestas páginas, mas é também uma forma de passar o que NÃO deve ser feito num projecto. É pena que isto seja, também, um espelho da corrente realidade. Espero que esta experiência ajude!
Para conseguir entregar os resultados do projecto ACIMA do orçamento e ACIMA do tempo previsto, tornando miserável o cliente pelo caminho, então…

Nunca Planeie

“Para quê planear se ninguém segue os  planos? Eu imprimo os planos, mas eles são esquecidos e colocados na prateleira. O que eu devo fazer é arregaçar as mangas e envolver-me no trabalho do projecto!”
sucess_failureUm homem sensato disse que “Se falhar a planear, então planeias falhar”. O planeamento é acerca de nos assegurarmos de ter as pessoas certas nas actividades certas, na altura certa. Só se planearmos podemos estar certos que iremos realizar o projecto dentro do tempo proposto.

Não comunique

“Mas porque é que eu tenho de dizer a toda a gente e sempre o que está a acontecer? Não tem sentido. O que eles têm de saber é qual é a lista de tarefas diárias. A comunicação faz perder muito tempo. Não vale a pena!”
A razão para comunicar é que isso mantém todos a ver a mesma página para que todos saibam como todos os outros estão a trabalhar, quando é difícil e quando não é. Por exemplo, se ninguém sabe que o projecto está a atrasar, então qual é a possibilidade de conseguir realizar em tempo se não comunicamos?

Esqueça a liderança, está sobrevalorizada

“A minha equipa tem é de fazer o seu trabalho senão levam uma corrida quando eu chegar ao escritório amanhã. Temos de estar sempre a mostrar o chicote para garantir que o pessoal trabalha efectivamente.”
Muito embora esta abordagem até possa funcionar no curto prazo, as pessoas precisam de ser recompensadas e reconhecidos os seus esforços no longo prazo, para estarem motivados. Em breve, precisam de sentir valorizadas e só um verdadeiro líder pode fazer isso. Precisamos se ser sempre positivos com a equipa, mesmo quando precisam de um resmungo. Seja equilibrado. Seja construtivo. Ponha-se nos seus sapatos, As grandes equipas têm grandes líderes, É tão simples como isto.

Apaixone-se pelo deslizar dos objectivos

“Para quê estar preocupado se o cliente pediu mais mudanças. Se o projecto está atrasado não é por nossa culpa. Se querem estar constantemente a alterar o âmbito do projecto, não sou que os vou parar”
Certo, o seu cliente pode mudar quando quer, mas você tem de ter controlo sobre isso porque quando o prazo foi excedido e o projecto está longe de estar completo devido a todos os pedidos de mudança que permitiu, posso assegurar que o cliente não vai ficar satisfeito.

Esqueça o cliente logo que começar o projecto

“Logo que obtiver a aprovação do cliente, não preciso de falar com ele até à conclusão do projecto. Quanto menos o envolver no projecto, menos coisas ele pode estragar. Se eu não falar com ele, então garanto que ele não me perturba.”
Esta abordagem pode funcionar até que seja necessário o apoio do cliente. Então estamos em trabalhos! Se precisa que o cliente aprove mais tempo, dinheiro ou recursos, tem de o manter ao seu lado durante todo o tempo. O cliente tem de ser informado a cada passo do progresso e sentir que é parte da equipa de projecto, se pretender o seu apoio total.
Trate o cliente como se este fosse o seu melhor amigo. Mantenha-se do seu lado e peça favores quando achar que deles necessita. Se tiver o seu apoio total, então receberá o que precisa quando pedir.
Este exercício ao contrário pretende que assim se compreenda o que não se deve fazer para garantir o sucesso.

quinta-feira, novembro 25, 2010

Os fracassos nas Transformações nas TI

Estou a iniciar um processo de formação de recursos humanos para uma organização pública em África, com o intuito de permitir a iniciação de um processo de transformação da gestão do serviço de TI. O que vou fazer é só o início de um processo de transformação e nem sequer o seu lançamento, somente a realização das condições prévias.

Eu cuidados teremos para evitar o fracasso nos processos de transformação?

Os processos de implementação de boas práticas em gestão de TI devem ser ponderados e compreendidos para garantir efeitos efectivos. O que acontece, na realidade, é que estes processos são muitas vezes mal preparados, pior acompanhados e pouco verificados e então falham. Vamos abordar alguns desses factores.

Porque é que as organizações decidem transformar os seus processos de TI? É quase sempre devido a um evento externo (i.e., regulação, competição, nova liderança) que desencadeia a transformação, mas independentemente da causa, todas as transformações têm as mesmas premissas básicas:

  • O que é que é necessário mudar?
  • Porque é que é necessário mudar?
  • Quem sofrerá o impacto da mudança?
  • Quando estará concluída a mudança?

Mas, quais são as razões comuns de falha nas transformações de TI?money_doom

Visão Partilhada do Sucesso

Uma das primeiras razões é a falta de uma visão partilhada comum. Esta visão inclui objectivos de negócio, estado final desejado e como esta mudança irá melhorar o negócio. Muitas vezes o líder possui uma visão clara e concisa das mudanças requeridas, mas não é capaz de as articular para a organização. As comunicações entre o líder e as suas “tropas” ficam perdidas no meio das camadas intermédias de gestão.

Quando se pretende modificar significativamente uma organização, todas as pessoas devem conhecer a visão, compreendê-la e aceitá-la (claro que isto vai-se obtendo paulatinamente no processo). Uma forma de resolver este problema é saltar por cima da cadeia de gestão e falar directamente com as “tropas”. Isto pode ser alcançado de várias formas: reuniões gerais, newsletters, email, sms, etc. Um aspecto chave é garantir que todos recebem a mesma mensagem e que esta não está a ser distorcida. Para os líderes de uma transformação o mais importante é comunicação, mais comunicação e, depois, comunicação.

Comunicar, comunicar, comunicar

Outra causa comum de fracasso nas transformações das TI é aquilo a que chamamos a resistência passiva. O que significa isto? Muitas a razão PORQUE uma transformação é necessária é mantida ao nível da direcção e não é partilhada com os outros níveis e com o pessoal. Ou, só são partilhadas algumas das razões para a mudança. Mesmo quando esta informação é partilhada, muitas vezes não é entendida pelo pessoal. Eles não têm o mesmo acesso a outras fontes de informação como a equipa de direcção e eles também não têm a mesma perspectiva.

A razão para a mudança deve ser colocada em termos tais que todas as pessoas possam relacionar-se com ela. Sem esta compreensão, as pessoas irão conformar-se com as “ordens” para mudar e na realidade, nunca irão aceitar de verdade a mudança. Ninguém se irá activamente opor à mudança, mas não iremos ter apoiantes activos ou agentes de mudança para assistir nas actividades.

Uma abordagem para evitar esta armadilha é envolver pessoas de todos os níveis em comunicações de dois sentidos. Ofereça ao pessoal a oportunidade de colocar as questões e perguntas acerca dos porquês da mudança, da sua necessidade, e permitir-lhes alcançar uma compreensão em sintonia com a equipa de liderança. Esta compreensão não acontece de um momento para o outro, irá levar tempo. Então necessita comunicar, comunicar e comunicar.

As Métricas ajudam a acontecer

Outro problema que a maioria dos esforços de transformação enfrenta é que ninguém está a seguir as melhorias. Sim, eu sei que todos os esforços têm um plano de projecto e uma escala de tempo e isto vai sendo reportado, mas até que ponto as mudanças estão a melhorar os resultados do negócio? Muitas vezes, o plano de projecto é utilizado para determinar em que medida o projecto progride e as pessoas não sabem na realidade se as melhorias estão a ter o desejado efeito.

O desenvolvimento de métricas é visto tão só como um subcomponente do projecto. De facto, deverá ter a mesma importância como o desenvolvimento dos Objectivos de Negócio. O desenho, recolha e acompanhamento destas métricas é muitas vezes realizado pela equipa de projecto. Se existem múltiplas equipas fazendo mudanças, usualmente cada equipa tem a sua abordagem para métricas de desenvolvimento o que resulta num conjunto de métricas descoordenadas. O que é que acontece quando o projecto termina e as equipas voltam às suas origens? Uma abordagem muito melhor é ver o desenvolvimento de métricas como um esforço separado mas apertadamente ligado às equipas de mudança.

Um grupo separado deverá reunir os requisitos em que se baseiam os objectivos de negócio e garantirá que estas mesmas métricas fornecem uma informação útil para todos os níveis de gestão. Depois de ser alcançado um acordo de que estas são as métricas “certas”, esta equipa deverá implementar as métricas e fornecer uma análise continuada e supervisão. Como estas métricas deverão comprovar a melhoria do negócio, devem continuar mesmo depois das equipas de projecto serem desmobilizadas. Se o que se passa não está escrito, então não aconteceu. A norma ISO 20.000 declara que se não é acompanhado e medido, então não irá acontecer.

A regra dos 80/20

O último tópico daquilo que liquida os esforços de transformação das TI é o tempo. Qualquer esforço sério de transformação tomará entre 12 a 24 meses para ficar concluído. Muitas das vezes, as melhorias de negócio não são tão óbvias senão quando o programa está quase terminado. Isto significa que já passou um ano desde que foi requerida a mudança e a altura em que foi implementada. Neste ano, ainda para mais, o ambiente já não é o mesmo e o impacto de quaisquer mudanças é inferior ao esperado. Muito provavelmente, as pessoas que esperavam a mudança implementaram medidas transitórias e temporárias para obter melhores resultados. Então por que leva tanto tempo a ver os resultados? Bem, quase todos os programas de transformação procuram quase a perfeição. Este é um programa grande e visível e eles querem que tudo corra bem para todos. Então o que podemos fazer para resolver isto?

Por natureza um Programa de Transformação é grande, complexo e longo. Mas este programa pode ser decomposto em pequenos subprojectos, que podem ter resultados concretos em 90 a 120 dias. Mais importante ainda, estes resultados NÃO tem de ser perfeitos. Utilizamos uma filosofia prática para obtermos 80% certo. Acima de tudo, uma melhoria de 80% em 90 dias é melhor que nenhuma melhoria em 1 ano. Os primeiros subprojectos devem apontar a melhorias já prontas a serem implementadas, coisas que são fáceis e rápidas de implementar. Desta forma, a sua equipa de mudança instila confiança nos seus clientes, na liderança de topo e, o que é mais importante, neles próprios. Este será um esforço longo e se nos sentirmos bem no início poderemos caminhar ate muito mais longe.

Em Suma

Para proceder a uma transformação da Gestão de Serviços de TI, é necessário o conhecimento e a vontade mas temos de estar atentos a:

  • Possuir uma clara visão da mudança que é comunicada de forma contínua e consistente e todos.
  • Garantir a compreensão e aceitação das razões para a mudança por todos.
  • Criar e implementar métricas ligadas aos resultados de negócio desejados.
  • Seja rápido e ágil com os resultados intermédios que estejam 80% certos.