SBInet: Responsabilidade na Aquisição da Cerca Virtual

Resumo

A Secure Border Initiative Network, ou SBInet, foi o componente tecnológico de um programa de fronteira mais amplo do Departamento de Segurança Interna (DHS) anunciado em 2005. A Alfândega e Proteção de Fronteiras (CBP) pretendia integrar torres, radares, câmeras, sensores terrestres não tripulados, comunicações e software de comando em uma visão operacional comum para o pessoal da Patrulha de Fronteira.
Em setembro de 2006, o CBP selecionou a Boeing como integradora principal de sistemas. A aquisição dependia de um escritório de programa governamental que pudesse definir necessidades operacionais, controlar requisitos, verificar o progresso do contratante e decidir quando um sistema integrado estava pronto para uso em campo e expansão.
O Projeto 28, um protótipo de aproximadamente US$ 20,6 milhões cobrindo 28 milhas no setor de Tucson, Arizona, expôs a diferença entre equipamento entregue e capacidade comprovada. O governo o aceitou em fevereiro de 2008, oito meses atrasado, após problemas de integração e ações corretivas. Autoridades e agentes relataram benefícios limitados, bem como soluções alternativas operacionais contínuas.
O Government Accountability Office (GAO) e o Escritório do Inspetor Geral do DHS repetidamente encontraram fraquezas nos requisitos, testes, linhas de base de custo e cronograma, gerenciamento de riscos, supervisão do contratante e pessoal governamental. Não se tratavam de defeitos administrativos separados. Juntos, enfraqueceram as evidências necessárias para conectar a atividade de aquisição ao valor operacional.
Em 2010, o primeiro bloco proposto do SBInet havia reduzido o escopo geográfico e as expectativas de desempenho, enquanto seu cronograma e valor do ciclo de vida permaneciam incertos. O GAO relatou que o programa não tinha um cronograma mestre integrado confiável, uma estimativa confiável de custo do ciclo de vida e uma relação demonstrada entre benefícios e custos esperados.
Em janeiro de 2011, o DHS encerrou o SBInet como originalmente concebido e avançou para um plano de tecnologia adaptado ao terreno e às necessidades operacionais. A decisão não significou que toda a tecnologia de vigilância de fronteira era inútil, nem apagou a capacidade limitada já implantada ao longo de 53 milhas no Arizona.
A lição de responsabilidade do SBInet é que uma parede de sensores não é capacidade pública até que detecção, classificação, comunicações, resposta do operador, manutenção e custo possam ser demonstrados juntos. O controle prático pertence às instituições que podem exigir essa prova, interromper a expansão quando ela estiver ausente e preservar as evidências por trás de ambas as decisões.

Uma Tela de Vigilância Pode Esconder a Parte Mais Difícil

A imagem no centro de uma cerca virtual é enganosamente simples. Um radar detecta movimento. Uma câmera se volta para um alvo. O software coloca um ícone em um mapa. Um operador vê o evento e envia um agente. Comparado com a construção de uma barreira física em terreno difícil, a tela pode parecer uma resposta flexível e quase automática.

Mas a tela é a última camada visível de um sistema muito maior. Um radar tem que distinguir movimento relevante de animais, clima e ruído. Uma câmera tem que fornecer imagens utilizáveis na distância e nas condições de iluminação prometidas. Torres precisam de energia, comunicações e manutenção. O software deve combinar observações sem criar atraso ou confusão intoleráveis. O mapa deve refletir as posições com precisão. Os agentes precisam de acesso à informação, confiança nela e procedimentos para decidir qual resposta é apropriada.

O SBInet tentou transformar essas dependências em uma plataforma de vigilância de fronteira. O programa não estava apenas comprando câmeras ou instalando torres. Estava adquirindo uma reivindicação operacional integrada: que sensores, comunicações, software e fluxos de trabalho da Patrulha de Fronteira criariam melhor consciência situacional em grandes áreas.

Essa afirmação só poderia ser verdade através de evidências. A entrega de hardware era evidência de entrega de hardware. Uma compilação de software concluída era evidência de que o código existia. Um marco do contratante mostrava que um evento contratual havia ocorrido. Nenhum desses fatos sozinho provava que o sistema poderia detectar, identificar e classificar um item de interesse em terreno real, comunicar a observação, ajudar um operador a tomar uma decisão e permanecer disponível por tempo suficiente para ser útil.

Essa distinção explica por que o SBInet pertence a uma série sobre risco e responsabilidade. A falha central não foi que todos os dispositivos falharam ou que nenhum agente recebeu qualquer benefício. Foi que a ambição do programa repetidamente superou a capacidade do governo de produzir evidências confiáveis e prontas para decisão sobre desempenho integrado, custo, cronograma e prontidão para escalar.

SBInet Começou como uma Promessa de Integração de Sistemas

O DHS estabeleceu a Secure Border Initiative mais ampla em novembro de 2005. O SBInet era o esforço tecnológico dentro dessa iniciativa, gerenciado através da Alfândega e Proteção de Fronteiras. De acordo com o GAO, a solução pretendida incluía sensores, comunicações, tecnologia da informação, infraestrutura tática e capacidades de comando e controle. Também visava desenvolver uma visão operacional comum que pudesse fornecer dados uniformes nos centros de comando e apoiar a interoperabilidade com organizações fora do DHS.

Essa descrição é importante porque define a unidade de responsabilidade. Se a necessidade pública fosse apenas um radar, o governo poderia julgar se o radar atendia às suas especificações. A unidade do SBInet era o sistema: uma mistura de pessoal, resposta rápida, infraestrutura e tecnologia destinados a apoiar o controle operacional.

