Onde termina o “Gerenciamento de Mudanças” e começa o “Falha do Projeto”?

Question

Entrei em um mini-argumento com meu chefe recentemente sobre "falha do projeto". Depois de três anos, nosso projeto para migrar uma base de código para uma nova plataforma (um projeto em que eu estava por 1,5 anos, mas minha liderança de equipe estava em apenas alguns meses) foi lançada.Ele, junto com a alta administração da minha empresa e do cliente (sou um daqueles consultores horríveis de que você tanto ouve falar).Meu compromisso é uma "Terceirização de Aplicativos") declarou o projeto um sucesso.Eu discordei, afirmando que apresentações antigas que encontrei mostravam que, comparado ao cronograma original, o atraso na implantação era melhor medido em meses e poderia ser medido em anos.Expliquei o que sei sobre o fracasso de projetos e os estudos e estatísticas por trás das taxas de fracasso.Ele respondeu que tudo isso era acadêmico e que nenhum projeto que ele liderou havia falhado, graças às maravilhas da gestão de mudanças/riscos - o que parece se resumir a explicar atrasos e reavaliar o cronograma com base em novos dados.

Talvez uma consultoria como essa seja diferente de outros projetos, mas parece que se trata apenas de um fracasso embrulhado em um nome mais bonito para evitar o estigma de não ter entregado no prazo, dentro do orçamento ou com funcionalidade total.O fato de ele ter explicado que minha empresa cedeu horas de trabalho de graça para finalizar o projeto dentro do orçamento máximo diz muito.

Então eu te pergunto isso:

• O que é gerenciamento de mudanças e como ele se aplica a um projeto?
• Onde termina o “gerenciamento de mudanças” e começa o “fracasso do projeto”?

---

@shog9:
Eu não estava perguntando sobre um jogo de culpas com os consultores, especialmente porque neste caso eu representar os consultores.Eu estava procurando opiniões sobre quando um projeto deveria ser considerado "fracassado", independentemente da funcionalidade necessária era finalmente implementado.
Estou procurando a diferença entre "na verdade, isso é um pouco mais complexo do que pensávamos e vai demorar mais uma semana", o que eu esperaria ser um tanto típico, e "falha do projeto" - como você deseja definir o fracasso.Existe alguma diferença?Será que este pequeno nível de atraso no cronograma constitui um “fracasso do projeto” estatístico?

Answer 1

Acho que, na maioria das vezes, nós, desenvolvedores, esquecemos que tudo o que fazemos é, afinal, uma questão de negócios.

Desse ponto de vista, um projeto não é um fracasso enquanto o cliente estiver disposto a pagar por ele.Tudo depende do cliente, alguns clientes têm mais paciência e entendem melhor os riscos do desenvolvimento de software, outros simplesmente não pagam se houver um atraso substancial.

De qualquer forma, sobre sua pergunta.Sempre que você desenvolve um projeto há riscos envolvidos, talvez você agende o final do projeto em uma determinada data, mas vai demorar uns seis meses a mais do que o esperado.Nesse caso, você deve equilibrar o que já gastou e o que tem a ganhar com os riscos que está assumindo.Na verdade, existe toda uma ciência chamada “tomada de decisão” que a estuda no nível do software, então seu chefe não está errado.

Vejamos algumas questões: O cliente está disposto a esperar pelo projeto?Ele está disposto a assumir certos custos excessivos?Mesmo que não o faça, vale a pena concluir o projeto assumindo os custos extras em vez de jogar fora todo o trabalho já feito?A empresa pode assumir o que já está perdido?

A verdadeira resposta para o seu problema está por trás dessas perguntas.Você não pode estabelecer um ponto e dizer, aqui, se o projeto não estiver concluído até esse momento, então será um fracasso.Quanto à sua situação específica, quem sabe?Seu chefe provavelmente tem mais informações que você, então seu trabalho é dizer a ele como está o projeto, quanto será necessário e quanto custará (em termos de horas/homem, se desejar)

Answer 2

