Projeto com falha: quando ligar?

Alguns meses atrás, minha empresa se viu em uma emergência incandescente de um projeto, e toda a minha equipe de seis pessoas realizou basicamente uma "semana de crise" de cinco semanas. Nas 48 horas anteriores à entrada em operação, trabalhei 41 delas, duas em turnos consecutivos. No meio disso, publiquei qual foi a minha pergunta de maior sucesso até hoje .

Durante todo esse tempo, nunca se falou em "fracasso". Sempre foi "fazê-lo, independentemente da dor".

Agora que a coisa acabou e nós, como organização, tivemos algum tempo para sentar e fazer um balanço do que aprendemos, uma pergunta me ocorreu. Não posso dizer que já participei de um projeto que, segundo eu, "falhou". Muitos que estavam atrasados ​​ou acima do orçamento, alguns desastrosamente, mas eu sempre acabei entregando ALGO.

No entanto, ouço sobre "projetos de TI com falha" o tempo todo. Eu estou pensando sobre a experiência das pessoas com isso. Quais foram os parâmetros que definiram "falha"? Qual foi o contexto? No nosso caso, somos uma loja de software com clientes externos. Um projeto interno a uma grande corporação tem mais espaço para "falhar"? Quando você faz essa ligação? O que acontece quando você faz?

Não estou absolutamente convencido de que fazer o que fizemos seja uma jogada inteligente de negócios. Não foi minha decisão (sou apenas um macaco de código), mas estou imaginando se seria melhor reduzir nossas perdas, dizer que não estamos cumprindo e seguir em frente. Não digo apenas que, devido à picada das longas horas - a empresa perdeu sua camisa no projeto, mais os custos intangíveis para a empresa em termos de moral e lealdade dos funcionários foram grandes . Considere o fato de que, contra o sucesso de RP por não entregar um projeto de alto nível como esse, foi ... e eu não sei qual é a resposta certa.

O conceito de falha é realmente uma ligação relacionada aos negócios. Se um projeto comercial custar mais do que o dinheiro que ele arrecada, esse projeto seria considerado um fracasso. Se um projeto de código aberto não puder criar uma comunidade em torno do código para ajudar a mantê-lo e cuidar dele, esse projeto de código aberto falhou.

Estive envolvido em projetos, onde entregamos tudo dentro do prazo e do orçamento, mas a equipe de desenvolvimento de negócios não conseguiu acompanhar o trabalho. Do ponto de vista comercial, o projeto falhou, embora o que entregamos tenha sido bem recebido e apreciado.

Em situações como a sua, a empresa precisa tomar algumas decisões difíceis. Se eles querem que o projeto seja bem-sucedido, precisam aprender algumas lições:

• A falha em planejar adequadamente causará estresse indevido em sua equipe e, finalmente, levará a um projeto com falha.
• Uma equipe estressada retaliará com alta rotatividade - e, eventualmente, você não poderá conseguir boas pessoas para ingressar na empresa.
• As emergências acontecem, mas descubra o que causou a emergência e mude suas práticas para evitar essa emergência no futuro.

Qualquer empresa que não aprende com seus erros repetirá a história com bastante frequência. Eu consideraria isso um sinal de que é hora de encontrar outra empresa.

Falha é algo que pode descrever uma meta que não está sendo alcançada.

Em resumo, quando você define seu objetivo, também define o que é uma falha nesse contexto.

Na literatura mencionada, uma falha é um projeto que está acima do orçamento e / ou não cumpriu o prazo .

Isso não significa que o produto não será usado. Isso significa que ele foi desenvolvedor com muito mais dor, dinheiro e tempo do que o esperado.

When you should cancel a project? Quando você tiver certeza de que qualquer novo segundo gasto nele fornecerá menos valor que seu custo.

Chama-se dilema de custo irrecuperável .

Se você está interessado no assunto, recomendo a Marcha da Morte , de Edward Yourdon . Um livro realmente ótimo.

Existem muitas maneiras diferentes de um projeto "falhar". E algumas em que trabalhei foram falhas:

