Gerenciamento de projetos e seu ciclo de vida

Cada fase do projeto consiste em uma etapa de seu ciclo de vida que pode ser seqüencial ou as
vezes sobreposta a outra fase cujo o número de fases é determinado pelas necessidades de
gerenciamento e controle da organização envolvida, e da natureza do projeto e sua área de atuação.
Uma metodologia pode ser utilizada para documentar o ciclo de vida. Todo o projeto tem um início
e um fim definidos, as entregas e atividades especificas nesse ínterim poderão variar muito de
acordo com o projeto. O ciclo de vida oferece uma estrutura básica para o gerenciamento do
projeto, independentemente do trabalho especifico envolvido.

Características do ciclo de vida do projeto

Independente do tamanho ou complexidade dos projetos, eles podem ser mapeados para a
estrutura de ciclo de vida a seguir:

• Inicio do projeto;
• Organização e preparação;
• Execução do trabalho do projeto e
• Encerramento do projeto.

Esta estrutura é freqüentemente utilizada para demonstração para a alta administração ou outras
entidades menos familiarizadas com os detalhes do projeto.
As características da estrutura genérica do ciclo de vida descritas pela metodologia PMI são
as seguintes:

• Inicialmente os custos de pessoal são baixos, atingindo o ápice enquanto o

projeto é executado e caem rapidamente conforme o projeto é finalizado.
• No inicio do projeto os riscos, as incertezas e a influência das partes interessadas
são maiores, caindo ao longo do tempo.
• A capacidade de influenciar as características finais do produto do projeto, sem
impacto significativo sobre os custos, é mais alta no inicio e torna-se cada vez
menor conforme o projeto progride para seu término.

Relação entre o ciclo de vida do projeto e do produto

O ciclo de vida do produto compreende em fases do produto. Essas fases são geralmente
seqüenciais e não sobrepostas, cuja determinação é dada de acordo com a necessidade de produção
e de controle da organização. O ciclo de vida do projeto geralmente esta contido em um ou mais
ciclo de vida do produto. Quando o objetivo do projeto é um serviço ou resultado, pode-se definir
um ciclo de vida para um serviço ou resultado e não um ciclo de vida de um produto. A última fase
do ciclo de vida do produto geralmente é a retirada do produto de circulação.

Se a saída do projeto for um produto, o desenvolvimento do produto pode ser um projeto, bem
como, um produto existente pode se beneficiar de um projeto para melhorias em suas funções ou
características ou até mesmo a criação de um novo modelo. Aspectos do ciclo de vida do produto
tais como, a realização de um estudo de viabilidade, a condução de pesquisas de mercado, a
execução de campanhas publicitárias, etc. prestam-se à execução como projetos. Nesses casos o
ciclo de vida do projeto difere-se do ciclo de vida do produto. Deste modo vemos que um produto
pode ter muitos projetos associados a ele. A administração e/ou supervisão dos projetos associados
ao produto por uma única autoridade superior pode aumentar significativamente a probabilidade de
sucesso.

Fases do projeto

As fases dos projetos são as etapas impostas pelo gerente do projeto para controlar de forma
eficiente o término de uma entrega importante. As fases podem ser seqüenciais ou sobrepostas, mas
geralmente são seqüenciais. A segmentação do projeto em fases permite que o projeto seja
subdividido logicamente a fim de facilitar o gerenciamento, planejamento e controle. A
determinação do número de fases do projeto depende do seu tamanho, grau de complexidade e
impacto potencial.

De acordo com a metodologia PMI, as fases do projeto possuem características semelhantes:

• Em projetos seqüenciais, o término de uma fase representa o ponto natural de

reavaliação dos esforços em andamento e representa a entrega do produto ou
trabalho produzido como entrega da fase;

• O foco do trabalho de uma fase é diferente de qualquer outra, envolvendo

diferentes organizações e conjunto de habilidades;

• Os projetos podem ter fases com mesmo nome ou fases similares com entregas
similares, porém, poucos são idênticos. Devido a heterogeneidade dos projetos
alguns apresentam somente uma fase outros apresentam várias fases. Cada fase
tem sua complexidade, custo e duração distintos. A Figura 2.3 ilustra um projeto
de fase única.
Governança do projeto

Para o (PMBOK, 2009) a governança de projetos consiste em determinar o método mais

apropriado de execução do projeto. Essa determinação é feita pelo gerente de projetos em conjunto
com a equipe de gerenciamento. Assim as decisões de quais recursos serão necessários, quais
pessoas serão envolvidas e qual a abordagem geral adotada para o término do trabalho devem ser
tomadas pela equipe de gerenciamento. Também deve ser decidido o número de fases do projeto e
como será a sua estrutura.

