O custo da dívida técnica pertence ao orçamento

A dívida técnica se torna um problema de orçamento quando altera caixa, capacidade, risco ou uma data assumida. Enquanto a engenharia não ligar esses efeitos a um período e a uma decisão, a expressão não tem mais peso financeiro do que «o código parece antigo». Um diretor financeiro não pode financiar uma metáfora. Pode comparar um custo recorrente com o preço e o prazo para eliminá-lo.

Já vi equipes perderem essa discussão ao apresentar a idade das dependências, a complexidade ciclomática, a quantidade de tíquetes ou um diagrama de arquitetura todo vermelho. Esses fatos podem diagnosticar a causa. Não precificam a consequência. A unidade útil é dinheiro por período, com as evidências operacionais e as premissas visíveis por baixo.

O modelo deste artigo separa três custos que as equipes costumam misturar: juros pagos em esforço adicional de entrega, perdas causadas por incidentes e margem de contribuição adiada por atrasos. Some-os apenas depois de eliminar sobreposições. Deixe a incerteza explícita. O resultado não parecerá um passivo auditado, nem deve fingir que é. Será um modelo de decisão que finanças pode questionar, atualizar e colocar ao lado de outros usos do capital.

Um número para a dívida precisa de um contrafactual

O custo da dívida técnica é a diferença entre o que o sistema consome agora e o que consumiria após uma correção específica. Esse segundo estado é o contrafactual. Sem ele, uma conta de manutenção alta não diz quanto pode ser evitado.

Defina o item de dívida com precisão suficiente para que um responsável descreva os dois estados. «A plataforma legada» é amplo demais. «O módulo de preços em lote exige regressão manual em 14 variações de tarifa» é mensurável. «As versões do serviço de sinistros exigem um congelamento de quatro horas porque a reversão não restaura o esquema anterior» também é. Cada frase identifica uma atividade afetada e o mecanismo que a encarece.

Use um registro com uma linha por mecanismo, não uma linha por reclamação. Uma linha funcional tem estes campos:

1. O limite do sistema e o comportamento que cria trabalho ou exposição adicional.
2. O fator atual de custo, sua unidade e a fonte da evidência.
3. O estado substituto plausível e o fator de custo esperado nele.
4. A pessoa responsável por atualizar a estimativa.
5. A primeira decisão ou data de entrega que a dívida pode alterar.

A comparação deve usar a mesma demanda nos dois estados. Se o serviço atual processa 80 versões por ano, compare-o com 80 versões depois da correção. Não faça o substituto parecer barato supondo menos clientes, incidentes, relatórios ou mudanças regulatórias. Declare separadamente qualquer crescimento esperado da demanda.

Estimativas contábeis e gerenciais também precisam de nomes diferentes. A maior parte da dívida técnica não é um passivo registrado segundo as regras de relatório financeiro. Chamá-la assim cria uma disputa evitável com a controladoria. Trate o cálculo como uma estimativa gerencial para alocação de capital, a menos que finanças determine que uma despesa ou obrigação específica pertence às contas. A estimativa ainda pode influenciar um orçamento sem aparecer no balanço patrimonial.

Um bom teste é saber se alguém fora da engenharia consegue mudar uma entrada sem aceitar o diagnóstico técnico. Finanças pode questionar o custo completo da mão de obra. Vendas pode questionar a probabilidade de uma data de lançamento. Operações pode discordar das horas atribuídas a uma interrupção. Se o modelo expõe essas entradas, a discussão se torna útil. Se as esconde atrás de uma única «pontuação de dívida», qualquer pessoa pode rejeitar o total sem explicar o motivo.

Defina a decisão antes de coletar mais dados. Um pedido para substituir uma aplicação inteira precisa de um padrão de evidência diferente de um pedido de cinco dias para remover um gargalo nas versões. Registre a ação proposta, o caixa necessário, a capacidade retirada de outros trabalhos e a data até a qual a aprovação importa. Depois, colete apenas evidências que possam mudar a escolha. Equipes muitas vezes passam um trimestre refinando um inventário de dívida enquanto a questão orçamentária continua sem definição.

Retire os custos irrecuperáveis da comparação. O valor gasto para construir e remendar o sistema atual pode explicar a hesitação da liderança, mas não muda a economia futura. Compare caixa e capacidade futuros em cada opção. O gasto histórico só entra na explicação quando cria uma obrigação contínua, como um contrato de suporte ou uma cobrança de data center já assumida.