1. O software shrink-wrap teve que ser reescrito para atender às novas regras estatutárias / regulamentares. Os mal-gerentes optaram por evitar contratar novas pessoas para ajudar com a carga de trabalho e, principalmente, com as habilidades que todos nós tínhamos. O produto não possuía os novos recursos necessários (tinha que ter um arquivo eletrônico feito de uma certa maneira) e precisava ser retirado do mercado. Enquanto este produto produzia cerca de 5% da receita de nosso escritório, estava ocorrendo uma mudança regulatória semelhante que afetou o produto que produziu 60% de nossa receita. Os desenvolvedores se encarregaram de aprender as habilidades necessárias, mas os gerentes optaram por esperar até que fosse tarde demais para começar a implementar as alterações necessárias. Recebemos três anos avisando que essas alterações estavam chegando, enquanto tentávamos fazer lances no lado servidor dessa alteração regulatória - e a empresa nos proibiu, com razão, de enviar a oferta. Nossos mal-gerentes optaram por nos fazer esperar até 8 meses antes da troca antes de termos permissão para trabalhar nela.

2. O projeto já estava acima do orçamento e estava atrasado quando fui contratado para ajudar a concluí-lo. Os gerentes de vários níveis mais altos decidiram que os custos irrecuperáveis ​​já eram altos demais para fazer o ROI necessário para o projeto, de modo que o projeto foi cancelado e todos os envolvidos demitidos. Trabalhar lá por uma semana antes de todo o grupo ser demitido (inclusive eu) foi o menor tempo em que trabalhei em um local.

3. O projeto interno levou tanto tempo para ser concluído que o patrocinador do projeto adquiriu o software disponível no mercado (neste caso, o Microsoft Office) e criou seu próprio VBA para realizar seu trabalho. O líder da equipe de desenvolvimento continuou prometendo a lua e se recusou a ouvir nas reuniões administrativas que o projeto já havia sido cancelado. 6 pessoas trabalharam por cerca de um ano concluindo um sistema que nunca seria usado.

O único projeto em que estive envolvido como programador ou como parte da equipe de PM foi Ricochet, que faliu com a falência da Metricom . Havia literalmente milhares de contratados em todo o país trabalhando nisso. Quando o diretor financeiro renunciou, o projeto simplesmente parou. Os móveis começaram a ser removidos dos escritórios quando o pessoal da liquidação desceu.

Para muitos de nós, o termo aplicável era 'desemprego', mas Lame Duck seria uma descrição adequada. Freqüentemente, pessoas importantes precisam permanecer até que um processo de autópsia / liquidação seja concluído, assim como alguns políticos que permanecem no cargo por alguns meses para concluir seu mandato antes da chegada do sucessor.

Como Otávio Décio indicou, não vejo um projeto fracassar a ponto de ser abandonado desde o boom das empresas.

Esse é um problema comum, também mencionado em alguns livros sobre gerenciamento de projetos. Nenhum projeto "falha", mesmo que tudo o que ele oferece seja uma experiência do tipo "o que evitar na próxima vez".

Na IMO, um projeto é um fracasso se não o fizer, teria sido mais barato. Por exemplo, se o produto tem uma expectativa de vida útil de 5 anos e economiza 100Kpa para a empresa, será uma falha se levar mais de 500K para fazê-lo. (Estou trapaceando com as taxas de juros aqui para simplificar). Algumas pessoas afirmam que todo projeto com excesso de custo e / ou tempo é um fracasso, mas na IMO essa definição faz pouco sentido, pois se concentra demais nas estimativas e no planejamento corretos.

Eu também nunca participei de nenhum projeto "com falha" - mas muitos projetos com custos e prazos excedentes. Acredito que a questão é que nenhuma das partes - o cliente ou o contratado - deseja que qualquer projeto seja considerado um fracasso por todas as crianças por razões, incluindo responsabilidade.

Então, eu acho que quando você ouve "projetos de TI com falha", na realidade, esses são "projetos que foram além dos limites, dentro do prazo ou do orçamento".

Afinal - quantas pessoas ou empresas que você conhece ficariam limpas e diriam "falhamos"?

