sexta-feira, 31 de julho de 2020

Grupo de Processos de Finalização

O grupo de processos de Finalização (ou Encerramento) inclui os processos usados para finalizar, formalmente, todas as atividades do projeto ou de uma fase do projeto, entregar o produto finalizado ou encerrar um projeto cancelado (isso pode acontecer quando, por qualquer motivo, a empresa decide cancelar o projeto por motivos estratégicos, financeiros, por exemplo). O grupo de processos de Finalização deve conter:
  • A confirmação de que o trabalho está de acordo com os requisitos;
  • O aceite formalizado (assinado) do produto ou serviço pelo cliente;
  • Relatórios finais de desempenho;
  • Arquivamento dos registros do projeto e toda a documentação produzida;
  • Atualização da base de conhecimento de lições aprendidas;
  • Encerramento do projeto; e
  • Liberação dos recursos do projeto.
Em resumo, o grupo de processos de Finalização, quando terminado, verifica se os processos definidos estão finalizados dentro de todos os grupos de processos para encerrar o projeto (ou uma fase do projeto), conforme adequado, e estabelece, formalmente, que o projeto (ou a fase do projeto) está concluído. Dentro do grupo de Processos de Finalização encontramos dois processos que podem ser vistos na Figura.

Processos do Grupo de Processos de Finalização.
Fonte: Baseado em PMI (2013).

quinta-feira, 30 de julho de 2020

Grupo de Processos de Controle e Monitoramento

O grupo de processos de Monitoramento e Controle ocorre em conjunto com a Execução, mas o foco é a verificação e a medição do trabalho para confirmar se o que foi executado está de acordo com o planejado.

O Monitoramento e Controle envolvem:

  • Medição do desempenho do projeto em comparação com as linhas de base;
  • Determinação de variações e consequentes recomendações de ações corretivas ou preventivas;
  • Avaliação das ações corretivas adotadas;
  • Auditoria de riscos;
  • Execução de relatórios de desempenho; e
  • Administração de contratos.
Dentro do grupo de Processos de Controle e Monitoramento encontramos dez processos que podem ser vistos na Figura.

Processos do Grupo de Processos de Controle e Monitoramento.
Fonte: Baseado em PMI (2013).

Se, eventualmente, forem detectadas diferenças entre o planejado e o executado, medidas corretivas são tomadas para que o projeto volte ao que foi planejado. A verificação e a medição consideram as linhas de base (planejamento inicial) de escopo, tempo, custo, qualidade, riscos identificados e qualquer fator definido no PGP (Plano de Gerenciamento do Projeto), incluindo a ocorrência de novos riscos para o cumprimento das metas e objetivos do projeto.

quarta-feira, 29 de julho de 2020

Grupo de Processos de Execução

O grupo de processos de Execução é a etapa em que o trabalho do projeto é realizado. Este grupo de processos tem como objetivos:
  • ✓ A mobilização da equipe de execução do trabalho;
  • ✓ A execução do trabalho de acordo com o planejamento;
  • ✓ Seguir as especificações e padrões estabelecidos;
  • ✓ A implantação de mudanças aprovadas e reparo de defeitos;
  • ✓ O desenvolvimento da equipe; e
  • ✓ A seleção e contratação de fornecedores.

A Execução é a etapa que utiliza a maior parte dos recursos, sejam materiais, financeiros ou humanos. Em resumo, o grupo de processos Execução envolve:

  • Alocação e desenvolvimento da equipe de execução do trabalho;
  • Alocação dos recursos necessários à execução do trabalho;
  • Execução do Plano de Gerenciamento do Projeto; e
  • Execução do trabalho do projeto.
Este grupo de processos também aborda o escopo definido na declaração do escopo do projeto e implanta as mudanças aprovadas. No grupo de Processos de Execução encontramos oito processos, apresentados na Figura.

Processos do Grupo de Processos de Execução.
Fonte: Baseado em PMI (2013).

terça-feira, 28 de julho de 2020

Grupo de Processos de Planejamento

O grupo de processos de Planejamento possui o maior número de processos de todo o guia, contendo 24 de um total de 47 processos definidos na 5ª edição do PMBoK.

É nessa etapa do projeto que todas as tarefas a serem executadas no projeto devem ser definidas, incluindo as atividades:

  • ✓ Planejar Gerenciamento do Escopo;
  • ✓ Planejamento dos custos das tarefas;
  • ✓ Planejar Gerenciamento do Custo (geral do projeto e sobre a sua forma de controle e monitoração);
  • ✓ Planejar o prazo de execução cada uma das atividades do projeto;
  • ✓ Planejar o Gerenciamento do Tempo (geral do projeto e sobre a sua forma de controle e monitoração);
  • ✓ Planejar as aquisições que devem ser realizadas para o desenvolvimento do projeto (fornecedores, por exemplo);
  • ✓ Planejar os recursos humanos envolvidos no projeto;
  • ✓ Planejar os riscos aos quais o projeto está sujeito;
  • ✓ Planejar o plano de respostas aos riscos avaliados;
  • ✓ Planejar o Gerenciamento das Partes Interessadas (stakeholders).

Este grupo de processos envolve a determinação do escopo do projeto (o que deve ser feito), a definição da equipe e suas funções e responsabilidades (quem deve fazer), o desenvolvimento do cronograma (quando deve ser feito) e do orçamento (a que custo), a determinação de padrões e métricas de qualidade, a identificação de riscos, a determinação do que deve ser comprado ou adquirido, a execução do Plano de Gerenciamento do Projeto (como deve ser feito) e sua aprovação e a reunião inicial do projeto.

Em resumo, o grupo de processos de Planejamento envolve:

  • Documentar e publicar a Declaração de Escopo do Projeto;
  • Desenvolvimento da EAP (Estrutura Analítica do Projeto) ou WBS (WorkBreakdownStructure);
  • Desenvolvimento do Cronograma do Projeto;
  • Determinação de Necessidades de Recursos;
  • Definição de Compras e Aquisições;
  • Desenvolvimento do Orçamento do Projeto;
  • Desenvolvimento e publicação do Plano de Gerenciamento do Projeto.

À medida que forem surgindo novas informações sobre o projeto (dependências, riscos, premissas e restrições adicionais) estas serão identificadas ou resolvidas.

Um dos documentos mais importantes gerados neste grupo de processos é o PGP (Plano de Gerenciamento do Projeto). Este documento detalha toda a gestão do projeto e é atualizado constantemente durante o andamento do projeto. Para que este documento seja inicialmente confeccionado é necessário o Termo de Abertura do Projeto, que é a saída do grupo de processos de Iniciação. Os 24 processos do grupo de Planejamento podem ser vistos na Figura.

Processos do Grupo de Processos de Planejamento.
Fonte: Baseado em PMI (2013).

segunda-feira, 27 de julho de 2020

Grupo de Processos de Iniciação

O grupo de processos de Iniciação apresenta processos que facilitam a autorização formal para início de um novo projeto. O escopo inicial é definido, os recursos financeiros iniciais são reservados e, se ainda não foi designado, o gerente do projeto é indicado.

Antes de iniciar as atividades do grupo de processos de Iniciação, os requisitos ou as necessidades de negócios da empresa são documentados. Esta é a etapa da análise de viabilidade do projeto feita por meio de um processo de avaliação das alternativas, desenvolvendo-se descrições claras dos objetivos, para, então, selecionar a melhor. A alternativa escolhida contém uma documentação com informações importantes sobre o novo projeto e o TAP – Termo de Abertura do Projeto ou Project Charter. Quando o TAP é aprovado, o projeto é oficialmente autorizado.

O Project Charter é um dos mais importantes documentos de saída e contém as seguintes informações: nome do projeto, nome do Gerente do Projeto, nome do patrocinador do projeto (sponsor), escopo do projeto, principais riscos, prazos, investimento (orçamento), principais fases do projeto, principais envolvidos, assinatura e aprovação do patrocinador. Apenas dois processos estão definidos no grupo de Iniciação.

