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

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.

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.

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.

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

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

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

5. Í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.

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