No entanto, ouço sobre "projetos de TI com falha" o tempo todo.

Quais foram os parâmetros que definiram "falha"?

É um termo pejorativo frequentemente usado quando o projeto muda. Muitas pessoas gostam de rotular a mudança como "falha". Não sei por que, mas isso os torna mais poderosos ou importantes por terem identificado uma falha.

Alguns projetos realmente perdem dinheiro e nada de valor é criado. Mas esses são raros.

Mesmo um projeto que nunca entregou software de trabalho é uma experiência de aprendizado sobre o que não fazer. Criou valor. Ele criou um valor imprevisto, para que possa ser rotulado da maneira que as pessoas quiserem rotular. "Falha" é tão bom quanto "Aprendeu o que não fazer" em alguns círculos.

A verdadeira questão é "o valor foi proporcional ao custo"? E mesmo assim, o valor pode ser tão difícil de medir que a resposta é inteiramente política ou subjetiva.

Um projeto interno a uma grande corporação tem mais espaço para "falhar"?

Possivelmente. "fracasso" é um termo político. Qualquer alteração no cronograma, orçamento ou escopo pode ser rotulada como "alteração" ou "falha". Eles também podem ser rotulados como "aprendemos algo importante sobre a incapacidade de nossa equipe de escrever um servidor da web". Ou, ainda mais positivamente, "aprendemos quais habilidades precisamos antes de tentar novamente".

Projetos externos geralmente têm mais supervisão de pessoal de vendas e entrega, contadores e gerenciamento de projetos. Projetos internos geralmente têm menos supervisão.

Quando você faz essa ligação? O que acontece quando você faz?

Quando é conveniente ter alguém pressionado para sair da organização, porque você discordou deles. Você rotula o projeto deles como "falha" e os transfere para que você possa ter pessoas diferentes.

A única maneira pela qual um projeto pode ser um fracasso total é a fraude criminal - onde não houve lições aprendidas, nada pode ser melhorado e os criminosos foram demitidos e presos, deixando a organização sem noção do que aconteceu.

Caso contrário, sempre há algum valor.

A verdadeira questão é "o valor foi proporcional ao custo?"

Assim, sua empresa que estava faturando esse trabalho trabalhou você e outras 5 pessoas até a morte por 5 semanas. Eles ainda lucram com o seu trabalho duro. Espero que você tenha algo, porque a segurança no emprego não é nada hoje em dia e há muito trabalho. (O plugue descarado entre em contato comigo se você precisar trabalhar e for um programador competente, conheço vários lugares que precisam desesperadamente de ajuda).

Dito isto, se sua empresa realmente tivesse que pagar por todo esse trabalho e pelas 41 horas antes de ir ao ar, eles teriam PERDIDO dinheiro.

Sua gerência precisa sentar e explicar que, se isso ocorrer novamente, você será pago. Eles precisam julgar melhor quando puxar o plugue.

Eu também, como muitos respondedores aqui, estive envolvido em vários grandes projetos que foram executados ao longo do tempo e do orçamento - um por mais de meia década. O pior cenário (o de meia década) envolveu uma loucura gratuita do Mythical Man Month, bem como uma escalada épica no escopo. Dito isto, nunca foi abandonado e eles estão começando a conquistar alguns clientes agora. Mas as expectativas iniciais (substituição limpa e bem projetada de um sistema antigo e desatualizado) e o orçamento e a linha do tempo relativamente modestos - foram abalados há muito tempo.

Além disso, ao contrário da maioria das pessoas aqui, também vi um projeto totalmente falhar - a ponto de ser abandonado . O prego final no caixão chegou no início de 2010. Esse era o cenário:

Empresa pequena (cerca de 30 pessoas) desenvolvendo soluções personalizadas de ERP para empresas de médio porte. Eles tinham algumas instalações de logística relativamente lucrativas com empresas de mineração australianas e algumas roupas de caminhões nos EUA. A plataforma era uma estrutura interna personalizada construída sobre o J2EE. Na verdade, relativamente personalizável e bem-feito - novas instalações simples podem ser construídas rapidamente, mas não se adaptam muito bem quando o nível de personalização exigido é muito complexo (como foi o caso de alguns de seus maiores clientes).

