Porque falham os projectos de TI?

15-4-2015

A maioria dos projectos de TI acaba também por ser um processo de mudança organizacional que vai muito para além da área estritamente tecnológica. O resultado final desse processo de mudança acaba por influenciar o resultado do projecto de TI propriamente dito.

Quer pela própria natureza dos projectos de TI (que implicam quase sempre ajustes nos processos da organização) quer pela razão que pode dar origem ao próprio projecto (necessidade de uma mudança) quase todos os projectos TI são acompanhados por uma mudança organizacional. Ignorar esta questão é colocar em risco o sucesso do projecto.

Há cerca de 12 anos a IBM publicou um livro com o título “On-line, On-time, On-budget”, na altura pareceu-me brilhante como conseguiram colocar os factores críticos de sucesso de um projecto num simples título. Bastava controlar os requisitos funcionais, o tempo e o orçamento e garantidamente alcançaríamos o sucesso do projecto…

Daí para cá muito se escreveu sobre o assunto, metodologias foram criadas e formações ministradas. Mas alguns projectos muito bem planeados, muito bem geridos do ponto de vista técnico continuam a falhar… Porquê?

O que a experiência me diz é que muitas das vezes nos esquecemos que as empresas são organizações vivas e complexas, que o caminho para alcançar um objectivo nem sempre é linear e que os “nossos” projectos por vezes têm impactos que estamos longe de prever no início.

Daí que para um projecto ser sucedido temos de garantir outras questões para além das meramente técnicas. Em última análise, o projecto tem sucesso se o impacto que se pretende que tenha no negócio seja conseguido. Para que isso aconteça é necessário “induzir” que o resultado do projecto de TI seja “absorvido” pela organização.

Alguns dos factores que me parecem ser críticos em qualquer projecto:

Planear não é um custo, é um investimento

É da natureza humana a tendência para investir muito mais na execução do que no planeamento, muitas vezes o planeamento é reduzido ao mínimo possível. Diz a teoria (e a experiência prova-o) que recursos investidos no planeamento (tempo e dinheiro) não só diminuem os recursos necessários na fase de execução como diminui o risco de imprevistos.

Âmbito inalterável… até ser indispensável reduzi-lo

Outro erro comum está relacionado com as alterações ao âmbito do projecto “de última hora”, ou porque não foi pensado antes ou porque algo mudou entretanto. É essencial “congelar” o âmbito, as decisões que vão sendo tomadas durante o projecto têm em conta este pressuposto. É no entanto aceitável que se altere, diminuindo-o, quando o âmbito inicial põe em risco o sucesso do projecto.

A importância de um “Sponsor” efectivo

As regras de gestão de projectos referem a importância de nomear um “Sponsor” que tenha poder na organização. Este papel não deve ser apenas figurativo, nem deve limitar-se a interferir em caso de conflito. O Sponsor deve ser o grande mobilizador de toda a organização para as mudanças necessárias.

As pessoas como factores críticos de sucesso

Nenhuma mudança se consegue sem o envolvimento das pessoas. É essencial comunicar com eficácia e em primeiro lugar aos colaboradores da organização. Cada vez mais vamos percebendo a importância do marketing interno nas organizações (Endomarketing).

O importante é o negócio, as ferramentas são apenas isso… ferramentas

Um dos riscos de usar metodologias estandardizadas é de os processos se puderem sobrepor ao negócio, ou seja, usar métodos complexos para resolver questões simples. Temos de usar o chamado “bom senso” e alinhar a complexidade dos métodos usados com os processos que estamos a tratar.

Quando o impensável acontece

O profissional de TI é por natureza um optimista, parte do princípio que tudo vai decorrer como planeado. Temos de contrariar esta tendência e considerar no planeamento o risco de algo puder não correr exactamente como planeado. O ideal seria puder medir esse risco à partida, mas mesmo não sendo, deveremos sempre considerar margens de segurança em termos de tempo e orçamento e ter planos alternativos.

 

Os exemplos que melhor demonstram estas questões são os projectos de CRM. É frequente ver gestores de topo tomarem a decisão de entrar no mundo do CRM, escolhem uma ferramenta IT e esperam que a empresa que o implementa dê formação aos utilizadores. Ora, a formação que os implementadores darão será de como usar a ferramenta. Para que um projecto desta natureza tenha sucesso é preciso criar na organização toda uma atitude virada para os clientes. É necessário ouvir os clientes, registar a informação obtida, tratar essa informação, analisá-la e finalmente fazer algo com ela. É suposto todo o processo gerar constantes acções no negócio, seja alteração de produto, de processos ou de comunicação.


