Certa vez em um escritório de projetos de software recebi a missão de averiguar o porquê projetos estavam atrasando. Não dava para responder essa pergunta assim de “bate-pronto”, era preciso uma análise mais cuidadosa para a questão.
Iniciei os trabalhos com uma auditoria nos documentos mais importantes de alguns dos projetos em andamento: plano de projeto, cronograma, planilha de riscos, dentre outros. Não parei por aí, observei alguns processos da instituição relativos ao desenvolvimento de software. Verifiquei também o histórico de estabilidade da infraestrutura/ambiente da instituição, afinal, o ambiente é a plataforma sob a qual os projetos são projetados gradativamente.
Outro ponto importante da análise foi identificar que algumas das atividades de suporte ao projeto, como implementação de rotinas em banco de dados e implementação do software em servidores, eram executados por equipes diferentes daquela responsável pela condução direta dos projetos. Note, então, que algumas micro-atividades dos projetos eram executadas por equipes terceirizadas e de contratos distintos firmados pela instituição contratante do projeto, algo comum quando a TI é atividade meio. Esse cenário de múltiplas empresas contratadas executando um mesmo projeto exige uma coordenação que vale estar explicitada nos contratos em forma de acordos de nível de serviço (service level agreement), pois atrasos cometidos por uma empresa podem afetar o trabalho das outras, causando um efeito dominó no projeto. Notei que grande parte dos cronogramas de projetos não consideravam o tempo de execução dessas tarefas executadas por “terceiros”.
Observadas todas estas questões, foi possível obter ótimos “insights” ao longo da análise. A medida que fui documentando as possíveis razões, percebi que seria interessante agrupá-las em “dimensões” ou “fatores”. São elas:
- Processos, procedimentos e padrões
- Fator humano
- Risco(s)
- Infraestrutura e ambiente
Confira no mapa abaixo como ficou o agrupamento – Alguns motivos pelos quais projetos atrasam são primários, mas outros nem tanto:
Um outro ponto importante a mencionar sobre esse trabalho, foi o de constatar que alguns elementos revelados na minha verificação correspondiam com os relatos de outros autores. Não encontrei nenhum artigo, no entanto, que abordasse um cenário parecido ao que eu abordei. Ao final desse post disponibilizo alguns links para esses outros artigos.
Quando apresentei o resultado do trabalho à diretoria, me foi solicitado que essas informações fossem difundidas no escritório de projetos. A segunda etapa da missão seria elaborar um “plano de providências” para auxiliar os gerentes cujos projetos estavam atrasados. O objetivo desse documento seria estruturar uma maneira de identificar causas específicas do atraso de um projeto e com isso atacar pontualmente cada uma dessas razões, visando recuperar o tempo perdido. A aplicação e história desse “plano de providências” eu conto no próximo post.
Para mais leitura listo abaixo outros artigos sobre o porquê projetos atrasam:
- Os 8 porquês dos atrasos nos projetos
- Projetos de software: por que atrasam?
- Top 11 causes of delays in IT projects
Bom, fico por aqui. Deixe um comentário, crítica, sugestão ou necessidade. E como diz um amigo meu gerente de projetos, até a próxima e bons projetos!
5 Comentários
Excelente mapa, parabéns pelo artigo!
Parabéns pelo artigo. Ótimo mapa mental e material de apoio para diversos profissionais de TI!
Parabéns pelo artigo. Estou compartilhando com os amigos do setor.
Excelente artigo, contribuiu muito para o meu trabalho. Parabéns!
Muito bom! Era o insight que eu precisava…