Recursos/White Papers

Gestão

6 projetos de TI mais temidos

A correção de sistemas antigos, a migração de e-mails para a nuvem, exigências de conformidade sem suporte e atualizações de ERP são alguns dos trabalhos que os profissionais de TI mais temem

Dan Tynan, CIO/EUA

Publicada em 25 de junho de 2018 às 16h43

Os projetos que a maioria dos profissionais de TI teme são as tarefas ingratas e essenciais que conquistam pouco reconhecimento ou respeito.

O gerenciamento de patches não é fascinante, mas deixar de ser feito pode fazer com que a organização acabe sofrendo com falhas de segurança. Os projetos de migração para a nuvem não costumam ser sensuais, mas a execução de servidores de e-mail  on-premise, em pleno 2018, é como usar telefones fixos analógicos. As implementações e atualizações de ERPs têm sido exemplos de fracasso em relação aos projetos de TI por mais de uma década, mas a maioria das grandes organizações não pode sobreviver sem algum tipo de sistema ERP.

A tecnologia quase nunca é a causa dos infernais projetos de TI. Mais frequentemente, as iniciativas tecnológicas desandam graças a expectativas irrealistas, falhas no escopo adequado, confrontos culturais, procrastinação ou falta de apoio adequado do alto escalão.

Confira os 6 projetos  mais temidos pelos profissionais de TI.

1. Enormes correções no último minuto
O patching é uma das tarefas essenciais que quase todo profissional de TI detesta fazer. Mas adie-o por muito tempo ou deixe de garantir que todas as suas máquinas estejam atualizadas e que sua organização possa acabar como a Equifax.

“Estamos constantemente nos deparando com grandes projetos onde as atualizações não acontecem há meses ou anos”, diz Oli Thordarson, CEO da fornecedora de serviços de TI Alvaka Networks. “Às vezes, podem ser centenas de servidores de produção, juntamente com servidores de teste e de desenvolvimento. Sabendo que, se algo der errado, podemos comprometer a  presença na Internet de uma marca, por exemplo, é bem estressante. É por isso que a equipe interna às vezes adia a correção, até que, de repente, a administração olhe para a situação e percebe que ela é esmagadora ”.

Os piores trabalhos de patch são aqueles onde os sistemas foram negligenciados por anos, acrescenta Unnar Gardarsson, CTO da Alvaka, que diz que ele é um dos raros profissionais de TI que realmente gosta de patch.

"O momento crítico é quando eu atualizo algo e os servidores demoram um tempo anormal para voltar, ou não voltam", ele diz. "Em alguns casos, posso entrar no console de recuperação de máquinas virtuais e ver o servidor. Em outros ambientes, tudo que posso fazer é corrigir e rezar." 

Lições aprendidas: Para evitar os piores cenários, tome cuidado extra para garantir que você tenha um plano de backup completamente testado que seja responsável por todos os sistemas, diz Gardarsson.

"Para cada trabalho de patch eu tenho um plano de projeto que leva em conta tudo, desde backups normais e instantâneos adicionais até notificar pessoas e interromper serviços", diz ele. "Alguns sistemas são realmente meticulosos e há um processo muito específico para colocá-los offline. Estar preparado e pensar em todos os cenários possíveis é fundamental."

2. Migração de email para a nuvem
Mudar de uma solução de e-mail on-premise para a nuvem parece simples, em princípio. Mas não é, diz Mike Meikle, CEO da SecureHIM.

É comu os usuários serem colecionadores de mensagens antigas que julgam importantes, diz Meikle. Eles têm centenas, quiçá milhares, de mensagens que deveriam ter apagado anos atrás, então o volume de dados é assustador. E se você estiver migrando de um sistema legado como o Lotus Notes (shudder), será obrigado a lidar com muita conversão de dados. Algumas das informações contidas nessas mensagens são altamente confidenciais e regulamentadas, portanto, você precisa estar em conformidade com os regulamentos HIPAA, GDPR , SOX, entre outros.

E, claro, você estará lidando com um sistema no qual as pessoas confiam virtualmente 24 horas por dia, sete dias por semana, para comunicações, agendamento, reservas de salas de reunião e assim por diante.

Meikle diz que trabalhou em empresas onde a migração para a nuvem levou mais de um ano e exigiu muito trabalho manual.

"Como o e-mail é onipresente, se a migração cair de alguma forma, a TI será imediatamente esfaqueada", ele diz. "Mesmo na era do Slack e outros aplicativos de bate-papo da equipe, a migração de e-mail é um daqueles projetos que a TI definitivamente teme."