Em setembro de 2006, o CBP concedeu à Boeing um contrato de integração principal de sistemas de entrega indefinida e quantidade indefinida. O contrato tinha um período base de três anos e três opções de um ano. Ordens de tarefa financiariam trabalhos específicos, incluindo gerenciamento de programa, implantação de protótipo, software de visão operacional comum, manutenção e atividades de implantação posteriores.

Usar um integrador principal pode ser razoável para um sistema complexo. Um contratante pode coordenar interfaces entre muitos fornecedores e componentes. O acordo não transfere a responsabilidade pública. O governo ainda tem que definir resultados da missão, reter conhecimento técnico, controlar requisitos, avaliar informações de custo e cronograma, supervisionar o trabalho do subcontratado e decidir se o sistema entregue é aceitável.

Registros de supervisão precoce mostram o quão exigente era esse papel. Em fevereiro de 2007, o GAO disse que o plano de gastos do ano fiscal de 2007 satisfazia quatro condições legislativas, satisfazia parcialmente quatro e não satisfazia uma. O plano continha informações amplas de custo e marco, mas faltava detalhes suficientes para apoiar medição e responsabilidade. Não conectava adequadamente atividades individuais a objetivos estratégicos, e processos-chave de gerenciamento de aquisição não foram totalmente definidos e implementados.

O problema, portanto, era visível antes da implantação nacional. O SBInet estava tentando uma aquisição concorrente e multifacetada enquanto a maquinaria de planejamento, requisitos, risco e controle de desempenho do governo ainda estava sendo construída.

Uma Estimativa de US$ 7,6 Bilhões Ainda Não Era um Mapa Confiável

O registro de gastos de 2007 ilustra a diferença entre um número grande e uma linha de base confiável. O DHS estimou que concluir a fase de aquisição para a fronteira sudoeste custaria US$ 7,6 bilhões para os anos fiscais de 2007 a 2011. Discutiu aproximadamente US$ 790 milhões para o setor de Tucson e US$ 260 milhões para o setor de Yuma.

O GAO não tratou esses números como autovalidados. O plano carecia de detalhes suficientes sobre atividades, marcos e custos. Não especificava como a alocação de Tucson seria dividida entre cercas, sensores terrestres, radares, câmeras, torres fixas e torres móveis. Não fornecia datas específicas de implementação para esses elementos e omitia atividades e custos correspondentes da fronteira norte.

Uma linha de base deve permitir que alguém fora da equipe do projeto pergunte se a realidade está se movendo conforme prometido. Qual capacidade é financiada? Quando é devida? Qual dependência poderia mover a data? Qual é o custo da força de trabalho governamental e do contratante? Qual resultado demonstrará que o gasto melhorou a missão?

Sem esses vínculos, um programa pode relatar que o dinheiro foi alocado e as tarefas estavam ativas, deixando o tomador de decisão incapaz de julgar se a capacidade útil está se aproximando. O plano se torna um relato de atividade, não um instrumento de controle.

O GAO também questionou o máximo declarado do contrato. O DHS considerou "6.000 milhas de fronteira segura dos EUA" como uma quantidade máxima adequada para o veículo de quantidade indefinida. O GAO argumentou que isso era um resultado, não um limite calculável sobre suprimentos, serviços ou dólares. O desacordo expôs uma questão mais ampla de responsabilidade: uma aspiração não é um teto de aquisição mensurável.

O relatório recomendou compromissos explícitos e mensuráveis para capacidades, cronogramas, custos e benefícios; um limite de contrato expresso em unidades ou dólares; e reconsideração da concorrência. O DHS concordou com a primeira e terceira recomendações, mas discordou sobre o máximo do contrato. Qualquer que fosse a interpretação legal, o ponto operacional permaneceu: o governo precisava de uma descrição limitada e testável do que estava comprando.

O Projeto 28 Tornou a Falha de Integração Visível

O Projeto 28 foi o primeiro teste vívido do conceito de cerca virtual. A ordem de tarefa cobria 28 milhas no setor de Tucson e foi avaliada em cerca de US$ 20,6 milhões. Seu objetivo era fornecer capacidades de detecção, identificação e classificação usando radares, câmeras, sensores, computadores, comunicações e software de visão operacional comum.

Os componentes foram implantados, mas o sistema não se tornou operacional no cronograma original. O GAO relatou problemas de integração de software, incluindo atrasos na exibição de informações de radar nos centros de comando. Os requisitos não haviam sido adequadamente definidos e os usuários não haviam sido suficientemente envolvidos em seu desenvolvimento. O hardware podia estar presente no deserto enquanto a cadeia operacional permanecia incompleta.

Em agosto de 2007, o CBP disse à Boeing que não aceitaria o projeto até que problemas especificados fossem corrigidos. A Boeing submeteu planos de ação corretiva. O DHS aceitou condicionalmente o Projeto 28 em dezembro de 2007 e exigiu análise adicional da qualidade do vídeo, dados de radar e temporização dos componentes. A aceitação final ocorreu em 22 de fevereiro de 2008, oito meses após a data planejada.

A aceitação final não significou que o sistema correspondia a todas as expectativas operacionais. O GAO registrou que os funcionários do programa consideraram os requisitos contratuais atendidos, mas também disseram que o Projeto 28 não havia atendido totalmente às suas expectativas. A Patrulha de Fronteira relatou limitações contínuas, incluindo resolução de imagem da câmera em distâncias maiores. Testes operacionais futuros deveriam informar o desenvolvimento posterior, em vez de reformar substancialmente o protótipo aceito.

