A renegociação nos casos de mudança do escopo do projeto pode ser uma das tarefas mais estressantes em um projeto. Apesar de ouvirmos muito por ai que o escopo muda, a realidade não é bem assim. Mudanças custam. Tipicamente quando não se sabe o que deve ser feito também não se sabe o custo e então o risco pode ir nas alturas. Em um cenário como este porque começar o projeto? Não seria melhor então definir primeiro o que será feito para ai sim iniciar o projeto?

Um grande amigo costuma dar o exemplo:
- Faz ai um bolo pra mim.
- De qual sabor?
- Tanto faz, faz ai e depois eu vejo que sabor eu quero
- Minutos depois ele volta falando:
- Eu quero de chocolate
- Xii, dançou pois eu já comecei a fazer de cenoura.

Enfim, não seria melhor esperar se definir o que quer? Há uma utilização equivocada dos métodos ágeis em diversas situações como a apresentada. Parece que está sendo mais ágil pois “já se começou a fazer”, mas esquece-se do retrabalho gerado e consequentemente do custo.

É importante lembrar que tudo tem um custo e todo bom gerente de projetos deve utilizar os recursos financeiros do mesmo da melhor forma.

Voltando ao artigo, uma das grandes dicas, em especial em projetos de software é descrever claramente o que será feito. Vejamos duas descrições.

Você escreveu: Cadastro de Fornecedores – Nesta tela será possível realizar o cadastro de fornecedores.

Qualquer pessoa que veja essa descrição vai imaginar que é uma tela simples. Imagine que a equipe fez um CRUD com uns 20 campos e ao chegar ao seu cliente ele fala que não era nada disso que ele queria, ele comenta que tinha entendido que a tela teria funções como duplicar o fornecedor, lista de últimos pedidos, usuários do fornecedor, faturas pagas, etc, etc, etc

Onde foi o erro? A descrição estava muito simples. Seria melhor detalhar ela um pouco como: Nesta tela será possível fazer operações com inclusão, exclusão, alteração e consulta de fornecedores. Para efeito de estimativas previmos o uso de até 20 campos.

Ficou mais objetivo e nem deu trabalho. Da mesma forma é uma boa prática o escopo vir com um anexo intitulado “lista de funcionalidades” onde serão colocados cada módulo e suas funcionalidades do ponto de vista de negócios.

Quando se tem um detalhamento como este e uma lista de funcionalidades, as renegociações de escopo ficam mais fáceis pois saem da esfera do “eu acho”, “estava sub-entendido”, e similares e vão para a esfera dos “fatos”.

Outro ponto a considerar é que o gerente do projeto deve lembrar que o escopo do projeto não muda a não ser que os stakeholders aprovem a mudança, e consequentemente se impacto, em especial em prazo e custo.

Resumindo:

• Não altere o escopo por sua própria vontade
• Descreva o que será feito e o que está previsto
• Elabore uma lista de funcionalidades
• Documente formalmente as mudanças
• Faça uma análise de impacto

Ações simples como estas lhe ajudará quando for necessário renegociar o escopo do projeto.

Hoje a tarde há um evento de Status Report com seu cliente e você deve apresentar o relatório com os mesmos indicadores apresentados sempre como atendimento à prazo, atendimento à custo, produtividade, índice de qualidade e outros. Para sua sorte a empresa em que você trabalha possui um sistema de gestão que lhe passa estas informações facilmente então é só pegar os dados lá certo?

Chegando no cliente com o Status Report debaixo do braço (na verdade em um pendrive) você inicia a apresentação comentando as pendências, ações, indicadores e de repente é interrompido com a seguinte frase: “Me parece que estes dados de progresso e qualidade são os mesmos da semana passada”. Você verifica e… infelizmente são, não houve variação nos indicadores na última semana. A partir daqui o gerente pode perder um elemento essencial: sua credibilidade.

A causa mais comum para esta situação é a não atualização dos dados do projeto pela equipe e isto ocorre por falta de disciplina, elemento este que infelizmente é cada vez mais raro. Independentemente da função exercida (especificação, codificação, testes, etc), deve-se também atualizar as informações dos sistemas, em especial o sistema de gestão afinal, o GP não vai advinhar que uma determinada tarefa está pronta nem vai adivinhar também seu custo, esforço, qualidade, etc.

Voltando ao início do texto, está situação poderia ser evitada com um simples indicador que o sistema já poderia passar ao gerente do projeto que é o índice de “Confiabilidade”, também conhecido como indicador de confiabilidade dos dados. Sua implementação é muito simples, basta implementar uma equação que leve em conta as últimas atualizações de dados de esforço e progresso com seu volume. Pode ser uma escala de 0% à 100% e pode-se criar uma regra onde os dados só são confiáveis se acima de um certo índice.

Se o sistema tivesse este indicador, antes de elaborar o Status Report você poderia ver o índice como ~60% e tomado a decisão de solicitar atualização dos dados antes de continuar, evitando assim o comprometimento da sua imagem. Da mesma forma, você poderia ver também que a última atualização dos dados foi à 8 dias, logo, a posição apresentada pelo sistema não é válida.

Enfim, considere a implementação de um indicador de confiabilidade em seu sistema de gestão.

Uma das definições de governança de TI mais fáceis é a de que Governança é a gestão da gestão. De uma forma simples até poderíamos dizer que após a definição de processos, objetivos e metas, a governança seria gerir se o processo está sendo seguido e se os objetivos estão sendo atendidos.

A definição de processos não é governança propriamente dita, mas é base para a mesma. É importante ter processos definidos para as principais trabalhos e uma forma fácil de se conseguir isto é implementar modelos como CMMI, PMI, Cobit, ISO e Itil. Este conjunto é campeão.

A governança deve garantir ações como: seguimento do processo, segurança, confiabilidade, utilização dos padrões, ambiente para a operação, atendimento das metas e outros. Pegando o exemplo abaixo, podemos entender de uma forma simples uma das atuações da governança:

No início do ano são definidas metas para cada área. Na área comercial, uma das metas é aumentar as vendas em 36% até o final de um ano. Em um cenário fictício onde históricamente não há diferença entre os meses, a cada mês a área deveria aumentar as vendas em 3%, e ir acumulando isto mês a mês, assim em janeiro teriamos 3% de aumento, em fevereiro o aumento seria de 6%, março 9% e assim por diante até chegar à dezembro, onde teríamos 36%. Se as metas forem atendidas, não há necessidade de ação, todavia, a governança deve atuar principalmente quando do não atendimento de uma destas metas parciais identificando o problema, suas causas e criando planos de ação para corrigir o desvio.

Um outro exemplo de atuação seria a satisfação de seus clientes. Seus clientes estão satisfeitos com os serviços de sua empresa? O que eles dizem dos seus serviços? Quais os pontos de melhoria na visão deles? Não podemos esquecer, conhecer o que o cliente pensa, qual sua percepção, é importantíssimo mas falaremos disto mais detalhadamente em breve.