Processos do grupo de Processos de Iniciação.
Fonte: Baseado em PMI (2013).

Esses processos são executados fora do escopo de controle do projeto, o que pode tornar os limites do projeto menos visíveis para as entradas iniciais do projeto. O limite de um projeto é definido como o momento em que o início ou a conclusão do projeto ou da fase do projeto é autorizado.

Limites do projeto.
Fonte: (PMI, 2013; p. 54).

domingo, 26 de julho de 2020

Interação entre os Grupos de Processos

Os grupos de processos estão ligados pelos objetivos que produzem e como já vimos, as saídas de um processo se tornam entradas para outro processo. O mesmo ocorre com os grupos de processos do PMBoK. Por exemplo, o grupo de processos de Planejamento fornece o plano de gerenciamento do projeto e a declaração do escopo do projeto ao grupo de processos de Execução, que atualiza o plano de gerenciamento do projeto conforme o projeto se desenvolve. A Figura ilustra como os grupos de processos interagem e o nível de sobreposição em momentos diferentes dentro de um projeto.

Interação entre os grupos de processos
Fonte: (PMI, 2013; p. 51).

No que se segue, cada um dos cinco grupos de processo será detalhado, de acordo com a 5ª edição do PMBoK-PMI (2013).

sábado, 25 de julho de 2020

Grupos de Processos do PMBoK e o PDCA

Os grupos de processos de gerenciamento de projetos têm grande correspondência com o conceito do ciclo PDCA (Plan – Do – Check – Act).


Ciclo PDCA.

O PDCA é um ciclo de desenvolvimento que tem foco na melhoria contínua e procura tornar mais claros e ágeis os processos envolvidos na execução da gestão. É aplicado para atingir resultados dentro de um sistema de gestão e usado em qualquer tipo de organização.

Resumidamente, o PDCA se inicia pelo planejamento, seguido de um conjunto de ações planejadas que são executadas, depois se verifica o que foi feito (se estava de acordo com o planejado) e, finalmente, toma-se uma ação para eliminar ou diminuir defeitos no produto ou na execução. Enfim, as etapas do ciclo PDCA são:

[P]Plan (planejamento): fixar uma meta, analisar os dados relacionados ao problema, analisar o processo e elaborar o plano de ação.

[D]Do (execução): executar as atividades de acordo com o plano de ação.

[C]Check (verificação): monitorar e avaliar periodicamente os resultados, comparando-se o planejado com o executado pelas métricas conhecidas como KPIs (Key Performance Indicator).

[A]Act (ação): agir conforme a avaliação e, se necessário, confeccionar novos planos de ação, com o intuito de melhorar a qualidade, eficiência e eficácia, melhorando a execução e corrigindo falhas.

Dicas do que se deve fazer para evitar prejuízos no ciclo PDCA:

  • Planeje (plano de ação);
  • Defina métodos que serão usados para se chegar nas metas;
  • Prepare a equipe de projeto;
  • Monitore se a execução está de acordo com o planejamento;
  • Tome ações preventivas e não tome medidas corretivas; e
  • Não deixe o PDCA tornar-se um processo repetitivo.

Agora que conhecemos os grupos de processos do PMBoK e o ciclo PDCA, vale lembrar que o ciclo PDCA é contínuo e repetitivo e o projeto é temporário, com data de início e fim. Relacionando o ciclo PDCA e os grupos de processos do PMBoK temos:

  • O grupo de processos de Planejamento do PMBoK corresponde ao Planejar(Plan) do PDCA;
  • O grupo de processos de Execução do PMBoK corresponde ao Fazer (Do) do PDCA;
  • O grupo de processos de Monitoramento e Controle do PMBoK englobam Verificar (Check) e Agir (Act) do PDCA; e
  • Adicionalmente, como o projeto é temporário, o PMBoK apresenta o grupo de processos de Iniciação e de Finalização do projeto.

sexta-feira, 24 de julho de 2020

Grupos de Processos do PMBoK

O guia do Conjunto de Conhecimentos em Gerenciamento de Projetos é a soma do conhecimento dentro da profissão de gerenciamento de projeto. O PMBoK completo inclui práticas comprovadas tradicionais que são amplamente aplicadas, além de práticas inovadoras que estão surgindo na profissão, e as que têm um consenso generalizado sobre o seu valor e utilidade.

Também se destina a fornecer um vocabulário comum entre a profissão e a prática para que se possa falar e escrever sobre gerenciamento de projeto.

O frame work PMBoK na sua 5ª edição é composto por 5 grupos de processos, 10 áreas do conhecimento e 47 processos de gerenciamento de projetos.

Os grupos de processo (Iniciação, Planejamento, Execução, Controle e Encerramento) organizam os processos de gerenciamento de projetos, mais detalhadamente, ao longo do tempo. Portanto, os grupos de processo são estados em que um projeto pode estar desde o início até sua conclusão.

Grupo de Processos

O gerenciamento de projetos é realizado por meio de processos, usando conhecimentos, habilidades, ferramentas e técnicas do gerenciamento de projetos que recebem entradas e geram saídas.

Normalmente, um projeto apresenta atividades em uma etapa inicial, quando se define o escopo do projeto. Encerrada essa etapa, seguem-se uma ou mais etapas intermediárias com atividades em que o projeto é planejado, executado e monitorado, culminando com atividades em uma etapa final, na qual o produto ou serviço é aceito e entregue ao cliente.

O PMBoK 5ª edição representa essas etapas em cinco grupos de processos, quais sejam:

  1. Grupo de Processos de Iniciação: define e autoriza um projeto ou uma nova fase de um projeto.
  2. Grupo de Processos de Planejamento: define o escopo, os objetivos, planeja e detalha o projeto.
  3. Grupo de Processos de Execução: reúne recursos, pessoas e executa o plano de projeto, visando satisfazer as suas especificações.
  4. Grupo de Processos de Monitoramento e Controle: controla as mudanças, monitora o desempenho e o progresso do projeto e acompanha riscos.
  5. Grupo de Processos de Encerramento (ou Finalização): encerra formalmente um projeto ou fase e libera recursos.

Grupos de processos do Gerenciamento de Projetos.
Fonte: (PMI, 2013; p. 50).

Importante ressaltar, que os grupos de processos não são fases do ciclo de vida do projeto. Além disso, a experiência em GP indica que há diferentes formas de gerenciar um projeto. Os grupos de processos e os processos que os compõem devem ser considerados como guias para a aplicação de conhecimentos e habilidades de GP durante o projeto. A aplicação dos processos é iterativa e muitos podem ser repetidos durante o projeto.

quinta-feira, 23 de julho de 2020

Partes Interessadas do Projeto

As partes interessadas do projeto (stakeholders) são pessoas e organizações que possuem interesses envolvidos no projeto ou que podem ser afetados como resultado, podendo exercer algum tipo de influência no projeto.

É importante que a equipe de GP identifique as partes interessadas, verificando necessidades e expectativas e gerenciando sua influência. Esse princípio é tão importante que recebeu na 5ª edição do PMBoK uma área de conhecimento com seus processos específicos.

As principais partes interessadas em todo o projeto incluem o gerente de projetos, clientes/usuários, organização executora, membros da equipe do projeto, equipe de gerenciamento de projetos, patrocinador, influenciadores e PMO (se existir na organização).

Stakeholders de um projeto.
Fonte: (PMI, 2013; p. 31).