Os juros são a capacidade consumida em cada sprint

Os juros da dívida são o esforço adicional causado pelo desenho atual durante a entrega normal. Meça as horas extras, calcule seu custo completo e atribua-as ao sprint ou a outro período de planejamento em que ocorrem.

Comece pelas atividades repetidas: análise, programação, preparação de testes, regressão, implantação, correção de dados, coordenação de versões e suporte após a versão. Compare o esforço observado com uma base defensável. Ela pode vir da mesma equipe trabalhando em um componente mais limpo, de uma mudança recente que contornou a restrição ou de um estudo de tempo antes e depois de um pequeno reparo. Pontos de história são uma moeda ruim aqui, pois seu significado varia por equipe e costuma mudar à medida que a equipe aprende.

Use este cálculo para cada atividade:

interest_per_sprint = events_per_sprint
                    * extra_hours_per_event
                    * loaded_cost_per_hour

capacity_interest_rate = extra_hours_per_sprint
                       / available_engineering_hours_per_sprint

O custo completo deve seguir a taxa que finanças já usa no planejamento. Pode incluir salário, encargos do empregador, benefícios e despesas gerais alocadas. Não o substitua discretamente por uma tarifa de consultoria só porque isso aumenta o total. Se finanças planeja com taxas específicas por função, calcule separadamente o tempo de desenvolvimento, testes, operações e gestão.

Meça a espera e o trabalho, mas não lhes dê o mesmo preço. Quatro engenheiros esperando duas horas por um ambiente de testes geram oito horas de capacidade deslocada se não puderem trocar de tarefa com eficiência. Uma versão parada dois dias em uma fila pode consumir pouco trabalho, mas atrasar receita ou redução de risco. Coloque o primeiro efeito nos juros e o segundo no atraso. Contar ambos como trabalho exagera o custo.

Colete uma amostra pequena antes de instrumentar tudo. Acrescente dois campos aos registros normais de entrega por alguns sprints: o mecanismo de dívida encontrado e o tempo extra que ele causou. Peça uma nota curta, não precisão forense. Revise valores claramente atípicos com as pessoas que fizeram o trabalho. A meta é uma estimativa que resista a perguntas, não um regime de controle de horas que custa mais do que revela.

Mantenha o numerador incremental. Uma suíte de testes frágil pode fazer a regressão levar 30 horas em vez de 12, então os juros da dívida são 18 horas. As 30 horas completas são gasto de manutenção, mas apenas 18 pertencem a esta decisão. A distinção evita a alegação comum de que a correção eliminará toda a manutenção.

Informe dinheiro e capacidade. «18.400 dólares por sprint» permite que finanças compare gastos. «0,7 equivalente de engenheiro» mostra à liderança de engenharia o que a dívida retira do roteiro. Os dois números vêm das mesmas horas, portanto nunca os some.

Interrupções exigem cuidado especial porque tempo de calendário e esforço divergem. Um desenvolvedor que perde 20 minutos com uma compilação pouco confiável pode precisar de mais 15 para recuperar o contexto, mas pedir às pessoas que estimem essa recuperação mental produz números ruidosos. Primeiro, meça o tempo decorrido em tarefas comparáveis. Se a amostra mostrar uma diferença repetível que o tamanho da tarefa não explica, inclua-a e documente o método. Caso contrário, registre a quantidade de interrupções como evidência e deixe o custo discutível da recuperação fora do total.

Cobranças de prestadores e fornecedores entram nos juros quando a dívida faz com que se repitam. Um especialista mantido apenas porque ninguém da equipe consegue modificar uma linguagem antiga é um custo operacional evitável se a substituição remover essa dependência. Um contrato geral de suporte que continue necessário depois da correção é custo residual. Peça a compras as partes realmente comprometidas e variáveis, em vez de alocar a fatura inteira por intuição.

O custo do incidente vai além do reparo

O custo do incidente é a perda esperada criada pelo mecanismo da dívida, não o custo total de todo incidente que toca um sistema antigo. Ligue cada evento incluído a um caminho causal e separe a perda realizada do risco futuro.

Para incidentes que já ocorreram, reconstrua o custo a partir de registros nos quais a empresa confia: cronologias de incidentes, registros de plantão, taxas salariais, faturas de nuvem ou fornecedores, casos de suporte, créditos aprovados por finanças e registros de transações. Use estas categorias apenas quando houver evidência:

• trabalho de resposta e recuperação;
• cobranças diretas de infraestrutura ou fornecedores;
• créditos a clientes, reembolsos, multas ou transações baixadas;
• margem de contribuição perdida em transações que não foram recuperadas;
• trabalho posterior necessário para evitar uma repetição imediata.

Não precifique duas vezes as horas dos funcionários. Se um engenheiro passa seis horas restaurando o serviço e essas horas já aparecem no trabalho de resposta, não as conte também como juros do sprint. Atribua o tempo a uma categoria. Da mesma forma, se pedidos atrasados forem concluídos depois, conte o efeito temporal ou os abandonos, não o valor nominal completo de todos os pedidos na fila.

O risco futuro usa frequência e impacto. Uma estimativa anual simples basta quando os dados são escassos:

expected_annual_incident_loss = expected_events_per_year
                              * loss_per_event

expected_loss_per_sprint = expected_annual_incident_loss
                         * sprint_days
                         / operating_days_per_year

Use um intervalo para as duas entradas. O caso baixo pode refletir eventos rotineiros recentes. O caso base pode usar a frequência observada com uma perda típica. O caso alto deve descrever um evento grave plausível e suas premissas causais, não uma catástrofe inventada. Se o sistema nunca produziu a falha temida, diga isso. Uma estimativa de risco ganha credibilidade quando distingue evidência de julgamento.

Percentuais de disponibilidade raramente são uma boa entrada de orçamento sozinhos. Os mesmos 40 minutos de indisponibilidade podem parar um canal de receita, atrasar um relatório interno ou passar despercebidos em um período ocioso. Precifique o processo de negócio que falhou, no momento em que falhou. Operações é responsável pelos fatos sobre duração e recuperação. Finanças ou o responsável pelo negócio deve assumir o valor unitário atribuído à atividade perdida.

Exposição de segurança e conformidade exige a mesma disciplina. Não multiplique uma multa teórica enorme por uma probabilidade estimada sem base e chame isso de precisão. Identifique a falha de controle, os registros ou processos afetados, o trabalho de correção já necessário e qualquer consequência contratual aceita pelo jurídico ou por finanças. Mantenha a exposição sem preço em um campo narrativo separado. Um valor monetário em branco é mais honesto do que um número sem entradas defensáveis.

Quase incidentes podem informar a frequência sem receber o preço de perdas realizadas. Um lote noturno com falha, detectado antes da liquidação, pode revelar o mesmo caminho de defeito de uma falha diurna cara, mas a empresa não sofreu a perda do cliente. Conte o evento ao estimar a recorrência e depois use o impacto adequado ao horário e aos controles. Isso evita tanto ignorar avisos quanto fingir que todo aviso foi um desastre.

O seguro não elimina o custo do incidente. Uma apólice pode reembolsar uma parte definida após a franquia e a investigação, enquanto trabalho de resposta, perda de clientes e efeitos temporais permanecem. Finanças só deve lançar a recuperação esperada como compensação separada quando a apólice e o evento a tornarem plausível. Engenharia nunca deve subtrair da estimativa um pagamento de seguro estimado sem base.

Receita atrasada é um cálculo de tempo

O custo da receita atrasada é a margem de contribuição adiada ou perdida porque a dívida prolonga o caminho até um evento comercial. A própria receita costuma ser o valor errado: a empresa evita alguns custos variáveis quando uma venda não ocorre, e algumas vendas adiadas chegam depois.

Primeiro, nomeie o evento. Pode ser a disponibilidade geral de um recurso pago, a integração de um cliente contratado, a entrada em uma região, uma mudança de preço ou um aumento da capacidade de transações. Depois, identifique a cadeia de dependências do mecanismo de dívida até essa data. «O código antigo nos atrasa» não basta. «Toda mudança no produto exige um ciclo de regressão de seis dias nas regras compartilhadas de faturamento, e este lançamento precisa de três desses ciclos» pode ser verificado.

Use a margem de contribuição e um perfil temporal:

margin_delayed = expected_revenue_in_period
               * contribution_margin_rate
               * probability_debt_is_on_critical_path

economic_cost_of_delay = margin_lost_permanently
                       + financing_or_opportunity_cost_of_margin_postponed

Mantenha a margem adiada separada da margem perdida para sempre. Se um lançamento escorrega um sprint e os clientes apenas começam um sprint depois, toda a margem do primeiro sprint não desapareceu. O custo econômico é o valor de receber esse fluxo mais tarde, somado aos clientes ou contratos que serão realmente perdidos. Um calendário de fluxo de caixa simples torna isso visível.

