PDCA E CICLO DE VIDA DE PROJETOS

Metodologias e práticas de gestão de projetos utilizam, como uma das suas ferramentas, o ciclo gerencial PDCA. As letras que compõem a sigla PDCA vêm dos vocábulos em inglês: Plan (planejar), Do (executar), Check (verificar) e Action (agir corretivamente). A Figura detalha o ciclo PDCA.

Todo projeto possui um ciclo de vida durante o qual são realizados os processos gerenciais que englobam diversas áreas de atuação  (por exemplo, escopo, tempo, recursos, etc.). Os processos gerenciais, por sua vez, dividem-se em iniciação, planejamento, execução, controle e encerramento. 

A iniciação e o encerramento são específicos da área de projetos, mas os três processos intermediários (planejamento, execução e controle) apoiam-se no ciclo gerencial PDCA. Os processos do PDCA ocorrem em ciclos tendendo, de preferência, para uma espiral. Os resultados das ações de iniciação são utilizados como entrada para as ações a serem tomadas durante o planejamento. Os processos de controle ocorrem simultaneamente com os processos de execução e dependendo dos resultados da análise de execução feita no processo de controle, pode-se voltar a executar ações de planejamento, podendo ser reiniciado o ciclo com a incorporação da melhoria.

Em gestão de projetos, o PDCA engloba:

A. planejamento (P): o planejamento depende da fase de iniciação do projeto, uma vez que as atividades planejadas devem ser somente as necessárias para cumprir o escopo do projeto definido na proposta;

B. execução (D): treinar, se necessário, executar o planejado, gerenciar o projeto, documentar a execução, consultar o planejamento para as próximas atividades, acompanhar a qualidade dos produtos e atualizar o arquivo do plano do projeto no MS Project;

C. verificação (C): fazer reuniões periódicas, avaliar o executado em relação ao planejado,avaliar o desempenho do projeto, avaliar solicitações de mudança e rever o plano de riscos, se necessário;

D. ação (A): tomar as ações corretivas e fazer ajustes no planejamento, se necessário,encerrar o projeto com propostas de aproveitamento dos seus produtos do projeto e respectivos indicadores para acompanhamento dos resultados esperados.

Em projetos, considerando a singularidade de sua execução, pode ocorrer uma sobreposição entre os processos D, C e A para as atividades que nunca foram executadas antes.

Fonte : TCU, Manual de Gestão de Projetos

10 DICAS PARA DEFINIR O ESCOPO DO PROJETO

Definir o Escopo do Projeto é uma etapa de vital importância. Se não for feita da forma correta, o projeto estará fadado ao fracasso, uma vez que é o escopo que determina o que irá (e não irá) ser feito/produzido/entregue ao termino do projeto. Um escopo mal-estruturado levará inevitavelmente a falhas de cronograma e de orçamento, uma vez que os problemas decorrentes da má especificação se farão presentes e a equipe terá que achar caminhos alternativos para a execução do projeto. Por fim, um escopo mal definido resulta em um cliente insatisfeito, uma vez que o mesmo pediu X e recebeu Z, levando a uma insatisfação do executivo, do time do projeto e do gerente. O efeito cascata disso pode ser terrível, como uma caça-às-bruxas para determinar de quem foi a culpa, quando na verdade a culpa foi do escopo mal-definido.

Para evitar isso, algumas medidas muito simples podem ser adotadas, aqui vai uma lista de 10 dicas para serem usadas na hora de determinar o escopo de um projeto:

• Assegure-se de que todos sabem e entendem qual o objetivo do projeto e que haja consenso sobre o resultado final do mesmo;
• Ouça com atenção o que seu cliente descreve;
• Tente entender não o que ele lhe pede para fazer, mas sim o que ele precisa para resolver o problema que lhe apresenta;
• Descubra o que ele não quer. Muitas vezes um projeto não vai para frente por que o escopo foca em coisas que não deveriam estar lá;
• Estabeleça o que não vai ser feito no projeto enquanto o cliente ainda estiver disponível. Se ele pedir X e Y, mas você perceber que Z e W devem ser providenciados, mas somente W é da sua responsabilidade, deixe claro que Z está fora do escopo do projeto;
• Estabeleça o que será necessário para que o projeto seja atingido, defina os pressupostos, de forma que todos saibam de antemão quais as necessidades básicas do projeto antes que elas atrapalhem seu andamento;
• Seja realista quanto ao que pode ou não ser realizado, quanto mais “pé-no-chão” é o escopo, maior a chance de sucesso do projeto;
• Evite o GoldPlating. Se não faz parte do escopo do projeto, não adianta tentar agradar o cliente com aplicações/funções ‘firula’. Elas podem acabar acarretando em um atraso no cronograma;
• Não tenho medo nem pena de fazer perguntas. Pode parecer óbvio para você, mas se não estiver absolutamente claro, pergunte;
• Tenha o time de projeto (ou os gerentes dos mesmos) na mesa de reunião quando o escopo for definido, assim qualquer problema técnico ou dúvida operacional poderá ser sanada na hora, em vez de descoberta posteriormente, causando problemas para o projeto.

Isso não cobre todas as coisas que se pode fazer para assegurar um escopo coerente, realista e dentro das expectativas do cliente, mas deve minimizar a quantidade de problemas que costumam ocorrer durante a elaboração do mesmo. Usar templates também pode ser uma boa idéia, já que elas facilitam a visualização do conteúdo e servem como guia para o que deve ser observado no processo de definição do escopo.