Enfim, apesar de muito amplo e completo, está é uma das principais diretivas (gestão da gestão) e saber disto pode ajudar em várias coisas e várias definições.

Em tempo, considere o uso de dashboards com foco nos principais projetos e alinhados aos objetivos estratégicos.

Olá pessoal, constantemente me pedem dicas sobre indicadores (ou KPIs como preferirem) para gestão de projetos, então, aqui agora estaremos apresentando alguns dos indicadores mais comuns no gerenciamento de projetos/serviços. Um ponto importante é ter mecanismos para que a coleta dos dados seja “podemos dizer” prática. Um bom sistema de gestão de projetos poderá resolver fácilmente isto.

Hoje falaremos um pouco do indicador mais utilizado na gestão de projetos que é o atendimento à prazo, todavia, ao longo do próximo mês falaremos também dos seguintes indicadores:

• Atendimento à prazo
• Atendimento ao custo
• Produtividade
• Densidade de defeitos
• Reutilização
• Retrabalho
• Satisfação do cliente
• Complemento
• Assertividade dos requisitos

Acompanhe este conjunto de matérias.

Atendimento à prazo

Objetivo: Indicar quanto o projeto está adiantado ou atrasado.

Aplicável à: Ver o projeto como um todo é o mais trivial. Uma evolução é medir cada fase, etapa, entrega, produto, etc.

Unidade: A mais comum é ser apresentado em percentual (%), mas há outras. Recomendo converter os dados em em dias (d) pois é uma unidade de fácil entendimento.

Problema típico: O problema mais comum é ver apenas se o projeto está ou não atrasado (data fim). Não olhar o atendimento a prazo do projeto ao longo de seu ciclo de desenvolvimento é um sério problema de falta de gestão. Está prática deve ser desencorajada.

Coleta: Defina um local único como por exemplo o sistema de gestão de projetos/serviços da empresa.

Forma de apresentação: Recomendo um gráfico onde seja possível visualizar a variação do desempenho sob o eixo de 0% (ou 0d) onde números negativos indicam que o projeto está atrasado e números positivos indicam que o projeto está adiantado.
É importante lembrar que o atendimento à prazo deve variar em números próximos à zero. Se você ainda não tem os baselines de desempenho, defina limites (superior e inferior) para o controle. Se o número estiver dentro dos limites, então você pode tomar a variação como natural, se estiver fora defina ações.

Como usar: Você precisa ter uma definição de tudo o que será feito no projeto e qual percentual cada elemento representa para o todo. Uma WBS pode ajudar muito. Depois, verifique diáriamente como está o indicador e tenha certeza de que sua equipe também conhece este número. Tome ações nos casos de indicadores fora dos limites.

Dica: Após ter amostras suficientes (recomendo pelo menos 100 pontos) verifique qual o desempenho padrão do processo e seus baselines. Estas informações além de serem essenciais no dia-a-dia, serão muito úties em programas de melhoria CMMI 4 ou MPS.Br B.?Interpretação: Números negativos indicam que o projeto está atrasado. Números positivos indicam que ele está adiantado.

Recomendação: Acompanhe este indicador diáriamente e tenha em mente a importância desta informação para a equipe.

Para ter informações precisas e confiáveis, assegure que é um apontamento diário da evolução e do trabalho.

A conclusão das atividades deve ser informada no primeiro momento que a mesma estiver concluída. Sobre a técnica de conclusão, particularmente recomendo a “pronto x não pronto” também conhecida como “ou 0% ou 100%”.
Procure também informações sobre SPI e EVM.

Project Charter

O project charter é o documento que autoriza formalmente o início do projeto. Podemos dizer que com este documento o gerente do projeto passa a ter auditoridade sobre o mesmo. O project Charter é um documento que deve passar uma visão geral do que é o projeto abordando assuntos como:

• Requisitos do projeto
• Objetivo do projeto
• Stakeholders
• Responsabilidades
• Cronograma com principais marcos
• Estimativas iniciais
• Riscos

WBS

A WBS é uma excelente ferramenta para decompor os trabalhos do projeto (Saiba mais sobre WBS). Graficamente, a WBS é apresentada como uma arvore de elementos onde são apresentados inicialmente os pacotes maiores de trabalho e estes pacotes vão se decompondo até um nível de gerenciamento bom para o gerente. Sua apresentação gráfica pode facilitar bastante aos envolvidos entenderem o que deve ser feito no projeto. Consequentemente, mudanças de escopo também ficam mais fáceis de se negociar.

Estimativas

As estimativas são elementos essenciais de todo projeto. Todo projeto deve pelo menor ter  estimativas de Esforço, Prazo, Custo, Equipe e Recursos. Utilizar uma técnica de mercado com APF pode facilitar todo o processo de estimativa de esforço, prazo e custo.

Muitas empresas não estimam o custo do trabalho, nestes casos o processo de gestão fica comprometido pois o gerente deve inclusive gerir o custo do projeto e gerir esforço é muito diferente de gerir custo.

Cronograma

O cronograma é outro instrumento base para o gerente de projetos. Ele basicamente é uma planilha contendo atividades, custo, esforço, responsáveis, data de início e data de término. Ferramentas como o Microsoft Project facilitam a vida do gerente de projetos visto que ele conta com diversos outros recursos como utilização de recursos humanos, Gráfico de Gantt, baselines e diversas outras visões que agilizam o trabalho do gerente do projeto.

Normalmente monta-se cronogramas focados na equipe do projeto, mas tão importante quanto a alocação da equipe do projeto é a alocação do usuário e clientes. Em posse do cronograma eles podem saber quais são suas atividades e quando elas devems ser executadas.

Plano de Projeto

O plano de projeto e Status Report são provavelmente os documentos mais importantes da gestão do projeto. O plano de projetos deve ser usado para direcionar as atividades do projeto e deve endereçar assuntos como:

• Escopo
• Riscos do projeto
• Equipe necessária
• Estimativas
• Entregáveis
• Agenda de eventos (auditorias, entregas, reuniões, acompanhamento, etc)
• Dependências
• Metas
• Responsabilidades
• Cronograma com milestones
• Etc

Um bom plano de projetos não garante que o projeto será bem executado, todavia quando seguido reduz consideravelmente as possibilidades de problemas.

Veja também: Plano de gerenciamento do projeto.

Status Report

O Status Report é um documento onde os envolvidos podem ver a situação atual do projeto. Este evento de acompanhamento é um dos principais momentos do projeto e deve ser realizado tanto internamente quando com seu cliente.

Tipicamente um Status report apresenta informações como:

• Indicador de atendimento ao prazo do projeto
• Indicador de atendimento ao custo do projeto
• Cronograma atualizado
• Principais realizações
• Problemas em aberto
• Como está o tratamento de riscos
• Próximas ações do projeto
• Planos de ação