Produto e vendas devem fornecer as entradas comerciais. Engenharia responde pela duração adicional e pela dependência causal. Finanças responde pela margem de contribuição e pelo método usado para valorar o tempo. Essa divisão impede que engenharia invente uma previsão de receita atraente e que finanças trate uma dependência técnica como uma reclamação genérica sobre entrega.

Cuidado com a aritmética do portfólio. Cinco recursos podem depender da mesma correção no banco de dados, mas a empresa talvez só tenha capacidade para lançar dois neste trimestre. Somar a previsão completa dos cinco cria um ganho imaginário. Modele o portfólio aprovado ou ponderado por probabilidade sob a restrição real de entrega.

Há também um valor de opção que normalmente deve ficar fora do total principal. Um sistema mais limpo pode baratear experimentos e permitir mudanças futuras, mas essas oportunidades não são fluxos de caixa comprometidos. Descreva-as e acompanhe se viram trabalho financiado. Não as use para salvar uma proposta de correção fraca.

A confiança na data importa tanto quanto a confiança na previsão. Se produto oferece uma previsão fixa de receita, mas o lançamento já tem três dependências sem solução, a dívida talvez não determine a data real. Mapeie o caminho crítico com responsáveis e condições de saída. A entrada de probabilidade deve ser a chance de que remover esse mecanismo mude a data comercial, não a chance de engenharia concluir o reparo.

Aumentos de capacidade precisam de outro modelo. Se o sistema atual limita pedidos ou contas, estime a demanda acima do limite por período e aplique a margem apenas às transações que a empresa poderá atender após a mudança. Não precifique capacidade teórica como receita. Um sistema que processa o dobro não gera retorno adicional quando a demanda continua abaixo do limite anterior.

Intervalos são mais confiáveis do que falsa precisão

Uma estimativa de dívida deve mostrar um caso baixo, um base e um alto porque suas entradas misturam medições e previsões. Um único total exato, especialmente com valores estranhamente precisos, indica que a incerteza foi escondida, não removida.

Para cada entrada, registre fonte, período de observação, responsável e confiança. Uma exportação de horários de versões oferece evidência mais forte do que uma estimativa em reunião sobre tempo de interrupção. Um pedido assinado por um cliente oferece evidência mais forte do que uma ideia de produto sem aprovação. Isso não torna as entradas fracas inúteis. Significa que a saída deve mostrar quanto elas controlam a decisão.

Faça uma análise de sensibilidade mudando uma entrada por vez. Se a proposta de correção só funciona quando inclui um lançamento especulativo, diga isso. Se o trabalho recorrente de testes sozinho paga a mudança, a decisão fica menos exposta a erro de previsão. Classifique as entradas por quanto movem o valor presente líquido ou o retorno e invista esforço de medição nas primeiras.

Use a taxa de desconto e o horizonte de investimento normais da empresa. Engenharia não deve inventar nenhum deles. Para um custo recorrente por sprint, o cálculo do valor presente pode continuar simples:

present_value = sum(period_cost[t] / (1 + period_rate)^t)

net_value = present_value_of_avoided_costs
          - remediation_cost
          - transition_cost
          - residual_cost

O custo residual importa. O substituto ainda precisará de manutenção, os incidentes não cairão a zero e as equipes continuarão executando testes. Modele o que permanece depois da mudança. Inclua também o custo de transição: operação paralela, suporte à migração, treinamento, conciliação de dados e desaceleração temporária das entregas. Omitir esses itens faz uma proposta sensata parecer publicidade.

Defina uma data de validade para a estimativa. Taxas, frequência de incidentes, dependências do roteiro e demanda do sistema mudam. Atualize os juros medidos com frequência a cada ciclo de planejamento e reveja grandes premissas de incidentes ou receita quando suas evidências mudarem. Uma estimativa antiga não deve virar verdade permanente porque apareceu uma vez em uma apresentação ao conselho.

Riscos correlacionados precisam de mais uma verificação. Um congelamento de versões pode aumentar o trabalho de entrega e atrasar um lançamento, enquanto a mesma alteração de esquema também aumenta a probabilidade de incidentes. Esses efeitos podem coexistir, mas seus casos altos talvez dependam do mesmo evento raro. Não combine todos os piores casos como se ocorressem de forma independente. Apresente um cenário coerente que declare quais eventos acontecem juntos e compare-o com o caso base.

