Por que os grandes projetos de TI tendem a falhar ou têm grandes excedentes de custo / cronograma? [fechadas]

Eu sempre leio sobre projetos de transformação ou integração em larga escala que são desastre total ou quase total. Mesmo que de alguma maneira eles consigam ter sucesso, o custo e o cronograma são enormes. Qual é a verdadeira razão por trás de grandes projetos serem mais propensos a falhas. O ágil pode ser usado nesse tipo de projeto ou a abordagem tradicional ainda é a melhor.

Um exemplo da Austrália é o projeto Queensland Payroll, onde eles mudaram os critérios de sucesso do teste para entregar o projeto.
Veja mais alguns projetos com falha nesta questão do SO ( na Wayback Machine )

Você tem alguma experiência pessoal para compartilhar?

O principal motivo é um aumento no escopo , que o livro "O Programador Pragmático" descreve como:

• apresentam inchaços
• featurism rastejante
• exigência de fluência

É um aspecto da síndrome do sapo cozido.

A idéia dos vários métodos "ágeis" é acelerar o feedback e - espero - corrigir a evolução do projeto no tempo.

Mas o outro motivo é o gerenciamento de versões : se você não estiver preparado para liberar o projeto (por mais imperfeito que seja), as chances são de que ele falhará (porque foi lançado tarde demais, com muitos recursos de buggy e mais difícil de corrigir / atualizar / atualizar).

Isso não significa que você precisa ter uma data de lançamento fixa, mas significa que você deve poder, a todo momento, criar uma versão em execução do seu programa, para testá-la / avaliar / liberá-la.

A postagem do blog " Projetos atrasados ​​estão atrasados ​​um dia de cada vez " contém muitos outros exemplos:

Eu sei que a coisa de 'Realizar' seria flexibilizar o escopo e manter a data de lançamento fixa, mas isso não funcionará se houver uma funcionalidade acordada que não possa ser concluída a tempo.

É por isso que não defendemos especificações ou “funcionalidades acordadas”. Essa é a raiz do problema - dizer que você sabe tudo sobre o que precisa e como será implementado antes mesmo de o primeiro pixel ser pintado ou a linha de código ser escrita. .

Quando você prevê um futuro rígido em um presente flexível, está com problemas. Futuros rígidos estão entre as coisas mais perigosas. Eles não deixam espaço para descobertas, emergências e erros que abrem novas portas.

Geralmente, a complexidade do projeto é subestimada .

Steve McConnell (da fama "Code Complete") tem uma lista dos erros clássicos .

Algumas práticas de desenvolvimento ineficazes foram escolhidas com tanta frequência, por tantas pessoas, com resultados tão previsíveis e ruins que merecem ser chamados de "erros clássicos" ...

Esta seção enumera três dezenas de erros clássicos. Eu pessoalmente vi cada um desses erros cometidos pelo menos uma vez e cometi muitos deles pessoalmente ...

O denominador comum nesta lista é que você não terá necessariamente um desenvolvimento rápido se evitar o erro, mas definitivamente obterá um desenvolvimento lento se não o evitar ...

Para facilitar a referência, a lista foi dividida de acordo com as dimensões da velocidade de desenvolvimento de pessoas, processos, produtos e tecnologias.

Pessoas

# 1: Motivação minada ...

# 2: Pessoal fraco ...

# 3: Funcionários com problemas não controlados ...

# 4: Heróico ...

# 5: Adicionando pessoas a um projeto atrasado ...

# 6: Escritórios barulhentos e lotados ...

# 7: Atrito entre desenvolvedores e clientes ...

# 8: Expectativas irrealistas ...

# 9: Falta de patrocínio eficaz do projeto ...

# 10: Falta de participação das partes interessadas ...

# 11: Falta de entrada do usuário ...

# 12: Política colocada sobre substância ...

# 13: Pensamentos ...

Processo

# 14: horários excessivamente otimistas ...

# 15: Gerenciamento insuficiente de riscos ...

# 16: Falha no contratante ...

# 17: planejamento insuficiente ...

# 18: Abandono do planejamento sob pressão ...

# 19: Perda de tempo durante o front end difuso. O "front end difuso" é o tempo antes do início do projeto, o tempo normalmente gasto no processo de aprovação e orçamento ...

# 20: Atividades upstream alteradas ... Também conhecido como "saltando para a codificação" ...

# 21: design inadequado ...

# 22: Garantia de qualidade em curto prazo ...

# 23: controles de gerenciamento insuficientes ...