Uma boa prática em todos os eventos de acompanhamento é utilizar o status report anterior para verificar o que evoluiu e se as pendências foram resolvidas.

Estas informações são o básico que qualquer Status Report deve conter e é importante lembrar que tudo que envolva “gente” ou compromissos deve ter o “quem” e “quando”. O “quem” é “quando” é uma forma simples de se obter o comprometimento das pesosas envolvidas.

Vale lembrar que o Status Report deve servir de insumo para o portfólio de projetos.

Planilha de riscos

A planilha de riscos ou como alguns gostam de falar “Plano de resposta aos riscos” é um documento onde você registra todos os riscos do projeto e define ações para tratar os riscos como Mitigação, Aceitação, Contingência, Transferêncie e outros. É importante lembrar que deve-se buscar eliminar o máximo de riscos do projeto.

Aceite

O termo de aceite formaliza que o projeto foi desenvolvido conforme suas especificações e que o cliente aprovou a entrega. Hoje em dia como há muitos projetos onde o faturamento é vinculado à entrega, nestes casos é interessante ter termos de aceite por entrega.

Encerramento do projeto

O documento de encerramento visa além de formalizar o término do projeto discutir como foi o mesmo e coletar lições aprendidas. Durante o encerramento é interessante tratar assuntos como:

• Como foi o atendimento aos objetivos de negócio
• Como terminaram os indicadores de custo, prazo e produtividade
• Quais os principais problemas do projeto
• Discutir sobre as lições aprendidas
• Registrar na base de conhecimento da organização

O CobiT é um bom modelo para governança de TI. Dentre seus elementos podemos contar com:

• Sumário executivo
• Framework
• Controle de objetivos
• Mapas de auditoria
• Ferramentas de implementação
• Guia com técnicas de gerenciamento

Reconhecido como um dos melhores métodos para gestão de TI, o CobiT apoia fortemente na governança de TI e otimizar o investimento e obter melhores resultados. Por ser orientado ao negócio, ele foca em fornecer informações suficientes para avaliar os resultados e a gestão. Modelos como ITIL, CMMI (ou MPS.Br), PMI e ISO possuem boas práticas que estão aderentes as necessidades do CobiT.

Assim como o CMMI, o CobiT possui cinco níveis de maturidade de governança:

• 0 Inexistente
• 1 Inicial / Ad Hoc
• 2 Repetitivo mas intuitivo
• 3 Processos definidos
• 4 Processos gerenciáveis e medidos
• 5 Processo otimizados

O CobiT está dividido em quatro domínios: Planejamento e organização, Aquisição e implementação, Entrega e suporte e Monitoração e estes domínios estão divididos em 34 processos como demonstrado abaixo:

Domínios e processos CobiT

Planejamento e Organização

• Define o plano estratégico de TI
• Define a arquitetura da informação
• Determina a direção tecnológica
• Define a organização de TI, os seus processos e seus relacionamentos
• Gerencia os investimento de TI
• Comunica os objetivos e direcionamentos gerenciais
• Gerencia os recursos humanos
• Gerenciar a qualidade
• Avalia e gerencia os riscos de TI
• Gerencia os projetos

Aquisição e implementação

• Identifica as soluções de automação
• Adquire e mantém os softwares
• Adquire e mantém a infra-estrutura tecnológica
• Viabiliza a operação e utilização
• Adquire recursos de TI
• Gerencia as mudanças
• Instala e aprova soluções e mudanças

Entrega e suporte

• Define e mantém os acordos de níveis de serviços (SLA)
• Gerencia os serviços de terceiros
• Gerencia a performance e capacidade do ambiente
• Assegura a continuidade dos serviços
• Assegura a segurança dos serviços
• Identifica e aloca custos
• Educa e treina os usuários
• Gerencia a central de serviços e incidentes
• Gerencia a configuração
• Gerencia os problemas
• Gerencia os dados
• Gerencia a infra-estrutura
• Gerencia as operações

Monitoração

• Monitora e avalia o desempenho da TI
• Monitora e avalia os controles internos
• Assegura a conformidade com requisitos externos
• Prove governança para a TI

Cada vez mais as organizações devem aprimorar seus controles, melhorar o desempenho e aumentar a qualidade. As organizações devem conhecer o desempenho e variação de seus processos e buscar oportunidades de melhoria e o CobiT cai como uma luva no atendimento à estes objetivos.

Quando um projeto é encerrado prematuramente, é cancelado ou termina sem que seus objetivos tenham sido atingidos, considera-se que ele fracassou. O Gestor do Projeto (GP) tem que se prevenir, o que não é muito difícil já que as causas são quase sempre as mesmas, uma (ou várias) destas:

Causa 1: Expectativas irrrealistas

Se é verdade que o segredo da felicidade é a administração das expectativas, se você não administrar as suas (e as do patrocinador), você pode acabar se decepcionando com resultados que, sob uma outra ótica, seriam considerados bons.

Seja por uma falha de compreensão do escopo ou por um cronograma muito apertado, os projetos que não têm sólidas bases realistas tendem a falhar mais do que os projetos que levam em conta a cultura da empresa e as restrições impostas naquele momento.

Mas como saber se as minhas expectativas são realistas? Pense em discutí-las com profissionais mais experientes que conhecem os problemas que você terá de resolver e que conhecem a organização.

Às vezes o procedimento mais simples fica travado pela burocracia e quem já passou por isso pode ajudá-lo contornar os obstáculos.

Causa 2: Planejamento deficiente

Depois de estudar muita estatística cheguei a uma conclusão: planejamento é muito mais arte do que ciência.

Você pode aprender os mais sofisticados métodos de previsão, saber calcular o desvio-padrão de uma estimativa e usar as ferramentas mais sofisticadas e mesmo assim errar. Porquê? Em geral por que partiu de premissas erradas. Você espera que determinado fornecedor entregue uma tarefa com uma eficiência de 95% e ele falha em 30% das vezes. Sua margem de manobra que era de 5% estourou e você deve acomodar os 25% (30%-5%) que aconteceram de forma imprevisível.

Vivemos num mundo complexo em que os eventos podem ser influenciados por acontecimentos de uma forma numa vez, mas por outra bem diferente na próxima ocorrência. Quando aproximamos um processo tendemos a buscar uma função com forma linear, algo como y=Ax+B. Neste modelo, a variável x que se observa explica a variável y segundo os parâmetros A e B. Mas se houver outro fator, digamos z, que afeta y e não colocamos na equação (porque quando medimos x e y, z era desprezível), podemos incorrer em grande erros nos casos em que esta variável omitida, z, assuma valores significativos.

Nos processos de Gestão de Riscos, deve-se identificar os fatores relevantes (no nosso caso, x e z) e procurar medir, ou estimar, qual o possível impacto no resultado final (no nosso caso, y).