Arredonde as saídas de acordo com a precisão da evidência. Se o esforço extra veio de entrevistas e de uma amostra curta, informar 417.263 dólares implica um conhecimento que a equipe não tem. Use um valor arredondado com bom senso e mantenha disponível o cálculo subjacente. A precisão da fórmula é útil; a precisão da resposta exibida precisa ser merecida.

Um exemplo calculado expõe as premissas

Considere um serviço de faturamento cujas regras compartilhadas exigem uma regressão manual a cada versão. O exemplo usa números redondos inventados para demonstrar o método, não para afirmar um resultado típico.

A equipe publica quatro vezes por sprint de duas semanas. Cada versão consome 22 horas extras de engenharia, testes e coordenação em comparação com mudanças em um serviço isolado mais novo. Finanças usa uma taxa completa combinada de 125 dólares por hora. O sistema também causou três incidentes atribuíveis no ano anterior, com trabalho documentado, créditos e margem perdida de 24.000 dólares em média por evento. Um recurso planejado de preços depende das mesmas regras, e a previsão aprovada mostra 160.000 dólares de receita mensal com margem de contribuição de 65 por cento. Produto estima em 50 por cento a chance de a dívida acrescentar um sprint ao lançamento.

Coloque as entradas em uma planilha que possa ser revisada linha por linha:

cost_bucket,input,base_value,source,owner
interest,releases_per_sprint,4,release_log,engineering
interest,extra_hours_per_release,22,time_sample,engineering
interest,loaded_cost_per_hour,125,planning_rate,finance
incident,events_per_year,3,incident_review,operations
incident,loss_per_event,24000,ledger_and_timeline,finance
delay,monthly_revenue,160000,approved_forecast,product
delay,contribution_margin_rate,0.65,margin_model,finance
delay,probability_on_critical_path,0.50,dependency_review,product

Os juros são 4 x 22 x 125 dólares, ou 11.000 dólares por sprint. Com 26 sprints de duas semanas como convenção de planejamento, a perda esperada com incidentes fica em cerca de 2.769 dólares por sprint. O atraso de um sprint coloca em risco aproximadamente metade da margem de um mês antes de ponderar a probabilidade: 160.000 dólares x 0,65 x 0,5 x 0,5, ou 26.000 dólares. O fator temporal é metade porque um sprint de duas semanas corresponde aproximadamente à metade do período mensal da previsão.

Não some imediatamente 26.000 dólares a cada sprint. Essa é uma exposição única, ligada à decisão, durante a janela de lançamento. A taxa recorrente é de 13.769 dólares por sprint em juros e incidentes esperados. A visão para a decisão deve mostrar duas linhas: custo recorrente evitável e exposição ao atraso ligada ao evento.

Suponha que a correção custe 310.000 dólares, a transição custe 45.000 e o serviço corrigido mantenha 25 por cento dos juros e perdas por incidentes atuais. O custo recorrente evitado fica então perto de 10.327 dólares por sprint. O retorno simples, sem desconto, sobre os 355.000 dólares totais de implementação e transição é de cerca de 34 sprints sem o efeito do lançamento, ou aproximadamente 32 sprints se o atraso ponderado for evitado. Finanças pode aplicar sua taxa normal de desconto e seu horizonte a partir daí.

Esse retorno pode ser pouco atraente. O modelo ainda cumpriu seu papel. A empresa pode adiar o trabalho, reduzir o escopo, buscar uma intervenção mais barata ou aceitar o custo de forma consciente. Engenharia não deve inflar o cenário de incidentes até a resposta mudar.

Agora teste as premissas mais fortes. Se o esforço extra por versão for de 14 horas, não 22, o custo recorrente evitado cai. Se apenas um incidente tiver sido realmente causado pelo módulo de regras, cai novamente. Se o trabalho de preços sair do roteiro aprovado, exclua a linha de atraso. Uma proposta que continue positiva após essas mudanças merece prioridade. Uma proposta que desaba identificou exatamente qual evidência a equipe precisa obter em seguida.

A linha do orçamento precisa de responsável e ritmo

O artefato operacional útil é um livro de custos da dívida ligado ao planejamento, não uma apresentação montada uma vez para o orçamento anual. Engenharia atualiza volumes de atividade e esforço extra. Operações atualiza incidentes. Produto atualiza datas do caminho crítico. Finanças controla taxas de mão de obra, margens, desconto e a definição de perda reconhecida.