Esses fatos não devem ser resumidos na afirmação de que o Projeto 28 não entregou nada. Ele operou ao longo da área de 28 milhas. Agentes disseram posteriormente ao GAO que melhorou algumas capacidades operacionais. As evidências também mostraram soluções alternativas envolvendo intensidade do sinal sem fio, controle remoto da câmera e sensibilidade do radar.

A questão da responsabilidade é mais nítida do que sucesso ou fracasso como slogan. O que a aceitação certificou? Se a aceitação contratual significava que um conjunto definido de entregas havia sido fornecido, os tomadores de decisão ainda precisavam de evidências separadas sobre adequação operacional, necessidades do usuário, mantenabilidade e prontidão para replicação. Um evento de aceitação assinado poderia encerrar uma obrigação enquanto deixava a decisão de expansão não resolvida.

Aceitação e Valor Operacional São Portões Diferentes

As aquisições públicas frequentemente usam a palavra "aceitação" como se fosse um veredito universal. Na prática, vários portões podem carregar esse rótulo. Um governo pode aceitar a entrega porque um contratante satisfez critérios negociados. Uma organização de teste pode descobrir que um sistema concluiu um evento planejado. Uma unidade operacional pode decidir que o sistema é útil sob condições especificadas. Um departamento pode determinar que a capacidade é custo-efetiva o suficiente para expandir.

O SBInet precisava que esses julgamentos permanecessem distintos. O Projeto 28 mostrou por quê. Sua aceitação final refletiu uma relação contratual após ação corretiva. Não estabeleceu que o protótipo era o design correto para toda a fronteira sudoeste, que todas as preocupações de campo haviam sido resolvidas ou que a mesma arquitetura seria econômica em terrenos diferentes.

O programa também planejou gerações posteriores de tecnologia que substituiriam grande parte do equipamento do Projeto 28. Isso tornou o protótipo uma fonte de lições, bem como capacidade limitada. Mas as lições aprendidas são valiosas apenas quando são capturadas em requisitos, planos de teste, controles de interface, estimativas de custo e decisões de implantação.

Uma aquisição fraca trata um protótipo como uma demonstração de que o momentum deve continuar. Uma aquisição controlada pergunta quais suposições o protótipo refutou. Os componentes comerciais eram maduros o suficiente? O software poderia processar dados de sensores em velocidade operacional? A cobertura de comunicações correspondia ao conceito? As interfaces do operador eram utilizáveis? Quantos defeitos apareceram sob cargas de trabalho realistas? Qual ônus de manutenção a experiência de campo revelou?

O governo também deve se proteger contra critérios móveis. Se os testes de aceitação são revisados principalmente para se adequar ao desempenho atual do sistema, o teste deixa de representar a necessidade original da missão. Por outro lado, recusar qualquer mudança seria igualmente insensato se os requisitos originais fossem inacessíveis, não verificáveis ou não relacionados às operações de campo.

O controle é a rastreabilidade. Cada critério alterado deve mostrar a justificativa da missão, evidência técnica, efeito no custo e cronograma, autoridade de aprovação e efeito nos resultados do usuário. Sem esse registro, os líderes do programa não podem distinguir adaptação disciplinada da redefinição gradual do sucesso.

Requisitos Eram a Arquitetura da Responsabilidade

Os requisitos podem parecer papelada técnica, mas no SBInet eles alocavam responsabilidade. Os requisitos operacionais descreviam o que a Patrulha de Fronteira precisava realizar. Os requisitos do sistema traduziam essas necessidades em características de desempenho e funcionais. Os requisitos de componente abordavam câmeras, radares, comunicações e outros elementos. Os requisitos de software e design governavam como esses elementos interagiriam.

O GAO descobriu que o programa havia definido um processo de desenvolvimento e gerenciamento de requisitos, mas não o implementou consistentemente. Uma revisão independente do DHS descobriu que alguns requisitos operacionais eram inacessíveis e não verificáveis. Como os requisitos de nível inferior foram derivados dessas declarações operacionais, a incerteza no topo poderia se propagar através do design do sistema, casos de teste e trabalho do contratante.

O GAO recomendou estabelecer uma linha de base de requisitos antes do design e desenvolvimento, analisá-los quanto à completude, atingibilidade e verificabilidade, e rastreá-los para cima até as necessidades da missão e para baixo até componentes e testes. Estes não são passos cerimoniais. Eles criam uma cadeia de custódia para a afirmação de capacidade.

Considere um requisito de câmera. Uma especificação para alcance óptico é incompleta sem suposições sobre terreno, atmosfera, tamanho do alvo, iluminação, estabilização e como um operador usará a imagem. Uma probabilidade de detecção é incompleta sem definir o conjunto de alvos relevante, condições de teste e carga de falsos alarmes. Um requisito de comunicação é incompleto se ignora onde os veículos viajam e quanto tempo leva para fazer login ou reconectar.

Os usuários de campo são essenciais porque sabem onde o desempenho abstrato encontra o atrito operacional. Eles não devem ser perguntados apenas se uma tela finalizada parece útil. Eles precisam de influência estruturada antes que as decisões de design se solidifiquem: cenários, missões prioritárias, atrasos aceitáveis, carga de trabalho, condições ambientais e quais informações suportam uma decisão de resposta.

Os requisitos, portanto, formam uma arquitetura de responsabilidade pública. Eles declaram o que a agência considera necessário, o que o contratante deve entregar, o que os testadores devem provar e o que os líderes estão autorizando quando aprovam uma mudança. Quando essa arquitetura é instável, toda medida posterior - cronograma, custo, fechamento de defeitos e aceitação - se torna mais difícil de interpretar.

