TEST IPC009

Ao construir o plano de trabalho (Work Plan) no iPC, qual prática aumenta a confiabilidade do cronograma?. Inserir durações genéricas e evitar vínculos, simplificando a manutenção. Decompor o trabalho em pacotes mensuráveis (WBS), estimar durações com base em esforço e recursos, aplicar calendários/feriados e modelar dependências lógicas. Focar apenas em marcos, deixando atividades detalhadas para a execução. Bloquear a edição do plano até o próximo gate para manter estabilidade.

Na seleção de ferramentas PPM segundo o guia do iPC, qual princípio deve guiar a escolha da solução?. Alinhar-se ao ecossistema do cliente e suportar coleta dos dados essenciais (cronograma, recursos, RAID, métricas), priorizando integração e governança sobre “feature count”. Escolher sempre a ferramenta com mais funcionalidades, independentemente do ambiente do cliente. Padronizar em um único produto (ex.: MS Project) para todos os programas, evitando exceções. Optar pela alternativa de menor custo de licença, mesmo que exija retrabalho manual em relatórios.

Qual prática melhor previne “scope creep” durante a execução do projeto?. Aceitar pequenas mudanças sem Change Request para evitar burocracia. Incluir buffers de prazo e custo para absorver mudanças sem alterar o baseline. Repriorizar o backlog ad hoc conforme pedidos dos stakeholders. Manter um baseline de requisitos, aplicar controle formal de mudanças, usar RTM para rastrear impactos e seguir a governança de aprovações.

Quando uma premissa crítica (Assumption) se mostra inválida durante a execução, qual é a ação correta segundo o iPC?. Remover a premissa do RAID e seguir, pois premissas não exigem ação. Converter a premissa em risco ou issue conforme o impacto, atualizar o RAID com dono/plano/data e refletir no cronograma e nas comunicações. Apenas informar verbalmente ao time; ajustes formais podem esperar. Abrir imediatamente um Change Request, mesmo sem análise de impacto.

No contexto de Métricas e Reporting em iPC, qual afirmação descreve melhor o propósito da análise de variação no ciclo de governança?. Reportar apenas números consolidados, sem detalhar causas, para agilizar a reunião. Comparar forecast com forecast para mostrar consistência na tendência. Comparar baseline, realizado e forecast, identificar causas‑raiz das variações e definir ações corretivas/preventivas com donos e prazos para acompanhamento. Focar exclusivamente nas variações financeiras, deixando cronograma e qualidade para times técnicos.

Ao usar o MS Project para o Work Plan no contexto do iPC, qual prática é recomendada para refletir restrições sem comprometer o recalculo automático do cronograma?. Modelar as restrições via vínculos lógicos apropriados (FS/SS/FF/SF) e leads/lags, evitando impor datas “Must Start/Finish On”. Definir “Must Start On” para todas as tarefas críticas para garantir datas fixas. Aplicar “Deadline” em todas as tarefas para “travar” o caminho crítico. Utilizar calendário 7x24 para simplificar o planejamento e reduzir dependências.

No ciclo financeiro do iPC, qual definição está correta sobre CTC e ETC?. CTC é o custo incorrido até a data; ETC é o custo total planejado. CTC é a projeção do custo remanescente até a conclusão; ETC é o custo incorrido até a data. CTC é o custo total estimado para concluir o contrato (incorrido + remanescente), enquanto ETC é o custo remanescente para completar o trabalho. CTC e ETC são sinônimos do orçamento aprovado (BAC).

Em iniciativas Ágeis no contexto do iPC, como os Core Metrics e a governança devem ser alimentados de forma consistente?. Usar apenas o burn-down de sprint e dispensar métricas de prazo/custo do iPC. Mapear entregáveis e sprints a marcos/gates, integrar backlog e burn-down ao plano de trabalho, e reportar SPI/CPI a partir de um baseline acordado. Tratar sprints como atividades de duração fixa sem dependências, eliminando caminho crítico. Reportar somente throughput de histórias por sprint como proxy de desempenho total.

Durante a fase Co-Create (Start Up) no iPC, qual é um resultado-chave a ser estabelecido antes do início da execução?. Um backlog técnico completo e imutável para todo o programa. Contratação de 100% da equipe no Day 1, independentemente do plano de capacidade. Garantia de que todas as dependências externas já estejam resolvidas. Modelo de governança acordado (com cadências), pacote de Core Metrics, e plano de trabalho inicial com baseline e entregáveis alinhados.

No contexto do RAID em iPC, qual afirmação diferencia corretamente risco de issue?. Risco é um evento futuro incerto; issue é um problema que já ocorreu e requer ação imediata. Risco é um problema atual; issue é uma premissa. Risco sempre exige ação corretiva; issue requer apenas monitoramento. Risco e issue são equivalentes e tratados da mesma maneira.

No iPC, por que é importante manter uma “Single Source of Truth” (SSOT) para plano, RAID e métricas?. Para permitir versões paralelas do plano e escolher a mais conveniente em cada governança. Para facilitar a atualização local por cada time, mesmo que cause divergências temporárias. Para assegurar consistência entre cronograma, RAID e Core Metrics, reduzir retrabalho e suportar decisões baseadas em dados confiáveis. Para manter a confidencialidade dos dados financeiros, isolando-os do restante do reporting.

Em uma análise de variação apresentada no pacote de Core Metrics, o que não pode faltar para tornar a governança acionável?. Apenas uma tabela com realizado versus planejado, sem comentários. Gráficos de tendência dos últimos meses, sem detalhar causas. Relação de riscos aberta, sem conexão explícita com a variação. Causa‑raiz da variação, quantificação do impacto e plano de ação corretivo/preventivo com dono e prazo.

No gerenciamento financeiro do iPC, qual prática ajuda a evitar reconhecimento de receita desalinhado com a entrega?. Alinhar marcos de faturamento a entregáveis aprovados com critérios de aceite definidos e reconciliar o revenue recognition com o plano e o contrato. Reconhecer receita proporcional ao esforço incorrido, independentemente do modelo contratual. Postergar todo reconhecimento de receita para o final do projeto para reduzir riscos. Basear o reconhecimento apenas em ordens de compra (PO), sem considerar critérios de aceite.

Com SPI < 1 indicando atraso próximo a um gate, qual é a abordagem correta segundo o iPC?. Rebaselinar imediatamente o cronograma para remover o atraso do dashboard. Suspender a execução até o próximo comitê de governança decidir os próximos passos. Elaborar e executar um plano de recuperação (ex.: remover bloqueios, realocar recursos para o caminho crítico, fast‑tracking/crashing quando aplicável), refletir no forecast e, se houver impacto no baseline, submeter Change Request. Aumentar horas extras sem registrar variações, para evitar ajustes no forecast.