Teixeira (2013) relata que os stakeholders podem ser do tipo passivo, reativo e ativo. Os stakeholders reativos costumam acreditar que o projeto poderá interferir de forma negativa em seu trabalho e buscam justificativas para apontar pontos de insucesso. Este tipo pode oferecer como risco, caso tenha alguma influência mais significativa, impactos negativos nos pilares de escopo, prazo, custo e qualidade. Os stakeholders passivos, geralmente, acreditam que o projeto não impactará suas atividades. Sua atuação limitada pode oferecer risco ao projeto, caso uma informação que chegue a ele seja negligenciada ou desconsiderada. Os stakeholders ativos, geralmente, atuam de forma direta no processo de gerenciamento organizacional e podem ver oportunidades no projeto, acreditando que possa afetar positivamente seu trabalho. O cuidado em relação a este tipo é que suas expectativas podem ser muito altas, distanciando-se do escopo do projeto.

quarta-feira, 22 de julho de 2020

Estruturas Organizacionais

Mesmo com todas as atividades até aqui descritas na condução de um projeto, a estrutura da organização afeta diretamente o resultado do projeto porque influencia a autoridade do gerente de projetos.

Os projetos e seu gerenciamento são realizados em um contexto mais amplo dentro das organizações e sua compreensão contribui para garantir que o trabalho seja conduzido e gerenciado de forma alinhada tanto com as metas como com as práticas estabelecidas pela governança organizacional. As organizações usam a governança para estabelecer a sua direção estratégica e os seus parâmetros de desempenho. As atividades de GP devem estar alinhadas com os negócios e, caso haja mudanças, os objetivos do projeto devem ser realinhados.

De acordo com o PMBoK-PMI (2013), a estrutura organizacional pode influenciar a forma como os projetos são conduzidos, pois afeta a disponibilidade dos recursos. As estruturas organizacionais variam de funcionais a projetizadas, com diversas estruturas matriciais entre elas. O Quadro mostra as características do projeto em relação ao tipo de estrutura da organização.

Características do projeto em relação à estrutura da organização.
Fonte: (PMI, 2013; p. 22).

A estrutura mais apropriada para a condução de um projeto é a estrutura organizacional por projeto ou projetizada, porque todos os recursos envolvidos são disponibilizados e o gerente de projetos tem mais autoridade e independência, facilitando a comunicação e integração da equipe e, consequentemente, aumentando a probabilidade de sucesso e redução de riscos do projeto.

Estrutura projetizada.
Fonte: (PMI, 2013; p. 25).

O PMO é um escritório de projetos e uma unidade da estrutura organizacional que unifica e controla a gestão de projetos sob seu domínio.

“Há vários tipos de estruturas de PMO nas organizações e elas variam em função do seu grau de controle e influência nos projetos da organização, tais como:

  • De suporte: os PMOs de suporte desempenham um papel consultivo nos projetos, fornecendo modelos, melhores práticas, treinamento, acesso a informações e lições aprendidas com outros projetos. Este tipo de PMO atua como um repositório de projetos. O nível de controle exercido pelo PMO é baixo.
  • De controle: os PMOs de controle fornecem suporte e exigem a conformidade por meio de vários meios. A conformidade pode envolver a adoção de estruturas ou metodologias de gerenciamento de projetos usando modelos, formulários e ferramentas específicas, ou conformidade com a governança. O nível de controle exercido pelo PMO é médio.
  • Diretivo: os PMOs diretivos assumem o controle dos projetos pelo seu gerenciamento direto. “O nível de controle exercido pelo PMO é alto.”

Fonte: (PMI, 2013; p. 11)

terça-feira, 21 de julho de 2020

Características do Ciclo de Vida de um Projeto

O ciclo de vida de projeto define as partes (ou fases) de um projeto que liga o início ao fim do projeto em sua totalidade.

Normalmente, quando uma organização deseja iniciar um novo projeto deve seguir as etapas:

1) Inicialmente, deve-se analisar a viabilidade do projeto. Isso é de responsabilidade do gerente de projetos quando do início do ciclo de vida do projeto.

2) Em seguida, deve-se avaliar a transição de uma fase para outra do projeto. Normalmente, essas fases são sequenciais e cada uma é entregue quando existe alguma forma de transferência técnica ou entrega. As entregas devem ser aprovadas formalmente pelas partes interessadas (isso garante que essas entregas intermediárias estejam de acordo com o solicitado inicialmente), exceção feita quando os riscos são baixos.

3) Finalmente, deve-se definir o ciclo de vida, que leva em consideração algumas atividades como:

  • O trabalho técnico e especializado de cada uma das fases;
  • Quando as entregas de cada fase devem ser produzidas e entregues, revisadas e validadas;
  • Quem são os envolvidos em cada fase do projeto; e
  • Como será feito o controle e aprovação de cada fase do projeto.

Um ponto importante aqui é lembrar que as fases do ciclo de vida de um projeto não são a mesma coisa que Grupos de Processos do gerenciamento de projetos. As fases aqui referenciadas são as partes do projeto que são entregues sequencialmente.

segunda-feira, 20 de julho de 2020

O Ciclo de Vida de um Projeto

Os projetos de software podem ser divididos em partes (ou fases) para melhorar o controle gerencial do projeto como um todo. Além disso, podemos melhorar o controle das interfaces deste novo projeto com as operações já existentes. Essas partes do projeto (ou fases do projeto) são denominadas de ciclo de vida de um projeto.

De acordo com o guia PMBoK – PMI (2013), a maior parte dos ciclos de vida de projetos apresentam características em comum, quais sejam:

  • Fases (ou partes do projeto), que geralmente são sequenciais.
  • Na fase inicial de um projeto, os níveis de custos e de pessoal envolvido são baixos; nas fases intermediárias, esses níveis chegam ao máximo e na fase de finalização vão diminuindo.

Ciclo de vida de um projeto.
Fonte: PMI (2013, p. 39).

  • No início do projeto, os níveis de incerteza e risco de não atingir os objetivos iniciais propostos são mais altos, pois não há todo o detalhamento necessário no processo, mas essa certeza vai sendo obtida, cada vez mais, durante o andamento do projeto.
  • Assim como os níveis de incerteza e riscos de não atingir os objetivos iniciais do projeto são altos no início do projeto, o mesmo ocorre com a capacidade das partes interessadas (stakeholders) de influenciarem as características do produto do projeto e isso em razão da falta de detalhamento do projeto nessa etapa. Além disso, os custos das mudanças (alterações de escopo, por exemplo) e da correção de erros, geralmente, aumentam conforme o projeto avança.

Custo das mudanças ao longo de um projeto.
Fonte: (PMI, 2013; p. 40).

domingo, 19 de julho de 2020

Software de Vendas – Organizando o Projeto

A seguir apresentamos o exemplo de uma situação de organização do projeto. Em uma sala de reunião na empresa CPI, uma indústria (fictícia), que fabrica produtos de consumo para uso residencial e comercial. Os nossos personagens são: Ivan, executivo da área de vendas e William, gerente de projetos. É a primeira reunião entre o executivo de vendas e o gerente de projetos e, neste momento, estão analisando como ficará a organização do projeto. Vamos acompanhar o diálogo entre eles:

  • Ivan: Bom dia, William! Depois que tivemos nosso primeiro contato, fiquei muito empolgado pela forma como abordou os passos iniciais que devemos seguir neste projeto. E agora, quais as recomendações?
  • William: Bom Ivan, o importante agora é identificarmos os principais envolvidos neste projeto e que, de alguma forma, estarão envolvidos diretamente ou indiretamente no projeto. Você é o nosso principal stakeholder, o nosso patrocinador, já que você estará financiando este projeto. Temos uma estrutura projetizada na CPI, o que facilita o meu trabalho como gerente de projetos aumenta as chances de sucesso e minimiza os riscos do projeto, pois toda a equipe estará focada todo tempo no projeto. Neste momento, queria inicialmente conhecer e identificar as necessidades do projeto para que possamos estabelecer os objetivos claramente a todos. Nesta primeira etapa, o objetivo é construirmos um documento gerencial que conterá basicamente:
    • Os objetivos do projeto;
    • Riscos;
    • Stakeholders envolvidos inicialmente;
    • Patrocinador;
    • Escopo do Projeto;
    • Custo do projeto; e
    • Prazo do Projeto.

    Este documento é o que chamamos Termo de Abertura do Projeto (TAP) ou Project Charter. Após definirmos esses pontos, vamos formalizá-lo para que todos os envolvidos tenham claros os pontos acordados. A partir daí, iniciamos as etapas de Planejamento, Execução, Controle/Monitoramento e Encerramento do Projeto.

  • Ivan: Perfeito William. Para esse detalhamento inicial, vou chamar mais algumas pessoas que estarão trabalhando diretamente neste projeto e que poderão dar os detalhes necessários para a preparação do Project Charter. E eu, como patrocinador, terei de assinar esse documento?
  • William: Sem dúvida. Você como patrocinador do projeto é o principal stakeholder é importante para todos que saibam que está de acordo e tem conhecimento do escopo do projeto, custo e prazo, para que possamos garantir a qualidade deste projeto.
  • Ivan: Ok William, mãos à obra.