Testes Tinham que Provar Toda a Cadeia

A abordagem de teste do SBInet contemplava várias camadas. A qualificação de componente poderia mostrar se o equipamento individual atendia às características especificadas. O teste de integração poderia demonstrar interfaces e interoperabilidade. A qualificação do sistema poderia testar o design montado. O teste de aceitação do sistema poderia apoiar a decisão contratual do governo. O teste e avaliação operacionais poderiam examinar eficácia e adequação no ambiente onde a Patrulha de Fronteira usaria o sistema.

O GAO descobriu que o teste não estava sendo gerenciado de forma eficaz. O programa começou a integrar componentes antes de testar individualmente os componentes reais destinados aos locais de implantação inicial. Uma estratégia de gerenciamento de testes foi elaborada, mas não finalizada e aprovada. Faltava uma definição clara de papéis, um cronograma mestre de alto nível e detalhes suficientes sobre marcos e métricas para orientar os testes do projeto.

A ordem importa. Se um componente instável entra na integração, os engenheiros podem gastar tempo diagnosticando o comportamento do sistema que se origina em uma parte não qualificada. Se as interfaces não são controladas, um teste de componente bem-sucedido diz pouco sobre o sistema combinado. Se os usuários operacionais chegam apenas depois que os critérios de aceitação são fixados, o programa pode provar o desempenho errado.

O GAO posteriormente relatou aproximadamente 1.300 defeitos encontrados entre março de 2008 e julho de 2009. Novos defeitos geralmente apareciam mais rápido do que eram resolvidos, e muitos careciam de prioridade de resolução. A contagem sozinha não prova que todo defeito era grave. A tendência e a triagem incompleta minaram a confiança de que o sistema estava amadurecendo em direção à implantação.

O registro oficial também descreveu preocupações de que algumas alterações nos casos e procedimentos de teste pareciam orientadas para passar no teste, em vez de qualificar o sistema. Esse é um limite crítico de governança. Um programa deve atualizar um teste quando as evidências mostram que o teste é inválido, redundante ou desconectado das necessidades da missão. Não deve reduzir o ônus da evidência meramente porque o design atual não pode passar.

O teste é onde as promessas públicas se tornam falseáveis. O controle mais forte teria conectado cada requisito operacional a um caso de teste, condição de teste, resultado medido, registro de defeito, disposição e autoridade de aprovação. Esse registro teria tornado possível ver não apenas se um evento passou, mas o que a aprovação realmente provava.

O Campo Relatou Benefícios e Soluções Alternativas ao Mesmo Tempo

A história do SBInet é distorcida se o uso limitado for apagado. Em 2008 e 2009, agentes da Patrulha de Fronteira no setor de Tucson disseram ao GAO que o Projeto 28 havia melhorado aspectos de sua capacidade operacional. O sistema estava em uso enquanto o programa aguardava implantações posteriores do SBInet.

Os agentes também descreveram soluções alternativas persistentes. Eles tinham problemas para encontrar intensidade de sinal sem fio confiável, controlar câmeras remotamente e ajustar a sensibilidade do radar. O GAO observou uso limitado de terminais de dados móveis instalados em veículos. Dependendo da intensidade do sinal, o login podia demorar muito e as conexões podiam ser perdidas repetidamente durante um turno. Os operadores na visão operacional comum às vezes retransmitiam informações.

Essa evidência mista é mais útil do que um veredito binário. Um sistema pode fornecer valor local enquanto permanece inadequado como modelo para uma expansão nacional. Pode ajudar um fluxo de trabalho e sobrecarregar outro. Pode ter desempenho sob algumas condições ambientais e degradar sob outras.

O feedback operacional deve ser estruturado em torno dessa variação. Quais funções foram usadas? Com que frequência? Sob quais condições? O que os agentes fizeram quando a tecnologia estava indisponível? O sistema reduziu ou aumentou a carga de trabalho do operador? Os alertas eram confiáveis? Com que rapidez os mantenedores podiam restaurar equipamentos com falha? Uma solução alternativa preservou a missão, e a que custo de pessoal?

A tentação em um programa problemático é usar qualquer declaração de campo positiva como prova de que a expansão é justificada, ou qualquer reclamação como prova de que o sistema é inútil. Nenhuma inferência é responsável. A evidência de campo deve estar ligada a benefícios definidos da missão e comparada com custo, alternativas e desempenho do equipamento existente.

A experiência do SBInet sugere um padrão em etapas. A implantação limitada pode ser valiosa como descoberta. A expansão deve exigir evidências mais fortes: desempenho repetível em terrenos representativos, tendências controladas de defeitos, comunicações utilizáveis, capacidade de manutenção, operadores treinados e um benefício quantificado em relação aos sistemas que substituiria ou complementaria.

Concorrência Transformou Incógnitas em Compromissos de Cronograma

Os primeiros planos do SBInet usavam ordens de tarefa concorrentes e atividades relacionadas. A concorrência pode acelerar a entrega quando as interfaces são estáveis e os riscos são compreendidos. Também pode multiplicar retrabalho quando requisitos, designs e testes ainda estão mudando.

O GAO alertou em 2007 que o programa não havia fornecido evidências mostrando que havia identificado dependências entre atividades concorrentes e estava gerenciando proativamente o risco associado. Ao mesmo tempo, o escritório do programa disse que a implementação acelerada havia priorizado sobre a definição e implementação completas de alguns processos de gerenciamento de aquisição.

Essa troca é comum em programas públicos urgentes. Os líderes temem que o processo atrase a capacidade. No entanto, um requisito, revisão de interface ou plano de teste não é valioso porque atrasa o trabalho. É valioso se impede a organização de escalar uma suposição não comprovada.