Causa 3: Falha no controle de desempenho

Não há nenhuma desculpa aceitável para se perder o controle sobre o desempenho da equipe de projeto e de outros interessados que afetam diretamente os resultados. Alguns GPs preferem relatórios, outros vão para o contato cara-a-cara. Não importa como, mas é vital que este processo de acompanhamento seja permanente e regular. Se a tarefa parece cansativa, automatize-a mas faça.

As pessoas respondem de forma diferente quando são monitoradas, como nos ensina o “efeito Hawthorne”.

Neste experimento, o mero fato de estarem sendo acompanhados por pesquisadores fazia com que os trabalhadores de uma fábrica produzissem mais. Tentaram variar a luminosidade do ambiente de trabalho e descobriu-se que com mais ou menos luz, as pessoas eram mais produtivas. Ficou ficou claro que não era a luz que influía nos resultados, mas o ato de estar sendo monitorado é que fazia o pessoal dar duro.

Desempenho pode ser algo complicado de medir. Num projeto de software, usa-se muito como métrica a quantidade de linhas de código escritas. Mas um programador pode entregar mais código e ao mesmo tempo cometer mais erros do que os outros. Um bom indicador deve ser simples, mas não tão simples que esconda o que se deseja realmente medir, que é a quantidade de código de boa qualidade.

Lembre-se da velha fórmula: “tudo o que se deseja obter deve ser medido”.

Causa 4: Falta de liderança efetiva

Eu encontrei vários GPs que vinham de organizações matriciais fortes e acredito que foram muito influenciados por elas. Parece que nestas organizações, as pessoas demoram mais a responder por receio de entrar numa área alheia. No limite, a guerra entre os “feudos” impede que boas iniciativas inter-departamentais decolem. As pessoas estão reprimidas e, se o GP é “cria da casa”, ele pode
apresentar hesitações “inexplicáveis”.

Estas pessoas usualmente apostam que muitos ruídos se dissipam “sozinhos”, o que obviamente não acontece. O ruído, ie. um pequeno problema dentro da equipe, pode ser mais do que isso. Pode ser que não seja tão pequeno mas que assim pareça por uma falha de percepção do GP. Quanto maior o projeto, maior a inércia (leia-se, resistência a mudanças) e maiores as chances de ruídos.

Quanto mais rápido o problema for endereçado pelo GP, melhor para todos.

Além disso, a verdadeira liderança é inspiradora e viral: um bom líder acaba criando um ambiente propício ao surgimento de novos líderes a sua volta. Uma dica: se você topar com uma equipe cheia de pessoas motivadas e que apresentam um claro interesse em liderar, você tem uma boa pista de que o GP é um bom líder.

Causa 5: Falta de skills dos membros do time de projeto

Quando contratou um profissional, o GP pode ter sido enganado pensando que o candidato sabia fazer uma coisa que na verdade não sabe, mas isso é difícil de ocorrer se você tomar as devidas precauções como estabelecer uma descrição funcional (“job description”) bem detalhada e que especifique uma série de habilidades que possam ser verificadas. Discutimos técnicas para isso em outro artigo.

Mas mesmo que você tenha feito tudo certo, começou o projeto, definiu e plataforma de desenvolvimento (digamos por exemplo, Windows), contratou experts e depois, por uma daquelas voltas da vida, descobre que o produto deveria ser desenvolvido em outra plataforma (por exemplo, Unix) que sua equipe não conhece. O que fazer? Trocar ou retreinar?

Depende dos recursos de tempo e verba disponíveis mas via de regra prepare-se para mudar boa parte da equipe, sem se deixar levar por sentimentos de amizade ou pena. Melhor seria especificar o pagamento de um bônus de desligamento antes de contratar o profissional. Quanto antes ficam claras as regras do jogo, melhor para todos. No final, a opção é simples: agir quando ainda há tempo ou ver o barco afundar.

Causa 6: Falta de motivação do time e dos interessados

O moral da equipe sofre muito quando a gestão é fraca. Imagine se o João, que é um gerente júnior importante para o projeto acabou de casar e está sendo pressionado pela esposa a procurar outro emprego que pague mais. O GP, temendo perdê-lo, lhe promete um bônus mas não pede autorização da direção nem com do pessoal de RH. Ele pensa que não é necessário já que o projeto tem orçamento para isso.

João dá duro, se esforça e o projeto é um sucesso. Na hora “H”, o bônus não vem como prometido e João recebe um tapinha nas costas. As explicações são as mais diversas: não temos orçamento para isso, é política de empresa não fazer estas coisas, você não seguiu os procedimentos da empresa, etc…

Isso pouco importa para quem não recebeu a devida recompensa. O que acontecerá com o desempenho de João depois disso? Isso para não mencionar a perda de credibilidade.

Tenho uma regra: quando um bom profissional está entregando abaixo do seu potencial o GP tem “culpa no cartório”: ele deveria ter se informado sobre o que está acontecendo. No caso do João, ele agora está saindo mais cedo para ir a entrevistas de emprego em outras empresas. O GP deveria ter tomado as devidas medidas corretivas, como se informar sobre a possibilidade de bonificar o pessoal.

Moral de história: se você não puder oferecer um bônus, não o faça. Se fizer, tem de cumprir.

Causa 7: Falta de apoio dentro da organização

Apoio aqui é a força política que um diretor, sócio ou presidente pode dar ao projeto. A figura mais importante para o projeto é a do patrocinador que deve comunicar aos demais membros da organização a importância da iniciativa para a empresa, cobrando deles a atenção necessária para que as tarefas sejam concluídas.

Por exemplo, imagine instalar um sistema financeiro numa empresa pequena com um grande número de pedidos processados manualmente todos os dias. Haverá uma sobrecarga do pessoal do departamento pelo tempo necessário ao teste e implantação do projeto.

Esse tempo extra pode exigir a contratação de pessoal temporário para fazer as tarefas do dia-a-dia enquanto o pessoal da casa usa a nova ferramenta. Sem apoio de alguém com poder de decisão pode ser difícil contratar esta equipe para ajudar na transição ou para fazer o pessoal do departamento financeiro separar duas horas do seu dia para testar e aprender a usar a nova ferramenta.

Causa 8: Falta de recursos

Apesar de algumas pessoas não tomarem o cancelamento de um projeto por falta de fundos como um fracasso, entendo que de alguma forma o GP poderia ter se antecipado ao problema. Qualquer companhia pode enfrentar momentos difíceis, que exijam a redução rápida de custos. No entanto, isso dificilmente acontece do nada (como, por exemplo, na mini-crise de 11 de setembro de 2001).

Em geral os sinais estão por toda parte e cabe ao GP estar ligado neles. Por exemplo, se parte dos recursos para um projeto ainda devem ser captados no mercado e os juros (leia-se, a taxa Selic) sobem, é provável que surjam dificuldades para realizar esta captação.