A menos que os objetivos tenham sido claramente declarados no início do projeto, não há linhas claras entre "sucesso" e "fracasso". Freqüentemente, um projeto teria um grau variável de sucesso/falha.

Para alguns, apenas obter alguns conceitos em código seria um sucesso, enquanto outros podem medir o sucesso como a recuperação de todos os investimentos e a obtenção de lucro.Dois modos bem conhecidos de falhas são o atraso no cronograma e a deterioração da qualidade, mas no mundo real, as pessoas não parecem se importar muito com eles.

Maneiras simples de escapar do cronograma são permitir que os gerentes façam solicitações quando quiserem (recursos crescentes) e deixar os programadores codificarem o que acharem certo (codificação de cowboy).Processo de gerenciamento de mudanças, como planejamento de sprint de scrum e jogo de planejamento do XP são alguns dos exemplos.Essas são algumas das tentativas da administração e dos desenvolvedores de entregar produtos confiáveis ​​no prazo.Se uma das partes não estiver interessada em algo confiável ou pontual, o gerenciamento de mudanças não será útil.

Answer 3

Suponho que o sucesso do projeto depende de quem é o cliente.Se o cliente fossem os diretores da empresa e eles estivessem satisfeitos, o projeto foi bem-sucedido, independentemente dos fracassos ao longo do caminho.

Answer 4

Andy Rutledge escreveu um artigo muito interessante sobre sucesso.Embora o título seja Discussões pré-licitação, o artigo define ter um projeto de sucesso, o que para Andy implica:

1. Eu ou minha equipe poderemos trazer nosso melhor trabalho para o resultado final?
2. O cliente está preparado para se envolver no projeto de forma adequada?
3. O cliente está preparado para iniciar este projeto?
4. O cliente está preparado para investir confiança nas minhas ideias ou nas da minha equipe?
5. Estou ou minha equipe está preparada para cumprir ou superar os requisitos do projeto?

Este artigo foi apontado por Obie Fernandez, um consultor de sucesso, em seu Faça a agitação conferência sobre consultoria.

Answer 5

O que é gerenciamento de mudanças e como ele se aplica a um projeto?

O gerenciamento de mudanças consiste em aprovar e comunicar alterações em um projeto antes que elas aconteçam.Se alguém em seu projeto (usuário, patrocinador, membro da equipe..quem quiser adicionar uma funcionalidade, a mudança precisa ser documentada e analisada para efeito.Quaisquer alterações resultantes no escopo, orçamento e cronograma deverão ser aprovadas antes da alteração ser realizada.Estas alterações são normalmente aprovadas pelo seu patrocinador, pelo seu comité de direção ou pelo seu cliente.

Assim que as alterações forem aprovadas e aceitas, esse será o seu novo plano.Não importa qual era o orçamento ou cronograma original.

O gerenciamento de mudanças em projetos baseia-se no princípio "Sem surpresas".As pessoas certas (seu Conselho de Controle de Mudanças) precisam aprovar quaisquer alterações no Escopo, Cronograma e Orçamento antes de serem implementadas.

Uma coisa a lembrar é que pode haver certas restrições e tolerâncias explícitas ou implícitas à mudança.Talvez você precise entregar seu projeto até uma determinada data para atender aos requisitos regulatórios do governo.Ou sua organização pode ter um limite de que, quando o orçamento do projeto for 30% superior ao orçamento original, ele deverá ir para o nível "C" ou o projeto será encerrado.Investigar e declarar explicitamente esses limites e tolerâncias antecipadamente é uma boa maneira de ter projetos mais bem-sucedidos.

Onde termina o “gerenciamento de mudanças” e começa o “fracasso do projeto”?

Se um projeto cumprir o escopo, cronograma e orçamento aprovados, ele será bem-sucedido.

No entanto, ainda pode ser visto como um fracasso.As revisões pós-implementação são uma boa ferramenta para qualificar isso junto às partes interessadas (não apenas ao seu chefe).Também valeria a pena examinar a Realização de Benefícios para ver fora da caixa preta do projeto e o impacto no negócio como um todo.