O Projeto 28 tornou a cadeia de dependências concreta. A integração de software atrasou o protótipo. As lições do protótipo deveriam informar blocos posteriores. Mas o trabalho em requisitos, designs, torres e sistemas de comando posteriores não poderia simplesmente pausar sem consequências de cronograma. Quanto mais trabalho prosseguisse antes que a lição estivesse estável, mais cara a correção poderia se tornar.

Um registro de concorrência teria tornado o risco visível. Para cada atividade autorizada antes que a evidência precursora estivesse completa, o programa poderia registrar a evidência ausente, a razão para prosseguir, a exposição máxima, um plano de reversão e a data da decisão. Os líderes saberiam então se a aceleração era um risco limitado ou um acúmulo de compromissos irreversíveis.

A questão não era a urgência em si. A segurança da fronteira era uma prioridade declarada, e o equipamento legado tinha limitações. A questão era se a urgência mudava o padrão de evidência ou meramente a velocidade na qual a evidência tinha que ser produzida. Se o padrão cai, o programa pode parecer mais rápido até que a integração e o retrabalho consumam o tempo economizado.

A Escala Encolheu Enquanto a Alegação do Programa Permaneceu Grande

O SBInet foi descrito como uma solução abrangente de fronteira, mas sua implantação planejada mudou repetidamente. Em 2009, o GAO documentou anos de atraso e um escopo de curto prazo reduzido. O Projeto 28 cobria 28 milhas. As implantações planejadas do Bloco 1 em Tucson-1 e Ajo-1 juntas cobriam cerca de 53 milhas.

Planos anteriores haviam contemplado implantação inicial nos setores de Tucson, Yuma e El Paso, cerca de 655 milhas. Uma linha de base posterior reduziu esse escopo inicial para Tucson e Yuma, cerca de 387 milhas. Os planos para incrementos subsequentes permaneceram incertos.

A redução de escopo pode ser prudente. Um programa não deve manter uma pegada irrealista apenas para preservar uma promessa antiga. Mas a responsabilidade exige que a alegação de custo, cronograma e benefício mude com o escopo.

Em 2010, o GAO descreveu o primeiro bloco como custando cerca de US$ 1,3 bilhão. Descobriu que as capacidades planejadas continuavam a diminuir. Os limites de desempenho foram relaxados. Os limites de detecção e identificação que antes haviam sido definidos em 95% foram reduzidos para 70%, enquanto o limite de disponibilidade operacional passou de 95% para 85%.

O GAO observou que a definição resultante poderia permitir desempenho agregado aceitável mesmo que categorias de identificação específicas tivessem desempenho abaixo de 50%. O significado operacional exato dependia de como as medidas eram construídas e aplicadas, mas o ponto de governança é claro: um limite de desempenho é uma declaração sobre o que a agência está preparada para chamar de aceitável.

Alterar um limite pode ser justificado pela realidade técnica, custo ou uma melhor compreensão da missão. O registro da decisão deve explicar qual necessidade do usuário permanece satisfeita, qual risco é aceito e se a estimativa de benefício ainda é válida. Caso contrário, o programa pode preservar o rótulo "Bloco 1" enquanto entrega uma promessa materialmente diferente.

Controles de Custo e Cronograma Não Produziram Previsão Confiável

Em 2010, tanto o GAO quanto o OIG do DHS estavam questionando os controles por trás das alegações de custo e cronograma do SBInet. O GAO avaliou o cronograma mestre integrado de agosto de 2009 em relação a nove práticas reconhecidas e encontrou conformidade substancial com apenas duas. O cronograma não capturava adequadamente todas as atividades, alocava recursos, identificava um caminho crítico, contabilizava folga razoável ou analisava o risco do cronograma.

Um cronograma não é confiável porque contém muitas datas. É confiável quando as dependências estão logicamente conectadas e os tomadores de decisão podem ver qual trabalho controla a data de conclusão. Se um atraso na qualificação do radar afeta integração, prontidão de teste, implantação e treinamento do operador, essa relação deve ser visível. Sem ela, uma data de conclusão relatada é uma agregação de desejos.

O GAO também descobriu que a estimativa de custo do ciclo de vida do Bloco 1 não atendia suficientemente às características de uma estimativa confiável: abrangente, bem documentada, precisa e credível. Exclusões e suposições limitavam sua utilidade. A estimativa omitia ou não tratava adequadamente o esforço governamental, algumas operações e manutenção, custos de sistemas legados, software, suporte ao programa e evolução futura de blocos. Riscos associados à maturidade de componentes comerciais não foram totalmente refletidos.

O OIG do DHS encontrou problemas de controle relacionados. As informações atuais da linha de base nem sempre eram inseridas no sistema de gerenciamento de valor agregado, reduzindo sua capacidade de alertar sobre variação de custo e cronograma. O escritório do programa operou sem um cronograma mestre integrado aprovado durante parte da revisão, e a equipe de supervisão de custo e cronograma era escassa.

Essas descobertas não foram previsões de que cada dólar seria desperdiçado. Elas mostraram que os líderes careciam de previsão confiável. Os controles de custo e cronograma devem revelar divergência cedo o suficiente para mudar de curso. Quando as linhas de base são atrasadas, incompletas ou instáveis, a gerência fica sabendo do problema depois que os compromissos já reduziram as opções.

A Supervisão do Contratante Exigia Autoridade Técnica do Governo