sábado, 18 de julho de 2020

Fatores Conflitantes de um Projeto

O Gerenciamento de Projetos (GP), segundo o guia PMBoK – PMI (2013, p. 5), “é a aplicação do conhecimento, habilidades, ferramentas e técnicas às atividades do projeto para atender aos seus requisitos”. O GP inclui atividades como o levantamento dos requisitos, a identificação das necessidades e expectativas dos stakeholders, a definição de procedimentos para que haja comunicação ativa entre os stakeholders etc. Mas também trata do gerenciamento dos aspectos conflitantes do projeto, como:
  • Escopo;
  • Qualidade;
  • Cronograma;
  • Orçamento;
  • Recursos; e
  • Riscos.

Esses fatores não são os únicos a gerar conflitos, mas estão relacionados de tal maneira que se algum deles sofrer alteração, pelo menos outro fator será afetado. Podemos exemplificar da seguinte forma: caso o tempo previsto no cronograma seja reduzido, o orçamento poderá sofrer ajustes para incluir recursos adicionais visando realizar a mesma quantidade de trabalho em menos tempo; mas se o orçamento não puder ser aumentado, o escopo ou a qualidade podem ser afetados para que o produto seja entregue em menos tempo, com o mesmo orçamento.

Fatores determinantes na qualidade de um projeto de software.

Dentre estes fatores que potencialmente geram conflitos, os gerentes de projetos, normalmente, lidam com mais frequência com três deles: escopo, prazo e custo (Figura 6), porque a qualidade do projeto é afetada diretamente pelo balanceamento desses três fatores. Qualquer modificação que possa ocorrer em qualquer desses fatores, afetará pelo menos outro fator e, consequentemente, afetará diretamente a qualidade do projeto.

Estas três restrições constituem o ponto crucial do gerenciamento de projetos, concentrando toda energia e atenção do gerente de projetos. Para ajudar o gerente a controlar, por exemplo, a restrição de tempo, cronogramas e prazos são desenvolvidas por meio de ferramentas como gráficos PERT CPM e Gantt. No que diz respeito à restrição de custo, são estabelecidos orçamentos a serem respeitados pelo uso de gráficos, por exemplo, o histograma de recursos. A restrição mais difícil de gerenciar é a relacionada ao escopo e às especificações do projeto, uma vez que, geralmente, existe uma grande dificuldade em apresentá-los de uma forma clara, além de como monitorá-los.

sexta-feira, 17 de julho de 2020

O Projeto e o Gerente de Projetos

De acordo com o guia PMBoK do PMI (2013, p. 3), um projeto “é um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo”.

“A natureza temporária dos projetos indica que eles têm um início e um término definidos. O término é alcançado quando os objetivos do projeto são atingidos ou quando o projeto é encerrado porque os seus objetivos não serão ou não podem ser alcançados, ou quando a necessidade do projeto deixar de existir. Um projeto também poderá ser encerrado se o cliente (cliente, patrocinador ou financiador) desejar encerrá-lo. Temporário não significa necessariamente de curta duração. O termo se refere ao engajamento do projeto e à sua longevidade. O termo temporário normalmente não se aplica ao produto, serviço ou resultado criado pelo projeto; a maioria dos projetos é empreendida para criar um resultado duradouro. Por exemplo, um projeto de construção de um monumento nacional criará um resultado que deverá durar séculos. Os projetos também podem ter impactos sociais, econômicos e ambientais que terão duração mais longa que os projetos propriamente ditos.”

Fonte: (PMI, 2013; p. 3).

Tirinha

Um projeto, de maneira geral, apresenta as seguintes características:

  • Temporário: não significa que seja sempre de curta duração, mas que tem uma data de início e uma data de término;
  • Único: cada projeto é exclusivo, pois mesmo que se implante o mesmo projeto em diferentes organizações, cada organização tem suas particularidades que devem estar contempladas no projeto, o que torna cada projeto único; e
  • Progressivo: o detalhamento do projeto é feito ao longo de seu desenvolvimento, de forma progressiva.

Para que uma empresa desenvolva a capacidade de gerenciar projetos de software de forma eficiente, é importante que seja definido um procedimento padronizado visando obter uma estrutura de governança de TI apropriada, planejamento adequado de projetos, alinhamento com a estratégia, integração de processos, trabalho em equipe, métricas de desempenho (KPIs - Key Performance Indicator), processos de controle, melhoria contínua, priorização de projetos, competências no gerenciamento de projetos e alocação eficiente de recursos.

Qualquer equipe de trabalho necessita de um líder e o mesmo ocorre com uma equipe de projetos e, neste caso, chamamos este líder de Gerente de Projetos.

Este profissional tem a responsabilidade de planejar e controlar a execução do projeto e deve possuir algumas características fundamentais, como:

  • Conhecimento coerente com a necessidade do projeto;
  • Experiência estratégica;
  • Liderança;
  • Especialização na área do projeto, para tomar boas decisões;
  • Competência interpessoal;
  • Gestão de pessoas; e
  • Realizações que comprovam suas habilidades gerenciais.

Entre as várias responsabilidades deste profissional, destacam-se:

  • Identificar as necessidades do projeto;
  • Estabelecer os objetivos claramente;
  • Atender as expectativas das partes interessadas no projeto (stakeholders); e
  • Assegurar a qualidade do projeto, balanceando os principais fatores conflitantes do projeto: Escopo, Prazo e Custo.

Além destas habilidades nas práticas de gerenciamento de projetos e a capacidade de aplicação adequada das ferramentas e técnicas de gerenciamento, este profissional deve possuir características pessoais que completam o perfil desejado para uma boa gestão de um projeto: líder do grupo, comunicador, influenciador, negociador, organizado, motivador, solucionador de problemas, gerenciador de conflitos, facilitador e seguro nas decisões.

Vale ressaltar que o envolvimento da alta administração da empresa na construção de uma estrutura de projetos garante o desenvolvimento das atividades do Gerente de Projetos de forma mais natural, reduzindo conflitos e aumentando a coesão da equipe de projetos.

O Gerente de projetos deve utilizar suas habilidades no gerenciamento e tentar controlar as variáveis de tempo, custo, qualidade, risco e escopo, fatores determinantes para o sucesso de um projeto.

quinta-feira, 16 de julho de 2020

Introdução ao Gerenciamento de Projetos de Software

A gestão de projetos é uma das áreas mais importantes de qualquer departamento de TI e, atualmente, é amplamente difundida dentro das empresas, pois o uso de novos métodos de controle e gestão de projetos permite garantir os melhores resultados neste processo.

O conjunto de conhecimentos em gestão de projetos é a soma dos conhecimentos ligados à profissão de gerenciamento de projetos que inclui práticas comprovadas e inovadoras que surgem na profissão.

