|
|
|
|
||||||||||||||||||||||||||||||||||||||||
|
A seguir são apresentadas respostas à algumas questões similares às da prova que freqüentemente geram dúvidas nos candidatos à Certificação PMP. Os alunos do Curso de Preparação para Certificação PMP da PM Tech têm acesso a cerca de 1000 questões similares às da prova. Uma atividade tem um tempo estimado de 4 dias, uma estimativa otimista de 2 dias, e uma estimativa provável de 3 dias. Usando a técnica Program Evaluation and Review Technique (PERT), a estimativa do tempo pessimista para esta atividade seria:
R: Veja que não está sendo
solicitado o cálculo da estimativa (que ele já tem e é 4). O
que está sendo solicitado é o cálculdo da Pessimista. Então
(Pessimista + 4 x
MaisProvavel + Otimista) / 6 = Estimativa
(P
+ 4x3 + 2) / 6= 4
P=24-12-2
= 10 dias
Se um gerente de projeto pode alugar ou comprar um equipamento sob as mesmas condições, quantos dias por ano este teria de ser utilizado de modo que as escolhas se igualassem?
160 x
número de dias = 3200 + 80 x número de dias
Qual a real diferença entre restrições e
premissas ? Será uma restrição ao projeto, por exemplo a
indisponibilidade da organização de utilizar determinada linguagem
de programação ou plataforma de desenvolvimento e premissa que o
projeto melhor seria desenvolvido em PHP acessando Oracle sobre
Linux ?
Uma restrição é uma limitação. Quanto a
premissa, na verdade se constitui de duas proposições, das quais
se infere a conclusão. Ou seja, partindo-se do pressuposto que a
premissa seja verdadeira, a segunda proposição pode ser
concluída. Premissas envolvem riscos. Se a linguagem não pode ser
utilizada, isto é uma restrição, agora PHP/Oracle/Linux ser a
melhor opção é uma premissa. Se esta premissa estiver errada (e
PHP na verdade não for a melhor opção), o resultado não será o
esperado.
Plano estratégico é o alinhamento do resultado do projeto (produto) ao planejamento estratégico da organização contratante ? Projetos são meios de se atingir o Plano Estratégico da Organização. Em geral existe uma hierarquia (Plano Estratégico -> Programa -> Projeto -> Subprojetos). A saída do plano estratégico da organização (ou o próprio plano) é uma entrada para o desenvolvimento do plano do projeto. Se o projeto deve estar alinhado a este plano, seus resultados também devem estar. O que devo considerar como informações históricas, dados armazenados de antigos projetos ? E se não tiver dados de projetos antigos, o que devo tomar como informação histórica ? Sem dúvida dados de projetos anteriores são informações históricas. Mas também é possível utilizar bases de dados públicas, de outras instituições (CREA, por ex.), bases de dados comerciais, estudos acadêmicos, benchmarking, publicações especializadas, consultorias, etc. No PMBOK o project charter indica, segundo meu entendimento, que deve ser um anúncio formal sobre como o resultado do projeto vai influênciar sobre o negócio do cliente e a descrição do mesmo. Esta descrição não é a mesma descrição do produto que foi entrada no processo de Iniciação ? No livro que é de tua co-autoria é mostrado mais informações que devem ir no project charter, incluindo a WBS. Para a certificação devo levar em consideração somente o que está no PMBOK, certo !? O Project Charter é um anúncio aos stakeholders, informando que existe um projeto, que nossa organização vai estar engajada nele e que determinada pessoa foi alocada como gerente de projeto e que recursos estarão a disposição dele. Também passa ao GP o máximo de informações já disponíveis sobre o projeto. Se uma WBS preliminar já tiver sido feita, não há problema em passa-la. O GP, contudo, vai ter de refaze-la, bem como refazer ou revisar todas as informações que porventura passadas a ele na WBS. Outra opção é o GP participar da confecção do project charter. Neste caso ele vai colocar nesta as informações que ele mesmo levantou, inclusive a WBS, se este já tiver feito. De qualquer modo o PMBOK não cita explicitamente a WBS como componente do Project Charter. Como deve ser realizada a análise do produto, qual o foco desta análise ? A Análise do Produto visa buscar o entendimento do que deve ser o resultado do projeto. É fundamental sabemos o máximo sobre o que o projeto deve produzir/resultar, de modo a podermos fazer o correto planejamento e gerenciamento do projeto. Quem são os stakeholders? Como podemos gerencia-los? Stakeholders são os indivíduos e as organizações ativamente envolvidos ou cujos interesses podem ser positivamente ou negativamente impactados pelo projeto. Pode incluir aqueles que podem exercer influência sobre o projeto. Quem São?
Os stakeholders devem ser identificados, ter seus requerimentos determinados e estes requerimentos devem ser influenciados e gerenciados para garantir o sucesso do projeto. É uma tarefa pró-ativa. O GP deve não apenas tentar cumprir o escopo do trabalho, mas sim determinar os stakeholders e incorporar seus requerimentos. v vO GP deve ter um “Plano de Gerenciamento dos Stakeholders”, incluindo tópicos como quando eles serão envolvidos no projeto e o que farão nele:
Como deve ser o detalhamento do suporte ( que é saída do planejamento do escopo) ? A que este se refere. Podes exemplificar ? Supporting Detail (Detalhes de suporte é uma tradução melhor que detalhamento do suporte). Várias áreas tem diferentes detalhes para suportar/auxiliar seu planejamento. São documentos e informações adicionais às citadas no processo, como saídas de outros processos, novas restrições e premissas, especificações, desenhos, plantas, padrões, normas, planos anteriores, etc. Variam muito conforme a área de aplicação. Por ex., podem incuir projeções de recursos, de fluxo de caixa, cronogramas alternativos, informações sobre reservas (de tempo, recursos, de contingência, etc.).
| ||||||||||||||||||||||||||||||||||||||||
|
PM Tech Capacitação em Projetos |
Telefone de Contato: (51) 3330-8495 |
E-mail:
pmtech@pmtech.com.br |
||||||||||||||||||||||||||||||||||||||||