O SBInet dependia fortemente de contratantes, desde o integrador principal de sistemas até o pessoal de apoio dentro da organização do programa. Os contratantes trouxeram habilidades de engenharia, integração e gerenciamento. Eles também criaram um problema de controle se o pessoal do governo não tivesse capacidade para desafiar suposições, avaliar entregas ou distinguir apoio contratado de decisões inerentemente governamentais.

O aviso de risco do OIG do DHS de 2006 disse que o departamento não tinha capacidade suficiente para planejar, supervisionar e executar o SBInet, administrar contratos e controlar custo e cronograma. Nessa fase, uma grande parte das posições planejadas era de contratantes. O relatório alertou que os requisitos operacionais haviam sido adiados até depois da seleção do integrador e recomendou planos para construir capacidade de gerenciamento e estabilizar requisitos.

Um relatório do OIG de 2009 descobriu que contratantes de apoio realizaram ou se aproximaram de atividades que deveriam permanecer sob controle governamental mais forte. Recomendou distinguir papéis de contratantes e federais e atribuir mais representantes técnicos do oficial de contratação para supervisionar o desempenho.

A preocupação não é que os contratantes sejam inerentemente não confiáveis. Um contratante principal é responsável perante os incentivos, escopo e critérios de aceitação do contrato. Apenas a agência pública pode reconciliar esses incentivos com o valor da missão, escolhas políticas e a gestão dos fundos apropriados.

A autoridade técnica do governo deve ser prática, não cerimonial. O pessoal precisa de acesso a dados de origem, linhas de base de requisitos, inventários de defeitos, procedimentos de teste, lógica de cronograma e suposições de custo. Precisa de tempo para revisar entregas atrasadas antes de um marco. Precisa do poder de rejeitar evidências que não atendem ao padrão.

O SBInet também ilustra por que apenas o número de funcionários é insuficiente. O programa precisava de engenheiros de sistemas, gerentes de teste, analistas de custo, analistas de cronograma, especialistas em contratação e representantes operacionais com direitos de decisão claramente atribuídos. Se a instituição não pode dizer quem possui uma interface, uma alteração de limite ou uma renúncia de aceitação, o integrador pode se tornar o autor de fato da evidência pública.

A Governança de Marcos Precisava de Evidências de Entrada e Saída

O relatório de custo e cronograma de 2010 do OIG do DHS focou em uma questão aparentemente processual com grandes consequências: se os eventos do programa tinham critérios de entrada e saída documentados e se o governo mostrou por que aceitou as evidências.

As principais revisões devem reduzir a incerteza. Uma revisão de requisitos deve mostrar que as necessidades são compreendidas e rastreáveis. Uma revisão de design deve mostrar que a solução é madura o suficiente para construção ou codificação. Uma revisão de prontidão de teste deve mostrar que procedimentos, configurações e ambientes podem produzir resultados válidos. Uma revisão de prontidão operacional deve mostrar que as partes interessadas concordam que o sistema pode entrar em serviço sob condições definidas.

Se o evento ocorre porque o calendário diz que deve, a revisão se torna teatro. Se os critérios são incompletos, as questões não resolvidas devem ser registradas com proprietários, prazos e decisões de risco. Se os líderes prosseguem condicionalmente, a condição deve restringir qual trabalho pode começar.

O OIG recomendou que o programa documentasse a revisão e aceitação governamental das realizações e critérios do evento, garantisse que as condições de entrada e saída fossem satisfeitas, abordasse questões abertas e atualizasse as avaliações de risco antes de eventos subsequentes. O CBP concordou, embora tenha contestado partes da caracterização do OIG sobre decisões específicas de implantação.

Esse desacordo em si demonstra o valor de um registro de evidências durável. Auditores e gerentes podem interpretar o risco de maneira diferente. Um pacote de decisão completo deve permitir que um leitor posterior veja os critérios, as evidências, os itens não resolvidos, a justificativa para prosseguir e os limites colocados na próxima fase.

Para um programa de tecnologia pública, a governança de marcos protege mais do que o cronograma. Preserva a base para a responsabilidade após mudanças de liderança, rotatividade de contratos e pressão política. Diz às equipes futuras se um sistema avançou porque estava pronto, porque o risco foi conscientemente limitado ou porque o momentum superou os controles.

A Avaliação de 2010 Mudou a Pergunta da Decisão

Em janeiro de 2010, o Secretário de Segurança Interna iniciou uma avaliação departamental do SBInet. A questão não era mais simplesmente como recuperar o cronograma atual. O DHS examinou se a abordagem era a estratégia de tecnologia de segurança de fronteira mais eficiente, eficaz e econômica.

O relatório de maio de 2010 do GAO aguçou essa questão. Descobriu escopo reduzido, cronograma não confiável, estimativa de custo do ciclo de vida não confiável, benefícios esperados não identificados e implementação inconsistente de processos de gerenciamento do ciclo de vida. O GAO recomendou limitar investimentos adicionais além dos dois locais de implantação atuais até que o DHS tivesse uma base analítica defensável.

Este é um importante pivô de responsabilidade. Os programas frequentemente respondem a dificuldades produzindo uma nova data, um novo nome de bloco ou um limite de desempenho revisado. Essas ações assumem que o conceito subjacente permanece justificado. A avaliação de 2010 reabriu o próprio conceito.

Uma decisão de alternativas precisa de uma comparação comum. Qual problema de missão deve ser resolvido em cada região? Quais sistemas existentes contribuem? Quais condições de terreno e população importam? Quais tecnologias comerciais são maduras? Quais são os custos do ciclo de vida, incluindo pessoal governamental e manutenção? Com que rapidez cada opção pode produzir benefícios mensuráveis?