E como tratar o problema com a equipe? É melhor abordar o tema claramente numa reunião do que deixar os rumores de demissões tomarem conta das mentes de pessoas que deveriam estar concentradas em obter resultados.

Se haverá um corte de orçamento, o GP deve se antecipar e planejar como se poderia reduzir custos e seguir com o projeto. No limte, ele deveria pensar em encerrar o projeto deixando resultados palpáveis, mesmo que não os originalmente esperados. A partir de algo concreto é mais provável que se possa retomar o projeto quando o ambiente econômico melhorar.

Mas se os recursos faltarem porque a empresa está vendo outros projetos como prioritários, o GP deve lutar por seu projeto e mostrar o que já se ganhou com ele e quanto ainda deve ganhar se completá-lo.

Se o patrocinador receber um plano para seguir com o projeto com custos reduzidos, isso pode evitar a suspensão/cancelamento do projeto.

Conclusão

Sejam quais forem as causas do cancelamento do projeto, recomendo que sempre se faça uma reunião de encerramento para se discutir “o que se pode aprender com essa experiência”. Quando há confiança e respeito mútuo a equipe enfrenta as consequências do fracasso de forma unida. Cabe ao GP informar aos demais os propósitos da reunião, senão corre-se o risco dos mais exaltados buscarem culpados, o que cria um clima desagradável que impede o diálogo.

Sugiro que cada um faça o seu mea culpa, levantando apenas os pontos em que deveria ter agido de outra forma, sem tentar explicar seus atos em resposta a erros dos outros. Assumindo que o grupo fez tudo o que podia ser feito para evitar o fracasso, o GP deve tirar as lições devidas e resumi-las para todos. Assim aumenta-se as chances de sucesso no próximo projeto.

De toda forma, planejamento e comunicação são as duas atribuições críticas que o GP não deve delegar.

[Fernando C Barbi do Gestão de Projetos.info]

Há muito tempo eu quero escrever sobre este tema mas estava procurando uma abordagem simples e não encontrava. O blog do Eli Rodrigues conseguiu falar do assunto de uma forma bem objetivo.

Projeto atrasado, replanejado ou eterno?

O dia-a-dia do Gerente de Projetos (GP) tem sempre bastante emoção. São mudanças, conflitos, atrasos, controles, reuniões calorosas, relatórios, falta de recursos etc. Sempre que tento explicar esse ofício a alguém me vem à mente a figura de uma pessoa segurando rédeas de uma carruagem sem a estrutura que prende os cavalos, cada um querendo ir para um lado. Os cavalos na analogia seriam as disciplinas de Gestão de Projetos e as rédeas, a dificuldade de manter as coisas sob controle.

Mesmo os projetos mais simples podem gerar problemas e cabe ao GP a tarefa de manter esse caos o mais organizado possível. É um desafio constante. Um projeto pode passar por situações que geram atrasos e também pode ser replanejado por motivos muito diversos. O Atraso de um projeto não segue processo, gera conflitos, prejuízos e tem resultados imprevisíveis. Já o Replanejamento deve seguir um processo de Controle de Mudanças, analisar impactos (inclusive positivos), registrar causas e recalcular os parâmetros necessários (escopo, prazo, custo etc).

Replanejamento e Atraso são coisas bem diferentes, mas possuem uma similaridade: ambos podem estender o Prazo do projeto. E seja a situação controlada ou não, o projeto sempre corre o risco de se tornar um Projeto Eterno, termo que quero abordar hoje.

Projeto Eterno

O termo Projeto Eterno surgiu de conversas de cafezinho com colegas de ofício e é um disparate às definições do PMBOK, mas ouso citar em tom de brincadeira para retratar uma situação desagradável: Projetos que se estendem demasiadamente além da linha de base inicial. Para ser considerado “eterno”, o projeto não precisa necessariamente ter longo prazo (acima de 12 meses), basta possuir um desvio da ordem de 100% de prazo. Embora não tenha dados estatísticos, arrisco ser taxativo ao dizer: Projetos com desvios tão altos tiveram problemas na concepção ou planejamento.

Projetos Eternos são pedras nos sapatos de quem quer prosseguir rumo a novos desafios, mas são excelentes para quem quer adotar o papel de “Salvador da Pátria”, aquele que está sempre no meio dos problemas, mas nunca resolve nada. Mas seja você progressista ou acomodado, sempre há um Projeto Eterno esperando por você. Abaixo apresento um caso fictício para exemplificar melhor este conceito controverso.

O Projeto que se eternizou…

Era uma vez um GP satisfeito com sua função, que recebeu um Project Charter e iniciou um projeto com o prazo final de 1 ano. O trabalho, um desenvolvimento de software, corria bem e já se iniciava o projeto de arquitetura.

De repente, situações estranhas começaram a acontecer: os arquitetos deixaram o projeto no meio do design, o cliente não encontrava tempo para validar os protótipos, uma nova lei mudou estruturalmente os requisitos, os recursos humanos começaram a enfrentar dificuldades com a tecnologia. O GP começou a notar que o conjunto desses fatores teria grande impacto no prazo.

Começaram muitas reuniões para resolução de problemas, a pressão subia junto com o prejuízo, cliente e fornecedor começaram a entrar em conflitos, as desavenças se amplificaram na equipe. Foram chamados consultores que propuseram mudanças estruturais: Tirar a responsabilidade de um único GP e distribui-la para vários, depois unificar novamente a gestão em uma única pessoa, depois trocar de GP.

Vários GPs depois, alguns requisitos entregues e passados três anos, o cliente ainda não assinou o Termo de Aceite, os requisitos continuam mudando, o time inteiro já foi modificado e o GP continua no mesmo projeto. Isto sim um Projeto Eterno!

Algumas Causas de Projetos Eternos

Em certa ocasião fui convidado a fazer uma “Análise de Causa e Efeito” de um Projeto Eterno e notei bastante pressão sobre a suposta causa “Incompetência do GP”. No entanto, em todas as análises causais que fiz na minha carreira uma coisa posso afirmar: as causas sempre têm raizes profundas. Abaixo elenco algumas causas comuns em Projetos Eternos.

• Falta de aderência às boas práticas de engenharia;
• Uso de terceirização através contratos guarda-chuva que não estabelecem regras e multas sobre entregas;
• Aplicação inadequada das práticas de gerenciamento de projetos;
• Objetivos agressivos de projeto estabelecidos sem o suporte de um plano realista.

Projeto atrasado, replanejado ou eterno?

Embora o termo Projeto Eterno seja uma grande brincadeira, não dá para negar que possui um fundo de verdade. Não sei dizer se isso acontece somente em empresas com menor grau de maturidade, se é responsabilidade do GP ou se é pura questão de sorte, deixo esta análise para os pesquisadores. Mas posso dizer que eles existem e estão entre nós.

