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.

É isso, boa sorte com seus projetos!

GoldPlating: A adição de funções e/ou entregas num projeto que não foram requisitadas. O GoldPlating costuma desviar as atividades de seu foco e comumente leva ao temido ScopeCreep.

Leia também:
Porque Projetos Falham
Porque Projetos Falham: 20 Dicas para Gerentes de Projetos
10 Dicas para MS Office Project 2007
10 Dicas de Liderança

Resposta PMP V

Qual é a prioridade relativa num projeto entre Custo, Prazo e Qualidade?

Custo – Prazo – Qualidade
Prazo – Custo – Qualidade
Qualidade – Prazo – Custo
Custo – Qualidade – Prazo
Todas tem a mesma prioridade

Resposta correta: Todas tem a mesma prioridade. Essa foi uma pegadinha para lembrar da Restrição Tripla. Lembrem-se de que um projeto só é considerado um sucesso quando a Restrição Tripla é respeitada, ou seja: Entregue no prazo, gastando dentro do especificado e atingido os requisitos de qualidade definidos no Escopo do Projeto.

Restrição Tripla (Custo-Prazo-Qualidade) é “Uma estrutura para a avaliação de demandas conflitantes. A restrição tripla é freqüentemente representada como um triângulo em que um dos lados ou um dos cantos representa um dos parâmetros que está sendo gerenciado pela equipe do projeto.” Os componentes da Restrição Tripla devem ser monitorados em conjunto, sendo assim – em teoria, e isso é o que vale para a prova a não ser que a questão especifique o contrário – nenhum deles possui prioridade sobre os outros, pois alterações em um item implicam na maioria das vezes e alterações em pelo menos mais um componente.

Lembre-se que as respostas para a certificação devem ser escolhidas sempre pensando na melhor resposta possível.

Prepare-se para a Certificação PMP no seu próprio ritmo!

Resposta PMP II

O RISCO DE NÃO ATINGIR OS OBJETIVOS E A QUALIDADE DO PROJETO

pode ser minimizado através de um monitoramento continuo
é considerado um risco de longo prazo
será refletido no uso cotidiano do produto/serviço
B e C
todas acima

Resposta Correta: todas acima. A não-adequação final do projeto aos requisitos de qualidade é sim um risco de longo prazo, pois estes costumam ser os mais sacrificados perto do final do projeto quando problemas ocorrem (estouros de Custo e/ou Prazo), e também por que o aval do cliente só vem com o termino do projeto e a apresentação final de seus Deliverables, que pode ou não ser o que o cliente esperava/necessitava. Um delivery que não atende as necessidades do cliente tenderá a causar problemas aos seus processos, demandar retrabalho, atender com eficiência reduzida ao problema a que se dispõe a resolver e/ou até mesmo jamais ser implementado. A melhor forma de se evitar este tipo de situação é monitorar de perto os parâmetros de qualidade do projeto com uma periodicidade regular e não muito entendida, comparando o que está sendo feito com os indicadores/requisitos/objetivos/scopo do projeto e, se possível, recebendo a aprovação do cliente (e ou demais stakeholders necessários) para garantir que a qualidade esteja assegurada.

Lembre-se que as respostas para a certificação devem ser escolhidas sempre pensando na melhor resposta possível.

Delivery: São as entregas das atividades descritas na EAP (Estrutura Analítica do Projeto) e/ou os resultados das etapas do ciclo de vida do projeto. Deliveries podem ser desde documentos, serviços ou até produtos. Por exemplo: o principal delivery da fase de Planejamento é o Plano de Gerenciamento do Projeto. Enquanto o delivery de um projeto de imobiliário pode ser um prédio ou sua planta.

Stakeholders: Stakeholders são as partes interessadas envolvidas de forma direta ou indireta com o projeto. Alguns exemplos de stakeholders são o cliente, o patrocinador do projeto, o gerente do projeto, o time do projeto, a sociedade civil, o governo, a empresa concorrente, uma ONG, ou qualquer outro indivíduo/organização cujos interesses venham a cruzar com o projeto.

Prepare-se para a Certificação PMP no seu próprio ritmo!

Resposta PMP I

INFORMAÇÕES DETALHADAS SOBRE AS ATIVIDADES E COMPONENTES ENCONTRADOS NA EAP PODEM SER ENCONTRADOS:em uma Declaração de Escopo
em um Dicionário da EAP
na documentação do Escopo
na documentação do Cronograma

Resposta Correta: em um Dicionário da EAP. A EAP ainda não existe quando a Declaração do Escopo é criada. A Documentação do Escopo não necessariamente inclui os pacotes de trabalho e entregas relacionados ao projeto, muitas vezes restringindo-se às alterações feitas no mesmo. A documentação do Cronograma não apresentaria os atributos relativos a cada entrega, apenas o momento em que elas deveriam ser concluídas. Lembre-se que as respostas para a certificação devem ser escolhidas sempre pensando na melhor resposta possível.