Para encurtar a história: algumas de suas instalações de maior e mais alto perfil funcionavam com o tempo e o orçamento, e parece que o mercado não gostou disso e, portanto, não conseguiu mais clientes. A empresa era basicamente um pônei de truque, fazendo pouco mais do que esse sistema ERP; portanto, uma vez que o fluxo de caixa disso secou, ​​eles fecharam o negócio e o sistema foi abandonado (o GFC também poderia ter participado dele) .

(Eu só trabalhei lá por 9 meses - em 2004/2005. Eles basicamente contrataram e tornaram redundantes quando a carga de trabalho veio e passou com novas instalações - em vez de contratar empreiteiros - o que é bastante desonesto. Em retrospecto, a falha provavelmente foi mais a fazer com um modelo de negócios esquisito do que com a tecnologia.)

Se o projeto foi implantado de forma que a solicitação original fosse atendida, eu consideraria o projeto bem-sucedido. Para mim, uma falha seria o lançamento de um aplicativo que era universalmente rejeitado pelos usuários finais porque não atendia às suas necessidades. Ou, pior ainda, o projeto é encerrado antes que um produto seja realmente implantado para os usuários e suas necessidades não sejam atendidas.

Geralmente, se uma empresa está trabalhando para um cliente externo, não é sua decisão puxar um projeto, pois pode haver problemas de contrato envolvidos (por exemplo, quebra de pagamentos de contratos) ou um grande golpe de RP, como você observou. Em alguns casos, se houver uma quebra da penalidade do contrato, o custo de finalização do contrato é várias vezes menor do que o da violação do contrato e a perda de uma quantia simbólica de dinheiro é a opção preferida.

A longo prazo, uma empresa pode trabalhar para melhorar a moral dos funcionários para compensar um período de crise durante um projeto ou substituir os funcionários que saíram porque foram pressionados demais, mas às vezes pode ser impossível recuperar-se das principais falhas do projeto ( ou seja, observe as empresas de jogos que falharam em entregar produtos dentro do prazo que faliram).

Quando o caso de negócios não aguentar mais.

Essa é a medida que o Prince2 (a metodologia de gerenciamento de projetos) usa e faz muito sentido para mim.

Essencialmente, diz que no final de cada etapa do projeto, ou se um projeto estiver fora de certas tolerâncias em determinadas áreas (cronograma, custo, qualidade), deve haver uma revisão do caso de negócios. Nesse ponto, você repassará os custos totais previstos e os benefícios de realização com base no que você sabe agora e, se o projeto não for mais bem-sucedido, ele será eliminado.

O problema com isso em muitos projetos que eu vi é que eles não definem o que estão tentando alcançar com detalhes detalhados, o que torna muito difícil avaliar (a) se isso ainda é realista, ou (b) ) se os custos que você vai gastar para chegar lá valem a pena. Nessas situações, a melhor coisa que você pode fazer é produzir um caso de negócios no momento em que você suspeitar que permita entender se suas suspeitas estão corretas.

A montagem de um business case não precisa ser uma tarefa importante, mas alguns lados do A4 o farão. Os custos são relativamente fáceis (como medida aproximada que um programador custa: (salário anual * 2) / 250 por dia para a Europa, provavelmente um pouco menos para os EUA, pois os benefícios são mais baixos e o número médio de dias úteis mais altos, que são os insumos aqui )

Os benefícios são mais difíceis, mas se você estimar o pessimista da maneira mais precisa possível, se o caso de negócios não se acumular (normalmente medido, pois deve gerar um retorno de x% dos custos em três anos, em que X provavelmente será de 50% ou então) você pode vê-lo com mais detalhes. Não se esqueça dos custos de licença e hardware (mesmo que você esteja usando o hardware existente, pois significa que ele não pode ser usado para mais nada depois de o ter escolhido) e o suporte contínuo.

Mas muito disso não é coisa de programador, é coisa que o gerente geral e os negócios devem fazer com a contribuição de toda a equipe do projeto.