Se perceber que o projeto está se tornando um Projeto Eterno, o melhor a fazer é identificar as causas e trabalhar as ações corretivas antes que os problemas se amplifiquem. Medir sempre CPI e SPI, reportarstatus regularmente ter a documentação atualizada para um provável replanejamento.  Se ainda assim não tiver como evitar a “eternização”, o jeito é levar o projeto conforme os fatores ambientais permitirem.

O importante é manter a carruagem na direção certa e ter previsibilidade de chegada. Nunca a eternidade!

[por Eli Rodrigues]

Nos últimos meses, a expressão “gestão de riscos” ganhou relevância no dia a dia das empresas. O quadro mundial realmente trouxe importantes lições para os executivos, mas outro fenômeno, não tão positivo, pode prejudicar negócios: o da aversão total a riscos.

Muitos CIOs e outros profissionais da área de TI estão sempre caminhando na tentativa de eliminar completamente todos os riscos. Ma buscar o risco zero não é uma abordagem equilibrada. É preciso ponderar o nível de risco que a empresa corre e até que ponto deixar de corrê-lo pode prejudicar os negócios.

Um exemplo é a empresa que, no afã de barrar vírus e malwares, simplesmente bloqueia os programas de mensagens instantâneas e os acesso às redes sociais, consideradas importantes ferramentas de produtividade. No passado, esse bloqueio já aconteceu com outras ferramentas que hoje são imprescindíveis, como e-mail e internet. Com essa atitude, a companhia pode acabar atrasando projetos e aumentando gastos com telefonia e deslocamentos. No final, eliminar o risco pode resultar em prejuízo.

Na opinião dos especialistas, a área de TI deveria seguir o mesmo padrão da gestão de risco financeiro, de crédito ou de projeto. Essas áreas realizam ponderações cuidadosas sobre os riscos e definem métricas sobre quais deles vale a pena correr para melhorar o desempenho nos negócios.

Nesse sentido, analisar e lidar com riscos requer algumas práticas padrão. São elas:

1 – Abordagem
A empresa deve decidir quais abordagens podem ser utilizadas e qual metodologia é mais adequada para determinada situação ou projeto. A metodologia é que descreve as características de risco as quais o projeto está sujeito.

2 – Coleta de informações
A base para a correta identificação dos riscos está nas informações dos projetos, obtidos por meio de três fontes: visão dos recursos do projeto, visão dos clientes e documentação de avanço do projeto.

3 – Identificação de probabilidades e seus impactos
Identificados os riscos, os impactos e probabilidades de ocorrência do risco devem ser analisados, orientando o plano de ação.

4 – Monitoramento contínuo
Embora não ocorram como processos isolados, as diferentes partes de uma empresa possuem impactos e ameaças diferentes diante de cada risco. O monitoramento deve ser contínuo para se chegar a uma situação ideal de gestão de riscos.

[cio.com]

Seja sincero: Você acha que o orçamento de TI da sua empresa está correto?

Muitos pensam que sim, mas acabam tendo que explicar escolhas erradas que geraram prejuízo para a empresa e para a própria carreira.

Abaixo, algumas coisas que é melhor não fazer:

1. Sempre dizer sim

Dizer sempre sim pode fazer o orçamento sair do controle, dizem especialistas da Tatum, empresa de serviços e consultoria para executivos, que citam o caso de um hospital onde o CIO seguia a diretriz de atender a todas as solicitações. Os executivos seniores instruíram TI a fazer tudo que as pessoas precisassem.

Como resultado, os projetos planejados correspondiam a cerca de 10% do orçamento de 100 milhões de dólares, enquanto os não planejados devoravam 30% dos recursos. O problema é que 60% do budget era gasto com manutenção. Gorsage diz que as melhores práticas pregam que 70% devem ser dedicados a manutenção, 25% a projetos planejados e apenas 5% a demandas imprevistas.

A gota d’água aconteceu quando um grande projeto de TI resultou em um fracasso caro – e este projeto foi originado de demandas desordenadas.

Finalmente, o CIO e a diretoria descobriram que precisavam de governança forte. Eles penaram por seis meses até conseguir. Com o novo e rigoroso processo de aprovação e planejamento, os gastos de TI do hospital chegaram mais perto da proporção ideal.

2. Imaginar que os custos acabam depois que o projeto entrou em operação

Subestimar o trabalho necessário depois que um projeto entra em operação é o principal problema dos orçamentos de TI.

Uma maneira comum é dispensar os integradores após a entrada do projeto em operação.

3. Planejar e gastar localmente

A falta de uma estrutura central de orçamento pode gerar prejuízos.

Durante algum tempo, a Guarda Aérea Nacional decidiu não ter um processo central de orçamento ou procurement para sua rede de TI. Por isso, as decisões de compra ficavam nas mãos de indivíduos em cada uma das suas 88 bases e 250 unidades menores.

Desde que centralizou o processo de orçamento e procurement, passou a obter preços melhores por volume. A sua infra-estrutura ficou mais segura e a manutenção mais simples e barata por conta da padronização.

4. Superestimar a equipe interna de TI

As pessoas não orçam adequadamente as necessidades. É difícil justificar um grande projeto. Daí a tendência a presumir que o pessoal interno pode fazer mais do que, na realidade, é capaz.

5. Acreditar piamente em grandes economias com terceirização offshore

Muitos na área de TI precisam aprender que a economia proporcionada pela terceirização offshore tem limite. Eles estabelecem expectativas irreais, confiando sempre no melhor cenário possível, bons demais para serem verdadeiros.

6. Evitar consultar; preferir presumir

Mesmo que você seja excelente em orçamento, os diretores podem causar problemas.

Quando alguns executivos conceberam um plano para expandir a Frontier Airlines com a compra de outra companhia regional, o grupo decidiu manter seus planos em segredo, recorda Bob Rapp, que era vice-presidente e CIO da empresa.

O grupo não consultou Rapp, que reportava ao CFO, até aprovar o projeto e seu custeio. Foi quando Rapp viu que as pressuposições sobre tecnologia estavam erradas.

Por exemplo, o plano não incluía um centro de controle de operações de sistemas específico para o setor – exigência do governo norte-americano. O custo não previsto foi de 1 milhão de dólares para construir o centro e mais 1 milhão de dólares por ano para operá-lo.

A partir de então, ele começou a reportar diretamente ao CEO para ajudar a evitar descuidos similares.

[cio.com]

Dias atrás li um artigo de uma situação similar em um site americano e ele me levou a escrever este artigo.

Imagine o seguinte cenário:

Você leva seu carro na oficina para trocar o óleo, o mecânico te passa o custo de 200,00 e fala para você voltar duas horas depois. Ao chegar para pegar o carro o mecânico não só te fala que vai custar mais, como também te fala que já fez, e que por isso você terá que pagar 500. Qual seria sua reação?