O Chaos Report, do Standish Group, mostra as taxas de sucesso e falhas dos projetos por meio de pesquisas em várias empresas. Essa pesquisa classifica o resultado de cada projeto de TI em uma destas três situações:

  • Sucesso (Successful): projetos dentro do prazo, custo e escopo;
  • Mudaram (Challenged): projetos fora do prazo, aumento do custo original ou mudança de escopo; e
  • Falharam (Failed): projetos cancelados.

O Quadro 1 mostra os resultados das pesquisas relatadas no Chaos Report de 2015 pelo Standish Group, mostrando o desempenho em projetos de tamanhos diferentes.

Quadro 1 – Estatísticas de desempenho em projetos de software em 2015 – Chaos Report.
CHAOS RESOLUTION BY PROJECT SIZE
  SUCCESSFUL CHALLENGED FAILED
Grand 2% 7% 17%
Large 6% 17% 24%
Medium 9% 26% 31%
Moderate 21% 32% 17%
Small 62% 16% 11%
TOTAL 100% 100% 100%
The resolution of all software projects by size from FY2011-2015 within the new CHAOS database. Fonte:(HASTIE; WOJEWODA, 2015).

Com a ascensão dos métodos ágeis de desenvolvimento, o Chaos Report de 2015, de acordo com Hastie; Wojewoda (2015), também forneceu um comparativo entre projetos baseados em metodologias tradicionais (indicado pelo método em cascata ou waterfall) e metodologias ágeis (agile), conforme mostra o Quadro 2.

Quadro 2 – Estatísticas de desempenho em projetos de software em 2015 – Chaos Report.
CHAOS RESOLUTION BY AGILE VERSUS WATERFALL
SIZE METHOD SUCCESSFUL CHALLENGED FAILED
All Size Projects Agile 39% 52% 9%
Waterfall 11% 60% 29%
         
Large Size Projects Agile 18% 59% 23%
Waterfall 3% 55% 42%
Medium Size Projects Agile 27% 62% 11%
Waterfall 7% 68% 25%
Small Size Projects Agile 58% 38% 4%
Waterfall 44% 45% 11%
The resolution of all software projects from FY2011-2015 within the new CHAOS database, segmented by the agile process and waterfall method. The total number of software projects is over 10.000. Fonte:(HASTIE; WOJEWODA, 2015).

Durante o processo de gerenciamento de projetos, algumas tarefas importantes devem ser executadas para que tenhamos sucesso, como planejamento e organização do trabalho, estimativa de recursos, controle da execução do projeto e análise dos resultados, entre outras.

Como já dissemos, uma das mais conhecidas publicações de melhores práticas em gerenciamento de projetos é o PMBoK, no qual se identifica um subconjunto do conjunto de conhecimentos em gerenciamento de projetos, que é reconhecido como boa prática. Esse guia fornece um vocabulário comum para se discutir, escrever e aplicar o gerenciamento de projetos possibilitando a troca eficiente de informações entre os profissionais de gerenciamento de projetos.

O PMBoK baseia-se em processos e atividades para descrever o trabalho a ser feito, de uma forma organizada, e esses processos se relacionam e interagem durante todo o projeto. O guia na sua 5ª edição contém 47 processos agrupados em 5 grupos de processos e 10 áreas de conhecimento e é reconhecidamente um padrão para a função de gerenciamento de projetos descrevendo normas, métodos, processos e melhores práticas.

Embora o PMBoK seja um guia composto por boas práticas, não precisamos aplicar todos os processos nele mencionados em todo o projeto. Na verdade, devemos verificar quais os processos que melhor se encaixam em nosso projeto.

quarta-feira, 15 de julho de 2020

Histórico do Gerenciamento de Projetos

De acordo com Pressman (2010), o gerenciamento de projetos surgiu nos Estados Unidos e Henry Gantt é considerado o pioneiro na gestão de projetos. Henry Gantt criou um método usando um gráfico de barras muito simples como instrumento de gerência do projeto, mas, atualmente, já foram incorporados novos elementos, como linhas para destacar dependências entre atividades, conforme mostrado na Figura.

O projeto da construção da represa Hoover, nos Estados Unidos, entre 1930 e 1936, foi desenvolvido utilizando-se os gráficos criados por Henry Gantt. Até meados dos anos 1950, o controle dos projetos era feito usando os gráficos de Gantt. Após esse período, dois novos modelos foram desenvolvidos:
  • PERT : desenvolvido como parte do programa do míssil do submarino Polaris da marinha norte-americana; e

Submarino Polaris 

  • CPM : desenvolvido em conjunto pelas empresas DuPont e Remington.
 
Esses dois modelos fizeram muito sucesso e rapidamente foram usados por muitas empresas no controle de seus projetos.

Mas o processo de melhoria das técnicas de gestão de projetos não parou por aí e, no fim da década de 1960, o PMI , fundado nos Estados Unidos em 1969, no auge dos projetos espaciais da NASA, começou o planejamento de um novo método de gerenciamento. O objetivo era desenvolver uma metodologia mais abrangente e que deveria servir aos interesses dos mais diferentes tipos de empresas.

No início dos anos 1980, o PMI iniciou o desenvolvimento de um guia de melhores práticas na gestão de projetos: o PMBoK – Project Management Body of Knowledge. O PMBoK procura fornecer um conjunto de termos comuns dentro da profissão de gerenciamento de projetos, por isso, não é considerada uma metodologia e sim, um guia de melhores práticas. Sua aceitação foi tão abrangente nas organizações que explicam a venda de mais de 3,5 milhões de cópias do guia de todas as edições lançadas.

O guia PMBoK encontra-se em sua 5ª edição que substituiu a 4ª edição, em 2013.

Capas da 4ª e 5ª edições do PMBoK (versão brasileira).

terça-feira, 14 de julho de 2020

Rede de Atividades: PERT e CPM

As redes de atividades foram desenvolvidas para superar a limitação primária do gráfico de Gantt, que é a inabilidade de retratar claramente os relacionamentos, dependências e restrições entre as atividades e eventos de um projeto.

A primeira técnica desenvolvida de cronogramação utilizando redes foi o PERT – Program Evaluation and Review Technique. PERT permite que gerentes visualizem o projeto inteiro, identifiquem inter-relacionamentos e dependências entre atividades e reconheçam quando e onde atrasos são aceitáveis.

Um dos aspectos chave dessa rede é o uso de técnicas probabilísticas para desenvolver um conjunto de estimativas de tempo para cada atividade, tornando-a particularmente adequada para projetos em que é difícil fazer estimativas acuradas com alta precisão.

Paralelamente ao desenvolvimento das redes PERT, a indústria de construção desenvolveu outro sistema de cronogramação utilizando redes baseado no conceito de caminho crítico. O caminho crítico de um projeto é o caminho ao longo das atividades da rede que consome mais tempo até a conclusão do projeto. Esta abordagem foi denominada Método do Caminho Crítico ou CPM – Critical Path Method.

De uma forma geral, as redes de atividades citadas são representações gráficas das atividades de um projeto, nas quais é apresentada a sequência lógica de planejamento, com as interdependências entre as atividades, que têm por finalidade atingir um objetivo: a conclusão do projeto.

Para o planejamento de uma rede de atividades, você terá que:

  • identificar as atividades;
  • identificar a ordem em que essas atividades ocorrem; e
  • determinar a duração das atividades.

A figura apresenta alguns tipos de atividades que podem ser usadas nos diagramas.

Tipos de atividades

 

O tempo de execução da rede pode ser obtido conforme mostrado na figura.

Cálculo do tempo de execução da rede de atividades

Para redes complexas, podemos definir cedo do evento, tarde do evento, folga do evento e caminho crítico. Os diagramas mostrados na figura exemplificam cada um desses termos.

Definição e exemplos de Cedo, Tarde, Folga do evento e Caminho Crítico