# 24: Convergência prematura ou muito frequente. Pouco antes do lançamento programado de um produto, há um esforço para prepará-lo para lançamento - melhore o desempenho do produto, imprima a documentação final, incorpore os ganchos finais do sistema de ajuda, aprimore o programa de instalação, elimine a funcionalidade que não será pronto a tempo, e assim por diante ...

# 25: Omitindo tarefas necessárias das estimativas ...

# 26: Planejando recuperar o atraso mais tarde ...

# 27: Programação tipo código. Algumas organizações pensam que a codificação rápida, flexível e fácil de usar é um caminho para o desenvolvimento rápido ...

produtos

# 28: Requisitos de revestimento de ouro. Alguns projetos têm mais requisitos do que precisam desde o início ...

# 29: Característica ...

# 30: desenvolvedor de revestimento de ouro. Os desenvolvedores são fascinados por novas tecnologias e, às vezes, estão ansiosos para experimentar novos recursos ... - seja ou não necessário em seus produtos ...

# 31: Me empurre, me puxe a negociação ...

# 32: Desenvolvimento orientado para a pesquisa. Seymour Cray, o projetista dos supercomputadores Cray, diz que não tenta exceder os limites de engenharia em mais de duas áreas por vez, porque o risco de falha é muito alto (Gilb 1988). Muitos projetos de software podem aprender uma lição com Cray ...

Tecnologia

# 33: Síndrome da bala de prata ...

# 34: Economias superestimadas de novas ferramentas ou métodos ... Um caso especial de economia superestimada surge quando os projetos reutilizam o código de projetos anteriores ...

# 35: Trocando ferramentas no meio de um projeto ...

# 36: Falta de controle automatizado de código-fonte ...

Projeto maior = Mais complexidade
Mais complexidade = Mais incertezas
Mais incertezas = Mais
difícil
estimar Mais difícil estimar = Estimativas ruins Estimativas ruins = Excedentes de custo

Eu culpo o processo de licitação. Ele recompensa o grupo que pode fazer o acordo parecer mais barato / rápido no papel.

As pessoas que fazem propostas não querem perder tempo se não tiverem chances de ganhar, então suas estimativas normais são colocadas em espera. Conheço pessoas que especificaram switches normais em vez de switches POE para economizar US $ 80. Mas o projeto precisava de POE porque tinha câmeras IP. Esses US $ 80 precisam ser gastos, mas agora estão fora das especificações.

Acredito firmemente que um projeto de US $ 2.000.000 em dois meses ainda levará dois meses em US $ 2.000.000, não importa quantos lances você receba. Se você acha que fazer o certo é caro, espere e veja como é caro fazer errado.

Uma razão possível é que as estimativas são baseadas em projetos menores, assumindo um crescimento linear no custo com o tamanho do projeto, quando na verdade o crescimento do custo é, por exemplo, quadrático devido ao aumento da complexidade, maior duração do projeto (mais tempo para alterações de requisitos) etc. difícil, e quanto maior o projeto, mais difícil é estimar corretamente.

Outro motivo são as estimativas tendenciosas do otimismo: para ganhar a licitação, as estimativas dos melhores casos são usadas para calcular o preço. Quanto maior o projeto, menos provável é o melhor cenário. As regras de licitação tornam provável que o oferente mais otimista receba a aceitação, portanto, mesmo que cinco fornecedores façam uma estimativa realista e o sexto seja otimista demais, o otimista vence a licitação e falha mais tarde. Então essa é uma seleção negativa.

O custo não exclui o cronograma aos olhos da "gerência", que é uma distinção importante a ser feita. Como sabemos, "nove mulheres não podem engravidar em um mês" , você ficaria surpreso com quantas pessoas pensam que os problemas diminuem em profundidade em relação à quantidade de dinheiro que é investida nelas. Um mau gerenciamento de projetos, geralmente se manifestando na forma de microgerenciamento, é a principal causa da maioria dos projetos de tanques (na minha experiência). A microgestão entra em ação quando a "administração" percebe que algo está saindo de controle e eles não têm idéia do porquê.

Quando essa não é a causa, o resultado esperado do projeto provavelmente não era sustentável, para começar. Na minha experiência, se o prazo de um projeto for muito curto, as pessoas terão tanto medo de cometer erros que resultam em 'trabalho duplo' que não realizam quase nada.