Lições aprendidas: Como acontece com outros projetos de TI infernais, fazer sua lição de casa com antecedência é essencial. Desative os requisitos do sistema ou do dispositivo e recrute um grupo central de usuários avançados para executar provas de conceitos e pilotos, para que você possa resolver a maioria das falhas antecipadamente. "Você realmente precisa conhecer suas necessidades dos usuários e o que elas vão tolerar."

3. Mandatos de conformidade órfãos no nascimento
Existem dois tipos de projetos de TI: aqueles que recebem um forte patrocínio da alta administração porque são estratégicos para o sucesso da organização e todos os demais. Mas os tipos mais infernais são aqueles em que os funcionários devem ser arrastados, chutando e gritando contra as regras de conformidade, sem ue a TI tenha apoio de cima.

"Os projetos regulados exigidos pela liderança executiva mas que não recebem apoio total são os piores", diz Sheldon C., diretor de uma empresa de serviços de TI. (Sheldon não é seu nome verdadeiro; ele pediu para ser anonimizado para evitar ser identificado por ex-colegas).

Até cerca de um ano atrás, Sheldon era vice-presidente de tecnologia de uma grande instituição financeira na costa oeste. Quando entrou para a empresa, ela já estava na mira dos reguladores, em parte por causa de um plano inadequado de recuperação de desastres. Os acionistas ativistas estavam pressionando a instituição a limpar a bagunça e, ainda que a alta gerência estivesse por trás do projeto, os diretores de departamento tinham suas próprias prioridades. O DR não estava no topo de suas listas.

Então eles não participaram. Eles não enviaram requisitos departamentais para prioridades de failover e recuperação nem identificaram dados e aplicativos de missão crítica. Eles não participaram de testes preliminares ou avançados. Ignoraram os e-mails de Sheldon.

Como os pedidos vinham da TI, os chefes de departamento sentiam-se à vontade para protelá-los, e os patrocinadores do projeto nada fizeram para interceder em nome de Sheldon.

"Mencionei repetidamente ao CEO que isso estava acontecendo, e pedi ajuda", diz ele. "Eu estava tipo, 'Ei, tem esse problema e ainda não recebi uma resposta".

Então o projeto avançou com riscos não sendo aceitos ou reconhecidos ”.

Lições aprendidas: Documentar todo o processo - incluindo todas as tentativas frustradas de conseguir que as partes necessárias participem - é fundamental. Mas você também precisa distribuir as informações para as pessoas certas, para que os patrocinadores do projeto não possam alegar ignorância mais tarde.

E se isso não funcionar, corte suas perdas. No caso de Sheldon, isso significava partir para uma nova posição na oportunidade mais rápida.

“O engraçado foi que o CIO considerou o projeto de DR um grande sucesso”, diz ele. “Recebi elogios por ter feito isso. Mas eu sabia que quando os auditores realmente olhassem para para ele, as pessoas que fizeram os elogios teriam que defender o que aconteceu. Quando a cultura da empresa está preparando você para o fracasso, é um sinal de que é hora de sair . ”

4. ERP é uma palavra de quatro letras
Provavelmente, nenhum tipo de projeto inspirou mais angústia ou causou mais azia do que implementar um novo sistema ERP.

Ter que interagir com o ERP e hardware legados é sempre um perigo; use barreiras linguísticas e culturais e você terá uma receita para um desastre de proporções épicas, observa Dan Coleby, diretor de desempenho de negócios e consultoria da IT Lab, no Reino Unido.

Em meados dos anos 2000, quando a Coleby estava trabalhando para uma empresa de consultoria Big 4 em Londres, ele foi chamado para ajudar a filial japonesa de uma grande multinacional a lançar seu sistema ERP global. No momento em que Coleby chegou, o projeto tinha mais de dois anos e estava consideravelmente acima do orçamento, em parte porque parte do hardware era realmente antigo.

"Um desses sistemas era tão antigo que tivemos que pedir emprestada uma fonte de alimentação de uma exposição no National Computer Museum, em Tóquio, diz ele. "Nós só tínhamos 8 horas por noite para atualizar o sistema ERP com novos dados, mas a interface levou 20 horas para ser executada, tornando-a essencialmente inútil."

As maiores barreiras não eram tecnológicas; eles eram pessoais e políticos. A Coleby teve que descobrir como fazer o sistema funcionar sem ninguém perder a cara.

"Não me foi permitido questionar a arquitetura, a estratégia ou a abordagem global da empresa para tecnologia", diz Coleby. "Acabei persuadindo os japoneses a mudar seus processos de negócios para que eles usassem menos informações. Cortei cerca de 90% dos dados para que o sistema pudesse funcionar em menos de 8 horas".