As redes de atividades fornecem ao gerente uma importante ferramenta para cronogramar e controlar seus projetos. Em geral, permitem a representação gráfica das atividades e seus relacionamentos em um projeto e também fornecem a base para determinar o caminho crítico do projeto e identificar possíveis realocações de recursos de modo a resolver problemas.

Através do uso de uma ferramenta de software adequada, você poderá atualizar e retrabalhar, caso necessário, essas redes, tendo informação do status e controle sobre as atividades e cronograma do projeto.

É interessante comentar que há várias outras possibilidades de representações gráficas para redes de atividades além daquelas apresentadas aqui. A despeito de sua grande utilidade, há limitações no uso das redes de atividades. O valor de uma rede de atividades estará diretamente dependente da validade das estimativas de tempo feitas para cada atividade. Além disso, às vezes é difícil retratar acuradamente todas as atividades e relacionamentos, especialmente em projetos grandes e complexos.

Por fim, uma vez desenvolvida uma rede de atividades detalhada, ela tende a ser o foco da atenção dos gerentes, quando, na verdade, haverá vários outros fatores não retratados na rede que precisarão de especial atenção no processo de gerenciamento. Portanto, caso você venha a gerenciar um projeto, tenha o cuidado para não cair nesse erro.

segunda-feira, 13 de julho de 2020

Gráfico de Gantt

Vamos recapitular: uma vez que você tenha determinado o conjunto de tarefas a serem executadas, você terá que atribuir valores específicos de esforço e duração para cada uma delas. A seguir, uma rede de tarefas deverá ser criada de modo a permitir que a equipe de software satisfaça a data de entrega estabelecida.

Um cronograma adequado exige que:

  • todas as tarefas figurem na rede;
  • o esforço e duração sejam adequadamente atribuídos a cada tarefa;
  • as interdependências entre as tarefas sejam indicadas;
  • recursos (humanos e materiais) sejam alocados ao trabalho a ser feito; e
  • marcos de referência pouco espaçados sejam estabelecidos de modo que o progresso possa ser acompanhado.

Para auxiliar na elaboração do cronograma de um projeto, você pode fazer uso, dentre outras opções, do gráfico de Gantt (ou diagrama de barras) e redes de atividades. De uma maneira simplificada, podemos dizer que:

  • O gráfico de Gantt pode mostrar para quando está programado o início e término de cada atividade (tarefa), quem são os responsáveis por elas, os vínculos entre essas atividades, o andamento de cada uma (em relação ao que já foi realizado até determinado momento), além de ser possível relacionar os recursos materiais necessários a cada uma delas. Seu mérito está na simplicidade.
  • As redes de atividades mostram a duração de cada atividade e a dependência temporal entre elas.

A figura ilustra o exemplo de um gráfico de Gantt.

Gráfico de Gantt

 

Fonte: <euax>.

Há vários softwares que facilitam a criação de gráficos de Gantt. Um dos mais conhecidos é o MS Project. Nele, quando uma tarefa é introduzida, ela é programada para começar na data de início do projeto. Ou seja, no momento que você entra com as tarefas, a data de início de cada uma delas é, por padrão, a data estabelecida para o início do projeto. Estabelecendo a duração de cada tarefa e vinculando-as, você estabelece uma dependência que determina a sequência de execução das tarefas. Assim, o Project agenda as tarefas definindo as datas de início e de término de cada tarefa. As barras de Gantt são, então, movidas para as datas apropriadas na escala de tempo, e linhas de vínculo são desenhadas para mostrar a dependência, conforme se pode ver na figura.

domingo, 12 de julho de 2020

Exemplo de uma Análise do Valor Agregado

Problema:

Considere que você é um gerente de projeto de software e que lhe foi solicitado calcular estatísticas de valor agregado para um pequeno projeto de software. O projeto tem 60 tarefas de trabalho planejadas, para as quais foram estimadas 648 pessoas-dia para sua finalização.

Na ocasião em que a análise do valor agregado lhe é solicitada, 10 tarefas já foram completadas. Todavia, o cronograma do projeto indica que 14 tarefas deveriam ter sido completadas.

Cronograma do projeto a ser desenvolvido
Tarefa Esforço Planejado Esforço Real
1 14.0 14.5
2 13.0 9.0
3 14.0 18.0
4 6.0 7.5
5 10.5 10.0
6 15.0 16.0
7 9.0 9.0
8 6.0 6.5
9 13.0 11.0
10 5.0 5.5
11 4.0 -
12 15.0 -
13 17.0 -
14 5.0 -

É solicitado que você calcule:

  1. Índice de Desempenho do Cronograma (SPI).
  2. Variância do Cronograma (SV).
  3. Porcentagem Programada para Conclusão.
  4. Porcentagem Completada.
  5. Índice de Desempenho do Custo (CPI).
  6. Variância do Custo (CV).

Solução:

Antes de começarmos, temos que obter os valores de BCWS, BCWP, ACWP e BAC que são os parâmetros básicos através dos quais os outros parâmetros são calculados.

Lembrando que o valor de BCWS é a soma dos BCWSi de todas as tarefas de trabalho que deveriam ter sido completadas até aquele momento no cronograma do projeto, teremos que somar os esforços planejados das tarefas 1 até a tarefa 14, que deveriam ser as tarefas finalizadas no momento da análise do projeto.

BCWS = 14 + 13 + 14 + 6 + 10,5 + 15 + 9 + 6 + 13 + 5 + 4 + 15 + 17 + 5

= 146.5 PD

Agora vamos calcular o valor de BCWP, que é a soma dos valores BCWS de todas as tarefas que foram efetivamente completadas em um determinado momento do cronograma, ou seja, temos que somar os valores de esforços planejados das tarefas 1 a 10:

BCWP = 14 + 13 + 14 + 6 + 10,5 + 15 + 9 + 6 + 13 + 5

= 105.5 PD

A seguir, obtemos o valor de ACWP, ou seja, a soma do esforço realmente despendido nas tarefas de trabalho que foram completadas em certo momento do cronograma do projeto. Nesse caso, temos que somar o esforço real gasto nas tarefas completadas (tarefas de 1 a 10):

ACWP = 14.5 + 9 + 18 + 7.5 + 10 + 16 + 9 + 6.5 + 11 + 5.5

= 107 PD

O BAC, que é a soma dos valores de todas as tarefas de trabalho programadas, foi fornecido no enunciado do exemplo:

BAC = 648 PD


De posse desses valores, podemos então calcular os parâmetros solicitados.

  1. Índice de Desempenho do Cronograma (SPI)

SPI = BCWP / BCWS = 105.5 / 146.5 = 0.72

Lembrando que quanto mais o SPI estiver próximo de 1, maior será a eficiência com a qual o projeto está utilizando os recursos cronogramados.

  1. Variância do Cronograma (SV)

SV = |BCWP – BCWS|= |105.5 – 146.5| = 41 PD

Quanto mais próximo de zero estiver SV mais próximo do planejado estará o andamento (ou custo) do projeto.

  1. Porcentagem Programada para Conclusão

BCWS / BAC = 146.5 / 648 = 0.2261 = 22.61%

Fornece uma indicação da porcentagem do trabalho que deveria ter sido completada no tempo t.

  1. Porcentagem Completada

BCWP / BAC = 105.5 / 648 = 0.1628 = 16.28%

Fornece uma indicação da porcentagem de conclusão do projeto em um determinado momento t.

Note que comparando a Porcentagem Programada com a Porcentagem Completada, calculadas há pouco, vemos que o projeto está atrasado.

  1. Índice de Desempenho do Custo (CPI)

CPI = BCWP / ACWP = 105.5 / 107 = 0.9860

CPI próximo de 1 indica de que o projeto está dentro do orçamento definido.

  1. Variância do Custo (CV)

CV = |BCWP – ACWP| = |105.5 – 107| = 1.5