É por isso que o gerenciamento deve ser preenchido com programadores experientes que têm um histórico de equipes líderes que produziram projetos bem-sucedidos. Essa pessoa pode dizer "De maneira alguma poderíamos fazer isso de forma responsável", apesar da receita possível, e não permaneceria na administração por muito tempo, razão pela qual muitos de nós (em última análise) respondem a MBA em vez de PHD.

Perdi a conta do número de empresas em que trabalhei onde um não programador estava encarregado de contratar programadores. Eu tive uma entrevista uma vez em que o gerente de contratação não queria fazer nada além de discutir um evento esportivo recente (acho que era um jogo de futebol). Se a pessoa que você tem no comando se inspira mais em um treinador da NFL do que em Knuth, o projeto vai acabar.

De vez em quando, você encontra algo que foi bem planejado, bem compreendido, realista e aparentemente simples. Por alguma razão, seis meses após o desenvolvimento, tudo se reverteu. Acontece. Raramente, porém, é que a causa subjacente de um projeto se tornar um barril de porco glorificado.

Ainda assim, tenho que admitir ... se você assistir as notícias, poderá ver um acidente ocasional de motocicleta ou um acidente de trem. Você nunca ouve falar dos milhões de motocicletas ou trens que chegam pontualmente todos os dias sem incidentes. O mesmo acontece com os projetos. Claro, é interessante ver uma autópsia pública de algo que deu muito, muito mal, mas você quase nunca ouve falar de coisas que deram muito, muito bem. Eu acho que os projetos de tanques ainda são a exceção, não a norma.

Na maioria das vezes, uma combinação de dois ou mais dos seguintes itens:

• problema de colaboração entre departamentos
• política ... muita política ...
• time errado
• programação irrealista
• mudança de escopo sem a metodologia apropriada
• informações ausentes

Belo livro sobre o assunto: Marcha da Morte .

As pessoas tendem a pensar que o desenvolvimento de software é um processo preditivo, tentando medir e estimar as coisas um ano antes. Isso não é possível! O software de construção não é fabricado por parafusos.

Seguindo a mesma "tendência", eles tentam fazer uma enorme análise (novamente um ano à frente) pensando que cobrirão todas as possibilidades e, mais tarde, transformar programador em meros datilógrafos. Como alguém pensa que isso poderia funcionar? Esse tipo de comportamento apenas leva a estimativas ruins e muita burocracia.

Quanto maior o projeto, maior a probabilidade de você estar trabalhando para uma grande organização. Quanto maior a organização, mais camadas de gerenciamento. Quanto mais camadas de gerenciamento, mais difícil são as más notícias ("não podemos ter o que queremos pelo que podemos pagar") para compor a cadeia de comando. Quanto menos prováveis ​​as más notícias puderem constituir a cadeia de comando, maior será a probabilidade de um plano de fantasia ser aceito e, em seguida, mantido por muito tempo depois que se sabe que é insustentável.

Projetos de software de todos os tamanhos "tendem a falhar" ou "têm custos excedentes". Você não ouve sobre a superação custo no negócio em torno do canto, mas você fazer ouvir sobre coisas como o sistema de Caso Virtual do FBI, ou o sistema de tratamento de bagagem do aeroporto de Denver. Portanto, farei a afirmação de que nem todos os sistemas grandes falham, nem todos os sistemas grandes têm excedentes de custo / cronograma.

Encontrei grandes sistemas que chegaram dentro do prazo (o cronograma mudou uma vez e apenas uma vez durante o projeto) e nas especificações (não tive acesso a informações orçamentárias, pois éramos apenas um dos muitos fornecedores). Um que ainda me impressiona (e eu escrevi um pouco sobre isso neste site) foi um grande sistema integrado de gerenciamento de clientes para um grande cliente financeiro (nos primeiros 100 dos 500 da Fortune). Estimo que gastaram cerca de US $ 100 mil / dia (por mais de um ano) nos salários das pessoas durante as teleconferências.

No caso do sistema de manuseio de bagagem, os gerentes de software disseram que "com base em projetos desse tamanho e complexidade, levará quatro anos para construir e depurar esse sistema". Os gerentes de vendas e executivos disseram que "o aeroporto abre em 2 anos, dissemos ao cliente que levaria 2 anos, então você tem 2 anos para fazer isso". O teste para verificar se você é um programador ou um gerente incorreto é uma resposta simples para a seguinte pergunta: "o sistema de manuseio de bagagem estava atrasado ou pontualmente?"

