Gestão de Expectativas em Projetos Tecnológicos: é a Diferença que Conta, Não a Entrega
Um programa tecnológico é avaliado como uma empresa cotada em bolsa na época de resultados: pela diferença entre o resultado e a expectativa, não pelo resultado em si. A maioria dos business cases perde este exame antes de o trabalho começar.
Todas as épocas de resultados alguém pergunta porque caíram as ações de uma empresa depois de bons resultados, e todas as revisões de entrega encenam a mesma cena: o projeto foi lançado, a demonstração funcionou, o painel está verde e a sala está fria. Nenhuma das audiências está a ser irracional. Ambas estão a corrigir um exame diferente. O veredicto nunca incide sobre o resultado; incide sobre a diferença entre o resultado e a expectativa que alguém definiu antes. Gerir expectativas em projetos tecnológicos não é uma soft skill acoplada à entrega. É o denominador pelo qual toda a entrega é dividida, e a maioria dos programas deixa que seja definido pelo documento mais otimista que alguma vez vão produzir: o dossiê de financiamento.
Os mercados tornam o mecanismo fácil de ver porque o avaliam diariamente. Uma cotação é uma previsão, e à data dos resultados essa previsão já incorpora uma estimativa detalhada do anúncio, razão pela qual os resultados são avaliados face ao consenso e à guidance prospetiva do mercado, e não isoladamente: empresas com lucros a encolher sobem depois de superarem um patamar pessimista, e empresas com lucros a crescer caem depois de falharem um patamar otimista. Todas as épocas de resultados emparelham uma empresa lucrativa vendida em massa com uma empresa deficitária comprada, e todas as épocas os comentadores chamam-lhe sentimento de mercado. É aritmética. O número reportado é o numerador. O denominador foi fixado meses antes, por outra pessoa, e o movimento do preço é a divisão.
O seu programa também tem uma cotação. Só que é ilíquida, e transaciona-se em reuniões. A estimativa de consenso é o que quer que o comité de acompanhamento se lembre do business case. A guidance é o seu roteiro. A credibilidade é o múltiplo: quanto da sua próxima previsão é que alguém ainda está disposto a acreditar.
Porque é que projetos de TI bem-sucedidos ainda são lidos como falhanços?
Porque a expectativa foi emitida no momento de máxima ignorância e máxima capacidade de venda. Um business case é escrito antes de o trabalho começar, por pessoas que precisam de o ver aprovado, em competição com outros casos que também estão a ser empolados. O número vencedor é escolhido pela sua força persuasiva, não pela sua exatidão, e depois solidifica-se no consenso face ao qual a entrega será avaliada. Dezoito meses depois, uma equipa entrega uma migração de plataforma que funciona, num prazo defensável, e descobre que está a ser avaliada face à versão do projeto que só alguma vez existiu no dossiê de aprovação. Entregar uma melhoria de 3 por cento face a uma promessa de 5 é um falhanço, seja o que for que a retrospetiva diga.
Repare no que isto prevê: a organização de entrega com melhor nota não é a que mais entrega. É aquela cujas previsões iniciais foram mais honestas. Isto é incómodo, porque a maioria dos processos de financiamento pune ativamente previsões honestas. Se a sua governação só financia projetos que prometem retornos espetaculares, não subiu a fasquia. Garantiu que todos os projetos ou mentem no início ou falham no fim.
Quando se deve travar um programa tecnológico em falha?
Mais cedo do que vai querer, e de forma mais completa. Os conselhos de administração temem o momento da imparidade: a admissão formal de que a replataformização de dois anos não vai render o que o roteiro prometia. Mas a evidência de mercado sobre imparidades em empresas cotadas aponta na direção contrária. Estudos sobre anúncios de imparidade de goodwill encontram retornos anormais positivos nos seis e doze meses seguintes ao reconhecimento da perda, sendo que imparidades maiores são seguidas de retornos subsequentes maiores. A leitura que retiro desta evidência: uma perda que a audiência já suspeitava é barata de admitir, porque a admissão não cria a perda. Liberta a ambiguidade que estava a ser penalizada enquanto era negada.
A versão organizacional é exata. Quando a liderança debate travar um programa em falha, a organização já o imparizou, na prática: os engenheiros contornam-no, os patrocinadores deixam de aparecer nas reuniões, as equipas dependentes desacoplam discretamente os seus planos. O cancelamento formal apenas confirma uma avaliação a que o corredor já tinha chegado meses antes. O que custa de facto é a conta-gotas: trimestre atrás de trimestre de «amarelo, em recuperação» que mantém toda a gente a precificar a incerteza. Se eu estiver errado quanto a isto, isso deveria manifestar-se em organizações que preferem a hemorragia lenta e que retêm mais confiança e melhores pessoas do que organizações que admitem com clareza. Nunca vi esse caso.
A adoção por mandato é adoção real?
A armadilha mais silenciosa está dentro de números aparentemente bons. A receita pode crescer porque os clientes querem mais do produto, ou porque estão a pagar mais pela mesma coisa: o trabalho da McKinsey sobre gestão do crescimento de receita descreve empresas, em contexto de inflação, a sustentar as vendas líquidas através de subidas de preço acentuadas, mesmo com os volumes a estagnar ou a cair. As duas situações parecem idênticas na linha do topo e significam coisas opostas sobre o futuro.
Os programas tecnológicos produzem a mesma ilusão com a utilização. Um assistente de IA implementado por mandato vai mostrar curvas de adoção que qualquer gestor de produto invejaria, porque a alternativa era ser desligado. A utilização por decreto é prima do crescimento liderado pelo preço: o indicador sobe enquanto a verdade da procura fica escondida, e a verdade chega na altura da renovação, juntamente com a reposição das expectativas. Se quer saber se o seu programa de IA está a compor ou apenas a andar em ponto morto, não pergunte quantas pessoas o usaram. Pergunte o que fizeram quando tiveram escolha.
Como se gerem as expectativas num projeto tecnológico?
Como uma empresa cotada que pretende continuar cotada. Escreva a previsão antes de o trabalho começar: a versão específica, datada e refutável do que o investimento deve gerar, separada com clareza do objetivo ambicioso que usa para motivar a equipa. É praticamente o que avaliar a preparação para IA antes de construir significa na prática: estabelecer a estimativa de consenso enquanto ainda pode ser honesta. Depois trate o roteiro como guidance, porque é assim que os seus stakeholders já o tratam: reveja a previsão no momento em que ela se move, não na revisão em que o falhanço se torna inegável. E avalie a diferença depois, publicamente. Este hábito de previsões escritas e diferenças avaliadas é a disciplina que o nosso trabalho de estratégia tecnológica mais se esforça por deixar instalada num cliente, porque um resultado sem uma previsão é apenas um número, e ninguém aprende nada com um número isolado.
O que deixa a assimetria que ninguém precifica. Superar as expectativas compra-lhe uma boa reunião de acompanhamento. Falhar custa-lhe a reunião e algo mais lento de reconstruir: a disposição de qualquer pessoa na sala para aceitar a sua próxima previsão à letra. As expectativas são o único ativo sobre o qual um responsável de entrega tem controlo total de emissão, e o mais fiavelmente emitido em excesso. Guie por baixo, reporte com verdade, e deixe que a diferença faça o trabalho.
Perguntas frequentes
Porque caem as ações depois de bons resultados?
Porque os mercados avaliam os resultados face à previsão de consenso e à guidance prospetiva já incorporadas na cotação, e não isoladamente. Um crescimento de lucros abaixo do nível esperado transaciona como um falhanço, e uma revisão em baixa da guidance pode anular uma superação histórica. O mesmo mecanismo opera nas revisões de entrega: o business case fixa o consenso face ao qual um projeto é avaliado.
O que é uma diferença de expectativas na entrega de um projeto?
A diferença entre o que um programa tecnológico entrega e o que o seu business case aprovado, os seus planos e os seus relatórios de progresso levaram os stakeholders a esperar. Os veredictos seguem esta diferença e não a produção absoluta, razão pela qual um projeto empolado que é entregue com competência ainda pode ser avaliado como um falhanço.
Um business case de IA deve ser conservador ou ambicioso?
Separe as duas funções. Financie face a uma previsão conservadora e refutável com a qual estaria satisfeito por ser avaliado, e motive a equipa com um objetivo ambicioso que seja explicitamente diferente do número de financiamento. Fundir os dois significa que todas as revisões futuras serão avaliadas face ao seu dia mais otimista.
Relacionado
- O Seu Fornecedor de Cloud Está a Financiar a Própria Receita de IA. Faça as Contas Antes de Assinar
- O Anúncio Não É o Contrato: o Fosso Entre o Que a IA Promete e o Que Assina
- O Número Sem Meta: Como os Sensores de Glicose Estão a Transformar os Wearables em Máquinas de Ansiedade
- Data & Strategy
Escrito por uma persona editorial de IA do sistema editorial proprietário da Abyshire e revisto pela nossa equipa.