EAP: A Estrutura Analítica do Projeto é uma decomposição das Atividades necessárias para chegar aos objetivos do projeto, normalmente caracterizada como uma hierarquia em árvore orientada a resultados. Cada Atividade é desmontada até seu menor componente, a Entrega. Necessariamente, a entrega é o produto final daquela atividade, seja uma parte do software, um documento, um teste, ou o final de uma etapa do projeto.

Dicionário da EAP: É um documento que detalha todas as entradas dos pacotes de trabalho da EAP, bem como traz os requisitos relacionados aos mesmos, podendo também listar o que não é parte daquele trabalho. O Dicionário apresenta os atributos das entregas e atividades, desde especificações técnicas, anotações, recomendações feitas pelo cliente, medidas, cores, e quaisquer outras informações que forem relevantes para que as mesas sejam concluídas dentro das expectativas dos stakeholders e necessidades do projeto.

De agora em diante, as questões para Certificação PMP serão postadas quinzenalmente para a sua comodidade todo dia 1º e 15 de cada mês.

Prepare-se para a Certificação PMP no seu próprio ritmo!

Por que projetos falham?

Não é terrível quando um projeto vai pelo ralo? A pior parte é que isso, segundo estatísticas, acontece pelo menos 70% das vezes segundo pesquisa do Standish Group. Parece muito, mas se você levar em consideração a Restrição Tripla (Custo-Tempo-Qualidade), um projeto só é um sucesso se conseguir atender aos requerimentos e especificações do escopo, ou seja, respeitar a Restrição Tripla.

Mas fora isso… quais as razões que levam um projeto ao fracasso? Aqui vai uma lista dos maiores problemas que costumam ser a sentença de morte da maioria dos projetos. A posição dos mesmos é a minha opinião sobre seu impacto no projeto, e a quantidade de Caveiras, o número de ocorrências do mesmo nas minhas pesquisas.

1. Falta de suporte do sponsor
2. Falta de envolvimento do cliente
3. Pouca ou ausência de habilidades interpessoais
4. Gerenciamento de Comunicações falho ou inexistente
5. Objetivos e metas mal definidas
6. Escopo do projeto mal definido
7. Scope Creep
8. Planejamento falho ou inexistente
9. Estimativas de tempo/recursos não realistas
10. Baixa integração do time
11. Má alocação de recursos materiais e humanos
12. Gerenciamento de expectativas do cliente
13. Inexistência ou mal uso de uma metodologia de gerenciamento de projetos
14. Gerenciamento de Riscos inexistente
15. Falta ou mal uso de um controle de mudanças
16. Pouco ou nenhum tempo para testes

Scope Creep: O temido Scope Creep acontece quando o Escopo do projeto não para de ser alterado, tornando-se sempre maior do que originalmente estava previsto, sem que nenhum recurso seja adicionado ou algum tipo de planejamento.

Esta lista não exaure o assunto, nem engloba todos os motivos possíveis, muito menos as nuances em que cada item pode se desdobrar, mas já serve como um aviso para navegantes de primeira viajem. Vale também lebrar que o Gerente de Projetos é o guardião do projeto que lhe foi confiado e, irrevogavelmente, a culpa sobre a falha do projeto irá sim cair sobre seus ombros. Mas agora já dá para saber com o que se preocupar. Boa sorte para todos nós.

Um exemplo real: Estávamos encarregados de conseguir o financiamento para uma ONG, para um centro de treinamento profissionalizante e; para o treinamento de voluntários para o trabalho em projetos sociais. Os seguintes fatores foram decisivos para o desfecho sofrível de ambos os projetos:

• Scope Creep: Cada reunião com o financiador do projeto terminava com uma alteração no escopo que tornava o projeto ainda maior do que o planejado sem, entretanto, levar em consideração os recursos alocados e o prazo estipulado;
• Estimativas de tempo/recursos nada realistas: Além de mim, eram mais três voluntários responsáveis por fazer toda as pesquisas necessárias, bem como escrever o projeto e atender às reuniões;
• Escopo do Projeto mal definido: a ONG não sabia exatamente o que queria e isso resultava em retrabalho a cada reunião;
• Má alocação de recursos materiais e humanos: Além de serem poucas pessoas responsáveis por toda a parte pesada do projeto, boa parte do time de voluntários não estava devidamente alocada, nem tinham o devido treinamento para executar as atividades que lhes foram confiadas.

Leia também:
Por que Projetos Falham: 20 Dicas para Gerentes de Projetos

Leia mais em:
http://www.projectperfect.com.au/info_it_projects_fail.php
http://www.itweb.co.za/office/ast/0107120730.htm
http://www.coleyconsulting.co.uk/failure.htm
http://www.onlamp.com/pub/a/onlamp/2006/06/20/why-do-projects-fail.html
http://it.toolbox.com/blogs/lpuleo/why-do-projects-fail-960
http://www.pm4girls.elizabeth-harrin.com/?p=185
http://www.jiscinfonet.ac.uk/infokits/project-management/projects-fail
http://itmanagement.earthweb.com/cio/article.php/2201981
http://en.wikipedia.org/wiki/Kitchen_sink_syndrome