Se o cliente souber exatamente o que deseja (e muito poucos o fazem), estará muito longe no caminho para manter os custos e o tempo sob controle (e essas são as pessoas que tendem a se sair muito bem). Se o seu projeto precisa atender a todos os recursos possíveis que seus clientes possam imaginar, e todos os departamentos têm poder de veto quando seus tijolos dourados de estimação são adicionados ao projeto, você está condenado a rejeitar falhas desde o início (como as do FBI). Projeto VCF).

Percepção da Realidade

Aqui está a melhor descrição deste problema que eu já encontrei. Balanço de árvore De businessballs.com

Fui apresentado ao conceito de "Percepção da realidade" logo no início da minha carreira em programação. Por isso, sou verdadeiramente grato. Acredito que esse é o maior motivo pelo qual qualquer projeto falha, não apenas projetos de TI .

Um dos motivos para falhas é que um grande projeto geralmente é importante para o negócio. Quando projetos e tarefas são de alto nível, incentiva as pessoas a mentir.

Seu chefe quer que você avalie seu status de conclusão no lado superior. Ele quer estimar superações e atrasos no lado baixo. Quando você encontra um problema, ele não quer saber que isso adicionará três semanas à tarefa; ele quer ouvir que você pode trabalhar em algumas horas hoje à noite.

E assim por diante.

Eu estava em um projeto há vários anos, para um cliente. Fui convidada depois que a proposta e o plano do projeto foram concluídos. Havia pressão constante para tomar decisões mais rápidas, mais rápidas e ridículas de corte de custos, sobrecarga pesada de pessoal, sem recursos para eles; sem mesas, computadores, qualquer coisa.

Finalmente, descobri que o projeto era licitado em 7 meses e 16 milhões de dólares. Estimei no verso de um envelope que deveria ser de 24 meses e 50 a 100 milhões. Marquei uma reunião com meu gerente e o gerente dele, e apresentei meu caso, e como NÃO estávamos chegando nem perto de entregar dentro do prazo ou orçamento; eles subestimaram todos os problemas. No final da reunião, o CIO telefonou e disse a ambos os gerentes essencialmente o que eu disse, com exceção da falha na proposta original.

Eu tive a chance de sair do projeto quando eles mudaram as tecnologias para uma em que eu não era experiente. Falei com alguém muito mais tarde. O projeto acabou sendo cancelado quando estava quase pronto ... aos 12 meses e 35 milhões de dólares.

Grandes projetos de alto nível desencorajam as pessoas que dizem "isso é um erro". Erros não são tolerados.

Elaborando um pouco da resposta do VonC:

Esses grandes projetos tendem a ter uma mentalidade de "tudo ou nada". O projeto, conforme definido, deve ser lançado de uma só vez - geralmente como uma mudança de um sistema existente.

Isso significa que os problemas de fluência de recursos / requisitos são mais difíceis de resolver; portanto, quando o projeto se concretiza, geralmente é visto como não cumprindo os requisitos. Isso pode ser exacerbado se o sistema existente tiver sido atualizado ou a tecnologia tiver sido movida nesse meio tempo.

Qual a solução para isso?

Realmente não sei como ninguém quer ter dois sistemas funcionando paralelamente a um conjunto de funções em mudança dividido entre os dois.

A complexidade de grandes projetos pode ser exacerbada por pressões políticas externas. Um departamento pode ter uma idéia muito clara e focada do que eles querem no novo sistema, mas os departamentos associados atendem a dezenas de solicitações ao longo da linha "Bem, desde que você esteja fazendo isso, por que não fazer esta pequena tarefa secundária para nós também? " Você pode começar dizendo "Não, isso está fora do escopo". Mas, em seguida, começa a briga política entre os acordos, e o orçamento do projeto é ameaçado, a menos que todos recebam seu pedaço da torta.

Durante anos, nossa polícia local não pôde procurar placas parciais através do sistema de veículos a motor, um recurso que parece absurdamente simples. Perguntei a um amigo o que havia de tão difícil em adicionar esse recurso, e eles disseram que toda vez que propunham a mudança para um banco de dados moderno, todos os outros departamentos do estado que mantinham alguma interação com o sistema de veículos a motor desejavam obter sua parcela. o sistema também foi consertado. O resultado foi um bloqueio completo na modernização da TI. Finalmente, o Estado reuniu capital suficiente para realizar um esforço de modernização amplo do sistema, que depois fracassou por ser tão terrivelmente complexo.

Um fator que foi abordado, mas ainda não abordado:

Quase todas as falhas dramáticas são contratos que foram oferecidos. O que acontece com uma empresa competente em tal situação? Eles fazem uma estimativa realista e, portanto, quase certamente são subornados por alguém que fez uma estimativa ruim.

