Existem questoes que podem ser verificadas durante todo o ciclo de vida de um projeto como forma antecipada de minimizar a quantidade de estresse e problemasO ambiente de TI esta acostumado com projetos de implementacoes de sistemas cada vez mais agressivos em termos de prazos e custos. Tais projetos acabam por requerer grande esforco adicional de toda a equipe (cliente e fornecedores), gerando horas extras, descontentamentos e, em grande parte deles , atrasos, alteracoes de escopo e custos adicionais.Muitos projetos ja iniciam com incertezas em relacao ao cumprimento das metas propostas. Mas sera que todo projeto exige todo esse nivel de estresse? Nao ha outro caminho?Temos visto uma gama enorme de projetos, todos eles com metodologias aplicadas, gestao integrada, PMO, ferramentas de controle e acompanhamento semanal e ate diario, mas que com o avanco das fases iniciais geram grandes dificuldades de implementacao.Nao e necessario repetir aqui que a base para o sucesso de um projeto e a comunicacao em todas as suas camadas. Sem ela nao ha projeto bem sucedido. Mas, alem da comunicacao, uma serie de outras questoes necessitam ser verificadas para que tenhamos sucesso em cada vez mais projetos. E quando dizemos sucesso, nos referimos nao so a escopo, custo e prazo, mas tambem outro a fator de suma importancia: a satisfacao das equipes envolvidas (cliente e fornecedores).Observe estes pontos:Os requisitos foram bem detalhados e a area usuaria final esta ciente do futuro funcionamento do sistema? Em alguns casos os requisitos sao detalhados pela equipe de TI sem a participacao da area de negocios, o que aumenta a chance de alteracoes de escopo ao contato com o futuro sistema o que ocorre geralmente em fases avancadas do projeto.O esforco foi realmente bem dimensionado? Cliente e implementador estao cientes das atividades previstas para cada um e dos esforcos necessarios? Ocorre muitas vezes que atividades sao subestimadas e previstas para ocorrerem em paralelo com outras, como, por exemplo, atividades de treinamento e de testes de sistema planejados para ocorrerem em paralelo e pela mesma equipe.A participacao dos times, principalmente da area usuaria, foi definida previamente de comum acordo? E muito comum atribuir responsabilidades a areas que nao estao preparadas para executa-las. E necessario o envolvimento cada vez mais cedo das equipes, de forma a adquirir o comprometimento de tais areas e garantir o cumprimento das metas propostas.Todas as fases do projeto foram detalhadas? Muito se tem visto de atividades e responsabilidades que surgem de um dia para o outro sob a alegacao de que sao atividades comuns a todos os projetos e desta forma implicitamente inseridas a estes, sem planejamento adequado.Respostas positivas para as questoes acima diminuem o surgimento de atividades nao previstas, falta de comprometimento, atrasos, e, alteracoes de escopo.Falando sobre alteracoes de escopo, os famosos change requests, e logico e racional que surjam em alguns dos projetos, principalmente os de maior escala, mas, estes nao devem ser utilizados para acomodar atividades nao detalhadas ou justificar atrasos decorrentes de outras situacoes, como as apontadas acima.Regras de jogo definidas a priori, com a participacao de todos os envolvidos, como TI, area usuaria