A análise também precisava evitar uma falsa escolha entre SBInet e nenhuma tecnologia. O DHS poderia encerrar a arquitetura única enquanto continuava a usar câmeras, sistemas móveis, imagens térmicas, aeronaves não tripuladas e outras ferramentas de vigilância. A decisão era sobre o modelo de aquisição e design integrado, não sobre a existência de uma missão de fronteira.

Ao reformular a questão, a avaliação reconheceu que a disciplina de recuperação às vezes significa parar. O cancelamento não é automaticamente prova de boa governança; pode chegar tarde e deixar custo irrecuperável. Mas continuar um programa sem um caso de custo-benefício crível não recuperaria esse custo irrecuperável. Aumentaria a exposição.

Cancelamento Foi um Reset de Governança, Não um Apagamento

Em janeiro de 2011, o DHS encerrou o SBInet como originalmente concebido. O departamento disse que a avaliação mostrou que o programa não poderia atingir seu objetivo original como uma solução tecnológica de fronteira única. Mudou para um plano usando tecnologias comprovadas adaptadas ao terreno, densidade populacional e necessidade operacional.

A supervisão posterior resumiu o registro mais diretamente: atrasos significativos e estouros de custo, tecnologia entregue a duas áreas do Arizona e cancelamento porque o programa não atendeu aos padrões de viabilidade e custo-efetividade. O GAO considerou a decisão de descontinuar a abordagem original como responsiva às suas recomendações acumuladas.

A decisão não estabeleceu que todo componente do SBInet era inútil. Sistemas de vigilância foram implantados ao longo de 53 milhas, e o Projeto 28 forneceu capacidade operacional limitada antes da substituição. Nem o cancelamento provou que as tecnologias sucessoras seriam automaticamente eficazes.

A distinção importa para o aprendizado institucional. Se o cancelamento é narrado como fracasso tecnológico total, evidências úteis de campo podem ser descartadas. Se é narrado como uma simples renomeação, as falhas de controle podem desaparecer. Um encerramento responsável identifica quais requisitos eram válidos, quais suposições de arquitetura falharam, quais componentes permanecem suportáveis, quais contratos devem ser encerrados e quais evidências devem orientar o sucessor.

O plano sucessor Arizona Border Surveillance Technology Plan usou um menu de tecnologias em vez do modelo integrado original. Relatórios posteriores do GAO e do OIG do DHS ainda encontraram fraquezas no planejamento e medição. Essa continuação não faz do SBInet a causa de todas as questões posteriores. Mostra que mudar o portfólio de equipamentos não repara automaticamente a disciplina de aquisição.

O reset de governança estaria completo apenas quando o novo plano pudesse documentar alternativas, benefícios esperados da missão, cronogramas, custos do ciclo de vida, medidas de desempenho e avaliações operacionais. Um conjunto diferente de torres não é um sistema de responsabilidade diferente, a menos que a evidência da decisão também mude.

O Risco Público Era Mais Amplo do que um Dispositivo Quebrado

Os riscos públicos diretos do SBInet eram riscos de gestão e capacidade. Fundos apropriados podiam ser comprometidos sem evidência confiável de valor. A implantação podia ser atrasada enquanto sistemas legados continuavam a carregar a missão. A agência podia escalar uma arquitetura que não havia demonstrado desempenho integrado. Mudanças repetidas podiam enfraquecer a confiança na gestão de tecnologia do DHS.

Esses riscos não devem ser convertidos em alegações não fundamentadas sobre migração, crime ou incidentes específicos de fronteira. As fontes oficiais discutiram o objetivo de detectar e responder a entradas ilegais, mas este relato não atribui uma travessia, apreensão ou resultado de segurança específico a um defeito do SBInet.

A distinção é uma força, não uma limitação. A responsabilidade pública não exige inventar um evento downstream dramático. Uma aquisição pode impor risco sério consumindo tempo, orçamento e atenção organizacional, enquanto falha em provar que a capacidade prometida chegará.

Também pode criar custos operacionais ocultos. Agentes trabalhando com comunicações não confiáveis, operadores compensando o comportamento do sensor, mantenedores mantendo equipamentos mistos legados e novos vivos e gerentes reconstruindo cronogramas incertos gastam capacidade escassa. Esses efeitos devem ser medidos em vez de assumidos, mas pertencem a uma análise completa do ciclo de vida.

A legitimidade institucional é afetada quando as alegações públicas permanecem amplas enquanto o escopo entregue se reduz. Os funcionários podem ter razões válidas de segurança para não divulgar detalhes sensíveis de desempenho. Ainda assim, podem fornecer aos órgãos de supervisão evidências controladas sobre custo, cronograma, rigor de teste e critérios de decisão.

O padrão público não é que todo programa de tecnologia deve ter sucesso. A integração complexa revelará defeitos. O padrão é que a incerteza é tornada visível, os usuários operacionais influenciam as evidências, os contratantes são supervisionados e os líderes param ou remodelam o programa quando o caso de valor não é mais crível.

Responsabilidade Segue o Controle Prático

A responsabilidade pelo SBInet foi distribuída, mas o controle prático ainda pode ser identificado. A liderança do DHS controlava a estrutura de investimento e a decisão de avaliar ou encerrar o programa. O CBP era o dono da missão e da organização de aquisição. O escritório do programa SBInet controlava requisitos, supervisão de ordens de tarefa, linhas de base e recomendações de marco. A Boeing controlava grande parte do trabalho de integração e das evidências do contratante. Os usuários da Patrulha de Fronteira controlavam o feedback operacional essencial. As organizações de teste e auditoria desafiavam a qualidade da prova.