Indicação absoluta das economias num custo (em relação aos custos planejados) ou dos excessos do custo (para um tempo qualquer)).

sábado, 11 de julho de 2020

EVA – Earned Value Analysis

A técnica EVA – Earned Value Analysis ou Análise do Valor Agregado utiliza um sistema de gerenciamento integrado que coordena o escopo, o cronograma e as metas de custo e mede objetivamente o progresso em face dessas metas. O propósito dessa técnica é fornecer aos gerentes dados mais precisos para monitorar a execução do projeto.

De acordo com Pressman e Maxim (2016, p. 772), “o valor agregado é uma medida do progresso que permite avaliar a porcentagem de conclusão de um projeto usando análise quantitativa, em vez de depender de suposições”.

Para realizar a Análise do Valor Agregado adequadamente, você terá que conhecer alguns parâmetros e seguir alguns passos, que são descritos de uma maneira simplificada a seguir.

  1. Determinar o Custo Orçado do Trabalho Cronogramado ou Budgeted Cost of Work Scheduled – BCWS: durante a atividade de estimativa, o custo ou o esforço (em pessoas-hora, pessoas-mês etc) de cada tarefa é planejado. BCWSi é o custo ou esforço planejado para a tarefa de trabalho i. Para determinar o progresso em um determinado ponto do cronograma do projeto, o valor de BCWS é a soma dos BCWSi de todas as tarefas de trabalho que deveriam ter sido completadas até aquele momento no cronograma do projeto.
  2. Calcular o valor do Custo Orçado do Trabalho Executado ou Budget Cost of Work Perfomed – BCWP: o valor de BCWP é a soma dos valores BCWS de todas as tarefas que foram efetivamente completadas em um determinado momento do cronograma.
  3. Determinar o Orçamento na Conclusão ou Budget at Completion – BAC: os valores de todas as tarefas de trabalho programadas são somados para obter o BAC, ou seja, BAC = S (BCWSk)

A distinção entre BCWS e BCWP é que o primeiro representa o orçamento das atividades que foram planejadas para estarem concluídas até um determinado momento e o último representa o orçamento das atividades que realmente foram concluídas até aquele momento.

Completados os passos anteriores, é possível calcular os seguintes indicadores:

  • Índice de Desempenho do Cronograma ou Schedule Performance Index – SPI:
  • SPI = BCWP / BCWS
  • Variância do Cronograma ou Schedule Variance – SV:
  • SV = |BCWP – BCWS|

O Índice de Desempenho do Cronograma (SPI) é uma indicação da eficiência com a qual o projeto está utilizando os recursos cronogramados. Um valor do SPI próximo de 1 indica execução eficiente do cronograma do projeto. SV é uma indicação absoluta da variância do cronograma planejado.

É possível calcular também:

  • Porcentagem programada para conclusão = BCWS / BAC (fornece uma indicação da porcentagem do trabalho que deveria ter sido completada no tempo t.)
  • Porcentagem completada = BCWP / BAC (fornece uma indicação da porcentagem de conclusão do projeto num determinado momento t)
  • Custo Real do Trabalho Realizado (Actual Cost of Work Performed – ACWP) (é a soma do esforço despendido realmente nas tarefas de trabalho que foram completadas em certo momento do cronograma do projeto)
  • Índice de Desempenho do Custo (Cost Performance Index – CPI):
    CPI = BCWP / ACWP
    (CPI próximo de 1 indica de que o projeto está dentro do orçamento definido)
  • Variância do Custo (Cost Variance – CV):
    CV = |BCWP – ACWP|
    (indicação absoluta das economias em um custo (em relação aos custos planejados) ou dos excessos do custo (para um tempo qualquer)).

sexta-feira, 10 de julho de 2020

Cronograma e Controle de Projetos

A função de controle compreende todas as atividades que um gerente de projeto pode utilizar na tentativa de garantir que o andamento atual esteja em conformidade com o planejamento desenvolvido.

Para controlar um projeto, um gerente necessita de meios para monitorar o progresso em relação ao plano estabelecido. O cronograma é utilizado como uma linha base (baseline) através da qual o progresso é medido. Se houver indícios que uma atividade está atrasada, essa informação poderá ser usada pela gerência como parâmetro para ações corretivas.

Tirinha

 

Fonte: <bytesdontbite>.

Contudo, considerar isoladamente uma informação do cronograma pode levar a interpretações errôneas. O gerenciamento adequado requer a integração de aspectos técnicos, de cronograma e de custos de um projeto. Assim, uma forma de medida de desempenho integrado é necessária para monitorar e controlar um projeto. A técnica de Análise do Valor Agregado (EVA) fornece essa capacidade.

quinta-feira, 9 de julho de 2020

Conceitos Básicos sobre Cronograma de Projeto (Project Schedule)

Em sua forma mais simples, um cronograma é uma lista de atividades e eventos organizados em função do tempo. Em sua forma mais complexa, um cronograma examina todas as atividades de um projeto e suas relações entre si em termos de restrições de tempo, orçamento e pessoas, isto é, recursos.

Cronograma de Projeto (Project Schedule)
 
Fonte: martellostudio/Shutterstock

Na execução de projetos, o cronograma é uma importante ferramenta de planejamento, controle e comunicação que, quando adequamente utilizada, suporta estimativas de tempo e custo, facilita a comunicação entre as pessoas envolvidas nas atividades do projeto e estabelece um compromisso com essas atividades.

Além disso, um cronograma é um importante elemento para atividades de gerenciamento: organização, atribuição de tarefas às pessoas envolvidas, controle e condução do projeto.

As pessoas envolvidas com cronogramas devem ter um conhecimento sólido de práticas e aplicações de cronogramação, tais como Gráfico de Gantt, redes de atividades: PERT, CPM etc. Essas pessoas devem saber não só como elaborar cronogramas detalhados, mas também devem ser capazes de compreender e analisar cronogramas criados por outros, como por exemplo, aqueles produzidos por contratados em um processo de terceirização.

De acordo com o PMI/PMBoK (2013, p. 142), o desenvolvimento do cronograma do projeto busca definir e sequenciar as atividades, estimar os recursos e as durações das atividades em combinação com uma ferramenta de cronograma para produzir o modelo do cronograma. O cronograma finalizado e aprovado é a linha de base que será usada para o controle do cronograma, que visa assegurar o término pontual do trabalho do projeto. A figura fornece uma visão geral da elaboração do cronograma.

Visão geral do desenvolvimento do cronograma

 

Fonte: PMI (2013, p. 144).

A elaboração do cronograma é um elemento crítico no processo de planejamento do projeto. Portanto, você deve estar percebendo que o cronograma é uma das mais úteis ferramentas disponibilizadas para a execução de um projeto e sua aplicação efetiva é essencial para atingir as metas estabelecidas.

quarta-feira, 8 de julho de 2020

Estratégias para Riscos Negativos ou Ameaças

Fonte: PMI/PMBoK (2013, p. 344-345).

Três estratégias que tipicamente lidam com ameaças ou riscos que podem ter impactos negativos nos objetivos do projeto, se ocorrerem, são prevenir, transferir e mitigar. A quarta estratégia, aceitar, pode ser usada tanto para riscos negativos ou ameaças quanto para riscos positivos ou oportunidades. Cada uma dessas estratégias de resposta ao risco tem uma influência variada e única na condição dos riscos. Essas estratégias devem ser escolhidas para corresponder à probabilidade e impacto do risco nos objetivos gerais do projeto. As estratégias de prevenção e mitigação são geralmente boas para riscos críticos com alto impacto, enquanto as estratégias de transferência e aceitação são geralmente boas para ameaças menos críticas e com impacto geral baixo. As quatro estratégias para riscos negativos ou ameaças são descritas a seguir em mais detalhes:

Prevenir. A prevenção de riscos é uma estratégia de resposta ao risco em que a equipe do projeto age para eliminar a ameaça ou proteger o projeto contra o seu impacto. Ela envolve a alteração do plano de gerenciamento do projeto para eliminar totalmente a ameaça. O gerente do projeto também pode isolar os objetivos do projeto do impacto do risco ou alterar o objetivo que está em perigo. Exemplos disso incluem estender o cronograma, alterar a estratégia ou reduzir o escopo. A estratégia de prevenção mais radical é a suspensão total do projeto. Alguns riscos que surgem no início do projeto podem ser evitados esclarecendo os requisitos, obtendo informações, melhorando a comunicação ou adquirindo conhecimentos especializados.

Transferir. A transferência de riscos é uma estratégia de resposta ao risco em que a equipe do projeto transfere o impacto de uma ameaça para terceiros, juntamente com a responsabilidade pela sua resposta. Transferir o risco simplesmente passa a responsabilidade de gerenciamento para outra parte, mas não o elimina. Transferir não significa negar a existência do risco através da sua transferência para um projeto futuro ou outra pessoa sem o seu conhecimento ou acordo. A transferência de riscos quase sempre envolve o pagamento de um prêmio à parte que está assumindo o risco. Transferir a responsabilidade pelo risco é mais eficaz quando se trata de exposição a riscos financeiros. As ferramentas de transferência podem ser bastante variadas e incluem, entre outras, o uso de seguros, seguros-desempenho, garantias, fianças etc. Podem ser usados contratos ou acordos para transferir a responsabilidade de determinados riscos para outra parte. Por exemplo, quando um comprador tem recursos que o vendedor não possui, pode ser prudente transferir uma parte do trabalho e o risco correspondente de volta ao comprador por meio de um contrato. Em muitos casos, o uso de um contrato de custo mais remuneração pode transferir o risco do custo para o comprador, enquanto um contrato de preço fixo pode transferir o risco para o vendedor.

Mitigar. Mitigação de riscos é uma estratégia de resposta ao risco em que a equipe do projeto age para reduzir a probabilidade de ocorrência, ou impacto do risco. Ela implica [sic] na redução da probabilidade e/ou do impacto de um evento de risco adverso para dentro de limites aceitáveis. Adotar uma ação antecipada para reduzir a probabilidade e/ou o impacto de um risco ocorrer no projeto em geral é mais eficaz do que tentar reparar o dano depois de o risco ter ocorrido. Adotar processos menos complexos, fazer mais testes ou escolher um fornecedor mais estável são exemplos de ações de mitigação. A mitigação pode exigir o desenvolvimento de um protótipo para reduzir o risco de implementação de um processo ou produto a partir de um modelo de bancada. Quando não é possível reduzir a probabilidade, a resposta de mitigação pode abordar o impacto do risco concentrando em fatores que determinam sua gravidade. Por exemplo, a inclusão de redundância em um sistema pode reduzir o impacto de uma falha do componente original.

Aceitar. A aceitação de risco é uma estratégia de resposta pela qual a equipe do projeto decide reconhecer a existência do risco e não agir, a menos que o risco ocorra. Essa estratégia é adotada quando não é possível ou econômico abordar um risco específico de qualquer outra forma. Essa estratégia indica que a equipe do projeto decidiu não alterar o plano de gerenciamento do projeto para lidar com um risco, ou não conseguiu identificar outra estratégia de resposta adequada. Essa estratégia pode ser passiva ou ativa. A aceitação passiva não requer qualquer ação exceto documentar a estratégia, deixando que a equipe do projeto trate dos riscos quando eles ocorrerem, e revisar periodicamente a ameaça para assegurar que ela não mude de forma significativa. A estratégia de aceitação ativa mais comum é estabelecer uma reserva para contingências, incluindo tempo, dinheiro ou recursos para lidar com os riscos.

terça-feira, 7 de julho de 2020

Mitigação, Monitoramento e Gerenciamento do Risco ou Risk Mitigation, Monitoring and Management – RMMM

Todas as atividades de análise de risco têm uma única meta: ajudar a equipe de projeto a desenvolver uma estratégia para lidar com o risco.

De acordo com Pressman e Maxim (2016, p. 788), uma estratégia efetiva para lidar com risco deve considerar três pontos: Mitigação, Monitoramento e Gerenciamento do Risco. Isso é conhecido como RMMM –Risk Mitigation, Monitoring and Management, ou seja:

  • Mitigation: busca evitar o risco ou os problemas que levam ao risco. Elabora um plano para mitigação de risco.
  • Monitoring: busca fazer um acompanhamento do projeto e monitorar os riscos. Monitora fatores que podem tornar o risco mais ou menos provável. Monitora também passos elaborados no plano para mitigação de risco.
  • Management: busca gerenciar os riscos e planejar para a contingência ao ocorrerem. Considera que o risco tornou-se realidade. Elabora um Plano de Contingência.

Exemplo de aplicação do RMMM

Considere o seguinte fator de risco: Rotatividade de pessoal, que tem probabilidade de 70% de ocorrer e impacto crítico. Em relação a esse risco, podemos seguir os três pontos RMMM conforme apresentado a seguir.

  • Mitigação: é preciso desenvolver uma abordagem proativa ao risco, desenvolvendo uma estratégia para reduzir a rotatividade. Entre as providências para a mitigação do risco, estão:
    • fazer reuniões com a equipe para determinar as causas da rotatividade (como más condições de trabalho, baixos salários, mercado de trabalho competitivo etc);
    • mitigar as causas que estão sob o controle da organização antes do início do projeto;
    • desenvolver estratégias que garantam a continuidade do projeto caso alguma pessoa saia da equipe;
    • buscar difundir as informações sobre as atividades de desenvolvimento entre as equipes de projeto (ou entre as pessoas da equipe) de forma mais ampla;
    • definir padrões de documentação para os produtos do projeto e estabelecer mecanismos para assegurar que todos os modelos e documentos sejam desenvolvidos a tempo;
    • realizar revisões em pares de todo o trabalho; e
    • designar um substituto para cada profissional cujo trabalho seja crítico.
  • Monitoramento: o gerente de projeto deve monitorar:
    • fatores que possam indicar se o risco está se tornando mais ou menos possível, como: grau de coesão da equipe, relações pessoais, atitude geral mediante pressões do projeto, potenciais problemas com remuneração e benefícios, oferta de empregos; e
    • a efetividade das providências indicadas para mitigar o risco, como verificar se os documentos, padrões e modelos estão sendo criados, para assegurar que sejam autossuficientes (para ser usado por um novato, por exemplo, caso seja necessário).
  • Gerenciamento: nesta etapa, entra em ação a gestão de riscos e o plano de contingência, pois os esforços de mitigação do risco falharam e o risco se tornou realidade, ou seja, uma ou mais pessoas avisam que irão se desligar do projeto. Caso a estratégia de mitigação tenha sido colocada em prática, existem substitutos indicados, há informações documentadas e o conhecimento está compartilhado na equipe. Algumas atitudes podem ser tomadas, como:
    • mudar o foco de utilização dos recursos;
    • reajustar o cronograma; e
    • trabalhar junto aos membros que estão deixando a equipe para que seu conhecimento possa ser transferido (captação de vídeos, criação de documentos do tipo wiki, reuniões com membros da equipe etc.).

As atividades de mitigação, monitoramento e gerenciamento de risco (RMMM) implicam custos adicionais ao projeto. Por exemplo, gastar tempo na busca de um substituto para cada técnico essencial custa dinheiro. Devido a isso, o planejador do projeto deve efetuar uma análise custo/benefício. Se as providências para mitigar o risco de alta rotatividade aumentarem o custo e a duração do projeto em uma estimativa de 15%, por exemplo, mas o fator de custo predominante for o de substituir o profissional, o gerente pode optar por não substituí-lo. Por outro lado, se a estimativa for de 3 a 5%, esta providência pode ser tomada.