Parece um absurdo, mas cada vez mais você vê comentários de situações similares em projetos de TI e muito disto acontece principalmente por falta de preparo e falta de gestão.

Falta de preparo

Uma coisa deve ficar clara para todo analista: Há um escopo que foi contratado e este escopo deve ser seguido. Se a proposta ou declaração de escopo diz que o projeto deve ter um cadastro de usuários com cinco campos (nome, login, senha, área e e-mail) com as funcionalidades incluir, consultar e excluir, então este é o escopo que deve ser levantado e desenvolvido. Nada mais, nada menos, afinal de contas foi isto que foi contratado. É muito comum um analista ir fazer o levantamento de dados sem ao menor ter se interado sobre o que deve ser feito. Isto é falta de preparo e deve ser fortemente desencorajado.

Outro caso muito comum é o analista realizar o levantamento anotando e detalhando todos os desejos do usuário. Se estes desejos estiverem dentro do escopo, bom, caso contrário isto deve ser tratado posteriormente.

Falta de gestão

Da mesma forma que o analista, o Gerente do Projeto também deve estar a par do que é o escopo controlar sua execução. Vale lembrar que uma mudança somente é uma mudança de fato após ser aprovada. SE não estiver aprovada pelos envolvidos ainda, então é apenas uma possível mudança.

Temos que lembrar que mesmo que comentários como “mas sem isso o sistema não me serve” ou “isso é essencial para o sistema” sejam ouvidos, ainda assim é uma possível mudança e só pode ser incorporada ao projeto após sua aprovação pelas partes interessadas com sua devida análise de impacto.

Isto nada mais é do que gerenciamento de escopo e somente com um bom gerenciamento de escopo poderemos evitar situações similares em nossos projetos. Um bom gerenciamento de escopo também ajuda a reduzir o custo dos projetos.

Normalmente quando ganhamos um projeto vem aquela felicidade, comemoração e estouro de champanhe, mas, o que acontece o day-after? Por onde iniciar um projeto? Aqui vão 3 dicas rápidas que irão auxiliar muito aos que se fazem está mesma pergunda: “Ganhamos o projeto. E agora o que faço?

Conhecendo o projeto

A primeira coisa que todo gerente de projetos deve fazer assim que fica sabendo que será o gerente do projeto é conhecer o mesmo, há cindo coisas básicas que você deve fazer durante o conhecimento do projeto:

• Conhecer o que foi vendido
  Leia a proposta, documento de visão ou similar, leia atentamente e anote possíveis problemas (para serem tratados posteriormente). Os analistas do projeto também devem conhecer bem o que foi vendido.
• Conhecer o escopo
  Verifique o que é escopo e o que não é escopo do projeto. Você também deverá lembrar seu cliente ou usuário sobre isso.
• Conhecer os riscos do projeto
  Este é um dos pontos cruciais, verifique os riscos que foram elencados e analise se há outros riscos que devem ser tratados.
• Conhecer as estimativas
  Este é outro ponto importante, conhecer em quanto tempo você deve entregar o projeto, qual o custo do mesmo, qual o esforço em cada atividade e outros.
• Avaliar se o projeto é “exequível”
  Após conhecer o que foi vendido, as estimativas, o escopo e riscos você deve avaliar se o projeto é exequível ou não. Se chegar a conclusão de que não é exequível, então é melhor nem iniciar o projeto.

Planejando o projeto

Você optou por ir em frente com o projeto, então chegou o momento de realizar o planejamento. Novamente há outras cinco dicas básicas para o planejamento:

• Elabore a EAP (WBS) do projeto
  A EAP é um jeito de apresentar gráficamente tudo o que será feito no projeto. Você terá seu sistema (módulos, sub-módulos, funcionalidades) de uma forma fácil de se entender. Utilize-a durante todo o projeto.
• Avalie os riscos do projeto
  É muito importante você avaliar bem os riscos do projeto. Utilize técnicas de gerenciamento de riscos para classifica-los e defina a forma de atendimento mais apropriada (transferência, mitigação, contingência, etc). Não se esqueça de comunica-los. Utilize como apoio a base de conhecimento de riscos da sua organização.
• Defina a equipe
  Muitos projetos falham por causa da pouca atenção à este item. Se você previu um analista sênior no projeto, não adianta colocar um programador junior bem intencionado. Não vai funcionar. Coloque a equipe certa, a equipe prevista para o projeto.
• Defina as responsabilidades
  Agora que você já sabe o que deve ser feito e já tem a equipe montada, é hora de definir quem fará o que no projeto. É importante lembrar também que o cliente ou usuário também faz parte do projeto, logo, ele também tem atribuições e responsabilidades.
• Elabore o cronograma
  Agora é só colocar tudo no cronograma com as datas e estimativas e pronto. Você já tem a versão zero do seu cronograma. Além do escopo do projeto, lembre-se de definir folgas para possíveis imprevistos, eventos de status report (equipe e cliente), integrações e verificações.

Fazendo o Quick Off

A reunião de quick off do projeto é o primeiro grande teste para o gerente do projeto. Neste evento ele deve apresentar o que será feito, como, por quem e quais as responsabilidades de cada um. Aqui temos mais cinco dicas básicas para o quick off do projeto.

• Preparação é tudo
  Não é possível causar uma segunda boa impressão, então, prepare-se bem para o quick off. A preparação inclui conhecer bem o escopo, expectativas do cliente e o planejamento que você elaborou. Durante a apresentação você deve passar confiança e firmeza. Nada de gaguejar ou “ler” os slides.
• Discuta o escopo
  É bom você discutir elemento por elemento do escopo com o cliente ou usuário. Isto ajudará a verificar se o entendimento está correto e se há algum ajuste à ser feito. Não esqueça de alinhar as expectativas.
• Apresente como o projeto será realizado
  Lembre-se de apresentar como o projeto será realizado. Apresente a metodologia, como serão as fases, o que será feito em cada fase, o que será entregue e coisas assim.
• Todos tem compromissos
  Inclusive o cliente tem compromissos. Se foi definido que haverá 4 dias de 8 horas para o levantamento de requisitos do módulo X, este compromisso deve ser seguido. O mesmo vale para a disponibilidade em validações. Não esqueça de comentar sobre elementos como estes aos seus clientes e usuários.
• Obtenha o comprometimento e defina os próximos passos
  Obtendo o comprometimento dos envolvidos as coisas ficam mais fáceis. Aproveite o momento e defina já o plano de comunicação, datas dos próximos eventos e início do projeto de fato.

O WBS (work breakdown structure) ou traduzindo: EAP (Estrutura Analítica do Projeto) é um dos principais elementos para o gerenciamento de projetos. A EAP te mostra o que você deve fazer, ou seja, qual será o seu escopo e ela deve ser elaborada antes do início do projeto, ou seja, em momento de planejamento.