A responsabilidade deve seguir as decisões que cada participante podia tomar. Um contratante é responsável pelo trabalho e representações dentro do contrato. Não é a autoridade final sobre se um limite serve à missão pública. Os operadores são responsáveis pela avaliação disciplinada, mas não podem corrigir uma estimativa de custo estruturalmente não confiável. Os auditores podem identificar fraquezas, mas os executivos do programa são os donos da resposta.

O controle mais consequente era a autoridade para escalar. A expansão compromete dinheiro e torna as suposições de design mais difíceis de reverter. A instituição que a autoriza deve ter exigido um pacote de evidências integrado: cenários de missão estáveis, requisitos rastreados, componentes qualificados, defeitos controlados, resultados de campo representativos, estimativas confiáveis de custo e cronograma, planejamento de manutenção e uma comparação de benefícios.

Nenhum artefato favorável isolado deve substituir o pacote. Um teste de aceitação aprovado pode não provar a capacidade de manutenção. Uma estimativa de custo pode ser bem documentada, mas baseada em desempenho não comprovado. O feedback positivo do usuário pode ser local e condicional. O valor está na consistência das evidências.

Essa estrutura também impede que a culpa recaia sobre uma câmera defeituosa, uma equipe de software ou um executivo. O registro do SBInet mostra fraquezas de controle interagindo ao longo de vários anos. A responsabilidade prática pergunta quem podia ver cada fraqueza, quem podia exigir correção e quem autorizou o próximo compromisso.

Um Portão de Evidência Melhor Antes de Escalar

As futuras aquisições públicas de vigilância podem extrair um modelo de controle concreto do SBInet.

Primeiro, defina cenários operacionais antes de selecionar uma arquitetura. Terreno, comunicações, tipos de alvo, carga de trabalho do operador, acesso de manutenção e procedimentos de resposta devem moldar o requisito.

Segundo, mantenha rastreabilidade bidirecional. Cada requisito de componente e software deve conectar-se para cima a uma necessidade do usuário e para baixo a um caso de teste. As mudanças devem preservar a justificativa e a autoridade de aprovação.

Terceiro, separe aceitação técnica, contratual e operacional. Cada portão deve declarar o que prova, o que permanece não provado e quais próximas ações são autorizadas.

Quarto, meça a maturidade de defeitos. Os defeitos devem ter gravidade, efeito operacional, proprietário, versão alvo e evidência de fechamento. A tendência deve informar a prontidão, não meramente a contagem de tickets fechados.

Quinto, torne as estimativas de custo e cronograma completas o suficiente para decisões. Mão de obra governamental, esforço do contratante, infraestrutura, software, treinamento, manutenção, sobreposição de sistemas legados e risco devem ser visíveis. O cronograma deve identificar dependências, caminho crítico e incerteza.

Sexto, preserve a autoridade técnica do governo. Os contratantes podem integrar o sistema, mas o pessoal federal deve ser dono dos requisitos, aceitação, risco e registro de decisão.

Sétimo, use a implantação incremental como um experimento com objetivos explícitos de aprendizado. Um incremento deve responder a perguntas definidas antes que a próxima expansão comece.

Finalmente, exija uma decisão de escala que possa falhar. Se as evidências não suportarem a expansão, o padrão deve ser pausar, redesenhar ou parar - não reinterpretar a promessa original.

Esses controles não garantem sucesso. Eles tornam o fracasso informativo e limitam o custo de descobrir que uma arquitetura está errada. Eles também dão aos líderes uma base defensável para continuar quando as evidências são fortes.

Conclusão: Uma Cerca Virtual Deve Ser Comprovada em Campo

O SBInet foi construído em torno de uma ideia atraente: integrar sensores e software para que uma vasta fronteira se torne mais visível e os agentes possam responder com melhores informações. A ideia não foi refutada meramente porque a aquisição original terminou. O registro do programa mostra como é difícil transformar essa ideia em infraestrutura pública confiável.

O Projeto 28 entregou equipamento e alguma capacidade limitada, mas também expôs problemas de integração, requisitos e operacionais. Blocos posteriores carregavam uma promessa maior enquanto o escopo e as expectativas de desempenho mudavam. Os controles de custo e cronograma não deram aos líderes previsão confiável. A supervisão do contratante e dos marcos não preservou consistentemente as evidências necessárias para uma expansão confiante.

O DHS eventualmente mudou a questão de como continuar o SBInet para se a arquitetura era o investimento certo. Encerrar o programa como originalmente concebido foi uma admissão de que as evidências existentes não justificavam o modelo de escalonamento original.

A lição não é que os governos devem evitar tecnologia complexa. Vigilância de fronteira, sistemas meteorológicos, despacho de emergência e serviços digitais públicos dependem de integração. A lição é que a complexidade aumenta o ônus da prova.

Uma torre não é cobertura. Uma detecção de radar não é identificação. Um ícone de mapa não é uma resposta operacional. Um marco contratual não é valor de missão. Um piloto não é uma arquitetura nacional.

A capacidade pública começa quando esses vínculos podem ser demonstrados sob condições representativas, com custo conhecido, defeitos controlados, usuários treinados, manutenção sustentável e um cronograma que reflita dependências reais. Até lá, a cerca virtual é uma alegação de aquisição.

O SBInet tornou a decisão de escala o artefato central de responsabilidade. As instituições com controle prático tinham que decidir se as evidências de campo eram fortes o suficiente para justificar a próxima milha. Quando essas evidências estavam ausentes, interromper a expansão não foi abandono da responsabilidade. Foi o exercício dela.

SBInet transformou sensores de fronteira virtual em um teste de responsabilidade na aquisição