"A estrutura de fases propicia uma base formal para o controle. Cada fase é formalmente iniciada
para especificar o que é permitido e esperado dela. Uma análise do gerenciamento costuma ser
feita para se chegar a uma decisão sobre o início das atividades de uma fase. Isso se aplica em
especial quando uma fase anterior ainda não foi concluída. Um exemplo seria quando uma
organização opta por um ciclo de vida em que mais de uma fase do projeto avança
simultaneamente. O início de uma fase é também o momento de revalidar antigas premissas,
analisar riscos e definir mais detalhadamente os processos necessários para realizar a(s)
entrega(s) da fase. Por exemplo, se uma fase específica não exigir a compra de novos materiais ou
equipamentos, não será necessário executar as atividades ou processos de aquisição."
(PMI,2009,p.25)

Como podemos ver a determinação da estrutura é importante para determinar os pontos de entrega
do trabalho que são marcos naturais para se reavaliar os riscos, detectar e corrigir erros de forma
eficaz. Se em uma entrega de fase, ou até mesmo durante a fase, for detectado que o risco é grande
demais para a continuação do projeto a fase poderá ser encerrada e a subsequente não será sequer
iniciada.

Fases do projeto e suas relações

Em projetos com mais de uma fase, geralmente as fases são dispostas sequencialmente, ou seja,
uma fase começa após o término da anterior. Porém, existem situações em que o projeto pode se
beneficiar relacionando as fases de maneira não sequencial. Conforme descrito pela metodologia
PMI em seu guia PMBOK nos casos em que as fases não são sequenciais elas podem ser:

• Relação sobreposta: uma fase tem início antes do término da anterior.

Esse tipo de abordagem pode aumentar os riscos e resultar em
retrabalho caso uma fase subsequente progrida antes que informações
precisas sejam disponibilizadas pela fase anterior.

• Relação iterativa: neste caso apenas uma fase está planejada a

qualquer momento. O planejamento da fase seguinte é feito de acordo
com o andamento da fase atual e na entrega de cada fase. Esta
abordagem reduz a capacidade de planejamento em longo prazo, mas
 é útil em ambientes de rápida transformação ou indefinidos.

Durante o ciclo de vida do projeto pode ocorrer várias relações entre fases dependendo do nível de
controle necessário, eficácia e o grau de incertezas.

Relação entre projetos e trabalho operacional

O trabalho operacional se difere dos projetos principalmente por que o trabalho operacional
(operações) é contínuo nas instituições e produzem produtos, serviços ou resultados repetitivos. Já
os projetos são temporários e terminam. O trabalho operacional apóia os planos estratégicos da
organização, acompanhando as novas direções estabelecidas pela organização. Diferente dos
projetos que terminam quando seus objetivos são atingidos.

O gerente de projeto trabalha juntamente com os gerentes operacionais para desenvolver um

projeto e com os diversos colaboradores dos departamentos a fim de atingir os objetivos do projeto.
Um exemplo disso é quando um projeto é criado para reprojetar um produto. O gerente de projetos
pode trabalhar com vários gerentes operacionais para pesquisar as preferências do consumidor,
redigir especificações técnicas, construir um protótipo, testá-lo e iniciar a fabricação. A equipe fará
interface com os departamentos operacionais para determinar a capacidade de fabricação dos
equipamentos atuais ou para determinar o momento mais adequado da transição das linhas de
produção para a fabricação do novo produto.

De acordo com o PMBOK (2009) a integração entre as equipes de projeto e operacional pode
contribuir para a modificação das operações existentes. Isso acontece porque o departamento de
operações entregará os serviços ou resultados do projeto em práticas futuras.

Partes Interessadas

Todas as entidades envolvidas no projeto, sejam elas pessoas físicas ou jurídicas, cujos interesses
sejam afetados de alguma forma (positiva ou negativa) são partes interessadas no projeto. As partes
interessadas podem exercer alguma influência no projeto, nas entregas ou nas pessoas da equipe.
Deste modo, é necessário que a equipe de projetos faça um levantamento detalhado sobre as
expectativas das partes interessadas a fim de determinar os requisitos do projeto. Além disso, o
gerente de projetos deve coordenar as influências de todas as partes interessadas para garantir os
requisitos e obter um bom resultado.
As partes interessadas podem ter autoridades e responsabilidades diferentes no projeto o que
dificulta a função do gerente de projetos. As partes interessadas podem prejudicar o andamento e os
objetivos do projeto. Por exemplo, o reconhecimento tardio de que o departamento jurídico é uma
parte interessada significativa, que gera atrasos e aumenta as despesas, devido a requisitos legais.

As partes interessadas podem ter influência positiva ou negativa em um projeto. Algumas se

