Quando o problema técnico não era apenas técnico

O contexto

O primeiro teste havia funcionado.

Uma solução de autenticação multifator estava sendo avaliada para uma operação de grande porte. O objetivo era reduzir riscos associados ao compartilhamento de credenciais e aumentar a segurança de acesso.

Em ambiente administrativo, o fluxo ocorreu como esperado: identificação, senha, biometria e integração com o diretório corporativo.

O próximo passo parecia natural: levar o piloto para algumas estações do ambiente operacional real.

Foi quando o comportamento mudou.

A mesma solução. A mesma integração principal. Outro ambiente.

O desafio

A hipótese mais provável era a existência de alguma política adicional de segurança aplicada à operação.

Tecnicamente, isso não tornava a solução necessariamente inviável. O middleware podia ser adaptado, e customizações semelhantes já haviam sido realizadas anteriormente.

O problema era outro: ninguém conseguia afirmar com segurança qual regra estava produzindo o conflito.

A equipe do cliente não podia simplesmente abrir todas as políticas de segurança para análise externa. O fornecedor, por outro lado, não queria mobilizar engenharia internacional com base apenas em hipóteses.

Cada novo teste também exigia preparação operacional, autorização, máquinas, acessos e coordenação com diferentes áreas.

A pergunta começava a mudar: o que precisa ser alterado tecnicamente — e temos as pessoas e autoridades certas dentro deste projeto?

O que aconteceu

A escalada aconteceu.

Especialistas técnicos foram envolvidos, hipóteses foram levantadas e a liderança técnica do fornecedor validou que o diagnóstico realizado até então era defensável.

Mas, em uma reunião posterior com níveis hierárquicos mais altos, apareceu uma informação decisiva:

Uma função crítica de Segurança da Informação não havia sido adequadamente incorporada ao projeto.

Até aquele momento, diferentes participantes pareciam acreditar legitimamente que o piloto possuía as aprovações necessárias.

O problema, portanto, não era simplesmente alguém ter “ignorado” um stakeholder. O próprio desenho de governança havia produzido uma percepção incompleta de autorização.

Quando a autoridade de segurança entrou efetivamente na discussão, o projeto foi encerrado antes que a hipótese técnica pudesse ser validada até o fim.

A solução podia continuar sendo tecnicamente recuperável. O projeto, entretanto, havia se tornado organizacionalmente irrecuperável.

Aprendizados de gestão

Patrocínio executivo não é autorização

Um executivo poderoso pode abrir portas, patrocinar um projeto e acelerar decisões. Isso não significa que ele detenha autoridade sobre todos os domínios envolvidos.

Segurança, Compliance, Dados, Tecnologia e outras funções podem possuir poderes próprios de aprovação ou veto.

Stakeholder mapping deveria começar menos por “quem são as pessoas?” e mais por “quais domínios de autoridade este projeto atravessa?”

A incerteza também precisa ser governada

Quando algo inesperado ocorre, organizações podem transformar rapidamente incerteza sobre o sistema em julgamento sobre pessoas.

Problemas complexos exigem preservar a investigação tempo suficiente para separar falha individual, restrição ambiental, problema de produto e problema de governança.

Uma solução existe dentro de duas arquiteturas

Todo projeto possui uma arquitetura técnica. Mas também possui uma arquitetura de autoridade. Ignorar qualquer uma delas pode inviabilizar a implementação.

Uma solução não é implementada apenas dentro de uma arquitetura tecnológica. Ela é implementada dentro de uma arquitetura de autoridade.

PARA LEVAR PARA SUA OPERAÇÃO

Quando um projeto começa a exigir cada vez mais escaladas, quem ainda não está na sala — e deveria estar?