Dê quatro números a cada item de dívida na planilha de planejamento: custo recorrente atual por sprint, exposição ligada a eventos, custo de correção e transição, e custo residual esperado. Mantenha disponíveis os casos baixo, base e alto logo abaixo. A linha de orçamento aprovada pode usar o caso base, enquanto o intervalo mostra a exposição da decisão.

O ritmo de revisão deve seguir a velocidade de mudança das entradas. Uma restrição de entrega com alto volume pode exigir uma revisão por sprint. Estimativas de incidentes podem mudar depois de cada evento atribuível. O atraso de receita só deve mudar quando uma previsão aprovada ou uma dependência mudar. Recalcular todos os campos a cada duas semanas cria trabalho inútil e ensina os responsáveis a ignorar o livro.

Use identificadores estáveis para impedir que custos migrem entre rótulos. Se a mesma restrição de esquema causa trabalho de entrega e uma interrupção, as duas entradas devem apontar para um único item de dívida com categorias separadas. Quando a correção entrar em produção, mantenha a linha aberta tempo suficiente para comparar o custo residual previsto com os resultados observados. Essa verificação posterior calibra estimativas futuras e detecta trabalho que apenas mudou de lugar.

Pedidos de orçamento devem apresentar escolhas. A opção A pode tolerar a dívida e financiar seu custo recorrente. A opção B pode contê-la com um reparo menor. A opção C pode substituir o componente afetado. Mostre custo, prazo, exposição residual e confiança para cada uma. Uma única proposta de reescrita para aceitar ou rejeitar convida finanças a discutir a ambição em vez da economia.

Não transforme o livro em medida de desempenho da engenharia. Equipes herdam restrições e fazem escolhas locais racionais sob pressão de prazo. Se a liderança usar o custo declarado da dívida para punir uma equipe, os dados ficarão misteriosamente limpos. Use-os para escolher investimentos e verificar resultados.

A economia da substituição deve incluir paridade

Uma reescrita de sistema legado só merece orçamento quando o custo evitado resiste ao risco de entrega. A estimativa do substituto deve incluir a descoberta de comportamentos não documentados, a comprovação da paridade de negócio, a migração de dados e tráfego, a operação das duas versões durante a transição e a retirada do caminho antigo. Uma conversão barata de código que omite essas atividades não precificou o projeto.

A transliteração também enfraquece a proposta econômica. Reproduzir limites de módulos obsoletos em uma linguagem nova preserva grande parte do custo de coordenação que criou os juros. O desenho de destino deve remover o mecanismo medido: isolar as regras de faturamento, tornar a reversão independente da restauração do esquema ou substituir a regressão manual por verificações executáveis de comportamento. Ligue cada mudança de desenho a uma linha no livro de custos.

Evidências de paridade devem usar comportamento real quando possível. Requisições e respostas de produção gravadas, tratadas sob os controles da empresa, podem formar uma estrutura de comparação. Acrescente casos de limite extraídos dos registros de incidentes e regras de negócio que o tráfego raramente exercita. Defina diferenças aceitáveis antes de comparar, pois horários, identificadores gerados, ordenação e comportamento de ponto flutuante podem variar sem mudar o resultado para o negócio.

CodeHero usa essa abordagem ao reescrever sistemas legados em Go, Rust e TypeScript: sua plataforma lê toda a base de código e verifica o comportamento com uma estrutura de paridade contra o tráfego de produção gravado. Os projetos são entregues em menos de 30 dias, então o orçamento pode ser comparado ao custo recorrente por sprint e à exposição a eventos sem fingir que a transição dura um período indefinido.

O documento de aprovação deve declarar o que acontece se o substituto não atingir a meta de custo ou a barreira de paridade. Uma mudança em etapas, um ponto explícito de reversão e a responsabilidade pelos defeitos residuais pertencem ao custo de transição. A capacidade temporariamente retirada do desenvolvimento do produto também. Coloque esses fatos na estimativa antes da aprovação, não na análise do incidente após o lançamento.

Quando o novo caminho estiver funcionando, meça as mesmas entradas usadas para justificá-lo. Esforço de versão, frequência de incidentes, trabalho de recuperação e duração do caminho crítico devem cair nos valores assumidos pelo orçamento. Se isso não acontecer, mantenha o livro aberto e descubra para onde o custo foi. Um número da dívida é confiável quando consegue provar que estava errado.