beneficiam de um projeto bem-sucedido, enquanto outras enxergam resultados negativos oriundos
do sucesso de um projeto. Por exemplo, líderes de negócios de uma comunidade que se beneficiará
de um projeto de expansão industrial através dos benefícios econômicos positivos à comunidade.
No caso das partes interessadas com expectativas positivas do projeto, seus interesses serão
atendidos da melhor forma possível se ajudarem o mesmo a ter sucesso. Os interesses das partes
interessadas negativas seriam atendidos de melhor forma se impedissem o progresso do projeto.
Negligenciar as partes interessadas negativas pode aumentar a probabilidade de falha. Uma parte
importante da responsabilidade de um gerente de projetos é gerenciar as expectativas das partes
interessadas. Isso pode ser difícil pois elas em geral têm objetivos muito diferentes ou conflitantes.
Parte da responsabilidade do gerente é balancear esses interesses e garantir que a equipe do
projeto interaja com as partes interessadas de uma maneira profissional e cooperativa. (PMI,
2009, p. 28)

De acordo com o PMBOK (2009) as partes interessadas são:

• Clientes/usuários;
• Escritório de projetos;
• Patrocinador;
• Gerentes de portfólios/comitê de análise de portfólios;
• Gerentes de programas;
• Gerentes de projetos;
• Equipe do projeto;
 • Gerentes funcionais;
• Gerenciamento de operações;
• Fornecedores/parceiros comerciais.

Ativos de processos organizacionais

Para SIQUEIRA (2010) todos os ativos relacionados a processos, de quaisquer organizações

envolvidas no projeto que podem ser usados para influenciar o sucesso do projeto, são ativos
organizacionais. Os ativos envolvem planos formais e informais, políticas, procedimentos e
diretrizes. Também são considerados ativos de processos organizacionais as bases de conhecimento
das organizações, como lições aprendidas e informações históricas, bem como cronogramas
terminados, dados sobre riscos e dados de valor agregado. Normalmente, a responsabilidade por
atualizar os ativos de processos organizacionais conforme necessário no transcorrer do projeto cabe
aos membros da equipe de projeto. A metodologia PMI agrupa os ativos de processos
organizacionais em duas categorias:

A. Processos e procedimentos

Dentre os processos e procedimentos podemos citar (PMBOK, 2009):

• Processos organizacionais padrões, como normas, políticas (por exemplo, política de

segurança e saúde, de ética e de gerenciamento de projetos), ciclos de vida padrão de
produtos e projetos, e políticas e procedimentos de qualidade (por exemplo, auditorias
de processos, metas de melhorias, listas de verificação e definições padronizadas de
processos para uso na organização);

• Diretrizes padronizadas, instruções de trabalho, critérios de avaliação de propostas e

critérios de medição de desempenho;

• Modelos (por exemplo, modelos de risco, estrutura analítica do projeto, diagrama de

rede do cronograma do projeto e contrato);

• Diretrizes e critérios para adaptação do conjunto de processos padrão da organização

de modo a satisfazer as necessidades específicas do projeto;

• Requisitos de comunicação da organização (por exemplo, tecnologia de comunicação

específica disponível, mídia de comunicação permitida, política de retenção de
registros e requisitos de segurança);
 • Diretrizes ou requisitos de encerramento do projeto (por exemplo, auditorias finais do
projeto, avaliações do projeto, validação do produto e critérios de aceitação);

• Procedimentos de controles financeiros (por exemplo, relatório de tempo, análises

obrigatórias de gastos e despesas, códigos contábeis e cláusulas contratuais padrões);

B. Base de conhecimento corporativa

Dentre as bases de conhecimento corporativa podemos citar (PMBOK, 2009):

• Bancos de dados de medição de processos usados para coletar e disponibilizar dados

de medição de processos e produtos;

• Arquivos do projeto (por exemplo, linhas de base de escopo, custo, cronograma e

qualidade, linhas de base de medição de desempenho, cronogramas de projeto,
diagramas de rede do cronograma do projeto, registros de riscos, ações de resposta
planejadas e impacto definido dos riscos);

• Bases de conhecimento de informações históricas e lições aprendidas (por exemplo,

registros e documentos de projetos, todas as informações e documentação de
encerramento dos projetos, informações sobre os resultados de decisões de seleção de
projetos anteriores e do desempenho de projetos anteriores, assim como informações
do esforço de gerenciamento de riscos);

• Bancos de dados de gerenciamento de questões e defeitos, que contêm o status dos

mesmos, informações de controle, solução de problemas e defeitos e resultados de
itens de ação;

• Bancos de dados de gerenciamento de configuração, que contêm as versões e linhas de

base de todas as normas, políticas, procedimentos e quaisquer outros documentos
oficiais de projetos da empresa e
• Bancos de dados financeiros, que contêm informações como horas de mão-de-obra,
custos incorridos, orçamentos e qualquer estouro dos custos do projeto.