A Gestão do Valor das TI: Práticas de Governança

10-2-2015

As organizações vêm-se deparando com uma cada vez maior dependência das TI, essenciais à sua sustentabilidade e desenvolvimento. Esta centralidade das TI no negócio implica uma atenção redobrada para incorporar valor (retorno financeiro e outros fatores estratégicos) a partir dos investimentos realizados em TI. Este é sem dúvida um dos dilemas com que as empresas se confrontam atualmente, isto é, como garantir a realização de valor dos investimentos em TI?

Independentemente da complexidade de respostas, a mensagem a reter é clara. “Apenas com processos/práticas de Governança e de Gestão das TI adequados e um empenho total de todos os níveis de responsabilidade, é possível obter benefícios para as partes interessadas dos investimentos realizados em TI”. Quando confrontado com esta problemática, defendo que o caminho passa pela implementação de práticas de Gestão do Valor das TI que facilitem a identificação, criação e captura de valor.

Apoiado num dos princípios basilares do COBIT 5, que distingue atividades de Governança das TI de atividades de Gestão das TI, proponho a implementação das seguintes práticas de Gestão do Valor no âmbito da Governança [1]:

  • Comité Estratégico de TI – Estrutura organizacional com responsabilidade de fornecer às estruturas de gestão uma direção para a estratégica de TI. No contexto dos investimentos em TI deve rever os riscos e o retorno de acordo com os recursos disponíveis. Reporta ao Conselho de Administração.
  • Processo de Planeamento Estratégico de TI – Definir um conjunto de atividades de identificação de oportunidades de investimento e garantir o alinhamento destas com os objetivos e estratégia de TI.
  • Balanced Scorecard de TI – Definir um processo de tomada de decisão ao nível corporativo com atividades de medida e avaliação do valor para o negócio dos investimentos.

Provavelmente estará a questionar a relevância destas práticas na realização de valor para a sua organização. Se não for capaz de responder às próximas questões [2] então talvez seja hora de ponderar.

– Estamos a fazer as coisas certas? Isto é, O investimento é consistente com os princípios do negócio? O Investimento contribui para os objetivos estratégicos? O investimento acrescenta valor com custos acessíveis e risco aceitável?

– Estamos a obter os benefícios? Isto é, Temos uma perceção clara e partilhada dos benefícios esperados? Existe uma atribuição de responsabilidades para a realização de benefícios? As métricas mais relevantes estão definidas?

[1] Práticas no âmbito da Gestão das TI em “A Gestão do Valor das TI: Práticas de Gestão” (artigo na newsletter “ITIL e Tal” de fevereiro 2015, exclusiva para associados da itSMF)

[2] Baseado nas questões “Four Ares” descritas por John Thorp em “The Information Paradox”.


Oferta de poster sobre ISO/IEC 20000

29-4-2010

A itSMF Portugal irá oferecer um poster sobre ISO/IEC 20000 a todos os participantes que se inscrevam através do site da itSMF na 7ª Conferência Anual itSMF 2010.

Esta oferta, que será entregue no local da conferência, é valida para os pagamentos confirmados.


A Conferência Anual 10 da itSMF Portugal está à sua espera

27-4-2010

Este ano a Conferência da itSMF Portugal, que tem por tema Partilhar Serviços na Era do Cloud Computing – Novas abordagens para a redução de custos e melhoria dos processos ,irá realizar-se no dia 25 de Maio, na Reitoria da Universidade Nova de Lisboa.

Informação sobre o programa e inscrições disponível em www.itsmf.pt


192.355 exames ITIL v3 em 2009

18-3-2010

O APM Group Ltd (APMG), enquanto organismo oficial acreditado pela OGC para certificação de institutos de exames ITIL, acaba de divulgar as estatísticas (obrigatórias) relativas aos exames ITIL por tipo de exame. São números impressionantes: 192.355 exames realizados em 2009, apenas no que respeita ao ITIL V3. 85% respeitantes ao nível de entrada no ITIL, ITIL V3 Foundation in IT Service Management. 6% relativos ao V3 Foundation Bridge. De entre os “novos ” cursos” ITIL, o que apresenta maior expressão é o IV3 OSA (ITIL Operational Support and Analysis), com pouco mais de 1% do total de exames ITIL V3 realizados em 2009. Ao nível das qualificações intermédias, observa-se uma ligeira vantagem quanto ao número de exames na área do “lifecycle” (SS, SD, ST, CSI e SO) relativamente aos exames na área da “practice” (SOA, RCV, OSA, PPO).

