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.

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).

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.

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.

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.

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.

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).