Você pode estrutura-la de viras formas como: “Projeto: fase: sub-fase: pacote de trabalho”, “Projeto: pacote maior: pacote menor” e outras, mas é importante colocar tudo o que será realizado no seu projeto. Outro ponto importante é a granularidade que você vai aplicar, não há uma regra única, mas as melhores práticas recomendam que você tenha pacotes do tamanho que seja interessante para o seu projeto. Não é interessante ter pacotes pequenos como 30 minutos (a não ser que eles sejam relevantes ao projeto) ou pacotes grandes como por exemplo um mês. Em casos assim, recomenda-se quebrar em pacotes menores. Particularmente gosto de trabalhar com pacotes de pelo menos 8 horas e não mais que 40 horas, mas está é regra que eu utilizo.

Exemplo de uma EAP

Este é o tipo de documento que ficará bem grande, mas com ele você terá claramente um mapa do que deve ser feito no seu projeto e como você está atendendo ao escopo. Aliás, uma boa prática é utiliza-la no acompanhamento de seus projetos junto ao seu cliente, pois é fácil entende-la. Mostre ao seu cliente, explique seu funcionamento e que ela mostra o sistema como um todo que isto ajudará demais no gerenciamento de escopo e negociação de eventuais mudanças.

Porque a EAP mostra tudo o que será feito no projeto, uma boa prática de gestão é nunca iniciar um projeto sem ter a EAP do mesmo. Aliás, em projetos críticos, quando você não tem tempo pra nada é onde você verá mais claramente os benefícios da mesma, recomenda até não iniciar um projeto sem antes elaborar sua EAP.

E também assim como você coloca “o que será feito”, você também pode colocar informações como:

• Quando
• Por quem
• Quem mais estará envolvido
• Qual o custo deste pacote
• Qual o esforço estimado para este pacote

Com informações como está você terá uma EAP mais detalhada, e poderá controlar melhor seu projeto.

Você provavelmente sempre ouviu comentários como: “Planejamento é essencial”, “não se inicia nada sem antes se planejar”, “O planejamento é a base para um bom projeto” e outras frases similares. Mas, nada melhor do que este vídeo para mostrar o quanto é importante um bom planejamento.

Áreas comerciais conhecem o rotineiro confronto com a implantação de recursos de TI em seus processos, mas a influência da tecnologia da informação se estende aos segmentos de produção e de prestação de serviços.

Na opinião de Peter Ratzer, sócio da Deloitte, a crescente aplicação da TI em processos comerciais, e na produção e em serviços, aumenta o valor desses recursos no processo de geração do valor dos negócios. Em consequencia disso, cabe aos CIOs abandonarem o estilo de governança predominantemente voltada à TI e assumirem uma postura focada na orientação comercial da TI, voltada à geração de valor para a empresa.

Uma estratégia que pode ser útil aos CIOs é a divisão dos procedimentos em seis esferas, a saber:

1. Organização da TI
2. Processos de gestão de TI
3. Gestão da demanda e surimentos em TI
4. Gestão de riscos e de desempenho da TI
5. IT Compliance
6. Cultura corporativa

Em seguida, Ratzer explica como gerir cada um desses domínios e quais foram as modificações que sofreram em função das novas necessidades de gerar valor aos negócios da corporação.

1. Organização da TI

Ano passado, muitas empresas padronizaram e centralizaram fortemente a TI. Ocorre que essa centralização gera enorme complexidade aos gestores e pode criar um abismo entre a TI e o negócio da organização.

Com a TI de orientação comercial, de produção e de serviços predominante, os CIOs precisam gerir as diferentes interfaces de forma eficiente e efetiva. O que requer que a centralização dos processos seja posta em segundo plano por determinado tempo.

Apenas dessa maneira será possível posicionar os alicerces organizacionais que prendem a estrutura de TI aos diferentes processos e promover uma melhor transmissão das necessidades à TI e uma posterior solução apropriada.

2. Profissionalização da gestão de processos de TI

Por conta da tendência de industrializar serviços de TI, vários processos padronizados são exportados para os provedores de serviços de TI. Isso gera um compromisso maior entre a empresa e os processo informatizados que permanecem à empresa e são geralmente de cunho comercial. Com esse movimento, a carga de trabalhos técnicos dos gestores de TI cai substancialmente. Se, por um lado, os CIOs precisam investir na exportação de processos, também lhes é requerido que incrementem a capacidade dos recursos de TI internos, com o objetivo de gerar suporte aos processos comerciais.

3. Separação das gestões

A invasão da TI nas diversas áreas da empresa faz esmaecer a fronteira entre a gestão de fornecedores e de demanda.

Acontece que determinar de maneira precisa as interfaces de contato com clientes e com fornecedores é um fator crítico de sucesso na otimização dos processos. Responsabilidade do CIO.

Vale ressaltar que as interfaces com clientes e com fornecedores dispensam a aplicação de princípios e de gestão distintos. Se, pelo lado da gestão de demanda é necessário um conhecimento prévio acerca do negócio da empresa, as relações com fornecedores exigem atenção especial aos aspectos econômicos da transação.

4. Gestão de desempenho e de risco

Em épocas passadas, essa gestão era orientada aos riscos de ordem técnica e às métricas da TI. De agora em diante, espera-se uma gestão que dialogue com os mesmos fatores, mas seja orientada a outros ambientes da empresa. De pouco adiantam soluções de cálculo de riscos que funcionam afastadas de potenciais focos de turbulência ou apresentam sinais de difícil interpretação.

5. TI-Compliance

Antigamente a regulamentação de TI era algo dirigido apenas a segmentos bastante específicos, ao passo que atualmente faz parte da realidade de uma grande variedade de serviços. Por força das altas multas que incidem em casos de indisponibilidade e/ou prejuízo de dados, o assunto ganhou a atenção dos executivos de alto nível.

Os fatores de sucesso na gestão de regulamentações são a definição clara acerca das responsabilidades e dos recursos e o distanciamento entre as políticas e a complexidade intrínseca ao desenvolvimento dos negócios.

A sugestão é a criação de um cargo executivo voltado à gestão das regulamentações, o CCO (Chief Compliance Officer), focado no desenvolvimento de soluções para garantir robustez aos negócios da corporação.

6. Cultura Corporativa

A relação entre a corporação e a TI deve ser promovida de empresa para empresa, entre sócios e colaboradores. O paradigma puramente técnico, alimentado por anos no seio das TIs, deve ser desconstruído. Em seu lugar, os técnicos e outros colaboradores do departamento devem passar a enxergar suas funções como recurso primordial na geração de valor para os negócios da empresa.

Para impulsionar tal tendência, sugere-se que, logo no processo de seleção de candidatos às vagas, seja ressaltado que essa é a visão esperada do novo colaborador.

[Por CIO Peter Ratzer / Deloitte]