Esquema de certificações ITIL v3

Esquema de certificações ITIL v3


Maturidade da Gestão de Serviço de TI – Parte III

23-11-2009

Nas duas partes anteriores deste artigo foi abordada a utilização da Process Maturity Framework para avaliar a maturidade dos processos nas cinco dimensões, segundo níveis definidos.

A título exemplificativo, apresentamos, para cada uma das dimensões referidas, o enquadramento correspondente ao nível de maturidade 3 (Definido):

Visão e Condução

  • Objectivos formalmente acordados e documentados.
  • Planeamento formalmente comunicado, acompanhado e revisto.
  • Recursos adequados e devidamente orçamentados.
  • Relatórios e revisões planeados e produzidos regularmente.

Processos

  • Processos e procedimentos bem definidos e divulgados.
  • Actividades regulares e planeadas.
  • Documentação de (com) qualidade.
  • Ocasionalmente acontecem processos proactivos.

Pessoas

  • Papéis e responsabilidades claramente acordados e definidos.
  • Objectivos formalizados.
  • Planeamento formal da formação.

Tecnologia

  • Recolha contínua de dados com definição de patamares de monitorização e alarmística.
  • Armazenamento de dados consolidados para planeamento, análise de tendências e previsão.

Cultura

  • Abordagem formalizada à orientação ao Cliente e ao Serviço.

Pensamos ser razoavelmente consensuais se dissemos que tudo o que respeita à Gestão de Serviço é relativamente simples (puro bom senso, dirão), o que não quer dizer que seja fácil. Julgo que este sentimento traduz a dificuldade inerente à operacionalização de novas práticas.

Contrariando aquele obstáculo, o modelo Process Maturity Framework permite endereçar e operacionalizar, na prática, a tarefa de estabelecer um baseline inicial de uma Organização, etapa fundamental no contexto de um programa de ITSM.


Identificar processos num mundo 2.0

18-11-2009

A gestão por processos pressupõe o conhecimento dos mesmos e a melhoria contínua requer frequentemente a modificação desses mesmos processos.

Para além de ser uma tarefa complexa, a implementação de processos redesenhados tem por vezes resultados inesperados e disruptivos, pois o que julgávamos ser feito afinal é apenas parte do “filme”.

Segundo o ITIL, um processo é um conjunto estruturado de actividades concebido para alcançar um objectivo específico, transformando um ou mais entradas definidas em saídas definidas.

Ainda segundo a mesma fonte, os processos são mensuráveis, proporcionam resultados específicos, têm clientes/intervenientes e respondem a eventos específicos.

…Mas em lado algum a definição diz que têm de estar no papel antes de serem realizados.

caravelaDito isto, em terra com tradição de exploradores, há que reconhecer que a descoberta de processos é uma abordagem com enorme potencial.

A descoberta de processos consiste em mapear o tratamento dado às tais “entradas definidas” (um pedido de suporte, por exemplo) até que elas se transformem numa das saídas definidas (a colocação do registo do pedido no estado fechado, por exemplo).

Esta abordagem é particularmente interessante se for suportada por uma plataforma colaborativa, ao estilo Web 2.0, em que quem executa a tarefas indica o que faz, para quem envia o assunto em seguida e o que lhe solicita (autorizar, tratar, conhecer, etc.) Uma vez terminada a execução do processo, voilà! O processo está mapeado.

…Ou quase.

Para mapear o processo será necessário que o mesmo seja executado nas suas múltiplas variações, para se descobrir os diferentes percursos alternativos de tratamento. No entanto, se Pareto nos ensinou alguma coisa é que com 20% do esforço alcançaremos provavelmente 80% do resultado.

Fazer o levantamento do processo é a primeira parte.

Para “ITILizar” uma organização é necessário reformular os processos para introduzir boas práticas e melhorias continuadamente, o que será muito mais fácil se tivermos como ponto de partida a realidade, em vez de um conto bem contado.