Lição aprendida: A tecnologia sozinha não é a resposta; pessoas e processos são essenciais, diz Coleby.

"No Laboratório de TI, sempre lidamos com organização, estrutura, processo e o lado de governança da TI, porque isso é sempre tão importante quanto a própria tecnologia."

falhaprojeto

5. Sob escopo e além do prometido
Seja pelo excesso de otimismo, o desejo de impressionar o chefe ou a falta de um escopo adequado dos projetos, subestimar o tempo e o esforço necessários para entregar um aplicativo pode transformar um projeto desafiador em um projeto infernal.

"Você vê as pessoas sendo muito otimistas sobre o que elas podem oferecer em um curto período de tempo, especialmente em empresas que se movem rapidamente", diz Alan Zucker, diretor fundador da Project Management Essentials.

No final dos anos 90, Zucker trabalhava como gerente de projetos no departamento de contabilidade de uma empresa de telecomunicações Fortune 100. A operadora faturava mais de US$ 1 bilhão por mês e usava centenas de planilhas e bancos de dados interligados para acompanhar tudo. A solução foi criar um único aplicativo para fechar os livros a cada mês, usando o Sybase no back-end com uma interface Power Builder.

Após uma reorganização da empresa, a responsabilidade pelo projeto recaiu sobre o grupo de Zucker.

"O grupo de TI criou uma ideia realmente elegante, que era carregar tudo em um banco de dados e permitir que as pessoas da contabilidade construíssem suas próprias regras de negócios", diz ele.

Mas eles prometeram entregar o aplicativo em nove meses. Quando Zucker herdou o projeto, quatro meses depois, nenhuma linha de código havia sido escrita. A TI ainda estava coletando os requisitos dos usuários. E eles estavam descobrindo que o trabalho era muito mais complicado do que imaginavam.

Foi quando começou o apontar de dados, diz Zucker.

“Minha contraparte na organização de TI começou a ficar muito ns defensiva”, diz ele. “Escrevia e-mails de páginas e páginas. Parecia estar em uma investigação policial. "Nesta data, neste momento, fulano de tal disse isso ..." e assim por diante. Me vi em uma situação belicosa, sem possibilidade de conversas construtivas.

Foi só depois que o gerente de TI foi transferido e Zucker conseguiu um novo parceiro e um cronograma mais generoso de que o projeto avançou. O aplicativo acabou sendo um sucesso, mas demorou mais dois anos para ser concluído.

Lições aprendidas: Zucker diz que percebeu que, no futuro, precisava se afastar do confronto e encontrar uma maneira de as duas partes sairem vencedoras. Ele também aprendeu que não há problema em pedir mais recursos e redefinir os termos originais do projeto. E, finalmente, foi uma lição de como mudar um único recurso - ou uma pessoa - pode melhorar totalmente a dinâmica da equipe.

6. Solicitações especiais do C-suite
Você pode querer ter o Android como padrão na sua organização, mas terá que tirar o iPhone das mãos do CEO.  Ou talvez um diretor com o ouvido do conselho solicite uma solução personalizada para seu departamento.

No cenário ideal, as solicitações do projeto são pontuadas em relação aos planos estratégicos e determinadas como necessárias para que a empresa atinja metas específicas antes de serem aprovadas e orçadas.

“Mas na maioria das organizações não é bem assim”, diz Meikle. “Muitas vezes é quem tem o maior entusiasmo político que faz as coisas.”

Mesmo as empresas mais disciplnadas podem ser vítimas dos caprichos daqueles que exercem mais influência, diz ele. Em muitos casos, isso acontece porque o CIO não tem o poder político para retroceder.

Lições aprendidas: Se você não tem um processo de registro de informações para projetos de TI, espere que as pessoas com mais influência passem por cima de suas prioridades, diz Meikle. Você precisa saber quem são seus principais interessados ​​em governança, risco e conformidade e certificar-se de que a TI tenha um lugar à mesa do comitê diretor.

"Você precisa do C-suite ao seu lado em seu campo para gerenciar efetivamente o fluxo de trabalho e o fluxo de projetos de TI", acrescenta. "Se não, você estará financiando cada capricho executivo de seu orçamento de TI enquanto seca seus recursos, deixando migalhas para projetos menos glamourosos, mas críticos, como infraestrutura e redes".



Reportagens mais lidas

Acesse a comunidade da CIO

LinkedIn
A partir da comunidade no LinkedIn, a CIO promove a troca de informações entre os líderes de TI. Acesse aqui