Se a empresa não pode estimar adequadamente, é surpreendente que eles também não consigam construir um sistema?

Michael Krigsman, no ZDNet, tem um blog dedicado a " IT Project Failures ", que pode ser interessante aqui.

Outro ponto é que, com projetos longos que duram anos, geralmente haverá atualizações a serem consideradas ou soluções alternativas, por exemplo, um projeto agora pode ser feito na nuvem versus no local, para algo que começa a surgir cada vez mais, que ao considerar estes não eram dados quando o projeto foi iniciado. Por exemplo, enquanto alguém pode começar com algo em 6.0, no momento em que a primeira fase é concluída, pode haver uma saída 6.3 ou 6.4 e a pergunta sobre quando atualizar está sendo feita. Alterações no escopo e na funcionalidade desejada, porque os requisitos não foram reunidos corretamente ou quando alguém mudou de idéia, são outros pontos que já foram abordados bastante.

O ágil pode ser usado nesse tipo de projeto ou a abordagem tradicional ainda é a melhor.

A razão pela qual processos ágeis bem aplicados não parecem sofrer com esse problema é por uma simples razão. Você não pode iniciar um projeto grande de maneira ágil. Você pode escolher um ou outro.

Com um processo ágil, você nunca está realmente olhando uma ou duas iterações para o futuro do projeto. não há 'plano' para os próximos 2 anos, apenas as próximas duas semanas. Quando sua visão é tão curta, você precisa fazer alguns compromissos. Você nunca pode começar com um plano para criar "A palavra final nos widgets", para qualquer tipo de widget que você esteja projetando. No máximo, você pode começar com "Um widget que pode frob", porque é sobre o máximo de trabalho que você pode realizar em uma ou duas iterações.

O bom disso é que, depois de algumas iterações, você já possui um produto completo e funcional que alguém pode achar útil, especialmente aquele cliente que precisa desesperadamente de um widget que pode frob e zort.

Essencialmente, grandes projetos podem falhar porque visam resolver todos os problemas de todos os clientes em potencial. Um projeto ágil nunca tem esse objetivo, em vez disso, aborda em cada versão apenas um problema crítico que um único cliente pode ter. Depois de um bom tempo, no entanto, um projeto ágil pode resolver muitos problemas críticos para muitos clientes.

• Falha ao enviar para usuários reais

Os grandes projetos têm uma tendência desagradável de entrar no modo "infraestrutura" por anos e esquecem-se de criar recursos reais para o usuário final e enviá-los. Quando é lançado, é muito caro mudar, e geralmente as maiores mudanças conceituais acabam sendo feitas após o primeiro teste beta real.

• Falha na estimativa precisa do custo

Se parece que os projetos superam o retorno do investimento, eles são cancelados.

• Falha no controle de qualidade

Com defeitos suficientes, é possível que o impulso para frente caia para zero ou abaixo. Sem nenhum progresso, é difícil argumentar pela existência continuada.

Eles esqueceram a Lei de Hofstadter: sempre leva mais tempo do que o esperado, mesmo quando você considera a Lei de Hofstadter.

Coisas que eu vi no desenvolvimento da Web:

• Muitos cozinheiros - o principal varejista da B&M, onde a ênfase mudou repentinamente para a web. De repente, 20 chefes de departamento estão perseguindo todas as iniciativas para impressionar o novo queijo principal. Uma vez eu tive que implementar novos ícones porque o legal não gostava da aparência dos antigos.

• Excesso de foco na correspondência das especificações para alcançar as metas - "Os ícones do IE6 estão um pouco desbotados em comparação aos do IE7. Abandone o trabalho crítico que está realizando na data de lançamento e atenda a 0,05% da nossa base de clientes para fazer coisas horríveis que levarão dias para implementar e diminuir ainda mais a experiência do IE ".

• Ferramentas ruins escolhidas por não desenvolvedores que nem sequer se incomodavam em pedir conselhos aos desenvolvedores internos.

• Desenvolvedores ruins escolhidos pelas ferramentas - "Por que pagar 20 desenvolvedores Java competentes com um salário decente quando podemos terceirizar 200 caras com pouco conhecimento de código que sabem muito pouco para usar o controle de versão?" como eles simultaneamente e com pessoas de diferentes países, trabalham nos back-ends principalmente para três aplicativos grandes.

• Arquitetura ruim / quebrada - Camadas e camadas de código de pânico, realizado ontem, por pessoas que foram demitidas ou agora são gerentes.